Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent Expires: August, 2009 Scott Mansfield Intended Status: Informational Eric Gray Ericsson March 2, 2009 MPLS TP Network Management Framework draft-mansfield-mpls-tp-nm-framework-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 2, 2009. Mansfield, et al Expires September 2, 2009 [Page 1] Internet-Draft MPLS-TP NM Framework March 2, 2009 Copyright and License 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. Abstract This document provides the network management framework the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Mansfield, et al Expires September 2, 2009 [Page 2] Internet-Draft MPLS-TP NM Framework March 2, 2009 Table of Contents 1. Introduction................................................4 1.1. Terminology............................................4 2. Management Architecture Consideration.......................5 2.1. Network Management Architecture........................5 2.2. Element Management Architecture........................6 2.3. Standard Management Interfaces.........................7 2.4. Management Channel.....................................7 3. Fault Management Considerations.............................7 4. Configuration Management Considerations.....................7 5. Performance Management Considerations.......................7 6. Security Considerations.....................................8 7. IANA Considerations.........................................8 8. Acknowledgments.............................................8 9. References..................................................8 9.1. Normative References...................................8 9.2. Informative References.................................8 10. Author's Addresses.........................................9 Mansfield, et al Expires September 2, 2009 [Page 3] Internet-Draft MPLS-TP NM Framework March 2, 2009 1. Introduction This document provides a framework for using the MPLS-TP NM requirements [1] for managing the elements and networks that support a Transport Profile for MPLS. 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 [3]. 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 [2]. 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.). 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). Communication Channel (CC): a logical channel between network elements (NEs) that can be used - e.g. - management plane applications or control plane applications. The physical channel supporting the CC is technology specific. An example of physical channels supporting the CC is a DCC channel within SDH. Management Communication Channel (MCC): a CC dedicated for management plane communications. Mansfield, et al Expires September 2, 2009 [Page 4] Internet-Draft MPLS-TP NM Framework March 2, 2009 Signaling Communication Channel (SCC): a CC dedicated for control plane communications. The SCC may be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages). 2. Management Architecture Consideration The management of the MPLS-TP network could be based on a multi- tiered distributed management systems, for example as described in ITU-T M.3010 [4] and M.3060 [5]. Each tier provides a predefined level of network management capabilities. The lowest tier of this organization model includes the MPLS-TP Network Element that provides the transport service and the Operations System (OS) at the Element Management Level. The management application function within the NEs and OSs provides the management support. The management application function at each entity can include agents only, managers only, or both agents and managers. The management application function that include managers are capable of managing an agent included in other management application functions. The management communication to peer NEs and/or Operations System (OSs) is provided via the message communication function within each entity (e.g. NE and OS). The user can access the management of the MPLS-TP transport network via a Local Craft Terminal (LCT) attached to the NE or via a Work Station (WS) attached to the OS. 2.1. Network Management Architecture A transport Management Network (MN) MAY consist of several transport-technology-specific Management Networks. Notation used in G.7710 [2] 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. Where there is no ambiguity, we 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 is 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 could be partitioned into MPLS-TP Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just "MSN" where usage is unambiguous) for consideration of Mansfield, et al Expires September 2, 2009 [Page 5] Internet-Draft MPLS-TP NM Framework March 2, 2009 scalability (e.g. geographic or load balancing) or administrative (e.g. administrative or ownership). The MPLS-TP MSN could be connected to other parts of the MN through one or more LCTs and/or OSs. The message communication function of an MPLS-TP NE initiates/terminates, routes, or otherwise processes management messages over CCs or via an external interface. Multiple addressable MPLS-TP NEs could 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 CCs. Within a particular site, the NEs could communicate via an intra-site CC 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. 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 communication function by performing the appropriate operations on (for example) the Managed Objects in a Management Information Base (MIB), as necessary. The message communication function 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. Mansfield, et al Expires September 2, 2009 [Page 6] Internet-Draft MPLS-TP NM Framework March 2, 2009 2.3. Standard Management Interfaces The MPLS-TP NM requirement document [1] 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 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. 2.4. Management Channel The Communication Channel (CC) provides a logical channel between NEs for transferring Management and/or Signaling information. Note that some technologies provide separate communication channels for Management (MCC) and Signaling (SCC). . MPLS-TP NEs communicate via the DCN. The DCN connects NEs with management systems, NEs with NEs, and management systems with management systems. 3. Fault Management Considerations A fault is an anomaly in the network or network element. Fault management provides the mechanisms to detect, verify, isolate, notify, and recover from the fault. 4. Configuration Management Considerations Configuration management provides the mechanisms to provision the MPLS-TP services, setup security for the MPLS-TP services and MPLS-TP network elements, and provides the destination for fault notifications and performance parameters. 5. Performance Management Considerations Performance statistics can overwhelm a management network, so it is important to provide flexible instrumentation that provides control over the amount of performance data to be collected. A distinction is made between performance data that is collected on-demand and data that is collected proactively. On-demand measurement provides the Mansfield, et al Expires September 2, 2009 [Page 7] Internet-Draft MPLS-TP NM Framework March 2, 2009 operator the ability to issue a command to initiate a measurement. Proactive measurement is something that happens continuously overtime after being configured with a periodicity and storage requirements. 6. Security Considerations 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. 7. IANA Considerations