Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent Expires: April, 2009 Scott Mansfield Intended Status: Informational Eric Gray Ericsson January 16, 2009 MPLS TP Network Management Requirements draft-gray-mpls-tp-nm-req-02.txt 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 July 16, 2009. Abstract This document specifies the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). This document is a product of a joint International Telecommunications Union - Telecommunications Standardization Sector (ITU-T) and Internet Engineering Task Force (IETF) effort to include a MPLS Transport Profile within the IETF MPLS architecture. The requirements are driven by the management functionality needs defined by ITU-T for packet transport networks. Gray, et al Expires July, 2009 [Page 1] Internet-Draft MPLS-TP NM Requirements January, 2009 Table of Contents 1. Introduction................................................3 1.1. Terminology............................................3 2. Management Interface Requirements...........................4 3. Management Communication Channel (MCC) Requirements.........4 4. Management Communication Network (MCN) Requirements.........5 5. Fault Management Requirements...............................5 5.1. Supervision Function...................................5 5.2. Validation Function....................................6 5.3. Alarm Handling Function................................7 5.3.1. Alarm Severity Assignment.........................7 5.3.2. Alarm Suppression.................................8 5.3.3. Alarm Reporting Control...........................8 5.3.4. Alarm Reporting...................................8 6. Configuration Management Requirements.......................9 6.1. Hardware/Software Configuration........................9 6.2. Path Configuration.....................................9 6.3. OAM Configuration......................................9 7. Performance Management Requirements........................10 7.1. Path Characterization Performance Metrics.............10 7.2. Performance Collection Instrumentation................11 7.2.1. Collection Frequency.............................11 7.2.2. Collection Granularity...........................11 8. Security Management Requirements...........................12 8.1. Management Communication Channel Security.............12 8.1.1. In-Band management security......................12 8.1.2. Out-of-Band management security..................12 8.2. Signaling Communication Channel Security..............13 8.3. Distributed Denial of Service.........................13 9. Security Considerations....................................13 10. IANA Considerations.......................................13 11. Acknowledgments...........................................14 12. References................................................14 12.1. Normative References.................................14 12.2. Informative References...............................14 13. Author's Addresses........................................15 Intellectual Property Statement...............................15 Disclaimer of Validity........................................16 Copyright Statement...........................................16 Acknowledgment................................................16 Gray, et al Expires July, 2009 [Page 2] Internet-Draft MPLS-TP NM Requirements January, 2009 1. Introduction This document describes the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). It leverages on the management requirements specified in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 [1] specifies generic management requirements for transport (including packet-based and circuit-based) networks. RFC 4377 specifies the OAM requirements, including OAM-related network management requirements, for MPLS networks. This document expands on the requirements in [1] and [2] to cover fault, configuration, performance, and security management for MPLS-TP networks. 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]. Editor's Note: Do we need the bulk of this section, since it will be in the NM-FRAME document? Should we have the acronyms spelled out in both documents? MPLS-TP NE: a network element (NE) that supports MPLS-TP functions MPLS-TP network: a network in which MPLS-TP NEs are deployed Data Communication Network (DCN): a network that supports Layer 1 (physical layer), Layer 2 (data-link layer), and Layer 3 (network layer) 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.). Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). Gray, et al Expires July, 2009 [Page 3] Internet-Draft MPLS-TP NM Requirements January, 2009 Embedded Communication Channel (ECC): a logical channel between network elements (NEs) that can be used - e.g. - for management plane application or control plane applications. The physical channel supporting the ECC is technology specific. An example of physical channels supporting the ECC is a DCC channel within SDH. Management Communication Channel (MCC): an ECC dedicated for management plane communications. Signaling Communication Channel (SCC): an ECC dedicated for control plane communications. The SCC MAY be used for GMPLS/ASON signaling and/or other control plane messages like e.g., routing messages. 2.Management Interface Requirements This document does not specify which management interface protocol should be the standard protocol for managing MPLS-TP networks. Managing an end-to-end connection across multiple operator domains where one domain is managed (for example) via NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is allowed. For the management interface to the management system, an MPLS- TP NE is not expected to actively support more than one management protocol in any given deployment. The protocol to be supported is at the discretion of the operator. 3. Management Communication Channel (MCC) Requirements The MPLS-TP management network SHOULD support seamless management connectivity with remote MPLS-TP domains and NEs as specified generically in ITU-T G.8601 [8] as well as with termination points located in NEs under control by a third party network operator as specified in G.8601. For management purpose, every MPLS-TP NE MUST connect to an OS either directly or indirectly via another MPLS-TP NE. When an MPLS-TP NE is connected indirectly to an OS, an MCC MUST be supported between the MPLS-TP NE and the other MPLS-TP NE. Gray, et al Expires July, 2009 [Page 4] Internet-Draft MPLS-TP NM Requirements January, 2009 4.Management Communication Network (MCN) Requirements Entities of the MPLS-TP management plane communicate via the DCN, or more specifically via the MCN. The MCN connects MPLS-TP NEs with management systems, NEs with NEs, and management systems with management systems. Transport 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 MCN operate properly, a number of management functions for the MCN are required: . Retrieval of DCN 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 DCN network addresses; . Retrieval of operational status of the DCN at a given node; . Capability to enable/disable access to the DCN. 5.Fault Management Requirements The Fault Management functions within 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 MUST support the following transmission supervision functions: . Supervision of continuity check functions used to detect a broken connection; . Supervision of connectivity check functions used to detect misconnection; Gray, et al Expires July, 2009 [Page 5] Internet-Draft MPLS-TP NM Requirements January, 2009 . Supervision of looping check functions used to detect unintended self-replication; . Supervision of Alarms based on native OAM, e.g., AIS (Alarm Indication Signal) and FDI (Forward Defect Indication) . Supervision of Lock indication; . Supervision of Packet loss measurement in both directions of the bidirectional connection; . Supervision of Misinsertion check function used to detect misinserted packet in the connection . Supervision of Diagnostic test; . Supervision of Route tracing; . Supervision of Remote defect indication; . Supervision of the detection of failure in the sequence of a protocol exchange (e.g. automatic protection switching protocol); The MPLS-TP NE transmission-related supervision mechanisms MUST support the flexibility to be configured to perform on-demand or proactively. The MPLS-TP NE MUST support supervision for software processing e.g., processing fault, storage capacity problem, version mismatch, Corrupted data, Out of memory, etc. The MPLS-TP NE MUST support hardware-related supervision for interchangeable and non-interchangeable units, cable, and power problem. The MPLS-TP NE SHOULD support environment-related supervision for temperature, humidity, etc. The MPLS-TP NE MUST support supervision of the OAM mechanisms that are deployed for supporting the OAM requirements defined in [3]. 5.2. Validation Function Validation is concerned with the integration of Fault Causes into Failures. A Fault Cause indicates a limited interruption of Gray, et al Expires July, 2009 [Page 6] Internet-Draft MPLS-TP NM Requirements January, 2009 the required transport function. A Fault Cause is not reported to maintenance personnel because it could exist only for a very short time. Note that 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 transport function arises. This Failure condition is subject to reporting to maintenance personnel and/or OS because corrective action might be required. Conversely, when the Fault Cause ceases after a certain time, clearing of the Failure condition also subject to reporting. The MPLS-TP NE MUST perform persistency check on fault causes before it declares a fault cause a failure. A transmission failure SHALL be declared if the fault cause persists continuously for a configurable time (Time-D). The failure SHALL be cleared if the fault cause is absent continuously for a configurable time (Time-C). Typically the default time values would be as follows: Time-D = 2.5 +/- 0.5 seconds Time-C = 10 +/- 0.5 seconds These time values are as defined in G.7710 [1]. 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. 5.3. Alarm Handling Function 5.3.1. Alarm Severity Assignment Failures might be categorized to indicate the severity or urgency of the fault. An MPLS-TP NE SHOULD support the flexibility of assignment of severity (e.g., Critical, Major, Minor, Warning) by the management system. Gray, et al Expires July, 2009 [Page 7] Internet-Draft MPLS-TP NM Requirements January, 2009 See G.7710 [1] for more description about alarm severity assignment. 5.3.2. Alarm Suppression An MPLS-TP NE MUST provide alarm suppression functionality that prevents the generation of a superfluous generation of alarms. Examples of alarm suppression mechanism include simply discarding the alarms (or not generating them in the first place), or aggregating the alarms together, thereby greatly reducing the number of alarm notifications to be emitted. An MPLS-TP NE supporting the inter-working of one or more networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS) with 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 (e.g., LSP) 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. An MPLS-TP NE SHOULD support the Alarm Reporting Control function for controlling the reporting of alarm conditions. See G.7710 [1] and RFC 3878 [1] for more description of ARC. 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). Local reporting is concerned with automatic alarming by means of audible and visual indicators near the failed equipment. An MPLS-TP NE MUST support local reporting of alarms. The MPLS-TP NE MUST support reporting of alarms to an OS. These reports are either autonomous reports (notifications) or reports Gray, et al Expires July, 2009 [Page 8] Internet-Draft MPLS-TP NM Requirements January, 2009 on request by maintenance personnel. The MPLS-TP ME SHOULD report local (environmental) alarms to a network management system. 6. Configuration Management Requirements Configuration Management provides functions to identify, collect data from, provide data to and control NEs. Specific configuration tasks requiring network management support include hardware and software configuration, configuration of NEs to support transport paths (including required working and protection paths), and configuration of required path integrity/connectivity and performance monitoring (i.e. - OAM). 6.1. Hardware/Software Configuration The MPLS-TP NE MUST support the configuration requirements specified in G.7710 [1] for hardware, software, and date/time. 6.2. Path Configuration The MPLS-TP NE MUST support the capability of configuring required working and/or protection paths. The MPLS-TP NE MUST support the capability of configuring required path performance characteristic thresholds (e.g. - Loss Measurement [LM], Delay Measurement [DM] thresholds). The MPLS-TP NE MUST support the capability of configuring required path protection as follows: . configure some paths as working and others as protection; . retrieve the status of these paths; . configure the wait to restore time; . operate/release manual protection switching; . operate/release force protection switching; . operate/release protection lockout; . request/set automatic protection switching (APS) parameters. 6.3. OAM Configuration The MPLS-TP NE MUST provide the capability of configuring the OAM functions specified in [3]. The MPLS-TP NE MUST support the capability to choose which OAM functions to use and which maintenance entity to apply them. Gray, et al Expires July, 2009 [Page 9] Internet-Draft MPLS-TP NM Requirements January, 2009 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 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 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 immediately or (2) one-time on-demand pre-scheduled or (3) on-demand periodically based on a specified schedule or (4) proactive on-going. The MPLS-TP NE MUST support the enabling/disabling of the connectivity check processing. The connectivity check process of the MPLS-TP NE MUST support provisioning of the identifiers to be transmitted and the expected identifiers. 7. Performance Management 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, and Performance monitoring for signal degradation. ITU-T Recommendation G.7710 [1] provides transport performance monitoring requirements for packet-switched and circuit-switched transport networks 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 The MPLS-TP NE MUST support collection of loss measurement (LM) so that they can be used to detect performance degradation. The MPLS-TP NE MUST support collection of delay measurement (DM) so that they can be used to detect performance degradation. The MPLS-TP NE MUST support reporting of Performance degradation via fault management for corrective actions (e.g. protection switching). Gray, et al Expires July, 2009 [Page 10] Internet-Draft MPLS-TP NM Requirements January, 2009 The MPLS-TP NE MUST support collection of loss ratio measurement so that they can be used to determine Severely Errored Second (SES). A SES is declared for a one second interval when the ratio of lost packets to total transmitted packets in that one second interval exceeds a predetermined threshold. The packet lost threshold for declaring SES MUST be configurable. The number of SESs MUST be collected per configurable intervals (e.g. 15-minute and 24-hour). The MPLS-TP NE MUST support collection of SES measurement so that they can be used to determine service unavailable time. 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 MPLS-TP NE MUST support collection of UAS so that they can be used to determine service availability. The number of unavailable time in seconds (UAS) MUST be collected per configurable intervals (e.g. 15-minute and 24- hour). 7.2.Performance Collection Instrumentation 7.2.1. Collection Frequency The performance collection mechanisms MUST support the flexibility to be configured to operate on-demand or proactively (i.e. continuously). 7.2.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. Gray, et al Expires July, 2009 [Page 11] Internet-Draft MPLS-TP NM Requirements January, 2009 - 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 Management Requirements 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, 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 support 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). Gray, et al Expires July, 2009 [Page 12] Internet-Draft MPLS-TP NM Requirements January, 2009 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. 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