Network Working Group A. Takacs Internet-Draft Ericsson Intended status: Standards Track D. Fedyk Expires: April 29, 2010 Alcatel-Lucent J. He Huawei October 26, 2009 OAM Configuration Framework and Requirements for GMPLS RSVP-TE draft-ietf-ccamp-oam-configuration-fwk-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 29, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Takacs, et al. Expires April 29, 2010 [Page 1] Internet-Draft GMPLS OAM Configuration Framework October 2009 Abstract OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring 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 RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. Takacs, et al. Expires April 29, 2010 [Page 2] Internet-Draft GMPLS OAM Configuration Framework October 2009 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . . 9 3.1. Operation overview . . . . . . . . . . . . . . . . . . . . 9 3.2. LSP Attributes flags . . . . . . . . . . . . . . . . . . . 10 3.3. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 11 3.4. TCME Configuration TLV . . . . . . . . . . . . . . . . . . 13 3.5. NIME Configuration TLV . . . . . . . . . . . . . . . . . . 14 3.6. Monitoring Disabled - Admin_Status bit . . . . . . . . . . 15 3.7. OAM configuration errors . . . . . . . . . . . . . . . . . 15 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Discussion on alternatives . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Takacs, et al. Expires April 29, 2010 [Page 3] Internet-Draft GMPLS OAM Configuration Framework October 2009 1. Introduction GMPLS is designed as an out-of-band control plane supporting dynamic connection provisioning for any suitable data plane technology; including spatial switching (e.g., incoming port or fiber to outgoing port or fiber), wavelength-division multiplexing (e.g., DWDM), time- division multiplexing (e.g., SONET/SDH, G.709), and lately Ethernet Provider Backbone Bridging -- Traffic Engineering (PBB-TE) and MPLS Transport Profile (MPLS-TP). In most of these technologies there are Operations and Management (OAM) functions employed to monitor the health and performance of the connections and to trigger data plane (DP) recovery mechanisms. Similarly to connections, OAM functions follow general principles but also have some technology specific characteristics. OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring 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. In some situations the use of OAM functions, like those of Fault- (FM) and Performance Management (PM), may be optional confirming to actual network management policies. Hence the network operator must be able to choose which kind of OAM functions to apply to specific connections and with what parameters the selected OAM functions should be configured and operated. To achieve this objective OAM entities and specific functions must be selectively configurable. In general, it is required that the management plane and control plane connection establishment mechanisms are synchronized with OAM establishment and activation. In particular, if the GMPLS control plane is employed it is desirable to bind OAM setup and configuration to connection establishment signaling to avoid two separate management/configuration steps (connection setup followed by OAM configuration) which increases delay, processing and more importantly may be prune to misconfiguration errors. Once OAM entities are setup and configured pro-active as well as on-demand OAM functions can be activated via the management plane. On the other hand, it should be possible to activate/deactivate pro-active OAM functions via the GMPLS control plane as well. This document describes requirements on OAM configuration and control via RSVP-TE, and specifies extensions to the RSVP-TE protocol providing a framework to configure and control OAM entities along with capability to carry technology specific information. Extensions can be grouped into generic elements that are applicable to any OAM Takacs, et al. Expires April 29, 2010 [Page 4] Internet-Draft GMPLS OAM Configuration Framework October 2009 solution and technology specific elements that provide additional configuration parameters only needed for a specific OAM technology. This document specifies the technology agnostic elements which alone can be used to establish and control OAM entities in the case no technology specific information is needed, and specifies the way additional technology specific OAM parameters are provided. The mechanisms described in this document provide an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other technology specific OAM bootstrapping techniques; e.g., LSP Ping [RFC4379] for MPLS networks. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is already in use to set up the LSPs that are to be monitored using OAM. Takacs, et al. Expires April 29, 2010 [Page 5] Internet-Draft GMPLS OAM Configuration Framework October 2009 2. Requirements MPLS OAM requirements are described in [RFC4377]. It provides requirements to create consistent OAM functionality for MPLS networks. 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. 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 document. 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 synchronizing defect detection times by setting appropriately bounded detection timeframes. MPLS-TP defines a profile of MPLS targeted at transport applications [MPLS-TP-FWK]. This profile specifies the specific MPLS characteristics and extensions required to meet transport requirements, including providing additional OAM, survivability and other maintenance functions not currently supported by MPLS. Specific OAM requirements for MPLS-TP are specified in [MPLS-TP-OAM-REQ]. MPLS-TP poses requirements on the control plane to configure and control OAM entities. o The use of OAM functions SHOULD be optional for the operator. A network operator SHOULD be able to choose which OAM functions to use and which Maintenance Entity to apply them to. o The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points as well as the activation/ deactivation of OAM when the transport path is established or modified. OAM functions SHOULD be configurable as part of connectivity (LSP or PW) management. Ethernet Connectivity Fault Management (CFM) defines an adjunct connectivity monitoring OAM flow to check the liveliness of Ethernet networks [IEEE-CFM]. With PBB-TE [IEEE-PBBTE] Ethernet networks will Takacs, et al. Expires April 29, 2010 [Page 6] Internet-Draft GMPLS OAM Configuration Framework October 2009 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. Without control plane support separate management commands would be needed to configure and start CFM. GMPLS based OAM configuration and control should be general to be applicable to a wide range of data plane technologies and OAM solution. There are three typical data plane technologies used for transport application, which are wavelength based such as WSON, TDM based such as SDH/SONET, packet based such as MPLS-TP [MPLS-TP-FWK] and Ethernet PBB-TE [IEEE-PBBTE]. In all these data planes, the operator MUST be able to configure and control the following OAM functions. o It MUST be possible to explicitly request the setup of OAM entities for the signaled LSP and provide specific information for the setup if this is required by the technology. o Control of alarms is important to avoid false alarm indications and reporting to the management system. It MUST be possible to enable/disable alarms generated by OAM functions. In some cases selective alarm control may be desirable when, for instance, the operator is only concerned about critical alarms thus the non- service affecting alarms should be inhibited. o When periodic messages are used for liveliness check (continuity check) of LSPs it MUST be possible to set the frequency of messages allowing proper configuration for fulfilling the requirements of the service and/or meeting the detection time boundaries posed by possible congruent connectivity check operations of higher layer applications. For a network operator to be able to balance the trade-off in fast failure detection and overhead it is beneficial to configure the frequency of continuity check messages on a per LSP basis. o Pro-active Performance Monitoring (PM) functions are continuously collecting information about specific characteristics of the connection. 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. o The extensions must allow the operator to use only a minimal set of OAM configuration and control features if the data plane technology, the OAM solution or network management policy allows. The extensions must be reusable as much as reasonably possible. Takacs, et al. Expires April 29, 2010 [Page 7] Internet-Draft GMPLS OAM Configuration Framework October 2009 That is generic OAM parameters and data plane or OAM technology specific parameters must be separated. Takacs, et al. Expires April 29, 2010 [Page 8] Internet-Draft GMPLS OAM Configuration Framework October 2009 3. GMPLS RSVP-TE Extensions 3.1. Operation overview In general, two types of Maintenance Poits (MPs) can be distinguished: Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs are capable of initiating and terminating OAM messages for Fault Management (FM) and Performance Monitoring (PM). MIPs on the other hand are located at transit nodes of an LSP and are capable of reacting to some OAM messages but otherwise do not initiate messages. Maintenance Entity (ME) refers to an association of MEPs and MIPs that are provisioned to monitor an LSP. The ME association is achieved by configuring MPs of an ME with the same unique ME Assocication ID (MA ID). Each MEP must have unique identification (MEP ID) within a Maintenance Entity. When an LSP is signaled forwarding association is established between endpoints and transit nodes via label bindings. This association creates a context for the OAM entities monitoring the LSP. On top of this association OAM entities may be configured with an MA ID and MEP IDs. The MA ID may be used to detect misconfiguration errors and leaking OAM traffic. While the MEP ID can be used to demultiplex and identify the originating MEP of OAM messages. Since MIPs do not originate OAM packets, on top of the configuration of Maintenance Entity associations, no specific configuration is required for them. Along the LSP several Tandem Connections may be provisioned and associated to the end-to-end connection. These Tandem Connections may implement their own OAM monitoring entities. The Tandem Connection Maintenance Entities (TCMEs) provide the same monitoring capabilities for a segment of a connection as what is possible on an end-to-end basis. As the endpoints of a TCME may be (and usually are) intermediate nodes of an end-to-end LSP, the placement of TCME ingress and egress endpoints must be explicitly identified. Altough provisioned together with the end-to-end connection, each TCME defines a new context for the OAM entities, which is independent from the end-to-end connection. The MA ID and MEP IDs for a TCME are within this new context. When an LSP is signaled Non-Intrusive Maintenance Elements (NIME) may be deployed along the path. These elements differ from the MIPs as they implemetn egress MEP functions: they not only process OAM messages but they can also trigger consequent actions, for instance, initiate segment protection switching. The NIMEs belong to the OAM entity context of the end-to-end LSP and, thus, the same MA ID is applied. As the NIMEs are placed at intermediate nodes, their placement must be explicitly indicated. Takacs, et al. Expires April 29, 2010 [Page 9] Internet-Draft GMPLS OAM Configuration Framework October 2009 In addition to the MA and MEP identification parameters pro-active OAM functions (e.g., Continuity Check (CC), Performance Monitoring) may have specific parameters requiring configuration as well. In particular, the frequency of periodic CC packets and the measurement interval for loss and delay measurements may need to be configured. MEP +-------------+ |OAM Functions| | FM | PM | +------+------+ | MEP ID | +-------------+ | MA ID | +-------------+ +-------------+ | connection | +-------------+ In some cases all the above parameters may be either derived form some exiting information or pre-configured default values can be used. In the simplest case the control plane needs to provide information whether or not a MA with MPs need to be setup for the signaled LSP. If OAM entities are created signaling must provide means to activate/deactivate OAM message flows and associated alarms. MA and MEP IDs as well as configuration of OAM functions are technology specific, i.e., vary depending on the data plane technology and the chosen OAM solution. In addition, for any given data plane technology a set of OAM solutions may be applicable. The OAM configuration framework allows selecting a specific OAM solution to be used for the signaled LSP and provides technology specific TLVs to carry further detailed configuration information. 3.2. LSP Attributes flags 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 new objects for RSVP-TE messages to allow the signaling 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 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 signaled transparently, and only examined at those points that need Takacs, et al. Expires April 29, 2010 [Page 10] Internet-Draft GMPLS OAM Configuration Framework October 2009 to act on them. The LSP_ATTRIBUTES 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 signaled 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. One bit (10 IANA to assign): "OAM MEP entities desired" is allocated in the LSP Attributes Flags TLV. If the "OAM MEP entities desired" bit is set it is indicating that the establishment of OAM MEP entities are required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported an error must be generated: "OAM Problem/MEP establishment not supported". If the "OAM MEP entities desired" bit is set and additional parameters are needed to configure the OAM entities an OAM Configuration TLV may be included in the LSP_ATTRIBUTES object. One bit (11 IANA to assign): "OAM MIP entities desired" is allocated in the LSP Attributes Flags TLV. If the "OAM MIP entities desired" bit is set it is indicating that the establishment of OAM MIP entities are required at the transit nodes of the signaled LSP. This bit can only be set if the "OAM MEP entities desired" bit is set. If the establishment of MIPs is not supported an error must be generated: "OAM Problem/MIP establishment not supported". One bit (12 IANA to assign): "Alarm indication desired" is allocated in the LSP Attributes Flags TLV. If the "Alarm indication desired" bit is set it is indicating that the OAM entities of the signaled LSP should be notified of lower layer failures. In the case of hierarchical LSPs this will create an association between the underlying (server) LSP's OAM entities and the currently signaled (client) LSP's OAM entities. 3.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. Takacs, et al. Expires April 29, 2010 [Page 11] Internet-Draft GMPLS OAM Configuration Framework October 2009 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 | Reserved | OAM Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ sub-TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the OAM Configuration TLV (2) (IANA to assign). OAM Type: specifies the technology specific OAM method. If the requested OAM method is not supported an error must be generated: "OAM Problem/Unsupported OAM Type". This document defines no types. The receiving node based on the OAM Type will check if a corresponding technology specific OAM configuration sub-TLV is included. If different technology specific OAM configuration sub-TLV is included than what was specified in the OAM Type an error must be generated: "OAM Problem/OAM Type Mismatch". OAM Type Description ------------ -------------------- 0-255 Reserved There is a hierarchy in between the OAM configuration elements. First, the "OAM MEP (and MIP) entities desired" flag needs to be set, if it is set an "OAM Configuration TLV" may be included in the LSP_ATTRIBUTES object, if this TLV is present based on the OAM Type a technology specific OAM configuration sub-TLV may be present. If this hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set but an OAM Configuration TLV is present an error must be generated: "OAM Problem/Configuration Error". OAM Function Flags: specifies pro-active OAM functions (e.g., connectivity monitoring, loss and delay measurement) that should be established and configured. If the selected OAM Function(s) is(are) not supported an error must be generated: "OAM Problem/Unsupported OAM Function". This document defines the following flags. Takacs, et al. Expires April 29, 2010 [Page 12] Internet-Draft GMPLS OAM Configuration Framework October 2009 OAM Function Flag Description --------------------- --------------------------- 0 Connectivity Monitoring 1 Performance Monitoring/Loss 2 Performance Monitoring/Delay 3.4. TCME Configuration TLV Two TCME Configuration TLVs together specify a Tandem Connection Monitoring entity: they designate the TCM ingress and TCM egress MEPs, respectively. TCME Configuration TLVs are carried in HOP_ATTRIBUTES subobjects [HOP_ATTR] in the ERO, the corresponding node in the ERO identifies where TCME MEP is placed. Both TCME Configuration TLVs of the same TCME must specify the same OAM technology and method. 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 |H|M| Level | OAM Functions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUB TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: indicates a new type: the TCME Configuration TLV (2) (IANA to assign). OAM Type: specifies the technology specific OAM method. The OAM Type values defined for OAM Configuration TLV are applied here. If the requested OAM method is not supported an error must be generated: "OAM Problem/Unsupported OAM Type". One bit (Flag H) is allocated to indicate which endpoint of a TCME is encoded by the TCME Configuration TLV. Setting this flag indicates the ingress endpoints while clearing it indicates the egress one. One bit (Flag M) "TCME MIP entities desired" is allocated. This flag indicates if OAM MIP entities monitoring the TCME are required. If this function is not supported an error must be generated: "OAM Problem/TCME MIP establishment not supported". Level provides a key for the ingress node to determine the egress of the same TCME. Therefore, the same Level values must be set to the ingress and egress endpoints of the same TCME. Overlapping (including nesting) TCM entities must use different Level values, but Takacs, et al. Expires April 29, 2010 [Page 13] Internet-Draft GMPLS OAM Configuration Framework October 2009 two entries not having common segments may use the same Level value. Value 0 is reserved and must not be used to identify a TCM entity. Futher technology specific constraints of the Level value may be defined by accompying documents. OAM Function Flags: specifies pro-active OAM functions (e.g., connectivity monitoring, loss and delay measurement) that should be established and configured. Same flags are applied as for OAM Configuration TLV. Both TLVs may contain technology sub-TLVs and the encoded sub-TLVs are relevant to the referred monitoring endpoint. The TCM ingress may update the OAM configuration of the egress point by changing already defined sub-TLVs or by adding new sub-TLVs. If the node, where TCME endpoint is to be configured, does not support that feature, must generate an error: "OAM Problem/TCM not supported". Since a TCME Configuration TLV pair encodes a TCME, the ingress node must check if a proper TCME Configuration TLV encoding the egress MEP is included in the ERO. If no such TLV (i.e., the same Level value is set and flag H is cleared) is found an error must be generated: "OAM Problem/TCM Egress is not properly configured". The above check ensures that a TCM egress will not be configured without peering TCM ingress. Therefore, there is no need TCME ingress checking procedure at the TCME egress. 3.5. NIME Configuration TLV Inserting a NIME Configuration TLV into a HOP_ATTRIBUTES object [HOP_ATTR] indicates that a non-intrusive monitoring element is to be configured. Futhermore, it encodes what OAM technology and method should be used at that entity. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM Type |D|U| Level | OAM Functions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SUB TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Takacs, et al. Expires April 29, 2010 [Page 14] Internet-Draft GMPLS OAM Configuration Framework October 2009 Type: indicates a new type: the NIM OAM Configuration TLV (3) (IANA to assign). OAM Type: specifies the technology specify OAM method. If the requested OAM method is not supported an error must be generated: "OAM Problem/Unsupported OAM Type". The same OAM type values to be used as for OAM Configuration TLV. Level value indicates which OAM flow of the connection is monitored: the end-to-end OAM flow (Level = 0) or TCM entity associated to the connection (Level > 0). Two bits (Flags D,U) indicates the direction of the monitored entity. The downstream traffic is monitored if flag D is set, while setting flag U means monitoring the upstream direction. Both directions are monitored if both flags are set. When both flags are cleared or the flag U is set but the LSP is not bidirectional an error must be generated: "OAM Problem/Invalid NIM direction defined". OAM Function Flags: specifies pro-active OAM functions (e.g., connectivity monitoring, loss and delay measurement) that should be established and configured. Same procedures and flags applied as for OAM Configuration TLV. 3.6. 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 monitoring and OAM triggered alarms of the LSP are disabled (e.g., no continuity check messages are sent, no AIS is generated). 3.7. OAM configuration errors To handle OAM configuration errors a new Error Code (IANA to assign) "OAM Problem" is introduced. To refer to specific problems a set of Error Values is defined. If a node does not support the establishment of OAM MEP or MIP entities it must use the error value (IANA to assign): "MEP establishment not supported" or "MIP establishment not supported" Takacs, et al. Expires April 29, 2010 [Page 15] Internet-Draft GMPLS OAM Configuration Framework October 2009 respectively in the PathErr message. If a node does not support a specific OAM technology/solution it must use the error value (IANA to assign): "Unsupported OAM Type" in the PathErr message. If a different technology specific OAM configuration TLV is included than what was specified in the OAM Type an error must be generated with error value:"OAM Type Mismatch" in the PathErr message. There is a hierarchy in between the OAM configuration elements. If this hierarchy is broken an the error value: "OAM Problem/ Configuration Error" must be used in the PathErr message. If a node does not support a specific OAM Function it must use the error value (IANA to assign): "Unsupported OAM Function" in the PathErr message. If an intermediate node is configured as a TCM ingress node, but no egress node for the same TCM entity is encoded in the ERO it must use "OAM Problem/TCM Egress is not properly configured" error value in the PathErr message If the node, where TCME endpoint is to be configured, does not support that feature, must generate an error: "OAM Problem/TCM not supported". If the technology does not support deploying MIPs monitoring a TCME an error must be generated by the TCME ingress: "OAM Problem/TCME MIP establishment not supported". If an intermediate node is configured as a non-intrusive monitoring node, but direction flags encode an invalid direction (both flags are set to 0 or flag "U" is set in the case of an unidirectional LSP) the node must issue a PathErr message with "OAM Problem/invalid NIM direction defined". Takacs, et al. Expires April 29, 2010 [Page 16] Internet-Draft GMPLS OAM Configuration Framework October 2009 4. 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 one new TLVs to be carried in the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path messages: OAM Configuration TLV. One new Error Code: "OAM Problem" and three new values: "MEP establishment not supported", "MIP establishment not supported", "Unsupported OAM Type" and "Unsupported OAM Function" needs to be assigned. Takacs, et al. Expires April 29, 2010 [Page 17] Internet-Draft GMPLS OAM Configuration Framework October 2009 5. Security Considerations The signaling 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 April 29, 2010 [Page 18] Internet-Draft GMPLS OAM Configuration Framework October 2009 6. Acknowledgements The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray and Dimitri Papadimitriou for their useful comments. Takacs, et al. Expires April 29, 2010 [Page 19] Internet-Draft GMPLS OAM Configuration Framework October 2009 Appendix A. Discussion on alternatives This appendix summarizes 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 signaled 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 signaling 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 April 29, 2010 [Page 20] Internet-Draft GMPLS OAM Configuration Framework October 2009 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 favor the first alternative (adding new TLVs to LSP_ATTRIBTES/LSP_REQUIRED_ATTRIBUTES. However, which alternative to select for standardization 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 April 29, 2010 [Page 21] Internet-Draft GMPLS OAM Configuration Framework October 2009 7. References [GELS-Framework] "GMPLS Ethernet Label Switching Architecture and Framework", Internet Draft, work in progress. [GMPLS-OAM] "OAM Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Networks", Internet Draft, work in progress. [HOP_ATTR] Kern, A. and A. Takacs, "Encoding of Attributes of LSP hops using RSVP-TE", Internet-draft Work in progress, October 2009. [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. [MPLS-TP-FWK] "A Framework for MPLS in Transport Networks", Internet Draft, work in progress. [MPLS-TP-OAM-REQ] "Requirements for OAM in MPLS Transport Networks", Internet Draft, 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 Takacs, et al. Expires April 29, 2010 [Page 22] Internet-Draft GMPLS OAM Configuration Framework October 2009 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. Takacs, et al. Expires April 29, 2010 [Page 23] Internet-Draft GMPLS OAM Configuration Framework October 2009 Authors' Addresses Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: attila.takacs@ericsson.com Don Fedyk Alcatel-Lucent Groton, MA 01450 USA Email: donald.fedyk@alcatel-lucent.com Jia He Huawei Email: hejia@huawei.com Takacs, et al. Expires April 29, 2010 [Page 24]