MPLS-TP Network Management Framework
draft-ietf-mpls-tp-nm-framework-05

Abstract

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.

The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.

This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call.

[RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.]

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 August 26, 2010.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
    1.1.  Terminology
2.  Management Architecture
    2.1.  Network Management Architecture
    2.2.  Element Management Architecture
    2.3.  Standard Management Interfaces
    2.4.  Management and Control specific terminology
    2.5.  Management Channel
3.  Fault Management
    3.1.  Supervision
    3.2.  Validation
    3.3.  Alarm Handling
4.  Configuration Management
    4.1.  LSP ownership handover
5.  Performance Management
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

1.  Introduction

This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Requirements for network management in an MPLS-TP network are documented in MPLS-TP NM requirements (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.) [3], and this document explains how network elements and networks that support MPLS-TP can be managed using solutions that satisfy those requirements. The relationship between OAM, management and other framework documents is described in the MPLS-TP framework (Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” April 2010.) [4] document.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network.

1.1.  Terminology

This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The terminology listed below are taken from/based on the definitions found in ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6], ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7] and ITU-T M.3013 (International Telecommunication Union, “Considerations for a telecommunication management network,” February 2000.) [13].

• Communication Channel (CCh): A logical channel between network elements (NEs) that can be used in (for example) management plane applications or control plane applications. For MPLS-TP, the physical channel supporting the CCh is the MPLS-TP Management Communication Channel (MCC).
• 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.). See ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7].
• Equipment Management Function (EMF): The management functions within an NE. See ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6].
• Local Craft Terminal (LCT): An out-of-band device that connects to an NE for management purposes. See ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6].
• Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a subset of the capabilities of an MPLS LSP in order to meet the requirements of an MPLS transport network as described in the MPLS-TP framework (Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, “A Framework for MPLS in Transport Networks,” April 2010.) [4].
• Management Application Function (MAF): An application process that participates in system management. See ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6].
• Management Communication Channel (MCC): A CCh dedicated for management plane communications. See ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7].
• Message Communication Function (MCF): The communications process that performs functions such as information interchange and relay. See ITU-T M.3013 (International Telecommunication Union, “Considerations for a telecommunication management network,” February 2000.) [13].
• Management Communication Network (MCN): A DCN supporting management plane communication is referred to as a Management Communication Network (MCN). See ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7].
• MPLS-TP NE: A network element (NE) that supports MPLS-TP functions. Another term that is used for a network element is node. In terms of this document, the term node is equivalent to NE.
• 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. See ITU-T M.3010 (International Telecommunication Union, “Principles for a telecommunication management network,” April 2005.) [11].
• Operations, Administration and Maintenance (OAM): For the MPLS-TP effort the term OAM means the set of tools that consist of "operation" activities that are undertaken to keep the network up and running, "administration" activities that keep track of resources in the network and how they are used, and "maintenance" activities that facilitate repairs and upgrades. For a complete expansion of the acronym see The OAM Acronym Soup (Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, “"The OAM Acronym Soup",” February 2010.) [15].
• Operations System (OS): A system that performs the functions that support processing of information related to operations, administration, maintenance, and provisioning (OAM&P) (see The OAM Acronym Soup (Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, “"The OAM Acronym Soup",” February 2010.) [15]) for the networks, including surveillance and testing functions to support customer access maintenance. See ITU-T M.3010 (International Telecommunication Union, “Principles for a telecommunication management network,” April 2005.) [11].
• Signaling Communication Network (SCN): A DCN supporting control plane communication is referred to as a Signaling Communication Network (SCN). See ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7].
• Signaling Communication Channel (SCC): A CCh dedicated for control plane communications. The SCC may be used for GMPLS/ASON signaling and/or other control plane messages (e.g., routing messages). See ITU-T G.7712 (International Telecommunication Union, “Architecture and specification of data communication network,” June 2008.) [7].

2.  Management Architecture

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 (International Telecommunication Union, “Principles for a telecommunication management network,” April 2005.) [11] and ITU-T M.3060/Y.2401 (International Telecommunication Union, “Principles for the Management of Next Generation Networks,” March 2006.) [12]. 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 (MAF) within the NEs and OSs provides the management support. The MAF at each entity can include agents only, managers only, or both agents and managers. The MAF that include managers are capable of managing an agent included in other MAF.

The management communication to peer NEs and/or Operations Systems (OSs) is provided via the Message Communication Function (MCF) 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. Management network partitioning below based on ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6] shows the management network partitioning. Notation used in G.7710 for a transport technology specific MN is x.MN, where x is the transport specific technology. An MPLS-TP specific MN is abbreviated as MT.MN. Where there is no ambiguity, we will use "MN" for an MPLS-TP specific MN. In the figure below O.MSN is equivalent to an OTN management Subnetwork.

 ______________________________  _________________________________
|.-------.-------.----.-------.||.--------.--------.----.--------.|
|:       :       :    :       :||:        :        :    :        :|
|:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:MT.MSN-1:MT.MSN-2: .. :MT.MSN-n:|
|:       :       :    :       :||:        :        :    :        :|
'-============================-''-===============================-'
                _______________________________
               |.-------.-------.-----.-------.|
               |:       :       :     :       :|
               |:x.MSN-1:x.MSN-2: ... :x.MSN-n:|
               |:       :       :     :       :|
               '-=============================-'

Management Network Partitioning

The management of the MPLS-TP network is separable from the management of the other technology-specific networks, and operates independently of any particular client or server layer management plane.

An MPLS-TP Management Network (MT.MN) could be partitioned into MPLS-TP Management SubNetworks ("MT.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 CChs 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 CChs. Within a particular site, the NEs could communicate via an intra-site CCh 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 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, FCAPS (Fault, Configuration, Accounting, Performance and Security) management, and Control Plane 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 (MCF) by performing the appropriate operations on (for example) the Managed Objects in a Management Information Base (MIB), as necessary. The MCF 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 (EMF) of a Network Element (NE). The high-level decomposition of the Network Element Function (NEF) picture provides the breakdown of the NEF, then the EMF picture provides the details of Equipment Management Function, and finally the Message Communication Function (MCF) picture details the MCF.

 ____________________________________________________
|            Network Element Function (NEF)          |
| _________________________________________          |
||                                         |         |
||    Transport Plane Atomic Functions     |         |
||_________________________________________|         |
|                     |                              |
|                     | Management                   |
|                     | Information                  |
|  ___________________|_________________             |
| |                    (from date/time)<-----------+ |
| | Equipment                           |          | |
| | Management     (to/from management)<--------+  | |
| | Function                            |       |  | |
| | (EMF)             (to/from control)<-----+  |  | |
| |                                     |    |  |  | |
| |                    (to local alarm)---+  |  |  | |
| |_____________________________________| |  |  |  | |
|                                         |  |  |  | |
|  +--------------------------------------+  |  |  | |
|  | +---------------------------------------+  |  | |
|  | | +----------------------------------------+  | |
|  | | | +-----------------------------------------+ |external
|  | | | | Date & Time  _________________            |time
|  | | | | Interface   | Message         |           |source
|  | | | +-------------- Communication  <-----------------------
|  | | |               | Function (MCF)  |           |
|  | | | Management    |                 |           |management
|  | | +---------------->                |           |plane
|  | |   Plane Interface                <---------------------->
|  | |                 |                 |           |local
|  | |                 |                 |           |craft
|  | |   Control Plane |                 |           |terminal
|  | +------------------>               <---------------------->
|  |     Interface     |                 |           |control
|  |                   |                 |           |plane
|  |     Local Alarm   |                <---------------------->
|  +-------------------->                |           |
|        Interface     |                 |           |to local
|                      |                 |           |alarms
|                      |_________________--------------------->
|____________________________________________________|

High-level decomposition of NEF

 ______________________________________________________
|              _______________________________________ |
|  Equipment  |             Management Application    ||
|  Management |                Function (MAF)         ||
|  Function   | _________________                     ||
|  (EMF)      ||                 |  __________________||
|  ___________||_______________  | |                  ||
| |                            | | | Date & Time      ||
| | Date & Time Functions      | | | Interface        ||<-- 1
| |____________________________| | |__________________||
|  ___________||_______________  |  __________________||
| |                            | | |                  ||
| | Fault Management           | | | Management       ||
| |____________________________| | | Plane Interface  ||<-> 2
|  ___________||_______________  | |__________________||
| |                            | |                    ||
| | Configuration Management   | |  __________________||
| |____________________________| | |                  ||
|  ___________||_______________  | | Control          ||
| |                            | | | Plane Interface  ||<-> 3
| | Account Management         | | |__________________||
| |____________________________| |                    ||
|  ___________||_______________  |                    ||
| |                            | |                    ||
| | Performance Management     | |                    ||
| |____________________________| |                    ||
|  ___________||_______________  |                    ||
| |                            | |                    ||
| | Security Management        | |                    ||
| |____________________________| |                    ||
|  ___________||_______________  |                    ||
| |                            | |                    ||
| | Control Plane Function     | |                    ||
| |____________________________| |                    ||
|             ||                 |  __________________||
|             ||                 | |                  ||
|             ||                 | | Local Alarm      ||
|       +----->| Agent           | | Interface        ||--> 4
|       v     ||_________________| |__________________||
|   .-===-.   |_______________________________________||
|   | MIB |                                            |
|   `-._.-'                                            |
|______________________________________________________|

Equipment Management Function

                  _________________
                 |                 |
                 |   Message       |
                 | Communication   |
                 | Function (MCF)  |
                 | _______________ |
   Date & Time   ||               || external
1 <--------------|| Date & Time   ||<--------------
   Information   || Communication || time source
                 ||_______________||
                 |                 |
                 | _______________ |
   Management    ||               || management
   Plane         ||  Management   || plane
2 <------------->||    Plane      ||<------------->
   Information   || Communication || (e.g. - EMS,
                 ||_______________||  peer NE)
                 |                 |
                 | _______________ | control
   Control Plane ||               || plane
3 <------------->|| Control Plane ||<------------->
   Information   || Communication || (e.g. - EMS,
                 ||_______________||  peer NE)
                 |        :        |
                 |        :        | local craft
                 |        :        | terminal
                 |        :        |<------------->
                 | _______________ |
   Local Alarm   ||               || to local
4 -------------->|| Local Alarm   ||-------------->
   Information   || Communication || alarms...
                 ||_______________||
                 |_________________|

Message Communication Function

2.3.  Standard Management Interfaces

The MPLS-TP NM requirements (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.) [3] document 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 or snmp and other segments by CORBA 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. The protocol(s) to be supported are 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 the communication channel terminology picture 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 (CCh) 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.

Common Terminology                   ____
 __________         __________      |    |
|          |       |          |  /->| NE | \   ____
|Management|       |Operations| /   |____|  \ |    |
|Station   | <---> |System    |       |(CCh)  | NE |
|__________|       |__________| \    _|__   / |____|
                                 \->|    | /
                                    | NE |
                                    |____|
                    Network Elements use a Communication
                    Channel (CCh) for Transport of Information

Management Terminology               ____
 __________         __________      |    |
|          |       |          |  /->| NE | \   ____
|Management|       |Operations| /   |____|  \ |    |
|Station   | <---> |System    |       |(MCC)  | NE |
|__________|       |__________| \    _|__   / |____|
                                 \->|    | /
                                    | NE |
                                    |____|
                    Network Elements use a Management
                    Communication Channel (MCC) for Transport
                    of Management Information


Control Terminology                  ____
 __________         __________      |    |
|          |       |          |  /->| NE | \   ____
|Management|       |Operations| /   |____|  \ |    |
|Station   | <---> |System    |       |(SCC)  | NE |
|__________|       |__________| \    _|__   / |____|
                                 \->|    | /
                                    | NE |
                                    |____|
                    Network Elements use a Control/Signaling
                    Communication Channel (SCC) for Transport
                    of Signaling Information

Communication Channel Terminology

3.  Fault Management

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

ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6] 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

ITU-T G.7710 (International Telecommunication Union, “Common equipment management function requirements,” July 2007.) [6] 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

Configuration management provides the mechanisms to:

• provision the MPLS-TP services
• setup security for the MPLS-TP services and MPLS-TP network elements
• provide the destination for fault notifications and performance parameters
• configure and control OAM

Also 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 (MP)), but also by Control Plane (CP) protocols. The utilization of the control plane is not a mandatory requirement (see MPLS-TP Requirements (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) [2]) but it is often used by network operators in order to make network configuration and Label Switched Path (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 to 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" RFC 5493 (Caviglia, D., Bramanti, D., Li, D., and D. McDysan, “Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network,” April 2009.) [10]. MP to CP ownership handover is then considered a requirement 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 RFC 3209 (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.) [1]. The utilization of RSVP-TE enhancements are defined in [5] (Caviglia, D., Ceccarelli, D., Li, D., and S. Bardalai, “RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.,” February 2010.).

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

Performance statistics could overwhelm a Management Network, so it is important to provide flexible instrumentation that enables control over the amount of performance data to be collected. Mechanisms for limiting the quantity of information collected are well known and deployed in IETF standards (see RFC 2819 (RMON) (Waldbusser, S., “Remote Network Monitoring Management Information Base,” May 2000.) [8] and RFC 4502 (RMON2) (Waldbusser, S., “Remote Network Monitoring Management Information Base Version 2,” May 2006.) [9]). The details of the performance data collected (including loss and delay measurement data) are found in the MPLS-TP NM requirements (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.) [3] document.

A distinction is made between performance data that is collected on-demand and data that is collected proactively. The definitions of on-demand and proactive measurement are provided for OAM in the MPLS-TP NM requirements (Mansfield, S. and K. Lam, “MPLS TP Network Management Requirements,” October 2009.) [3] document.

On-demand measurement provides the operator with the ability to do performance measurement for maintenance purpose such as diagnosis or to provide detailed verification of proactive measurement. It is used typically on specific LSP service instances for a limited time, thus limiting its impact on network performance under normal operations. Therefore on demand measurement does not result in scaling issues.

Proactive measurement is used continuously over time after being configured with periodicity and storage information. Data collected from proactive measurement are usually used for verifying the performance of the service. Proactive performance monitoring has the potential to overwhelm both the process of collecting performance data at a Network Element (for some arbitrary number of service instances traversing the NE), and the process of reporting this information to the OS. As a consequence of these considerations, operators would typically limit the services to which proactive performance measurement would be applied to a very selective subset of the services being provided and would limit the reporting of this information to statistical summaries (as opposed to raw or detailed performance statistics).

6.  Acknowledgements

The authors/editors gratefully acknowledge the thoughtful review, comments and explanations provided by Diego Caviglia, Bernd Zeuner and Dan Romascanu.

7.  IANA Considerations

This memo includes no request to IANA.

8.  Security Considerations

The ability for the authorized network operator to access EMF interfaces (section 2.3) when needed is critical to proper operation. Therefore the EMF interfaces need to be protected from denial of service conditions or attack. The EMF Interfaces that use or access private information should be protected from eavesdropping, mis-configuration, and/or mal-configuration by unauthorized 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 considers private.

Section 4.3 of the Security Framework for MPLS and GMPLS Networks (Fang, L. and M. Behringer, “Security Framework for MPLS and GMPLS Networks,” March 2010.) [14] document provides a description of the attacks on the Operation and Management Plane and also discusses the background necessary to understand security practices in Internet Service Provider environments. The security practices described are applicable to MPLS-TP environments.

9.  References

9.1. Normative References

9.2. Informative References

Authors' Addresses