[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-mpls-tp-nm-framework

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/