Network Working Group A. Takacs Internet-Draft B. Gero Intended status: Standards Track Ericsson Expires: January 12, 2009 D. Mohan Nortel July 11, 2008 GMPLS RSVP-TE Extensions to Control Ethernet OAM draft-takacs-ccamp-rsvp-te-eth-oam-ext-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Takacs, et al. Expires January 12, 2009 [Page 1] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Abstract The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This memo specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities for point-to-point Ethernet LSPs. Takacs, et al. Expires January 12, 2009 [Page 2] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Changes from previous version Two alternative ways to extend RSVP-TE with OAM configuration are summarised in a new appendix ("Discussion on alternatives"). The description of RSVP-TE extensions is restructured; a new section is added ("Technology Independent Extensions") to identify common technology independent extensions. Note, this part may be moved to a separate framework document leaving only the Ethernet specific extensions in this document. Some nits and typos cleared. Takacs, et al. Expires January 12, 2009 [Page 3] Internet-Draft GMPLS based Ethernet OAM Control July 2008 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 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivations and asumptions . . . . . . . . . . . . . . . . . . 6 3. Overview of Ethernet OAM operation in PBB-TE networks . . . . 8 4. Scope of the RSVP-TE extensions . . . . . . . . . . . . . . . 10 5. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 11 5.1. Operation overview . . . . . . . . . . . . . . . . . . . . 11 5.2. Technology Independent Extensions . . . . . . . . . . . . 13 5.2.1. Monitoring Disabled - Admin_Status bit . . . . . . . . 13 5.2.2. OAM entities desired -- LSP Attributes flag . . . . . 13 5.2.3. OAM Configuration TLV . . . . . . . . . . . . . . . . 14 5.3. Ethernet OAM Configuration TLV . . . . . . . . . . . . . . 15 5.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 16 5.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 16 5.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 5.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 18 5.4. Error handling . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Takacs, et al. Expires January 12, 2009 [Page 4] Internet-Draft GMPLS based Ethernet OAM Control July 2008 1. Background Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE-PBBTE] decouples the Ethernet data and control planes by explicitly supporting external control/management mechanisms to configure static filtering entries in bridges and create explicitly routed Ethernet connections. In addition PBB-TE defines mechanisms for 1:1 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-CFM]. With PBB-TE Ethernet networks will support explicitly-routed Ethernet connections. CFM can be used to track the liveliness of PBB-TE connections and detect data plane failures. In IETF the GMPLS controlled Ethernet Label Switching (GELS) [GELS-Framework] work is extending the GMPLS control plane to support the establishment of point-to-point PBB-TE data plane connections. We refer to GMPLS established PBB-TE connections as Ethernet LSPs. GELS enables the application of MPLS-TE and GMPLS provisioning and recovery features in Ethernet networks. MPLS OAM requirements are described in [RFC4377]. It provides requirements to create consistent OAM functionality for MPLS networks. The GMPLS OAM requirements are described in [GMPLS-OAM]. The GMPLS OAM requirements are based on the MPLS OAM requirements [RFC4377], in addition it also considers the existing OAM techniques in non-packet networks. This memo discusses the basic aspects of Ethernet OAM and specifies RSVP-TE extensions addressing OAM requirements for Ethernet networks. Takacs, et al. Expires January 12, 2009 [Page 5] Internet-Draft GMPLS based Ethernet OAM Control July 2008 2. Motivations and asumptions The following list is an excerpt of MPLS OAM requirements documented in [RFC4377]. Only a few requirements are discussed that bear a direct relevance to the discussion set forth in this memo and which also motivated the extensions specified in this document. Note that IETF started work on an MPLS Transport Profile (MPLS TP), which includes specification of MPLS TP OAM requirements and mechanisms. This section will be extended if new requirements are defined. o It is desired to support the automation of LSP defect detection. It is especially important in cases where large numbers of LSPs might be tested. o In particular some LSPs may require automated ingress-LSR to egress-LSR testing functionality, while others may not. o Mechanisms are required to coordinate network responses to defects. Such mechanisms may include alarm suppression, translating defect signals at technology boundaries, and synchronising defect detection times by setting appropriately bounded detection timeframes. Generally, the frequency of OAM execution must be set properly, to achieve the OAM requirements. When periodic messages are used for liveliness check of LSPs the frequency of messages must be set properly fulfilling the requirements of the service and/or meeting the detection time boundaries posed by possible congruent connectivity check operations of higher layer applications. Furthermore, for consistent measurement of Service Level Agreements (SLAs) it may be required that measurement points agree on a common probing rate to avoid measurement problems. In order for Ethernet LSPs to provide reliable service delivery, data plane fault detection mechanisms are needed to trigger recovery actions. Note that if lower layer fault detection (or protection) mechanisms (such as those supported by SONET/SDH) are available, we may rely on them and alleviate the need for frequent OAM message exchanges for liveliness checks of Ethernet LSPs. However, when - for example - Ethernet is deployed over a WDM optical layer that does not provide the SONET/SDH protection characteristics, failure detection and recovery must be solved in the Ethernet layer. We assume that in networks where PBB-TE and GELS will be deployed the default LSP path fault detection mechanism will be based on CFM Connectivity Check Message (CCM) flows. Takacs, et al. Expires January 12, 2009 [Page 6] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Fast fault detection and recovery are key to reliable service delivery. However, there is a trade-off between fast fault detection and signalling and processing overhead of connectivity monitoring flows. Today, networks are providing transport of multiple service types each with special requirements on quality of service including the requirements on recovery. To balance the tradeoff between fast detection and overhead it is essential that fault detection and recovery are matching the requirements of the supported service, as highlighted in [RFC3469]. For example, while business services may require sub-second protection switching, best effort Internet traffic may rely on slower (in the order of seconds) restoration mechanisms. These different requirements are reflected in the frequency of connectivity monitoring packets that are needed to be exchanged over the Ethernet LSP supporting a particular service type. We assume that - for a network operator to be able to balance the trade-off in fast failure detection and overhead - it will be beneficial to configure the frequency of CCM messages on a per Ethernet-LSP basis. Additionally, to simplify network management and reduce the risk (and impact) of misconfiguration, it is desirable to use Ethernet LSP signaling to configure CFM at both ends of the LSP automatically. Takacs, et al. Expires January 12, 2009 [Page 7] Internet-Draft GMPLS based Ethernet OAM Control July 2008 3. Overview of Ethernet OAM operation in PBB-TE networks For the purposes of this document, we only discuss Ethernet OAM [IEEE-CFM] aspects that are relevant for the connectivity monitoring of point-to-point PBB-TE connections. PBB-TE [IEEE-PBBTE] defines point-to-point Ethernet Switched Paths (ESPs) as a provisioned traffic engineered unidirectional connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP- VID] where the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA is the source address of the ESP, and the ESP-VID is a VLAN identifier allocated for explicitly routed connections. To form a bidirectional PBB-TE connection two co-routed point-to-point ESPs are combined. The combined ESPs must have the same ESP-MAC addresses but may have different ESP-VIDs. Note that although it would be possible to use GMPLS to setup a single unidirectional ESP, the Ethernet OAM mechanisms are only full functional when bidirectional connections are established with co- routed ESPs. Hence, we focus on bidirectional point-to-point PBB-TE connections. At both ends of the bidiretional point-to-point PBB-TE connection one Maintenance Endpoint (MEP) is configured. The MEPs monitoring a PBB-TE connection must be configured with the same Maintenance Domain 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. MEPs exchange Connectivity Check Messages (CCMs) periodically with fixed intervals. Eight distinct intervals are defined in [IEEE-CFM]: Takacs, et al. Expires January 12, 2009 [Page 8] Internet-Draft GMPLS based Ethernet OAM Control July 2008 +---+--------------------+----------------+ | # | CCM Interval (CCI) | 3 bit encoding | +---+--------------------+----------------+ | 0 | Invalid | 000 | | | | | | 1 | 3 1/3 ms | 001 | | | | | | 2 | 10 ms | 010 | | | | | | 3 | 100 ms | 011 | | | | | | 4 | 1 s | 100 | | | | | | 5 | 10 s | 101 | | | | | | 6 | 1 min | 110 | | | | | | 7 | 10 min | 111 | +---+--------------------+----------------+ Table 1: CCM Interval encoding If 3 consecutive CCM messages are not received by one of the MEPs it declares a connectivity failure and signals the failure in subsequent CCM messages, by setting the Remote Defect Indicator (RDI) bit, to the remote MEP. If a MEP receives a CCM message with RDI set it immediately declares failure. The detection of a failure may trigger protection switching mechanisms or may be signalled to a management system. However, what happens once a failure is detected is out of the scope of this document. Takacs, et al. Expires January 12, 2009 [Page 9] Internet-Draft GMPLS based Ethernet OAM Control July 2008 4. Scope of the RSVP-TE extensions Although the setup of both unidirectional and bidirectional Ethernet LSPs is feasible, due to the symmetric bidirectional connectivity requirement of CFM, we only consider bidirectional point-to-point Ethernet LSPs. The applicability for multipoint Ethernet LSPs is for further study. Note that in addition to Connectivity Check, which is the focus of this document, CFM defines Link Trace and Loopback mechanisms as well. The proposed extension automatically creates the MEPs and associates them to the LSP. Once the MEPs are created the Link Trace and Loopback functionality is available for on demand OAM actions. Whether additional parameters besides those specified in the next sections are required (or are beneficial) to support Link Trace and/or Loopback is for further study. In addition parameters needed to support measurement of Service Level Agreements (SLAs) is also left for further study. Hence additional parameters may be defined in subsequent versions of this document. Note also, that it has been discussed that the extensions defined may be applicable to other fault detection mechanisms that use periodic Hello messages, e.g., BFD, as well. However, it is not clear whether there is a need to bootstrap BFD sessions using RSVP-TE. As such BFD related discussions and extensions are left for further study. Takacs, et al. Expires January 12, 2009 [Page 10] Internet-Draft GMPLS based Ethernet OAM Control July 2008 5. GMPLS RSVP-TE Extensions 5.1. Operation overview To simplify the configuration of connectivity monitoring, when an Ethernet LSP is signalled the associated MEPs should be automatically established. Furthermore, GMPLS signalling should be able to enable/ disable connectivity monitoring of a particular Ethernet LSP. To monitor an Ethernet LSP a set of parameters must be provided to setup a Maintenance Association and related MEPs. 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 formating rules for these names have been defined by [IEEE-CFM]. Since these information is also carried in all CCM messages, the combined length of the Names is limited to 44 bytes. How these parameters are determined is out of scope of this document. o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely identifies a given MEP within a Maintenance Association. That is, the combination of MAID and MEP ID must uniquely identify a MEP. How the value of the MEP ID is determined is out of scope of this document. o The Maintenance Domain Level (MD Level) allows hierarchical separation of monitoring entities. [IEEE-CFM] allows differentiation of 8 levels. How the value of the MD Level is determined is out of scope of this document. Note that most probably for all Ethernet LSPs a single (default) MD Level will be used. o The desired CCM Interval must be specified by the management system based on service requirements or operator policy. The same CCM Interval must be set in each of the MEPs monitoring a given Ethernet LSP. How the value of the CCM Interval is determined is out of scope of this document. o The desired CCM priority to be set by MEPs for the CCM frames can be specified. The same CCM priority must be set in each of the MEPs monitoring a given Ethernet LSP. How CCM priority is determined is out of scope of this document. o MEPs must be aware of their own and the reachability parameters of the remote MEP. In the case of bidirectional point-to-point Takacs, et al. Expires January 12, 2009 [Page 11] Internet-Draft GMPLS based Ethernet OAM Control July 2008 PBB-TE connections this requires that the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are configured in each MEP, where the ESP-MAC A is the same as the local MEP's MAC and ESP-MAC B is the same as remote MEP's MAC. The GMPLS Ethernet Label for forwarding, as defined in [GELS-PBBTE], consists of the ESP-MAC DA and ESP-VID. Hence the necessary reachability parameters for the MEPs can be obtained from Ethernet Labels (i.e., carried in the "downstream" and upstream labels). Assuming the procedures described in [GELS-PBBTE] for bidirectional Ethernet LSP establishment the MEP configuration should be as follows. When the RSVP-TE signalling is initiated for the bidirectional Ethernet LSP the local node generates a Path message and: o Allocates an Upstream Label from its MAC address (ESP-MAC A) and locally selected VID (ESP-VID1), that it would like to use to receive traffic; o Inserts an Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES object, specifying the CCM Interval and MD Level; o Adds an MD Name Sub-TLV (optional) and a Short MA Name Sub-TLV to the Ethernet OAM Configuration TLV, that will unambiguously identify a Maintenance Association for this specific PBB-TE connection. Note that values for these parameters may be derived from the GMPLS LSP identification parameters; o Adds a MEP ID Sub-TLV to the Ethernet OAM Configuration TLV. It selects 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 the MAC address (ESP-MAC B) and VID (ESP-VID2) it would like to use 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 it can extract the remote side's reachability information from the LABEL object whereby this node has also obtained all the information needed to establish its local MEP. Takacs, et al. Expires January 12, 2009 [Page 12] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Once the MEPs are established the monitoring of the LSP is operational. In certain situations, e.g., maintenance, re- optimisation of LSPs, it is desirable to explicitly enable or disable the monitoring of LSPs (i.e., start/stop exchanging CC messages). To allow administrative control of LSP monitoring one bit in the ADMIN_STATUS Object is used. The "Monitoring Disabled" (M) bit is allocated for this purpose. Note that since the reachability information could be extracted from the Ethernet Labels it is an option not to use any extension to support MEP configuration of Ethernet LSPs. That is, an implementation could use default parameters for CCM intervals and determine Maintenance Association and MEP identification parameters automatically from LSP identification information. However, we rejected this approach, as it does not provide means to set the CCM interval on a per LSP basis, leaving limited possibilities to configure CFM in a way that matches the supported service's requirements. Moreover, there is no way for providing additional parameters to configure other aspects of Ethernet OAM, e.g., Performance Monitoring. 5.2. Technology Independent Extensions 5.2.1. Monitoring Disabled - Admin_Status bit Administrative Status Information is carried in the ADMIN_STATUS Object. The Administrative Status Information is described in [RFC3471], the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3473]. One bit is allocated for the administrative control of OAM monitoring. In addition to the Reflect (R) bit, 7 bits are currently occupied (assigned by IANA or temporarily blocked by work in progress Internet drafts). As the 24th bit (IANA to assign) this draft introduces the Monitoring Disabled (M) bit. When this bit is set the connectivity monitoring of the LSP is disabled, i.e., no continuity check messages are sent. 5.2.2. OAM entities desired -- LSP Attributes flag In RSVP-TE the Flags field of the SESSION_ATTRIBUTE object is used to indicate options and attributes of the LSP. The Flags field has 8 bits and hence is limited to differentiate only 8 options. [RFC4420] defines a new object for RSVP-TE messages to allow the signalling of arbitrary attribute parameters making RSVP-TE easily extensible to support new applications. Furthermore, [RFC4420] allows options and attributes that do not need to be acted on by all Label Switched Routers (LSRs) along the path of the LSP. In particular, these Takacs, et al. Expires January 12, 2009 [Page 13] Internet-Draft GMPLS based Ethernet OAM Control July 2008 options and attributes may apply only to key LSRs on the path such as the ingress LSR and egress LSR. Options and attributes can be signalled transparently, and only examined at those points that need to act on them. The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC4420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signalled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object must be examined and processed by each LSR. One TLV is defined in [RFC4420]: the Attributes Flags TLV. A new bit (10 IANA to assign): "OAM entities desired" is allocated in the LSP Attributes Flags TLV. If the "OAM entities desired" bit is set it is indicating that the establishment of OAM entities are required at the endpoints of the signalled LSP. A receiving node with the "OAM entities desired" bit set will look for the OAM Configuration TLV for additional information. 5.2.3. OAM Configuration TLV This TLV specifies which OAM technology/method should be used for the LSP. The OAM Configuration TLV is carried in the LSP_ATTRIBUTES object in Path messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Type | OAM Function | Reserved (set to all 0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the OAM Configuration TLV (2) (IANA to assign). OAM Type: specifies the technology specify OAM method. If the requested OAM method is not supported an error must be generated. This document defines the following types. OAM Type Description ------------ ------------------ 0 Reserved 1 Ethernet OAM 2-256 Reserved Takacs, et al. Expires January 12, 2009 [Page 14] Internet-Draft GMPLS based Ethernet OAM Control July 2008 The receiving node based on the OAM Type will look for the corresponding technology specific OAM configuration TLV. OAM Function Flags: specifies the OAM functions (e.g., connectivity monitoring, loss and delay measurement) that should be established and configured. In this document one flag (C: connectivity monitoring) is defined. OAM Function Flag Description --------------------- --------------------------- 0 (C) Connectivity Monitoring 1-7 Reserved 5.3. Ethernet OAM Configuration TLV The Ethernet OAM Configuration TLV (depicted below) is defined for Ethernet OAM specific configuration parameters. The Ethernet OAM Configuration TLV is carried in the LSP_ATTRIBUTES object in Path messages. This new TLV accommodates generic Ethernet OAM information and carries sub-TLVs. If the Ethernet OAM Configuration TLV is included in the LSP_ATTRIBUTES object this signals the request that MEPs should be established for the LSP. If MEPs cannot be established, due to any reason, an error must be generated. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |MD L.| Reserved (set to all 0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the Ethernet OAM Configuration TLV (3) (IANA to define). Length: indicates the total length including sub-TLVs. Version: identifies the CFM protocol version according to [IEEE-CFM]. MD L. (MD Level): indicates the desired MD Level. The values are according to [IEEE-CFM]. Takacs, et al. Expires January 12, 2009 [Page 15] Internet-Draft GMPLS based Ethernet OAM Control July 2008 5.3.1. MD Name Sub-TLV The optional MD Name sub-TLV is depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Format | Name Length | Reserved (set to all 0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ MD Name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1, MD Name Sub-TLV (IANA). Length: indicates the total length of the TLV including padding. Format: according to [IEEE-CFM]. 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. Also the combined length of MD Name and Short MA Name must be less or equal to 44bytes, if this is violated an error must be generated. Note that it is allowed to have no MD Name, as such the MD Name sub- TLV is optional. In this case the MA Name must uniquely identify a Maintenance Association. 5.3.2. Short MA Name Sub-TLV The Short MA Name sub-TLV is depicted below. Takacs, et al. Expires January 12, 2009 [Page 16] Internet-Draft GMPLS based Ethernet OAM Control July 2008 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Format | Name Length | Reserved (set to all 0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Short MA Name ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 2, Short MA Name Sub-TLV (IANA) Length: indicates the total length of the TLV including padding. Format: according to [IEEE-CFM]. Name Length: the length of the MA Name field in bytes. This is necessary to allow non 4 byte padded MA Name lengths. Short MA Name: variable length field formatted according to the format specified in the Format field. If an undefined Format is specified an error must be generated. Also the combined length of MD Name and Short MA Name must be less or equal to 44bytes, if this is violated an error must be generated. Note that it is allowed to have no MD Name, in this case the MA Name must uniquely identify a Maintenance Association. 5.3.3. MEP ID Sub-TLV The MEP ID Sub-TLV is depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) (IANA) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local MEP ID | Remote MEP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 3, MEP ID Sub-TLV (IANA) Length: indicates the total length of the TLV including padding. Local MEP ID: a 16 bit integer value in the range 1-8191 of the MEP ID on the initiator side. Takacs, et al. Expires January 12, 2009 [Page 17] Internet-Draft GMPLS based Ethernet OAM Control July 2008 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. 5.3.4. Continuity Check (CC) Sub-TLV The Continuity Check (CC) sub-TLV is depicted below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (4) (IANA) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prio | CCM I | Reserved (set to all 0s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prio: Indicates the priority to be set for CCM frames. In Ethernet 3 bits carried in VLAN TAGs identify priority information. CCM I (CCM Interval): CCM Interval, according to the 3 bit encoding [IEEE-CFM] shown in Table 1. 5.4. Error handling Error messages and procedures will be detailed in subsequent versions of this document. Takacs, et al. Expires January 12, 2009 [Page 18] Internet-Draft GMPLS based Ethernet OAM Control July 2008 6. IANA Considerations One bit (Monitoring Disabled (M)) needs to be allocated in the ADMIN_STATUS Object. One bit ("OAM entities desired") needs to be allocated in the LSP Attributes Flag Registry. This document specifies two new TLVs to be carried in the LSP_ATTRIBUTES objects in Path messages: OAM Configuration TLV and Ethernet OAM Configuration TLV. In addition, it specifies sub-TLVs within the new Ethernet OAM Configuration TLV. Takacs, et al. Expires January 12, 2009 [Page 19] Internet-Draft GMPLS based Ethernet OAM Control July 2008 7. Security Considerations The signalling of OAM related parameters and the automatic establishment of OAM entities introduces additional security considerations to those discussed in [RFC3473]. In particular, a network element could be overloaded, if an attacker would request liveliness monitoring, with frequent periodic messages, for a high number of LSPs, targeting a single network element. Security aspects will be covered in more detailed in subsequent versions of this document. Takacs, et al. Expires January 12, 2009 [Page 20] Internet-Draft GMPLS based Ethernet OAM Control July 2008 8. Acknowledgements The authors would like to thank Adrian Farrel, Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful comments. Takacs, et al. Expires January 12, 2009 [Page 21] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Appendix A. Discussion on alternatives This appendix summarises the discussions after IETF-71 about the way OAM configuration information should be carried in RSVP-TE. The first question is how the requirement for OAM establishment is signalled and how the operation of OAM is controlled. There is a straightforward way to achieve these using existing objects and fields: o Use one or more OAM flags in the LSP Attributes Flag TLV within the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES object to signal that OAM entities for the LSP need to be established. If for any reason this cannot be done a notification is sent or an error is raised. o Once the LSP with the desired OAM entities is established OAM operation may be controlled using one or more flags in the ADMIN_STATUS object. For instance, the generation of connectivity monitoring messages can be disabled/enabled by setting/clearing a flag in the ADMIN_STATUS object. However, there are two alternatives when it comes to signalling the actual configuration parameters of OAM entities. o Extension of the LSP_ATTRIBUTES object with new TLVs. o Definition of a new RSVP-TE object to carry OAM information. In the first case, a new OAM configuration TLV is defined in the LSP_ATTRIBUTES object. This TLV would provide the detailed information needed for LSPs with a set OAM flag in the LSP Attributes Flag TLV. The rationale for this approach is that in addition to setting flags the LSP_ATTRIBUTES object may carry complementary information for all or some of the flags set. Furthermore, as top level RSVP-TE objects may become scarce resources, it seems to be beneficial not to allocate new RSVP-TE objects for the purpose of providing detailed information for new LSP Attribute Flags. Currently there is only one TLV, the Attributes Flag TLV, defined in the LSP_ATTRIBUTES object. Defining a new TLV associated with one of the flags would make a precedence and possibly be a guideline for similar future extensions. The other alternative would be to allocate a dedicated object for OAM configuration information. The rationale for this is that the complex information that may be required for OAM configuration would unnecessarily add complexity to LSP_ATTRIBUTES/ LSP_REQUIRED_ATTRIBUTES objects and their processing mechanisms. Takacs, et al. Expires January 12, 2009 [Page 22] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Furthermore, traditionally RSVP uses dedicated objects (*_SPECs) to carry configuration information of data plane entities, thus a new object like an "OAM_SPEC" may be a better fit to existing protocol elements. The authors of this document favour the first alternative (adding new TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which alternative to select for standardisation is up for the working group to decide. In any case, the information to be carried would be the same or very similar for both alternatives. Takacs, et al. Expires January 12, 2009 [Page 23] Internet-Draft GMPLS based Ethernet OAM Control July 2008 9. References [GELS-Framework] "GMPLS Ethernet Label Switching Architecture and Framework", Internet Draft, work in progress. [GELS-PBBTE] "GMPLS control of Ethernet PBB-TE", Internet Draft, work in progress. [GMPLS-OAM] "OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks", Internet Draft, work in progress. [IEEE-CFM] "IEEE 802.1ag, Draft Standard for Connectivity Fault Management", work in progress. [IEEE-PBBTE] "IEEE 802.1Qay Draft Standard for Provider Backbone Bridging Traffic Engineering", work in progress. [RFC3469] "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003. [RFC3471] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4377] "Operations and Management (OAM) Requirements for Multi- Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [RFC4420] "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. Takacs, et al. Expires January 12, 2009 [Page 24] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Authors' Addresses Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: attila.takacs@ericsson.com Balazs Gero Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: balazs.gero@ericsson.com Dinesh Mohan Nortel 3500 Carling Ave Ottawa, ON, K2H8E9 Canada Email: mohand@nortel.com Takacs, et al. Expires January 12, 2009 [Page 25] Internet-Draft GMPLS based Ethernet OAM Control July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Takacs, et al. Expires January 12, 2009 [Page 26]