Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent Expires: April, 2009 Scott Mansfield Intended Status: Informational Eric Gray Ericsson October 8, 2008 MPLS TP Network Management Requirements draft-gray-mpls-tp-nm-req-01.txt 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 8, 2009. Abstract This document specifies the network management requirements for supporting the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Gray, et al Expires April, 2009 [Page 1] Internet-Draft MPLS-TP NM Requirements October, 2008 Table of Contents 1. Introduction................................................3 1.1. Terminology............................................3 2. Management Architecture.....................................4 2.1. Network Management Architecture........................4 2.2. Element Management Architecture........................5 2.3. Standard Management Interfaces.........................6 3. Management Channel Requirements.............................6 4. OAM Management Requirements.................................7 5. Fault Management Requirements...............................8 5.1. Supervision Function...................................8 5.2. Validation Function...................................10 5.3. Alarm Handling Function...............................11 5.3.1. Alarm Severity Assignment........................11 5.3.2. Alarm Suppression................................11 5.3.3. Alarm Reporting Control..........................11 5.3.4. Alarm Reporting..................................11 6. Configuration Requirements.................................12 7. Performance Requirements...................................12 7.1. Path Characterization Performance Metrics.............13 7.2. SLA Performance Metrics...............................14 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics.......14 7.4. Performance Collection Instrumentation................14 7.4.1. Collection Frequency.............................14 7.4.2. Collection Granularity...........................14 8. Security Requirements......................................14 8.1. Management Communication Channel Security.............14 8.1.1. In-Band management security......................15 8.1.2. Out-of-Band management security..................15 8.2. Signaling Communication Channel Security..............15 8.3. Distributed Denial of Service.........................15 9. Security Considerations....................................16 10. IANA Considerations.......................................16 11. Acknowledgments...........................................16 12. References................................................16 12.1. Normative References.................................16 12.2. Informative References...............................17 13. Author's Addresses........................................17 Intellectual Property Statement...............................18 Disclaimer of Validity........................................18 Copyright Statement...........................................18 Acknowledgment................................................19 Gray, et al Expires April, 2009 [Page 2] Internet-Draft MPLS-TP NM Requirements October, 2008 1. Introduction This document describes the requirements necessary to manage the elements and networks that support a Transport Profile for MPLS. These requirements are derived from the set of requirements specified in ITU-T G.7710/Y.1701 [1], which addresses generic management requirements for transport networks (including packet-based and circuit-based). This document also leverages the OAM requirements for MPLS Networks (RFC4377)[2] and MPLS-TP Networks [3] documents and expands on the requirements to cover the modifications necessary for configuration, performance, fault, and security for the Transport Profile. 1.1. Terminology 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 [6]. MPLS-TP NE: a network element (NE) that supports MPLS-TP functions MPLS-TP network: a network in which MPLS-TP NEs are deployed Equipment Management Function (EMF): the management functions within an NE. See ITU-T G.7710 [1]. Data Communication Network (DCN): a network that supports Layer 1 (physical), Layer 2 (data-link), and Layer 3 (network) functionality for distributed management communications related to the management plane, for distributed signaling communications related to the control plane, and other operations communications (e.g., order-wire/voice communications, software downloads, etc.). A DCN supporting management communication is referred to as a Management Communication Network (MCN). A DCN supporting signaling communication is referred to as a Signaling Communication Network (SCN). Embedded Communication Channel (ECC): a logical operations channel between network elements (NEs) that can be utilized by multiple applications (e.g., management plane applications, control plane applications, etc.). The physical channel supporting the ECC is technology specific. An example of physical channels supporting the ECC is a DCC channel within SDH. Gray, et al Expires April, 2009 [Page 3] Internet-Draft MPLS-TP NM Requirements October, 2008 Management Communication Channel (MCC): a dedicated logical operations channel between NEs for management plane communications. The physical channel supporting the MCC is technology specific. Signaling Communication Channel (SCC): a dedicated logical operations channel between NEs for control plane communications. This SCC MAY be used for GMPLS/ASON signaling and/or other control plane messages like e.g., routing messages. The physical channel supporting the SCC is technology specific. Management Application Function (MAF): an application process that participates in system management. Each NE and Operations System (OS) MUST support a MAF. A MAF is the origin and termination for all TMN messages. 2. Management Architecture The management of the MPLS-TP network is based on a multi-tiered distributed management systems as described in ITU-T M.3010 [8] and M.3060 [9]. Each tier provides a predefined level of network management capabilities. The lowest tier of this organization model includes the MPLS-TP Network Element Functions (NEFs) that provides the transport service and the Operations System Functions (OSFs) at the Element Management Level. The Management Application Function (MAF) within the NEFs and OSFs provides the management support. The MAF at each entity can include agents only, managers only, or both agents and managers. MAFs that include managers are capable of managing an agent included in other MAFs. The management communication to peer NEFs and/or Operations System Functions (OSFs) is provided via the Message Communication Function (MCF) within each entity (e.g. NEF and OSF). The user can access the management of the MPLS-TP transport network via a Local Craft Terminal (LCT) attached to the NEF or via a Work Station (WS) attached to the OSF. 2.1. Network Management Architecture A transport Management Network (MN) MAY consist of several transport-technology-specific Management Networks. Notation used in G.7710 ([1]) for a transport-technology-specific MN is x.MN, where x is the transport specific technology. For example, a MPLS-TP specific MN might be MPLS-TP.MN (this was previously TM- MN for T-MPLS specific MN). Where there is no ambiguity, we Gray, et al Expires April, 2009 [Page 4] Internet-Draft MPLS-TP NM Requirements October, 2008 will use "MN" for an MPLS-TP specific MN, and "MPLS-TP.MN" (or "MPLS-TP MN") and "MN" where both are used in a given context. The management of the MPLS-TP network SHALL be separable from the management of the other technology-specific networks, and operate independently of any particular client or server layer management plane. A MPLS-TP Management Network MAY be partitioned into MPLS-TP Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just "MSN" where usage is unambiguous). The MPLS-TP MSN MAY be connected to other parts of the MN through one or more Local Craft Terminals (via F-interface, see M.3010) and/or Operations Systems (via Q-interface, see M.3010 [8]). The MCF of an MPLS-TP NE initiates/terminates, routes, or otherwise processes management messages over ECCs or via an external Q-interface or F-interface. Multiple addressable MPLS-TP NEs MAY be present at a single physical location (i.e. site or office). The inter-site communications link between the MPLS-TP NEs will normally be provided by the ECCs. Within a particular site, the NEs MAY communicate via an intra-site ECC or via a LAN. 2.2. Element Management Architecture The Equipment Management Function (EMF) of a MPLS-TP NE provides the means through which a management system manages the NE. Figure 5/G.7710 [1] illustrates examples of EMF components within an NE. The EMF interacts with the NE's transport functions and control functions (i.e., control plane functions that reside in the NE) by exchanging Management Information (MI) across the Management Point (MP) Reference Points. The EMF MAY contain a number of functions that provide a data reduction mechanism on the information received across the MP Reference Points. The EMF includes functions such as Date & Time and the FCAPS (Fault, Configuration, Accounting, Performance and Security) management functions. The EMF provides event message processing, data storage and logging. The management Agent, a component of the EMF, converts internal management information (MI signals) into Management Application messages and vice versa. The Agent responds to Management Application messages from the Message Communications Function (MCF) by performing the appropriate Gray, et al Expires April, 2009 [Page 5] Internet-Draft MPLS-TP NM Requirements October, 2008 operations on (for example) the Managed Objects in a Management Information Base (MIB), as necessary. The MCF contains communications functions related to the outside world of the NE (i.e. Date & Time source, Management Plane, Control Plane, Local Craft Terminal and Local Alarms). The Date & Time functions keep track of the NE's date/time which is used by the FCAPS management functions to e.g. time stamp event reports. 2.3. Standard Management Interfaces This document places no restriction on which management interface to be used for managing an MPLS-TP network. It is possible to provision and manage an end-to-end connection across a network where some segments are created/managed/deleted, for example by netconf/XML or snmp/smi and other segments by CORBA/IDL interfaces. Use of any network management interface for one management related purpose does not preclude use of another network management interface for other management related purposes, or the same purpose at another time However, an MPLS-TP NE is not required to offer more than one standard management interface. 3. Management Channel Requirements The Embedded Communication Channel (ECC) provides a logical operations channel between NEs for transferring Management and/or Signaling information. Note that some technologies provide separate communication channels for Management (MCC) and Signaling (SCC). This document places no restriction on the physical topology of the MN to support management communications. However, the MPLS- TP MN SHOULD support seamless connectivity with remote transport domains and NEs as specified in ITU-T G.8601 [10] as well as with termination points located in NEs under control by a third party network operator as specified in G.8601. Each MPLS-TP MSN MUST have at least one MPLS-TP NE which is connected to an OS (possibly via a Mediation Device). This NE is called a Gateway Network Element (GNE). The GNE SHOULD be able to perform an intermediate system network layer routing function for ECC messages destined for any end system in the MSN. Messages passing between the OS and any of the end systems in Gray, et al Expires April, 2009 [Page 6] Internet-Draft MPLS-TP NM Requirements October, 2008 the subnetwork are routed through the GNE and, in general, other intermediate systems. MPLS-TP NEs communicate via the DCN. The DCN connects NEs with management systems, NEs with NEs, and management systems with management systems. DCN architecture and requirements are specified in ITU-T G.7712/Y.1703 [7], including network layer protocols and their interworking. In order to have the DCN operate properly, a number of management functions are required. Examples are: . Retrieval of network parameters to ensure compatible functioning, e.g. packet size, timeouts, quality of service, window size, etc.; . Establishment of message routing between DCN nodes; . Management of network addresses; . Retrieval of operational status of the DCN at a given node; . Capability to enable/disable access to the DCN. 4. OAM Management Requirements The purpose of the Operation and Maintenance (OAM) functionality is to maintain the integrity of the network and to ensure that the transport service is compliant with the committed Service Level Agreement (SLA). [3] specifies the requirements for the OAM functionality that are deployed in the transport plane to maintain the integrity of the client signal between ingress and egress ports of the MPLS- TP network. These OAM functionalities are sometimes called "Horizontal OAM". There are OAM functionalities that are deployed in the management plane to support maintaining the overall network integrity and achieving the SLA. These OAM functionalities are sometimes called "Vertical OAM" or OAM&P (Operation, Administration, Maintenance, & Provisioning), in the sense that they involves higher level systems, such as element management systems (EMS), network management systems (NMS), and/or service Gray, et al Expires April, 2009 [Page 7] Internet-Draft MPLS-TP NM Requirements October, 2008 management systems (SMS). Examples of vertical OAM functions include hardware provisioning, software configuration, alarm notification/retrieval, performance monitoring (PM) data collection & reporting. Note that management of horizontal OAM parameters is also part of the vertical OAM function. Regardless what specific horizontal OAM mechanisms (tools) will be deployed in the transport plane, these mechanisms (tools) need to be managed (e.g. configured and monitored) to ensure their proper functioning. The management requirements for the horizontal OAM mechanisms will be specified in the subsequence sections, along with the vertical OAM management requirements. 5.Fault Management Requirements The Fault Management functions within the EMF of an MPLS-TP NE enable the supervision, detection, validation, isolation, correction, and reporting of abnormal operation of the MPLS-TP network and its environment. 5.1. Supervision Function The supervision function analyses the actual occurrence of a disturbance or fault for the purpose of providing an appropriate indication of performance and/or detected fault condition to maintenance personnel and operations systems. The MPLS-TP NE shall support the following types of supervision: A) Transmission supervision: . Continuity supervision for the detection of a broken connection; . Connectivity supervision for the detection of a misconnection; . Looping supervision for unintended self-replication; . Alarm suppression based on native OAM, e.g., AIS (Alarm Indication Signal) and FDI (Forward Defect Indication) . Lock indication supervision; . Packet loss measurement in both directions of the bidirectional connection; Gray, et al Expires April, 2009 [Page 8] Internet-Draft MPLS-TP NM Requirements October, 2008 . Misinsertion supervision for misinserted packet in the connection . Diagnostic test supervision; . Route trace supervision; . Remote defect indication supervision; . Protocol supervision for the detection of failure in the sequence of a protocol exchange (e.g. automatic protection switching protocol); The transmission supervision mechanisms MUST support the flexibility to be configured to perform on-demand or proactively. B) Software Processing Supervision for software or software processing fault, such as storage capacity problem, version mismatch, Corrupted data, Out of memory, etc. C) Hardware Supervision for interchangeable and non- interchangeable units, cable, and power problem. D) Environment Supervision for temperature, humidity, etc. The following requirements related to defect detection specified in RFC 4377 [2] are applicable for MPLS-TP NE. . The ability to detect defects in a broken connection (LSP, PW) MUST NOT require manual hop-by-hop troubleshooting of each node used to switch traffic for that connection. . The automation of path liveliness is desired in cases where large numbers of connections might be tested. . Synchronization of detection time bounds by tools used to detect broken connections is required. . Any detection mechanisms that depend on receiving the status via a return path SHOULD provide multiple return options with the expectation that one of them will not be impacted by the original defect. Gray, et al Expires April, 2009 [Page 9] Internet-Draft MPLS-TP NM Requirements October, 2008 . The OAM packet for defect detection MUST follow the customer data path exactly in order to reflect path liveliness used by customer data. . Defect SHOULD be detected by the network operator prior to the customers of the service in question detecting them. . Recovery of service from faults MAY be automatically taken according to the type of fault. 5.2. Validation Function Validation is concerned with the integration of Fault Causes into Failures. A Fault Cause indicates a limited interruption of the required function. A Fault Cause is not reported to maintenance personnel because it could exist only for a very short time. Some of these events however are summed up in the Performance Monitoring process, and when this sum exceeds a certain value, a Threshold Report can be generated. When the Fault Cause lasts long enough, an inability to perform the required function arises. This Failure condition is subject to be alarmed to maintenance personnel because corrective action might be required. Conversely, when the Fault Cause ceases after a certain time, the Failure condition MUST disappear. The EMF within the MPLS-TP NE MUST perform a persistency check on the fault causes before it declares a fault cause a failure. A transmission failure shall be declared if the fault cause persists continuously for 2.5 +/- 0.5 sec. The failure shall be cleared if the fault cause is absent continuously for 10 +/- 0.5 sec. The failure declaration and clearing MUST be time stamped. The time-stamp shall indicate the time at which the fault cause is activated at the input of the fault cause persistency (i.e. defect-to-failure integration) function, and the time at which the fault cause is deactivated at the input of the fault cause persistency function. Gray, et al Expires April, 2009 [Page 10] Internet-Draft MPLS-TP NM Requirements October, 2008 5.3. Alarm Handling Function 5.3.1. Alarm Severity Assignment Failures MAY have been categorized to indicate the severity or urgency of the fault. The MPLS-TP NE SHOULD support the flexibility of assignment of severity (e.g., Critical, Major, Minor, Warning) by the management system. See G.7710 [1] for more description. 5.3.2. Alarm Suppression An MPLS-TP NE MUST provide alarm suppression functionality that prevents the generation of a superfluous generation of alarms, e.g., by simply discarding them (or not generating them in the first place), or by aggregating them together, thereby greatly reducing the number of notifications emitted. An MPLS-TP NE supporting the inter-working of one or more networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS) over MPLS-TP MUST be able to translate an MPLS-TP defect into the native technology's error condition. See RFC 4377 [2] for more description. 5.3.3. Alarm Reporting Control Alarm Reporting Control (ARC) supports an automatic in-service provisioning capability. Alarm reporting MAY be turned off on a per-managed entity basis to allow sufficient time for customer service testing and other maintenance activities in an "alarm free" state. Once a managed entity is ready, alarm reporting is automatically turned on (to ALM). See G.7710 [1] for more description. 5.3.4. Alarm Reporting Alarm Reporting is concerned with the reporting of relevant events and conditions, which occur in the network (including the NE, incoming signal, and external environment). The MPLS-TP NE MUST support local reporting of alarms. Local reporting is concerned with automatic alarming by means of audible and visual indicators near the failed equipment. Gray, et al Expires April, 2009 [Page 11] Internet-Draft MPLS-TP NM Requirements October, 2008 The MPLS-TP NE MUST support reporting of alarms to an OS. These reports are either autonomous reports (notifications) or reports on request by maintenance personnel. 6. Configuration Requirements Configuration Management provides functions to exercise control over, identify, collect data from, and provide data to NEs. Generic configuration management requirements for transport network are specified in G.7710 [1], for examples hardware, software, protection switching, alarm reporting control, and date/time. The EMF of the MPLS-TP NE MUST support the capability of configuring the OAM functions as part of connectivity management, including bidirectional point-to-point connection, uni-directional point-to-point connection, and uni-directional point-to-multipoint connection. The EMF of the MPLS-TP NE MUST have the flexibility to configure OAM parameters to meet their specific operational requirements, such as whether (1) one-time on-demand or (2) periodically based on a specified frequency. The EMF of the MPLS-TP NE MUST support the capability to choose which OAM functions to use and which maintenance entity to apply them. The EMF of the MPLS-TP NE MUST support the configuration of maintenance entity identifiers (e.g. MEP ID and MIP ID) for the purpose of connection connectivity checking. The connectivity check process of the MPLS-TP NE needs to be provisioned with the identifiers to transmit, the expected identifiers, and enable/disable the connectivity check processing. The EMF of the MPLS-TP NE MUST support retrieval of the details of the NE's path forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. 7. Performance Requirements Performance Management provides functions to evaluate and report upon the behavior of the equipment, NE, and network for the purpose of Maintenance, Bring-into-service, Quality of service, Gray, et al Expires April, 2009 [Page 12] Internet-Draft MPLS-TP NM Requirements October, 2008 and Performance monitoring for signal degradation. Generic requirements for packet-switched and circuit-switched transport networks are specified in G.7710 [1] with the objective of providing coherent and consistent interpretation of the network behavior, in particular for hybrid network which consists of multiple transport technologies. The performance management requirements specified in this document are driven by such an objective. 7.1. Path Characterization Performance Metrics Packet loss measurement and delay measurement MUST be collected so that they can be used to detect performance degradation. Performance degradation MUST be reported via fault management for corrective actions (e.g. protection switch). Performance degradation MUST be reported via performance monitoring, e.g. as Errored Second (ES), Severely Errored Second (SES), and Unavailable Second (UAS), for Service Level Agreement (SLA) verification and billing. An ES is declared when, during one second period, there is one or more Errored Blocks (EBs) detected, or when a defect is declared. In a packet layer, a block is a packet. An EB is an indication of a lost packet. A SES is declared when, during one second, the number of EBs exceeds a threshold, or when a defect is declared. The number of SESs (and ESs) is summed over 15-minute and 24- hour intervals. A Background Block Error (BBE) is an EB not occurring as part of a SES. The number of BBEs is summed over 15-minute and 24-hour intervals, over which the trend analysis is performed. A period of unavailable time (UAT) begins at the onset of 10 consecutive SES events. These 10 seconds are considered to be part of unavailable time. A new period of available time begins at the onset of 10 consecutive non-SES events. These 10 seconds are considered to be part of available time. The number of unavailable time in seconds (UAS) is summed over 15-minute and 24-hour intervals. Gray, et al Expires April, 2009 [Page 13] Internet-Draft MPLS-TP NM Requirements October, 2008 7.2. SLA Performance Metrics TBD 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics TBD 7.4. Performance Collection Instrumentation 7.4.1. Collection Frequency The performance collection mechanisms MUST support the flexibility to be configured to operate on-demand or proactively. 7.4.2. Collection Granularity On Packet loss measurement: - For bidirectional (P2P) connection, collection of on-demand single-ended packet loss measurement is required. - For bidirectional (P2P) connection, collection of proactive packet loss measurements for both directions is required. - For unidirectional (P2P and P2MP) connection, collection of proactive packet loss measurement is required. On Delay measurement: - For unidirectional (P2P and P2MP) connection, collection of on-demand delay measurement is required. - For bidirectional (P2P) connection, collection of on-demand one-way and two-way delay measurement is required. 8. Security Requirements The EMF of the MPLS-TP NE MUST be able to secure the transport plane and control plane. 8.1. Management Communication Channel Security Secure channels MUST be provided for all network traffic and protocols used to support management functions. This MUST include, at least, protocols used for configuration, monitoring, Gray, et al Expires April, 2009 [Page 14] Internet-Draft MPLS-TP NM Requirements October, 2008 configuration backup, logging, time synchronization, authentication, and routing. The MCC MUST support application protocols that provide confidentiality and data integrity protection. 8.1.1. In-Band management security If in-band management is provided, the MCC MUST require the following: - Use of open cryptographic algorithms (See RFC 3871 [5] section 4.5) - Authentication - Allow management connectivity only from authorized IP addresses or MAC Addresses. 8.1.2. Out-of-Band management security The MPLS TP NE MUST support an out-of-band management console port. The management traffic MUST remain separate from the data and control plane traffic (no routing or forwarding between the management plane and the data/control plane). 8.2. Signaling Communication Channel Security Secure control plane protocols MAY be used in place of their insecure counterparts. If an insecure protocol is used, the transport layer protocol MAY be used to secure the SCC. 8.3. Distributed Denial of Service Denial of Service (DoS) attack is an attack which tries to prevent a target from performing an assigned task, or providing its intended service(s), through any means. A Distributed DoS (DDoS) can multiply attack severity (possibly by an arbitrary amount) by using multiple (potentially compromised) systems to act as topologically (and potentially geographically) distributed attack sources. It is possible to lessen the impact and potential for DDOS by using secure protocols, turning off unnecessary processes, logging and monitoring, and ingress filtering. RFC 4732 [4] provides background on DOS in the context of the Internet. Gray, et al Expires April, 2009 [Page 15] Internet-Draft MPLS-TP NM Requirements October, 2008 9. Security Considerations Section 8 lists a set of security requirements that apply to MPLS-TP network management. Provisions to any of the network mechanisms designed to satisfy the requirements described herein are required to prevent their unauthorized use. Likewise, these network mechanisms MUST provide a means by which an operator can prevent denial of service attacks if those network mechanisms are used in such an attack. Solutions MUST provide mechanisms to prevent this private information from being accessed by unauthorized eavesdropping, or being directly obtained by an unauthenticated network element, system or user. Performance of diagnostic functions and path characterization involves extracting a significant amount of information about network construction that the network operator MAY consider private. 10. IANA Considerations