Internet Engineering Task Force                        S. Mansfield, Ed.
Internet-Draft                                              E. Gray, Ed.
Intended status: Informational                                  Ericsson
Expires: December 12, 2009 April 26, 2010                                      H. Lam, Ed.
                                                          Alcatel-Lucent
                                                           June 10,
                                                        October 23, 2009

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

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 December 12, 2009. April 26, 2010.

Copyright 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 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . .  Terminology  . . . . . . .  3
     1.2.  Terminology . . . . . . . . . . . . . . . .  3
   2.  Management Architecture  . . . . . . .  3
   2.  Management Architecture Considerations . . . . . . . . . . . .  4
     2.1.  Network Management Architecture  . . . . . . . . . . . . .  4
     2.2.  Element Management Architecture  . . . . . . . . . . . . .  6
     2.3.  Standard Management Interfaces . . . . . . . . . . . . . .  9
     2.4.  Management and Control specific terminology  . . . . . . . 10
     2.5.  Management Channel . . . . . . . . . . . . . . . . . . . . 10
   3.  Fault Management Considerations . . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Supervision  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.3.  Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Configuration Management Considerations . . . . . . . . . . . . . . . . . . . 12
     4.1.  LSP ownership handover . . . . . . . . . . . . . . . . . . 12
   5.  Performance Management Considerations . . . . . . . . . . . . . . . . . . . . 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 16

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.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are

   This framework relies on the management terminology from the ITU-T to
   describe the management architecture that could be interpreted as described in RFC 2119 [2].

1.2. used for an
   MPLS-TP management network.

1.1.  Terminology

   Communication Channel (CC): a (CCh): 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 CCh is technology specific.  An example of physical
   channels supporting the CC CCh 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 [3]. [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 [3]. [2].

   Management Communication Channel (MCC): a CC A CCh 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 [7]. [6].

   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 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.

   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 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).

2.  Management Architecture Considerations

   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 [8] [7] and ITU-T M.3060/Y.2401 [9]. [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 Systems
   (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 may consist of several transport
   technology specific Management Networks.  Management network
   partitioning (Figure 1) below from ITU-T G.7710 [3] [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:|
                  |:       :       :     :       :|
                  '-=============================-'

                      Management Network Partitioning

                                 Figure 1

   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 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 CCs. CChs.  Within a particular site, the NEs could communicate via
   an intra-site CC 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 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 Time, FCAPS (Fault,
   Configuration, Accounting, Performance and Security) management 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 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.  The high-level
   decomposition of the NEF picture (Figure 2) provides the breakdown of
   the Network Element Function, then the equipment management function
   picture (Figure 3) provides the details of Equipment Management
   Function, and finally the message communication function picture
   (Figure 4) details the Message Communication Function.

    ___________________________________________________

    ____________________________________________________
   |            Network Element Function (NEF)          |
   | _________________________  _______________________ _________________________________________          |
   ||    Equipment Control                                         |         |
   ||    Transport Plane      ||
   ||         Function        || Atomic Function      ||
   ||_________________________||_______________________|| Functions     |         |                |___________|
   ||_________________________________________|         |
   |                     |                              | Management        Control       Management
   |                     | Management                   |
   |                     | Information     Information Information                  |
   |                     |   |__                              ____________|                              |
   |  ____|____________________________|___  ___________________|_________________             |
   | |                    (from date/time)<-----------+ |
   | | Equipment                           |          | |
   | | Management     (to/from management)<--------+  | |
   | | Function                            |       |  | |
   | | (EMF)             (to/from control)<-----+  |  | |
   | |                                     |    |  |  | |
   | |                    (to local alarm)---+  |  |  | |
   | |_____________________________________| |  |  |  | |
   |                                         |  |  |  | |
   |  +--------------------------------------+  |  |  | |
   |  | +---------------------------------------+  |  | |
   |  | | +----------------------------------------+  | |
   |  | | | +-----------------------------------------+ |
   |  | | | | Date & Time  _________________            |external
   |  | | | | Info Interface   | Message         |           |time
   |  | | | +-------------- Communication  <-----------------------
   |  | | |               | Function (MCF)  |           |
   |  | | | Management    |                 |           |management
   |  | | +---------------->                |           |element
   |  | |   Plane Info    | Interface                <---------------------->
   |  | |                 |                 |           |
   |  | |   Control Plane |                 |           |
   |  | +------------------>                |           |
   |  |     Information     Interface     |                 |           |control
   |  |                   |                 |           |element
   |  |     Local Alarm   |                <---------------------->
   |  +-------------------->                |           |
   |        Information        Interface     |                 |           |to local
   |                      |                 |           |alarms
   |                      |_________________--------------------->
   |____________________________________________________|

                      High-level decomposition of NEF

                                 Figure 2

    _______________________________________

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

                       Equipment Management Function

                                 Figure 3

                     _________________
                    |                 |
                    |   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...
                    ||_______________||
                    |_________________|

                      Message Communication Function

                                 Figure 4

2.3.  Standard Management Interfaces

   The MPLS-TP NM requirements [1] 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/XML netconf or snmp/smi snmp and other segments by
   CORBA/IDL 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.  However, an MPLS-TP NE is not
   expected to actively support more than one management protocol in any
   given deployment.  The protocol protocol(s) to be supported is 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 (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) (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    |         |(CC)       |(CCh)  | NE |
   |----------|       |----------|
   |__________|       |__________| \     |----|    _|__   / |____|
                                    \->|    | / |----|
    Management         Operations    \->
                                       | NE |/
     Station             System          |----| |
                                       |____|
                       Network Elements use a Communication
                       Channel (CC) (CCh) for Transport of Management Information

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

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

                     Communication Channel Terminology

                                 Figure 5

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

   ITU-T G.7710 [3] [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

   ITU-T G.7710 [3] [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.
   The utilization of the control plane is not a mandatory requirement
   (see MPLS-TP Requirements [4]) [3]) 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" RFC 5493 [10]. [9].  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 [5]. [4].
   The utilization of RSVP-TE enhancements are defined in [6]. [5].

   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 could 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 on-
   demand and data that is collected proactively.

   On-demand measurement provides the operator with the ability to issue a command do
   performance measurement for maintenance purpose such as diagnosis or
   to initiate a 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 something that happens used continuously over time after being
   configured with a periodicity and storage
   requirements. information.  Data collected
   from proactive measurement are usually used for verifying the
   performance of the LSP service, while service.  Proactive performance monitoring has the
   potential to overwhelm both the process of collecting performance
   data
   collected from on-demand measurement are usually used for maintenance
   purposes such as diagnose or at a network element (for some arbitrary number of service
   instances traversing the NE), and the process of reporting this
   information to provide detailed verification the OS.  As a consequence of these considerations,
   operators would typically limit the services to which proactive measurement.
   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 and Bernd
   Zeuner.

7.  Contributors

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Security Considerations

   Provisions to any of the network mechanisms designed to satisfy the
   requirements described herein are required need to prevent their unauthorized use.  Likewise, these network mechanisms MUST use
   and provide a means by which for an operator can to prevent denial of service
   attacks if those network mechanisms are used in such an attack.

   Solutions MUST need to 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 considers private.

10.  References

10.1.  Normative References

   [1]  Mansfield, S., Lam, K., Gray, E., S. and A. Farrel, K. Lam, "MPLS TP Network Management
        Requirements", draft-ietf-mpls-tp-nm-req-01 draft-ietf-mpls-tp-nm-req-06 (work in progress), April
        October 2009.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]  International Telecommunications Union, "Common equipment
        management function requirements", ITU-T Recommendation G.7710/
        Y.1701, July 2007.

   [4]

   [3]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
        Ueno, "MPLS-TP Requirements",
         draft-ietf-mpls-tp-requirements-08 draft-ietf-mpls-tp-requirements-10
        (work in progress),
         May August 2009.

   [5]

   [4]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G.
        Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
        RFC 3209, December 2001.

   [6]

   [5]  Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
        Bardalai, "draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt",
         draft-ietf-ccamp-pc-spc-rsvpte-ext-02 "RSVP-TE Signaling Extension For Management Plane To
        Control Plane LSP  Handover In A GMPLS Enabled Transport
        Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-04 (work in
        progress),
         October 2008. September 2009.

10.2.  Informative References

   [7]

   [6]  International Telecommunications Union, "Considerations for a
        telecommunications management network", ITU-T Recommendation
        M.3013, February 2000.

   [8]

   [7]  International Telecommunications Union, "Principles for a
        telecommunication managemetn network", ITU-T Recommendation
        M.3010, April 2005.

   [9]

   [8]  International Telecommunications Union, "Principles for the
        Management of Next Generation Networks", ITU-T Recommendation
        M.3060/Y.2401, March 2006.

   [10]

   [9]  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", RFC 5493, April 2009.

Authors' Addresses

   Scott Mansfield (editor)
   Ericsson
   136 Elgin Lane
   Evans City, PA  16033
   250 Holger Way
   San Jose, CA  95134
   US

   Phone: +1 724 931 9316
   Email: scott.mansfield@ericsson.com

   Eric Gray (editor)
   Ericsson
   900 Chelmsford Street
   Lowell, MA  01851
   US

   Phone: +1 978 275 7470
   Email: eric.gray@ericsson.com

   Hing-Kam Lam (editor)
   Alcatel-Lucent
   600-700 Mountain Ave
   Murray Hill, NJ  07974
   US

   Phone: +1 908 582 0672
   Email: hklam@alcatel-lucent.com