--- 1/draft-ietf-mpls-tp-nm-req-00.txt 2009-04-16 23:12:10.000000000 +0200 +++ 2/draft-ietf-mpls-tp-nm-req-01.txt 2009-04-16 23:12:10.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent - Expires: August, 2009 Scott Mansfield + Expires: October, 2009 Scott Mansfield Intended Status: Informational Eric Gray Ericsson - February 23, 2009 + April 15, 2009 MPLS TP Network Management Requirements - draft-ietf-mpls-tp-nm-req-00.txt + draft-ietf-mpls-tp-nm-req-01.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. @@ -24,21 +24,21 @@ 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 August 23, 2009. + This Internet-Draft will expire on October 15, 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 @@ -47,51 +47,49 @@ 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....................................7 + 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.2. Alarm Suppression.................................7 5.3.3. Alarm Reporting Control...........................8 5.3.4. Alarm Reporting...................................8 - 6. Configuration Management Requirements.......................9 + 6. Configuration Management Requirements.......................8 6.1. System Configuration...................................9 6.2. Control Plane Configuration............................9 6.3. Path Configuration.....................................9 - 6.4. Protection Configuration..............................10 + 6.4. Protection Configuration...............................9 6.5. OAM Configuration.....................................10 - 7. Performance Management Requirements........................11 - 7.1. Path Characterization Performance Metrics.............11 + 7. Performance Management Requirements........................10 + 7.1. Path Characterization Performance Metrics.............10 7.2. Performance Measurement Instrumentation..............12 7.2.1. Measurement Frequency............................12 7.2.2. Measurement Scope................................12 8. Security Management Requirements...........................13 8.1. Management Communication Channel Security.............13 - 8.1.1. Security of Management Communications............13 - 8.2. Signaling Communication Channel Security..............14 - 8.3. Data Channel Security.................................14 - 8.4. Distributed Denial of Service.........................14 + 8.2. Signaling Communication Channel Security..............13 + 8.3. Distributed Denial of Service.........................13 9. Security Considerations....................................14 - 10. IANA Considerations.......................................15 - 11. Acknowledgments...........................................15 - 12. References................................................15 - 12.1. Normative References.................................15 - 12.2. Informative References...............................16 + 10. IANA Considerations......................................14 + 11. Acknowledgments...........................................14 + 12. References................................................14 + 12.1. Normative References.................................14 + 12.2. Informative References...............................15 13. Author's Addresses........................................16 - Copyright Statement...........................................17 + Copyright Statement...........................................16 Acknowledgment................................................17 APPENDIX A: Communication Channel (CC) Examples...............18 1. Introduction This document describes the requirements necessary to manage the elements and networks that support an MPLS Transport Profile (MPLS-TP). It leverages 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 @@ -155,23 +153,24 @@ 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. + TP NE MAY actively support more than one management protocol in + any given deployment. For example, an MPLS-TP NE may use one + protocol for configuration and another for monitoring. The + protocols to be supported are at the discretion of the operator. 3. Management Communication Channel (MCC) Requirements An MPLS-TP management network SHOULD support seamless management connectivity with remote MPLS-TP domains and NEs as well as with termination points located in NEs under control by a third party network operator. See ITU-T G.8601 [8] for example scenarios in multi-carrier multi-transport-technology environments. For management purpose, every MPLS-TP NE MUST connect to an OS @@ -185,21 +184,21 @@ 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. As a practical requirement, MCN connections require addressing. See the section on addressing in [13] for further information. In order to have the MCN operate properly, a number of - management functions for the MCN are required: + management functions for the MCN are required, including: . 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; @@ -213,73 +212,51 @@ 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 supervision of the OAM mechanisms + that are deployed for supporting the OAM requirements defined in + [3]. + 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; - . Supervision of looping check functions used to detect loops in the data-plane forwarding path (which result in non- delivery of traffic, wasting of forwarding resources and unintended self-replication of traffic); - . Supervision of Alarms based on native OAM, e.g., AIS (Alarm - Indication Signal) and FDI (Forward Defect Indication) - - . Supervision of traffic 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 determination; - - . Supervision of Remote defect indication; - . Supervision of the detection of failure in the sequence of a protocol exchange (e.g. automatic protection switching protocol); - . Supervision of client failure indication. - 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. + 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 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. @@ -325,21 +302,21 @@ See G.7710 [1] for more description about alarm severity assignment. 5.3.2. Alarm Suppression Alarms may be generated from many sources, including OAM, device status, etc. An MPLS-TP NE MUST provide alarm suppression functionality that - prevents the generation of a superfluous alarms. + prevents the generation of superfluous alarms. Examples of alarm suppression mechanisms 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. Note: An MPLS-TP NE supporting the inter-working of one or more networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with MPLS-TP needs to translate an MPLS-TP fault into an existing transport technology failure condition for reporting to the @@ -367,21 +344,21 @@ 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 - on request by maintenance personnel. The MPLS-TP ME SHOULD + on request by maintenance personnel. The MPLS-TP NE 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 @@ -431,24 +408,24 @@ 6.5. OAM Configuration The MPLS-TP NE MUST provide the capability to configure the OAM entities and 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. The MPLS-TP NE MUST support the capability to configure the OAM - entities/functions as part of LSP setup, including bidirectional - point-to-point connections, associated uni-directional point-to- - point connections, and uni-directional point-to-multipoint - connections. + entities/functions as part of LSP setup and tear-down, including + co-routed bidirectional point-to-point, associated bidirectional + point-to-point, and uni-directional (both point-to-point and + point-to-multipoint) connections. The MPLS-TP NE MUST support the configuration of maintenance entity identifiers (e.g. MEP ID and MIP ID) for the purpose of LSP 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. @@ -537,67 +513,61 @@ 7.2.1. Measurement Frequency The performance measurement mechanisms MUST support the flexibility to be configured to operate on-demand or proactively (i.e. continuously over a period of time). 7.2.2. Measurement Scope On measurement of packet loss and loss ratio: - - For bidirectional P2P connections - - - . on-demand measurement of single-ended packet loss, - and loss ratio, measurement are required; - - . proactive measurement of packet loss, and loss - ratio, measurement for each direction are required. - - - For associated unidirectional P2P connections - + - For bidirectional (both co-routed and associated) P2P + connections - . on-demand measurement of single-ended packet loss, and loss ratio, measurement are required; . proactive measurement of packet loss, and loss ratio, measurement for each direction are required. - Note: for associated unidirectional P2P connections, this data + Note: for associated bidirectional P2P connections, this data can only be measured at end-points. - For unidirectional (P2P and P2MP) connection, proactive measurement of packet loss, and loss ratio, are required. On Delay measurement: - For unidirectional (P2P and P2MP) connection, on-demand measurement of delay measurement is required. - - For bidirectional (P2P) connection, on-demand measurement - of one-way and two-way delay are required. + - For co-routed bidirectional (P2P) connection, on-demand + measurement of one-way and two-way delay are required. + + - For associated bidirectional (P2P) connection, on-demand + measurement of one-way delay is required. 8. Security Management Requirements The MPLS-TP NE MUST support secure management and control planes. 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. Security of Management Communications - If management communication security is provided, the MPLS-TP NE MUST support the following: - Use of open cryptographic algorithms (See RFC 3871 [5]) - Authentication - allow management connectivity only from authenticated entities. - Authorization - allow management activity originated by an authorized entity, using (for example) an Access Control @@ -608,122 +578,116 @@ 8.2.Signaling Communication Channel Security Security considerations for the SCC are similar to the considerations driving the requirements described in section 8.1. Security Requirements for the control plane are out of scope for this document and are expected to be defined in the appropriate control plane specifications. Management of the control plane security must also be defined at that time. - 8.3. Data Channel Security - - 8.4.Distributed Denial of Service + 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 + Section 8 includes 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. + Solutions MUST provide mechanisms to prevent unauthorized and/or + unauthenticated access to private information by network + elements, systems or users. 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 -