Network Working Group Hing-Kam Lam Internet Draft Alcatel-Lucent Expires: October, 2009 Scott Mansfield Intended Status: Informational Eric Gray Ericsson April 23, 2009 MPLS TP Network Management Framework draft-mansfield-mpls-tp-nm-framework-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. 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 October 23, 2009. Mansfield, et al Expires October 23, 2009 [Page 1] Internet-Draft MPLS-TP NM Framework April 23, 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 October 23, 2009 [Page 2] Internet-Draft MPLS-TP NM Framework April 23, 2009 Table of Contents 1. Introduction................................................4 1.1. Terminology............................................4 2. Management Architecture Consideration.......................5 2.1. Network Management Architecture........................6 2.2. Element Management Architecture........................7 2.3. Standard Management Interfaces........................10 2.4. Management and Control specific terminology...........11 2.5. Management Channel....................................11 3. Fault Management Considerations............................13 3.1. Supervision...........................................13 3.2. Validation............................................13 3.3. Alarm Handling........................................13 4. Configuration Management Considerations....................13 4.1. LSP ownership handover................................13 5. Performance Management Considerations......................14 6. Security Considerations....................................15 7. IANA Considerations........................................15 8. Acknowledgments............................................15 9. References.................................................15 9.1. Normative References..................................15 9.2. Informative References................................16 10. Author's Addresses........................................16 Mansfield, et al Expires October 23, 2009 [Page 3] Internet-Draft MPLS-TP NM Framework April 23, 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]. 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. 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.). Equipment Management Function (EMF): the management functions within an NE. See ITU-T G.7710 [2]. Local Craft Terminal (LCT): An out-of-band device that connects to an NE for management purposes. Management Application Function (MAF): An application process that participates in system management. See ITU-T G.7710 [2]. Management Communication Channel (MCC): a CC dedicated for management plane communications. Message Communication Function (MCF): The communications process that performs functions such as information interchange and relay. See ITU-T M.3013 [10]. Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). Mansfield, et al Expires October 23, 2009 [Page 4] Internet-Draft MPLS-TP NM Framework April 23, 2009 MPLS-TP NE: a network element (NE) that supports MPLS-TP functions. MPLS-TP network: a network in which MPLS-TP NEs are deployed. Network Element Function (NEF): The set of functions necessary to manage a network element. Operations System (OS): A system that performs the functions that support processing of information related to operations, administration, maintenance, and provisioning (OAM&P) for the networks, including surveillance and testing functions to support customer access maintenance. Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). 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 [7] and M.3060 [8]. 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. Mansfield, et al Expires October 23, 2009 [Page 5] Internet-Draft MPLS-TP NM Framework April 23, 2009 2.1.Network Management Architecture A transport Management Network (MN) MAY consist of several transport technology specific Management Networks. Figure 1 below from G.7710 [2] shows an example of management network partitioning. Notation used in G.7710 for a transport technology specific MN is x.MN, where x is the transport specific technology. In the example "O.MSN" is equivalent to an optical management subnetwork, and "S.MSN" is equivalent to an SDH management subnetwork. A MPLS-TP specific MN might be abbreviated as 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. ______________________________ ______________________________ |.-------.-------.----.-------.||.-------.-------.----.-------.| |: : : : :||: : : : :| |:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:S.MSN-1:S.MSN-2: .. :S.MSN-n:| |: : : : :||: : : : :| '-============================-''-============================-' _______________________________ |.-------.-------.-----.-------.| |: : : : :| |:x.MSN-1:x.MSN-2: ... :x.MSN-n:| |: : : : :| '-=============================-' Figure 1 Management Network Partitioning 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 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 (MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise processes management messages over CCs or via an external interface. Mansfield, et al Expires October 23, 2009 [Page 6] Internet-Draft MPLS-TP NM Framework April 23, 2009 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. Below are diagrams that illustrate the components of the element management function of a network element. Figure 2 provides the breakdown of the Network Element Function, then Figure 3 provides the details of Equipment Management Function, and finally Figure 4 details the Message Communication Function. Mansfield, et al Expires October 23, 2009 [Page 7] Internet-Draft MPLS-TP NM Framework April 23, 2009 ___________________________________________________ | Network Element Function (NEF) | | _________________________ _______________________ | || Equipment Control || Transport Plane || || Function || Atomic Function || ||_________________________||_______________________|| | | |___________| | | | | Management Control Management | | | | Information Information Information | | | |__ ____________| | | ____|____________________________|___ | | | (from date/time)<-----------+ | | | Equipment | | | | | Management (to/from management)<--------+ | | | | Function | | | | | | (EMF) (to/from control)<-----+ | | | | | | | | | | | | (to local alarm)---+ | | | | | |_____________________________________| | | | | | | | | | | | | +--------------------------------------+ | | | | | | +---------------------------------------+ | | | | | | +----------------------------------------+ | | | | | | +-----------------------------------------+ | | | | | | Date & Time _________________ |external | | | | | Info | Message | |time | | | | +-------------- Communication <----------------------- | | | | | Function (MCF) | | | | | | Management | | |management | | | +----------------> | |element | | | Plane Info | <----------------------> | | | | | | | | | Control Plane | | | | | +------------------> | | | | Information | | |control | | | | |element | | Local Alarm | <----------------------> | +--------------------> | | | Information | | |to local | | | |alarms | |_________________---------------------> |____________________________________________________| Figure 2 High-level decomposition of NEF Mansfield, et al Expires October 23, 2009 [Page 8] Internet-Draft MPLS-TP NM Framework April 23, 2009 _______________________________________ | ________________________ | | Equipment | Management Application || | Management | Function (MAF) || | Function | _____ || | (EMF) || | _______________|| | ___________||___ | | || | | | | | Date & Time || | | Date & Time | | | Interface |<-- 1 | | Functions | | |_______________|| | |________________| | _______________|| | ___________||___ | | || | | | | | Management || | |Fault Management| | | Plane |<-> 2 | |________________| | | Interface || | ___________||___ | |_______________|| | | | | _______________ | | | Configuration | | | || | | Management | | | Control Plane || | |________________| | | Interface |<-> 3 | ___________||___ | |_______________|| | | | | | | | Account | | | | | Management | | | | |________________| | | | ___________||___ | | | | | | | | | Performance | | | | | Management | | | | |________________| | | | ___________||___ | | | | | | | | | Security | | | | | Management | | _______________ | | |________________| | | || | || | | Local Alarm || | +----->|Agent| | Interface |--> 4 | v ||_____| |_______________|| | .-===-. |_________________________| | | MIB | | | `-._.-' | |_______________________________________| Figure 3 Equipment Management Function Mansfield, et al Expires October 23, 2009 [Page 9] Internet-Draft MPLS-TP NM Framework April 23, 2009 _________________ | | | Message | | Communication | | Function (MCF) | | _______________ | Date & Time || || external 1 <--------------| Date & Time <----------------- Information || Communication || time source ||_______________|| | | | _______________ | Management || || management Plane || Management || element 2 <---------------> Plane <---------------> Information || Communication || (e.g. - EMS, ||_______________|| peer NE) | | | _______________ | control Control Plane || || element 3 <---------------> Control Plane <---------------> Information || Communication || (e.g. - EMS, ||_______________|| peer NE) | : | | : | | : | | _______________ | Local Alarm || || to local 4 ----------------> Local Alarm |---------------> Information || Communication || alarms... ||_______________|| |_________________| Figure 4 Message Communication Function 2.3.Standard Management Interfaces The MPLS-TP NM requirement document [1] places no restriction on which management interface is 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 Mansfield, et al Expires October 23, 2009 [Page 10] Internet-Draft MPLS-TP NM Framework April 23, 2009 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 and Control specific terminology Data Communication Network (DCN) is the common term for the network used to transport Management and Signaling information between: management systems and network elements, management systems to other management systems, and networks elements to other network elements. The Management Communications Network (MCN) is the part of the DCN which supports the transport of Management information for the Management Plane. The Signaling Communications Network (SCN) is the part of the DCN which supports transport for signaling information for the Control Plane. As shown in Figure 5 each technology has its own terminology that is used for the channels that support management and control plane information transfer. For MPLS-TP, the management plane uses the Management Communication Channel (MCC) and the control plane uses the Signaling Communication Channel (SCC). 2.5. 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. Mansfield, et al Expires October 23, 2009 [Page 11] Internet-Draft MPLS-TP NM Framework April 23, 2009 Common Terminology |----| /-> | NE |\ |----------| |----------| / |----| \ |----| | | <---> | | |(CC) | NE | |----------| |----------| \ |----| / |----| Management Operations \-> | NE |/ Station System |----| Network Elements use a Communication Channel (CC) for Transport of Management Information Management Terminology |----| /-> | NE |\ |----------| |----------| / |----| \ |----| | | <---> | | |(MCC) | NE | |----------| |----------| \ |----| / |----| Management Operations \-> | NE |/ Station System |----| Network Elements use a Management Communication Channel (MCC) for Transport of Management Information Control Terminology |----| /-> | NE |\ |----------| |----------| / |----| \ |----| | | <---> | | |(SCC) | NE | |----------| |----------| \ |----| / |----| Management Operations \-> | NE |/ Station System |----| Network Elements use a Control/Signaling Communication Channel (SCC) for Transport of Signaling Information Figure 5 Communication Channel Terminology Mansfield, et al Expires October 23, 2009 [Page 12] Internet-Draft MPLS-TP NM Framework April 23, 2009 3. Fault Management Considerations A fault is the inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. Fault management provides the mechanisms to detect, verify, isolate, notify, and recover from the fault. 3.1. Supervision G.7710 [2] lists five basic categories of supervision that provide the functionality necessary to detect, verify, and notify a fault. The categories are: Transmission Supervision, Quality of Service Supervision, Processing Supervision, Hardware Supervision, and Environment Supervision. Each of the categories provides a set of recommendations to ensure the fault management process is fulfilled. 3.2. Validation G.7710 [2] describes a fault cause as a limited interruption of the required function. It is not reasonable for every fault cause to be reported to maintenance personnel. The validation process is used to turn fault causes (events) into failures (alarms). 3.3. Alarm Handling Within an element management system, it is important to consider mechanisms to support severity assignment, alarm reporting control, and logging. 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. Inventory reporting is also considered part of configuration management. Associated with configuration management are hardware and software provisioning and inventory reporting. 4.1. LSP ownership handover MPLS-TP networks can be managed not only by Network Management Systems (i.e. management plane), but also by control plane protocols. Mansfield, et al Expires October 23, 2009 [Page 13] Internet-Draft MPLS-TP NM Framework April 23, 2009 The utilization of the control plane is not a mandatory requirement (see MPLS-TP Requirements [4]) but it is often used by network operators in order to make network configuration and LSP recovery both faster and simpler. In networks where both CP and MP are provided, an LSP could be created by either (CP or MP). The entity creating an LSP owns the data plane resources comprising that LSP. Only the owner of an LSP is typically able modify/delete it. This results in a need for interaction between the MP and CP to allow either to manage all the resources of a network. Network operators might prefer to have full control of the network resources during the set-up phase and then allow the network to be automatically maintained by the control plane. This can be achieved by creating LSPs via the management plane and subsequently transferring LSP ownership to the control plane. This is referred to as "ownership handover" [9]. MP to CP ownership handover is then considered a requirement [9] where a control plane is in use that supports it. The converse (CP to MP ownership handover) is a feature that is recommended - but not required - for (G)MPLS networks because it has only minor applications (for example moving LSPs from one path to another as a maintenance operation). The LSP handover procedure has already been standardized for GMPLS networks, where the signaling protocol used is RSVP-TE [5]. The utilization of RSVP-TE enhancements are defined in [6]. MP and CP interworking includes also the exchange of information that is either requested by the MP, or a notification by the CP as a consequence of a request from the MP or an automatic action (for example a failure occurs or an operation is performed). The CP is asked to notify the MP in a reliable manner about the status of the operations it performs and to provide a mechanism to monitor the status of control plane objects (e.g. TE Link status, available resources), and to log control plane LSP related operations. Logging is one of the most critical aspects because the MP always needs to have an accurate history and status of each LSP and all data plane resources involved in it. 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 October 23, 2009 [Page 14] Internet-Draft MPLS-TP NM Framework April 23, 2009 operator the ability to issue a command to initiate a measurement. Proactive measurement is something that happens continuously over time after being configured with a periodicity and storage requirements. Data collected from proactive measurement are usually used for verifying the performance of the LSP service, while data collected from on-demand measurement are usually used for maintenance purposes such as diagnose or to provide detailed verification of proactive measurement. 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 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 There are no IANA actions associated with this document. 8. Acknowledgments The authors/editors gratefully acknowledge the thoughtful review, comments and explanations provided by Diego Caviglia and Bernd Zeuner. 9. References 9.1. Normative References [1] Lam, H.K., et al., "MPLS TP Network Management Requirements", work in progress. [2] ITU-T Recommendation G.7710/Y.1701, "Common equipment management function requirements", July, 2007. Mansfield, et al Expires October 23, 2009 [Page 15] Internet-Draft MPLS-TP NM Framework April 23, 2009 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [4] Niven-Jenkins, B., et al., "MPLS-TP Requirements", work in progress. [5] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [6] Caviglia, D., et al., "RSVP-TE Signaling Extension For The Conversion Between Permanent Connections And Soft Permanent Connections In A GMPLS Enabled Transport Network", work in progress. 9.2.Informative References [7] ITU-T Recommendation M.3010, "Principles for a telecommunication management network", April 2005. [8] ITU-T Recommendation M.3060/Y.2401, "Principles for the Management of Next Generation Networks", March 2006. [9] Caviglia, D., et al., "Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network", RFC 5493, April 2009. [10] ITU-T Recommendation M.3013, "Considerations for a telecommunications management network", February 2000. 10.Author's Addresses Editors: Scott Mansfield Ericsson 5000 Ericsson Drive Warrendale, PA, 15086 Phone: +1 724 742 6726 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 Mansfield, et al Expires October 23, 2009 [Page 16] Internet-Draft MPLS-TP NM Framework April 23, 2009 Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851 Phone: +1 978 275 7470 Email: eric.gray@ericsson.com Author(s): Contributor(s): Mansfield, et al Expires October 23, 2009 [Page 17]