draft-ietf-mpls-tp-nm-framework-01.txt   draft-ietf-mpls-tp-nm-framework-02.txt 
Internet Engineering Task Force S. Mansfield, Ed. Internet Engineering Task Force S. Mansfield, Ed.
Internet-Draft E. Gray, Ed. Internet-Draft E. Gray, Ed.
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: April 26, 2010 H. Lam, Ed. Expires: May 20, 2010 H. Lam, Ed.
Alcatel-Lucent Alcatel-Lucent
October 23, 2009 November 16, 2009
MPLS-TP Network Management Framework MPLS-TP Network Management Framework
draft-ietf-mpls-tp-nm-framework-01 draft-ietf-mpls-tp-nm-framework-02
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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 2, line 17
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010. This Internet-Draft will expire on May 20, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides the network management framework for the described in the BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Management Architecture . . . . . . . . . . . . . . . . . . . 4 2. Management Architecture . . . . . . . . . . . . . . . . . . . 5
2.1. Network Management Architecture . . . . . . . . . . . . . 4 2.1. Network Management Architecture . . . . . . . . . . . . . 6
2.2. Element Management Architecture . . . . . . . . . . . . . 6 2.2. Element Management Architecture . . . . . . . . . . . . . 7
2.3. Standard Management Interfaces . . . . . . . . . . . . . . 9 2.3. Standard Management Interfaces . . . . . . . . . . . . . . 10
2.4. Management and Control specific terminology . . . . . . . 10 2.4. Management and Control specific terminology . . . . . . . 11
2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 10 2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 11
3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 11 3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 13
4. Configuration Management . . . . . . . . . . . . . . . . . . . 12 4. Configuration Management . . . . . . . . . . . . . . . . . . . 13
4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 12 4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 13
5. Performance Management . . . . . . . . . . . . . . . . . . . . 13 5. Performance Management . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document provides a framework for using the MPLS-TP NM This document provides a framework for using the MPLS-TP NM
requirements [1] for managing the elements and networks that support requirements [1] for managing the elements and networks that support
a Transport Profile for MPLS. a Transport Profile for MPLS.
This framework relies on the management terminology from the ITU-T to This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an describe the management architecture that could be used for an
MPLS-TP management network. MPLS-TP management network.
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 1.1. Terminology
Communication Channel (CCh): A logical channel between network Communication Channel (CCh): A logical channel between network
elements (NEs) that can be used - e.g. - management plane elements (NEs) that can be used in (for example) management plane
applications or control plane applications. The physical channel applications or control plane applications. For MPLS-TP, the
supporting the CCh is technology specific. An example of physical physical channel supporting the CCh is the MPLS-TP Management
channels supporting the CCh is a DCC channel within SDH. Communication Channel (MCC).
Data Communication Network (DCN): a network that supports Layer 1 Data Communication Network (DCN): A network that supports Layer 1
(physical), Layer 2 (data-link), and Layer 3 (network) functionality (physical), Layer 2 (data-link), and Layer 3 (network) functionality
for distributed management communications related to the management for distributed management communications related to the management
plane, for distributed signaling communications related to the plane, for distributed signaling communications related to the
control plane, and other operations communications (e.g., order-wire/ control plane, and other operations communications (e.g., order-wire/
voice communications, software downloads, etc.). voice communications, software downloads, etc.).
Equipment Management Function (EMF): the management functions within Equipment Management Function (EMF): The management functions within
an NE. See ITU-T G.7710 [2]. an NE. See ITU-T G.7710 [2].
Local Craft Terminal (LCT): An out-of-band device that connects to an Local Craft Terminal (LCT): An out-of-band device that connects to an
NE for management purposes. NE for management purposes.
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 [3].
Management Application Function (MAF): An application process that Management Application Function (MAF): An application process that
participates in system management. See ITU-T G.7710 [2]. participates in system management. See ITU-T G.7710 [2].
Management Communication Channel (MCC): A CCh dedicated for Management Communication Channel (MCC): A CCh dedicated for
management plane communications. management plane communications.
Message Communication Function (MCF): The communications process that Message Communication Function (MCF): The communications process that
performs functions such as information interchange and relay. See performs functions such as information interchange and relay. See
ITU-T M.3013 [6]. ITU-T M.3013 [7].
Management Communication Network (MCN): A DCN supporting management Management Communication Network (MCN): A DCN supporting management
plane communication is referred to as a Management Communication plane communication is referred to as a Management Communication
Network (MCN). Network (MCN).
MPLS-TP NE: a network element (NE) that supports MPLS-TP functions. 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 Another term that is used for a network element is node. In terms of
this document, the term node is equivalent to NE. this document, the term node is equivalent to NE.
MPLS-TP network: a network in which MPLS-TP NEs are deployed. MPLS-TP network: A network in which MPLS-TP NEs are deployed.
Network Element Function (NEF): The set of functions necessary to Network Element Function (NEF): The set of functions necessary to
manage a network element. manage a network element.
Operations System (OS): A system that performs the functions that Operations System (OS): A system that performs the functions that
support processing of information related to operations, support processing of information related to operations,
administration, maintenance, and provisioning (OAM&P) for the administration, maintenance, and provisioning (OAM&P) for the
networks, including surveillance and testing functions to support networks, including surveillance and testing functions to support
customer access maintenance. customer access maintenance.
Signaling Communication Network (SCN): A DCN supporting control plane Signaling Communication Network (SCN): A DCN supporting control plane
communication is referred to as a Signaling Communication Network communication is referred to as a Signaling Communication Network
(SCN). (SCN).
Signaling Communication Channel (SCC): a CCh dedicated for control Signaling Communication Channel (SCC): A CCh dedicated for control
plane communications. The SCC may be used for GMPLS/ASON signaling plane communications. The SCC may be used for GMPLS/ASON signaling
and/or other control plane messages (e.g., routing messages). and/or other control plane messages (e.g., routing messages).
2. Management Architecture 2. Management Architecture
The management of the MPLS-TP network could be based on a multi- The management of the MPLS-TP network could be based on a multi-
tiered distributed management systems, for example as described in tiered distributed management systems, for example as described in
ITU-T M.3010 [7] and ITU-T M.3060/Y.2401 [8]. Each tier provides a ITU-T M.3010 [8] and ITU-T M.3060/Y.2401 [9]. Each tier provides a
predefined level of network management capabilities. The lowest tier predefined level of network management capabilities. The lowest tier
of this organization model includes the MPLS-TP Network Element that of this organization model includes the MPLS-TP Network Element that
provides the transport service and the Operations System (OS) at the provides the transport service and the Operations System (OS) at the
Element Management Level. The management application function within Element Management Level. The Management Application Function (MAF)
the NEs and OSs provides the management support. The management within the NEs and OSs provides the management support. The MAF at
application function at each entity can include agents only, managers each entity can include agents only, managers only, or both agents
only, or both agents and managers. The management application and managers. The MAF that include managers are capable of managing
function that include managers are capable of managing an agent an agent included in other MAF.
included in other management application functions.
The management communication to peer NEs and/or Operations Systems The management communication to peer NEs and/or Operations Systems
(OSs) is provided via the message communication function within each (OSs) is provided via the Message Communication Function (MCF) within
entity (e.g. NE and OS). The user can access the management of the each entity (e.g. NE and OS). The user can access the management of
MPLS-TP transport network via a Local Craft Terminal (LCT) attached the MPLS-TP transport network via a Local Craft Terminal (LCT)
to the NE or via a Work Station (WS) attached to the OS. attached to the NE or via a Work Station (WS) attached to the OS.
2.1. Network Management Architecture 2.1. Network Management Architecture
A transport Management Network (MN) may consist of several transport A transport Management Network (MN) may consist of several transport
technology specific Management Networks. Management network technology specific Management Networks. Management network
partitioning (Figure 1) below from ITU-T G.7710 [2] shows an example partitioning (Figure 1) below based on ITU-T G.7710 [2] shows the
of management network partitioning. Notation used in G.7710 for a management network partitioning. Notation used in G.7710 for a
transport technology specific MN is x.MN, where x is the transport transport technology specific MN is x.MN, where x is the transport
specific technology. In the example "O.MSN" is equivalent to an specific technology. An MPLS-TP specific MN is abbreviated as MT.MN.
optical management subnetwork, and "S.MSN" is equivalent to an SDH Where there is no ambiguity, we will use "MN" for an MPLS-TP specific
management subnetwork. A MPLS-TP specific MN might be abbreviated as MN. In the figure below O.MSN is equivalent to an OTN management
MPLS-TP.MN. Where there is no ambiguity, we will use "MN" for an Subnetwork.
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:| |: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:| |:x.MSN-1:x.MSN-2: ... :x.MSN-n:|
|: : : : :| |: : : : :|
'-=============================-' '-=============================-'
Management Network Partitioning Management Network Partitioning
Figure 1 Figure 1
The management of the MPLS-TP network is be separable from the The management of the MPLS-TP network is separable from the
management of the other technology-specific networks, and operate management of the other technology-specific networks, and operates
independently of any particular client or server layer management independently of any particular client or server layer management
plane. plane.
A MPLS-TP Management Network could be partitioned into MPLS-TP An MPLS-TP Management Network (MT.MN) could be partitioned into
Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just "MSN" MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just
where usage is unambiguous) for consideration of scalability (e.g. "MSN" where usage is unambiguous) for consideration of scalability
geographic or load balancing) or administrative (e.g. administrative (e.g. geographic or load balancing) or administrative (e.g.
or ownership). administrative or ownership).
The MPLS-TP MSN could be connected to other parts of the MN through 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 one or more LCTs and/or OSs. The Message Communication Function
(MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise (MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise
processes management messages over CChs or via an external interface. processes management messages over CChs or via an external interface.
Multiple addressable MPLS-TP NEs could be present at a single Multiple addressable MPLS-TP NEs could be present at a single
physical location (i.e. site or office). The inter-site physical location (i.e. site or office). The inter-site
communications link between the MPLS-TP NEs will normally be provided communications link between the MPLS-TP NEs will normally be provided
by the CChs. Within a particular site, the NEs could communicate via by the CChs. Within a particular site, the NEs could communicate via
an intra-site CCh or via a LAN. an intra-site CCh or via a LAN.
2.2. Element Management Architecture 2.2. Element Management Architecture
skipping to change at page 6, line 22 skipping to change at page 7, line 28
Reference Points. The EMF may contain a number of functions that Reference Points. The EMF may contain a number of functions that
provide a data reduction mechanism on the information received across provide a data reduction mechanism on the information received across
the MP Reference Points. the MP Reference Points.
The EMF includes functions such as Date & Time, FCAPS (Fault, The EMF includes functions such as Date & Time, FCAPS (Fault,
Configuration, Accounting, Performance and Security) management, and Configuration, Accounting, Performance and Security) management, and
Control Plane functions. The EMF provides event message processing, Control Plane functions. The EMF provides event message processing,
data storage and logging. The management Agent, a component of the data storage and logging. The management Agent, a component of the
EMF, converts internal management information (MI signals) into EMF, converts internal management information (MI signals) into
Management Application messages and vice versa. The Agent responds Management Application messages and vice versa. The Agent responds
to Management Application messages from the message communication to Management Application messages from the Message Communication
function by performing the appropriate operations on (for example) Function (MCF) by performing the appropriate operations on (for
the Managed Objects in a Management Information Base (MIB), as example) the Managed Objects in a Management Information Base (MIB),
necessary. The message communication function contains as necessary. The MCF contains communications functions related to
communications functions related to the outside world of the NE (i.e. the outside world of the NE (i.e. Date & Time source, Management
Date & Time source, Management Plane, Control Plane, Local Craft Plane, Control Plane, Local Craft Terminal and Local Alarms).
Terminal and Local Alarms).
The Date & Time functions keep track of the NE's date/time which is 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 used by the FCAPS management functions to e.g. time stamp event
reports. reports.
Below are diagrams that illustrate the components of the element Below are diagrams that illustrate the components of the Element
management function of a network element. The high-level Management Function (EMF) of a Network Element (NE). The high-level
decomposition of the NEF picture (Figure 2) provides the breakdown of decomposition of the Network Element Function (NEF) picture
the Network Element Function, then the equipment management function (Figure 2) provides the breakdown of the NEF, then the EMF picture
picture (Figure 3) provides the details of Equipment Management (Figure 3) provides the details of Equipment Management Function, and
Function, and finally the message communication function picture finally the Message Communication Function (MCF) picture (Figure 4)
(Figure 4) details the Message Communication Function. details the MCF.
____________________________________________________ ____________________________________________________
| Network Element Function (NEF) | | Network Element Function (NEF) |
| _________________________________________ | | _________________________________________ |
|| | | || | |
|| Transport Plane Atomic Functions | | || Transport Plane Atomic Functions | |
||_________________________________________| | ||_________________________________________| |
| | | | | |
| | Management | | | Management |
| | Information | | | Information |
| | |
| ___________________|_________________ | | ___________________|_________________ |
| | (from date/time)<-----------+ | | | (from date/time)<-----------+ |
| | Equipment | | | | | Equipment | | |
| | Management (to/from management)<--------+ | | | | Management (to/from management)<--------+ | |
| | Function | | | | | | Function | | | |
| | (EMF) (to/from control)<-----+ | | | | | (EMF) (to/from control)<-----+ | | |
| | | | | | | | | | | | | |
| | (to local alarm)---+ | | | | | | (to local alarm)---+ | | | |
| |_____________________________________| | | | | | | |_____________________________________| | | | | |
| | | | | | | | | | | |
| +--------------------------------------+ | | | | | +--------------------------------------+ | | | |
| | +---------------------------------------+ | | | | | +---------------------------------------+ | | |
| | | +----------------------------------------+ | | | | | +----------------------------------------+ | |
| | | | +-----------------------------------------+ | | | | | +-----------------------------------------+ |external
| | | | | Date & Time _________________ |external | | | | | Date & Time _________________ |time
| | | | | Interface | Message | |time | | | | | Interface | Message | |source
| | | | +-------------- Communication <----------------------- | | | | +-------------- Communication <-----------------------
| | | | | Function (MCF) | | | | | | | Function (MCF) | |
| | | | Management | | |management | | | | Management | | |management
| | | +----------------> | |element | | | +----------------> | |plane
| | | Plane Interface <----------------------> | | | Plane Interface <---------------------->
| | | | | | | | | | | |local
| | | Control Plane | | | | | | | | |craft
| | +------------------> | | | | | Control Plane | | |terminal
| | +------------------> <---------------------->
| | Interface | | |control | | Interface | | |control
| | | | |element | | | | |plane
| | Local Alarm | <----------------------> | | Local Alarm | <---------------------->
| +--------------------> | | | +--------------------> | |
| Interface | | |to local | Interface | | |to local
| | | |alarms | | | |alarms
| |_________________---------------------> | |_________________--------------------->
|____________________________________________________| |____________________________________________________|
High-level decomposition of NEF High-level decomposition of NEF
Figure 2 Figure 2
skipping to change at page 9, line 18 skipping to change at page 10, line 18
| Communication | | Communication |
| Function (MCF) | | Function (MCF) |
| _______________ | | _______________ |
Date & Time || || external Date & Time || || external
1 <--------------|| Date & Time ||<-------------- 1 <--------------|| Date & Time ||<--------------
Information || Communication || time source Information || Communication || time source
||_______________|| ||_______________||
| | | |
| _______________ | | _______________ |
Management || || management Management || || management
Plane || Management || element Plane || Management || plane
2 <------------->|| Plane ||<-------------> 2 <------------->|| Plane ||<------------->
Information || Communication || (e.g. - EMS, Information || Communication || (e.g. - EMS,
||_______________|| peer NE) ||_______________|| peer NE)
| | | |
| _______________ | control | _______________ | control
Control Plane || || element Control Plane || || plane
3 <------------->|| Control Plane ||<-------------> 3 <------------->|| Control Plane ||<------------->
Information || Communication || (e.g. - EMS, Information || Communication || (e.g. - EMS,
||_______________|| peer NE) ||_______________|| peer NE)
| : | | : |
| : | | : | local craft
| : | | : | terminal
| : |<------------->
| _______________ | | _______________ |
Local Alarm || || to local Local Alarm || || to local
4 -------------->|| Local Alarm ||--------------> 4 -------------->|| Local Alarm ||-------------->
Information || Communication || alarms... Information || Communication || alarms...
||_______________|| ||_______________||
|_________________| |_________________|
Message Communication Function Message Communication Function
Figure 4 Figure 4
skipping to change at page 12, line 45 skipping to change at page 13, line 45
network elements, and provides the destination for fault network elements, and provides the destination for fault
notifications and performance parameters. Inventory reporting is notifications and performance parameters. Inventory reporting is
also considered part of configuration management. also considered part of configuration management.
Associated with configuration management are hardware and software Associated with configuration management are hardware and software
provisioning and inventory reporting. provisioning and inventory reporting.
4.1. LSP ownership handover 4.1. LSP ownership handover
MPLS-TP networks can be managed not only by Network Management MPLS-TP networks can be managed not only by Network Management
Systems (i.e. management plane), but also by control plane protocols. Systems (i.e. Management Plane (MP)), but also by Control Plane (CP)
The utilization of the control plane is not a mandatory requirement protocols. The utilization of the control plane is not a mandatory
(see MPLS-TP Requirements [3]) but it is often used by network requirement (see MPLS-TP Requirements [4]) but it is often used by
operators in order to make network configuration and LSP recovery network operators in order to make network configuration and Label
both faster and simpler. Switched Path (LSP) recovery both faster and simpler.
In networks where both CP and MP are provided, an LSP could be 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 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 data plane resources comprising that LSP. Only the owner of an LSP
is typically able modify/delete it. This results in a need for 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 interaction between the MP and CP to allow either to manage all the
resources of a network. resources of a network.
Network operators might prefer to have full control of the 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 resources during the set-up phase and then allow the network to be
automatically maintained by the control plane. This can be achieved automatically maintained by the Control Plane. This can be achieved
by creating LSPs via the management plane and subsequently by creating LSPs via the Management Plane and subsequently
transferring LSP ownership to the control plane. This is referred to transferring LSP ownership to the Control Plane. This is referred to
as "ownership handover" RFC 5493 [9]. MP to CP ownership handover is as "ownership handover" RFC 5493 [10]. MP to CP ownership handover
then considered a requirement where a control plane is in use that 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 supports it. The converse (CP to MP ownership handover) is a feature
that is recommended - but not required - for (G)MPLS networks because that is recommended - but not required - for (G)MPLS networks because
it has only minor applications (for example moving LSPs from one path it has only minor applications (for example moving LSPs from one path
to another as a maintenance operation). to another as a maintenance operation).
The LSP handover procedure has already been standardized for GMPLS The LSP handover procedure has already been standardized for GMPLS
networks, where the signaling protocol used is RSVP-TE RFC 3209 [4]. networks, where the signaling protocol used is RSVP-TE RFC 3209 [5].
The utilization of RSVP-TE enhancements are defined in [5]. The utilization of RSVP-TE enhancements are defined in [6].
MP and CP interworking includes also the exchange of information that 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 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 consequence of a request from the MP or an automatic action (for
example a failure occurs or an operation is performed). The CP is 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 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 operations it performs and to provide a mechanism to monitor the
status of control plane objects (e.g. TE Link status, available status of Control Plane objects (e.g. TE Link status, available
resources), and to log control plane LSP related operations. Logging resources), and to log Control Plane LSP related operations. Logging
is one of the most critical aspects because the MP always needs to 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 have an accurate history and status of each LSP and all Data Plane
resources involved in it. resources involved in it.
5. Performance Management 5. Performance Management
Performance statistics could overwhelm a management network, so it is Performance statistics could overwhelm a Management Network, so it is
important to provide flexible instrumentation that provides control important to provide flexible instrumentation that provides control
over the amount of performance data to be collected. over the amount of performance data to be collected.
A distinction is made between performance data that is collected on- A distinction is made between performance data that is collected on-
demand and data that is collected proactively. demand and data that is collected proactively.
On-demand measurement provides the operator with the ability to do On-demand measurement provides the operator with the ability to do
performance measurement for maintenance purpose such as diagnosis or performance measurement for maintenance purpose such as diagnosis or
to provide detailed verification of proactive measurement. It is to provide detailed verification of proactive measurement. It is
used typically on specific LSP service instances for a limited time, used typically on specific LSP service instances for a limited time,
thus limiting its impact on network performance under normal thus limiting its impact on network performance under normal
operations. Therefore on demand measurement does not result in operations. Therefore on demand measurement does not result in
scaling issues. scaling issues.
Proactive measurement is used continuously over time after being Proactive measurement is used continuously over time after being
configured with periodicity and storage information. Data collected configured with periodicity and storage information. Data collected
from proactive measurement are usually used for verifying the from proactive measurement are usually used for verifying the
performance of the service. Proactive performance monitoring has the performance of the service. Proactive performance monitoring has the
potential to overwhelm both the process of collecting performance potential to overwhelm both the process of collecting performance
data at a network element (for some arbitrary number of service data at a Network Element (for some arbitrary number of service
instances traversing the NE), and the process of reporting this instances traversing the NE), and the process of reporting this
information to the OS. As a consequence of these considerations, information to the OS. As a consequence of these considerations,
operators would typically limit the services to which proactive operators would typically limit the services to which proactive
performance measurement would be applied to a very selective subset performance measurement would be applied to a very selective subset
of the services being provided and would limit the reporting of this of the services being provided and would limit the reporting of this
information to statistical summaries (as opposed to raw or detailed information to statistical summaries (as opposed to raw or detailed
performance statistics). performance statistics).
6. Acknowledgements 6. Acknowledgements
skipping to change at page 15, line 6 skipping to change at page 16, line 6
attacks if those network mechanisms are used in such an attack. attacks if those network mechanisms are used in such an attack.
Solutions need to provide mechanisms to prevent private information Solutions need to provide mechanisms to prevent private information
from being accessed by unauthorized eavesdropping, or being directly from being accessed by unauthorized eavesdropping, or being directly
obtained by an unauthenticated network element, system or user. obtained by an unauthenticated network element, system or user.
Performance of diagnostic functions and path characterization Performance of diagnostic functions and path characterization
involves extracting a significant amount of information about network involves extracting a significant amount of information about network
construction that the network operator considers private. construction that the network operator considers private.
Section 4.3 of the Security Framework for MPLS and GMPLS Networks
[11] document provides a description of the attacks on OAM, 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.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Mansfield, S. and K. Lam, "MPLS TP Network Management [1] Mansfield, S. and K. Lam, "MPLS TP Network Management
Requirements", draft-ietf-mpls-tp-nm-req-06 (work in progress), Requirements", draft-ietf-mpls-tp-nm-req-06 (work in progress),
October 2009. October 2009.
[2] International Telecommunications Union, "Common equipment [2] International Telecommunication Union, "Common equipment
management function requirements", ITU-T Recommendation G.7710/ management function requirements", ITU-T Recommendation G.7710/
Y.1701, July 2007. Y.1701, July 2007.
[3] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. [3] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework
Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-10 for MPLS in Transport Networks",
(work in progress), August 2009. draft-ietf-mpls-tp-framework-06 (work in progress),
October 2009.
[4] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. [4] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", S. Ueno, "MPLS-TP Requirements",
RFC 3209, December 2001. draft-ietf-mpls-tp-requirements-10 (work in progress),
August 2009.
[5] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S. [5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
Bardalai, "RSVP-TE Signaling Extension For Management Plane To G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
Control Plane LSP Handover In A GMPLS Enabled Transport RFC 3209, December 2001.
Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-04 (work in
progress), September 2009. [6] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Bardalai, "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), September 2009.
10.2. Informative References 10.2. Informative References
[6] International Telecommunications Union, "Considerations for a [7] International Telecommunication Union, "Considerations for a
telecommunications management network", ITU-T Recommendation telecommunication management network", ITU-T Recommendation
M.3013, February 2000. M.3013, February 2000.
[7] International Telecommunications Union, "Principles for a [8] International Telecommunication Union, "Principles for a
telecommunication managemetn network", ITU-T Recommendation telecommunication management network", ITU-T Recommendation
M.3010, April 2005. M.3010, April 2005.
[8] International Telecommunications Union, "Principles for the [9] International Telecommunication Union, "Principles for the
Management of Next Generation Networks", ITU-T Recommendation Management of Next Generation Networks", ITU-T Recommendation
M.3060/Y.2401, March 2006. M.3060/Y.2401, March 2006.
[9] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, [10] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent Connections "Requirements for the Conversion between Permanent Connections
and Switched Connections in a Generalized Multiprotocol Label and Switched Connections in a Generalized Multiprotocol Label
Switching (GMPLS) Network", RFC 5493, April 2009. Switching (GMPLS) Network", RFC 5493, April 2009.
[11] Fang, L. and M. Behringer, "Security Framework for MPLS and
GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-07 (work in
progress), October 2009.
Authors' Addresses Authors' Addresses
Scott Mansfield (editor) Scott Mansfield (editor)
Ericsson Ericsson
250 Holger Way 250 Holger Way
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 724 931 9316 Phone: +1 724 931 9316
skipping to change at page 16, line 24 skipping to change at page 18, line 4
Email: scott.mansfield@ericsson.com Email: scott.mansfield@ericsson.com
Eric Gray (editor) Eric Gray (editor)
Ericsson Ericsson
900 Chelmsford Street 900 Chelmsford Street
Lowell, MA 01851 Lowell, MA 01851
US US
Phone: +1 978 275 7470 Phone: +1 978 275 7470
Email: eric.gray@ericsson.com Email: eric.gray@ericsson.com
Hing-Kam Lam (editor) Hing-Kam Lam (editor)
Alcatel-Lucent Alcatel-Lucent
600-700 Mountain Ave 600-700 Mountain Ave
Murray Hill, NJ 07974 Murray Hill, NJ 07974
US US
Phone: +1 908 582 0672 Phone: +1 908 582 0672
Email: hklam@alcatel-lucent.com Email: Kam.Lam@alcatel-lucent.com
 End of changes. 54 change blocks. 
165 lines changed or deleted 207 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/