--- 1/draft-ietf-mpls-tp-nm-req-04.txt 2009-09-19 02:12:10.000000000 +0200 +++ 2/draft-ietf-mpls-tp-nm-req-05.txt 2009-09-19 02:12:10.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent - Expires: March, 2010 Scott Mansfield +Expires: March 18, 2010 Scott Mansfield Intended Status: Standards Track Eric Gray Ericsson - September 1, 2009 + September 18, 2009 MPLS TP Network Management Requirements - draft-ietf-mpls-tp-nm-req-04.txt + draft-ietf-mpls-tp-nm-req-05.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 March 1, 2010. + This Internet-Draft will expire on March 14, 2010. Abstract This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in @@ -130,27 +130,26 @@ cover fault, configuration, performance, and security management for MPLS-TP networks, and the requirements for object and information models needed to manage MPLS-TP Networks and Network Elements. In writing this document, the authors assume the reader is familiar with references [12] and [15]. 1.1. Terminology - Although this document is not a protocol specification, 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 [5] - and are to be interpreted as instructions to protocol designers - producing solutions that satisfy the requirements set out in - this document. + 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 [5]. Although + this document is not a protocol specification, the use of this + language clarifies the instructions to protocol designers producing + solutions that satisfy the requirements set out in this document. Anomaly: The smallest discrepancy which can be observed between actual and desired characteristics of an item. The occurrence of a single anomaly does not constitute an interruption in ability to perform a required function. Anomalies are used as the input for the Performance Monitoring (PM) process and for detection of defects (from [21], 3.7). Communication Channel (CCh): A logical channel between network elements (NEs) that can be used - e.g. - for management or @@ -191,21 +190,21 @@ Management Communication Channel (MCC): A CCh dedicated for management plane communications. Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). MPLS-TP NE: A network element (NE) that supports the functions of MPLS necessary to participate in an MPLS-TP based transport - service. See [8] for further information on functionality + service. See [7] for further information on functionality required to support MPLS-TP. MPLS-TP network: a network in which MPLS-TP NEs are deployed. OAM, On-Demand and Proactive: One feature of OAM that is largely a management issue is control of OAM; on-demand and proactive are modes of OAM mechanism operation defined - for example - in Y.1731 ([22] - 3.45 and 3.44 respectively) as: . On-demand OAM - OAM actions which are initiated via manual @@ -268,29 +267,28 @@ provide the connection to an OS. 4. Management Communication Network (MCN) Requirements Entities of the MPLS-TP management plane communicate via a DCN, or more specifically via the MCN. The MCN connects management systems with management systems, management systems with MPLS-TP NEs, and (in the indirect connectivity case discussed in section 3) MPLS-TP NEs with MPLS-TP NEs. - RFC 5586 (Error! Reference source not found.) defines a Generic - Associated Channel (G-ACh) to enable the realization of a - communication channel (CCh) between adjacent MPLS-TP NEs for - management and control. Reference [7] describes how the G-ACh - may be used to provide infrastructure that forms part of the MCN - and SCN. It also explains how MCN and SCN messages are - encapsulated, carried on the G-ACh, and decapsulated for - delivery to management or signaling/routing control plane - components on a label switching router (LSR). + RFC 5586 [13] defines a Generic Associated Channel (G-ACh) to + enable the realization of a communication channel (CCh) between + adjacent MPLS-TP NEs for management and control. Reference [8] + describes how the G-ACh may be used to provide infrastructure + that forms part of the MCN and SCN. It also explains how MCN and + SCN messages are encapsulated, carried on the G-ACh, and + decapsulated for delivery to management or signaling/routing + control plane components on a label switching router (LSR). ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN architecture and requirements. The MPLS-TP MCN MUST support the requirements (in reference [6]) for: - CCh access functions specified in section 7.1.1; - MPLS-TP SCC data-link layer termination functions specified in section 7.1.2.3; @@ -311,22 +309,22 @@ In order to have the MCN operate properly, a number of management functions for the MCN are needed, 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; + . Retrieval of operational status of the DCN at a given node; . Capability to enable/disable access by an NE to the DCN. Note that this is to allow isolating a malfunctioning NE from impacting the rest of the network. 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. @@ -528,24 +526,24 @@ If a control plane is supported in an implementation of MPLS-TP, the MPLS-TP NE MUST support the configuration of MPLS-TP control plane functions by the management plane. Further detailed requirements will be provided along with progress in defining the MPLS-TP control plane in appropriate specifications. 6.3. Path Configuration In addition to the requirement to support static provisioning of - transport paths (defined in [8], section 2.1 - General + transport paths (defined in [7], section 2.1 - General Requirements - requirement 18), an MPLS-TP NE MUST support the configuration of required path performance characteristic - thresholds (e.g. - Loss Measurement [LM], Delay Measurement [DM] + thresholds (e.g. - Loss Measurement , Delay Measurement thresholds) necessary to support performance monitoring of the MPLS-TP service(s). In order to accomplish this, an MPLS-TP NE MUST support configuration of LSP information (such as an LSP identifier of some kind) and/or any other information needed to retrieve LSP status information, performance attributes, etc. If a control plane is supported, and that control plane includes support for control-plane/management-plane hand-off for LSP @@ -704,21 +702,21 @@ For performance measurement mechanisms that support both proactive and on-demand modes, the MPLS-TP NE MUST support the capability to be configured to operate on-demand or proactively. 7.2.2. Measurement Scope On measurement of packet loss and loss ratio: . For bidirectional (both co-routed and associated) P2P - connections - + connections: o on-demand measurement of single-ended packet loss, and loss ratio, measurement is REQUIRED; o proactive measurement of packet loss, and loss ratio, measurement for each direction is REQUIRED. . for unidirectional (P2P and P2MP) connection, proactive measurement of packet loss, and loss ratio, is REQUIRED. @@ -828,41 +826,42 @@ 12.1. Normative References [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007. [2] Nadeau, T., et al, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006. [3] Vigoureux, M., et al, "Requirements for OAM in MPLS - Transport Networks", work in progress. + Transport Networks", draft-ietf-mpls-tp-oam-requirements, + work in progress. [4] Jones, G., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and specification of data communication network", June 2008. - [7] Beller, D., et al, "An Inband Data Communication Network - For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- - dcn, work in progress. - - [8] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- + [7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- ietf-mpls-tp-requirements, work in progress. 12.2. Informative References + [8] Beller, D., et al, "An Inband Data Communication Network + For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- + dcn, work in progress. + [9] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004. [10] ITU-T Recommendation M.20, "Maintenance philosophy for telecommunication networks", October 1992. [11] Telcordia, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 5, August 2004. @@ -874,22 +873,22 @@ [14] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", draft-ietf-opsawg-operations-and-management, work in progress. [15] Mansfield, S. et al, "MPLS-TP Network Management Framework", draft-ietf-mpls-tp-nm-framework, work in progress. - [16] Enns, R. et al, "NETCONF Configuration Protocol", draft- - ietf-netconf-4741bis, work in progress. + [16] Enns, R. et al, "NETCONF Configuration Protocol", + draft-ietf-netconf-4741bis, work in progress. [17] McCloghrie, K. et al, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [18] OMG Document formal/04-03-12, "The Common Object Request Broker: Architecture and Specification", Revision 3.0.3. March 12, 2004. [19] Caviglia, D. et al, "Requirements for the Conversion between Permanent Connections and Switched Connections in @@ -915,23 +914,21 @@ [24] Lam, H., et al, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004. [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and availability performance", January 2009. [26] Handley, M., et al, "Internet Denial-of-Service Considerations", RFC 4732, November 2006. - Author's Addresses - - Editors: +Editors' Addresses Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 Phone: +1 978 275 7470 Email: Eric.Gray@Ericsson.com Scott Mansfield Ericsson @@ -940,23 +937,21 @@ +1 724 931 9316 EMail: Scott.Mansfield@Ericsson.com Hing-Kam (Kam) Lam Alcatel-Lucent 600-700 Mountain Ave Murray Hill, NJ, 07974 Phone: +1 908 582 0672 Email: hklam@Alcatel-Lucent.com - Author(s): - - Contributor(s): +Contributor's Address Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.