draft-ietf-mpls-tp-nm-framework-05.txt   rfc5950.txt 
Internet Engineering Task Force S. Mansfield, Ed. Internet Engineering Task Force (IETF) S. Mansfield, Ed.
Internet-Draft E. Gray, Ed. Request for Comments: 5950 E. Gray, Ed.
Intended status: Informational Ericsson Category: Informational Ericsson
Expires: August 26, 2010 K. Lam, Ed. ISSN: 2070-1721 K. Lam, Ed.
Alcatel-Lucent Alcatel-Lucent
February 22, 2010 September 2010
MPLS-TP Network Management Framework Network Management Framework for MPLS-based Transport Networks
draft-ietf-mpls-tp-nm-framework-05
Abstract Abstract
This document provides the network management framework for the This document provides the network management framework for the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
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-
MPLS-TP management network. TP management network.
The management of the MPLS-TP network could be based on multi-tiered The management of the MPLS-TP network could be based on multi-tiered
distributed management systems. This document provides a description distributed management systems. This document provides a description
of the network and element management architectures that could be of the network and element management architectures that could be
applied and also describes heuristics associated with fault, applied and also describes heuristics associated with fault,
configuration, and performance aspects of the management system. configuration, and performance aspects of the management system.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. capabilities and functionalities of a packet transport network.
This Informational Internet-Draft is aimed at achieving IETF Status of This Memo
Consensus before publication as an RFC and will be subject to an IETF
Last Call.
[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.]
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 26, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5950.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management Architecture . . . . . . . . . . . . . . . . . . . 6 2. Management Architecture . . . . . . . . . . . . . . . . . . . 5
2.1. Network Management Architecture . . . . . . . . . . . . . 6 2.1. Network Management Architecture . . . . . . . . . . . . . 5
2.2. Element Management Architecture . . . . . . . . . . . . . 7 2.2. Element Management Architecture . . . . . . . . . . . . . 6
2.3. Standard Management Interfaces . . . . . . . . . . . . . . 11 2.3. Standard Management Interfaces . . . . . . . . . . . . . . 10
2.4. Management and Control specific terminology . . . . . . . 12 2.4. Management- and Control-Specific Terminology . . . . . . . 11
2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 12 2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 11
3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 13 3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 13
4. Configuration Management . . . . . . . . . . . . . . . . . . . 14 4. Configuration Management . . . . . . . . . . . . . . . . . . . 13
4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 15 4.1. LSP Ownership Handover . . . . . . . . . . . . . . . . . . 14
5. Performance Management . . . . . . . . . . . . . . . . . . . . 15 5. Performance Management . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document provides the network management framework for the This document provides the network management framework for the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP). Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
Requirements for network management in an MPLS-TP network are Requirements for network management in an MPLS-TP network are
documented in MPLS-TP NM requirements [3], and this document explains documented in "Network Management Requirements for MPLS-based
how network elements and networks that support MPLS-TP can be managed Transport Networks" [3], and this document explains how network
using solutions that satisfy those requirements. The relationship elements and networks that support MPLS-TP can be managed using
between OAM, management and other framework documents is described in solutions that satisfy those requirements. The relationship between
the MPLS-TP framework [4] document. Operations, Administration, and Maintenance (OAM), management, and
other framework documents is described in the MPLS-TP framework [4]
document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication (IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network. capabilities and functionalities of a packet transport network.
1.1. Terminology 1.1. Terminology
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. The terminology listed below are taken MPLS-TP management network. The terminology listed below are taken
from/based on the definitions found in ITU-T G.7710 [6], ITU-T G.7712 from/based on the definitions found in ITU-T G.7710 [6], ITU-T G.7712
[7] and ITU-T M.3013 [13]. [7], and ITU-T M.3013 [13].
o Communication Channel (CCh): A logical channel between network o Communication Channel (CCh): A logical channel between network
elements (NEs) that can be used in (for example) management plane elements (NEs) that can be used in (for example) management plane
applications or control plane applications. For MPLS-TP, the applications or control plane applications. For MPLS-TP, the
physical channel supporting the CCh is the MPLS-TP Management physical channel supporting the CCh is the MPLS-TP Management
Communication Channel (MCC). Communication Channel (MCC).
o Data Communication Network (DCN): A network that supports Layer 1 o Data Communication Network (DCN): A network that supports Layer 1
(physical), Layer 2 (data-link), and Layer 3 (network) (physical), Layer 2 (data-link), and Layer 3 (network)
functionality for distributed management communications related to functionality for distributed management communications related to
skipping to change at page 5, line 30 skipping to change at page 4, line 34
o MPLS-TP NE: A network element (NE) that supports MPLS-TP o MPLS-TP NE: A network element (NE) that supports MPLS-TP
functions. Another term that is used for a network element is functions. Another term that is used for a network element is
node. In terms of this document, the term node is equivalent to node. In terms of this document, the term node is equivalent to
NE. NE.
o MPLS-TP network: A network in which MPLS-TP NEs are deployed. o MPLS-TP network: A network in which MPLS-TP NEs are deployed.
o Network Element Function (NEF): The set of functions necessary to o Network Element Function (NEF): The set of functions necessary to
manage a network element. See ITU-T M.3010 [11]. manage a network element. See ITU-T M.3010 [11].
o Operations, Administration and Maintenance (OAM): For the MPLS-TP o Operations, Administration, and Maintenance (OAM): For the MPLS-TP
effort the term OAM means the set of tools that consist of effort the term OAM means the set of tools that consist of
"operation" activities that are undertaken to keep the network up "operation" activities that are undertaken to keep the network up
and running, "administration" activities that keep track of and running, "administration" activities that keep track of
resources in the network and how they are used, and "maintenance" resources in the network and how they are used, and "maintenance"
activities that facilitate repairs and upgrades. For a complete activities that facilitate repairs and upgrades. For a complete
expansion of the acronym see The OAM Acronym Soup [15]. expansion of the acronym, see "The OAM Acronym Soup" [15].
o Operations System (OS): A system that performs the functions that o 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) (see The OAM administration, maintenance, and provisioning (OAM&P) (see "The
Acronym Soup [15]) for the networks, including surveillance and OAM Acronym Soup" [15]) for the networks, including surveillance
testing functions to support customer access maintenance. See and testing functions to support customer access maintenance. See
ITU-T M.3010 [11]. ITU-T M.3010 [11].
o Signaling Communication Network (SCN): A DCN supporting control o Signaling Communication Network (SCN): A DCN supporting control
plane communication is referred to as a Signaling Communication plane communication is referred to as a Signaling Communication
Network (SCN). See ITU-T G.7712 [7]. Network (SCN). See ITU-T G.7712 [7].
o Signaling Communication Channel (SCC): A CCh dedicated for control o Signaling Communication Channel (SCC): A CCh dedicated for control
plane communications. The SCC may be used for GMPLS/ASON plane communications. The SCC may be used for GMPLS/ASON
signaling and/or other control plane messages (e.g., routing signaling and/or other control plane messages (e.g., routing
messages). See ITU-T G.7712 [7]. messages). See ITU-T G.7712 [7].
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 [11] and ITU-T M.3060/Y.2401 [12]. Each tier provides a ITU-T M.3010 [11] and ITU-T M.3060/Y.2401 [12]. 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 (MAF) Element Management Level. The Management Application Function (MAF)
within the NEs and OSs provides the management support. The MAF at within the NEs and OSs provides the management support. The MAF at
each entity can include agents only, managers only, or both agents each entity can include agents only, managers only, or both agents
and managers. The MAF that include managers are capable of managing and managers. The MAF that includes managers is capable of managing
an agent included in other MAF. an agent included in other MAF.
The management communication to peer NEs and/or Operations Systems The management communication to peer NEs and/or OSs is provided via
(OSs) is provided via the Message Communication Function (MCF) within the Message Communication Function (MCF) within each entity (e.g., NE
each entity (e.g. NE and OS). The user can access the management of and OS). The user can access the management of the MPLS-TP transport
the MPLS-TP transport network via a Local Craft Terminal (LCT) network via a Local Craft Terminal (LCT) attached to the NE or via a
attached to the NE or via a Work Station (WS) attached to the OS. 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 based on ITU-T G.7710 [6] shows the partitioning (Figure 1) below (based on ITU-T G.7710 [6]) shows the
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. An MPLS-TP specific MN is abbreviated as MT.MN. specific technology. An MPLS-TP-specific MN is abbreviated as MT.MN.
Where there is no ambiguity, we will use "MN" for an MPLS-TP specific Where there is no ambiguity, we will use "MN" for an MPLS-TP-specific
MN. In the figure below O.MSN is equivalent to an OTN management MN. In the figure below, O.MSN is equivalent to an OTN management
Subnetwork. Subnetwork.
______________________________ _________________________________ ______________________________ _________________________________
|.-------.-------.----.-------.||.--------.--------.----.--------.| |.-------.-------.----.-------.||.--------.--------.----.--------.|
|: : : : :||: : : : :| |: : : : :||: : : : :|
|:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:MT.MSN-1:MT.MSN-2: .. :MT.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 separable from the The management of the MPLS-TP network is separable from the
management of the other technology-specific networks, and operates management of the other technology-specific networks, and it operates
independently of any particular client or server layer management independently of any particular client- or server-layer management
plane. plane.
An MPLS-TP Management Network (MT.MN) could be partitioned into An MPLS-TP Management Network (MT.MN) could be partitioned into
MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just
"MSN" where usage is unambiguous) for consideration of scalability "MSN" where usage is unambiguous) for consideration of scalability
(e.g. geographic or load balancing) or administrative (e.g. (e.g., geographic or load balancing) or administration (e.g.,
administrative or ownership). operation 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
The Equipment Management Function (EMF) of a MPLS-TP NE provides the The Equipment Management Function (EMF) of an MPLS-TP NE provides the
means through which a management system manages the NE. means through which a management system manages the NE.
The EMF interacts with the NE's transport functions by exchanging The EMF interacts with the NE's transport functions by exchanging
Management Information (MI) across the Management Point (MP) Management Information (MI) across the Management Point (MP)
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 and 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 (MCF) by performing the appropriate operations on (for Function (MCF) by performing the appropriate operations on (for
example) the Managed Objects in a Management Information Base (MIB), example) the Managed Objects in a Management Information Base (MIB),
as necessary. The MCF contains communications functions related to as necessary. The MCF contains communications functions related to
the outside world of the NE (i.e. Date & Time source, Management the world outside of the NE (i.e., Date and Time source, Management
Plane, Control Plane, Local Craft Terminal and Local Alarms). Plane, Control Plane, Local Craft Terminal, and Local Alarms).
The Date & Time functions keep track of the NE's date/time which is The Date and Time functions keep track of the NE's date/time, which
used by the FCAPS management functions to e.g. time stamp event is 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 Equipment
Management Function (EMF) of a Network Element (NE). The high-level Management Function (EMF) of a Network Element (NE). The high-level
decomposition of the Network Element Function (NEF) picture decomposition of the Network Element Function (NEF) picture
(Figure 2) provides the breakdown of the NEF, then the EMF picture (Figure 2) provides the breakdown of the NEF, then the EMF picture
(Figure 3) provides the details of Equipment Management Function, and (Figure 3) provides the details of Equipment Management Function, and
finally the Message Communication Function (MCF) picture (Figure 4) finally the Message Communication Function (MCF) picture (Figure 4)
details the MCF. details the MCF.
____________________________________________________ ____________________________________________________
| Network Element Function (NEF) | | Network Element Function (NEF) |
| _________________________________________ | | _________________________________________ |
skipping to change at page 9, line 48 skipping to change at page 8, line 48
| | +------------------> <----------------------> | | +------------------> <---------------------->
| | Interface | | |control | | Interface | | |control
| | | | |plane | | | | |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
______________________________________________________ ______________________________________________________
| _______________________________________ | | _______________________________________ |
| Equipment | Management Application || | Equipment | Management Application ||
| Management | Function (MAF) || | Management | Function (MAF) ||
| Function | _________________ || | Function | _________________ ||
| (EMF) || | __________________|| | (EMF) || | __________________||
| ___________||_______________ | | || | ___________||_______________ | | ||
skipping to change at page 11, line 45 skipping to change at page 10, line 45
Information || Communication || alarms... Information || Communication || alarms...
||_______________|| ||_______________||
|_________________| |_________________|
Message Communication Function Message Communication Function
Figure 4 Figure 4
2.3. Standard Management Interfaces 2.3. Standard Management Interfaces
The MPLS-TP NM requirements [3] document places no restriction on The "Network Management Requirements for MPLS-based Transport
which management interface is to be used for managing an MPLS-TP Networks" document [3] places no restriction on which management
network. It is possible to provision and manage an end-to-end interface is to be used for managing an MPLS-TP network. It is
connection across a network where some segments are created/managed/ possible to provision and manage an end-to-end connection across a
deleted, for example by netconf or snmp and other segments by CORBA network where some segments are created/managed/deleted, for example
interfaces. Use of any network management interface for one by NETCONF or SNMP and other segments by CORBA interfaces. Use of
management related purpose does not preclude use of another network any network management interface for one management-related purpose
management interface for other management related purposes, or the does not preclude use of another network management interface for
same purpose at another time. The protocol(s) to be supported are at other management-related purposes, or the same purpose at another
the discretion of the operator. time. The protocol(s) to be supported are at the discretion of the
operator.
2.4. Management and Control specific terminology 2.4. Management- and Control-Specific Terminology
Data Communication Network (DCN) is the common term for the network Data Communication Network (DCN) is the common term for the network
used to transport Management and Signaling information between: used to transport Management and Signaling information between:
management systems and network elements, management systems to other management systems and network elements, management systems to other
management systems, and networks elements to other network elements. management systems, and networks elements to other network elements.
The Management Communications Network (MCN) is the part of the DCN The Management Communications Network (MCN) is the part of the DCN
which supports the transport of Management information for the that supports the transport of Management information for the
Management Plane. The Signaling Communications Network (SCN) is the Management Plane. The Signaling Communications Network (SCN) is the
part of the DCN which supports transport for signaling information part of the DCN that supports transport of signaling information for
for the Control Plane. As shown in the communication channel the Control Plane. As shown in , the communication channel
terminology picture (Figure 5) each technology has its own terminology picture (Figure 5) each technology has its own
terminology that is used for the channels that support management and terminology that is used for the channels that support the transfer
control plane information transfer. For MPLS-TP, the management of management and control plane information. For MPLS-TP, the
plane uses the Management Communication Channel (MCC) and the control management plane uses the Management Communication Channel (MCC), and
plane uses the Signaling Communication Channel (SCC). the control plane uses the Signaling Communication Channel (SCC).
2.5. Management Channel 2.5. Management Channel
The Communication Channel (CCh) provides a logical channel between The Communication Channel (CCh) provides a logical channel between
NEs for transferring Management and/or Signaling information. Note NEs for transferring Management and/or Signaling information. Note
that some technologies provide separate communication channels for that some technologies provide separate communication channels for
Management (MCC) and Signaling (SCC). Management (MCC) and Signaling (SCC).
MPLS-TP NEs communicate via the DCN. The DCN connects NEs with MPLS-TP NEs communicate via the DCN. The DCN connects NEs with
management systems, NEs with NEs, and management systems with management systems, NEs with NEs, and management systems with
skipping to change at page 14, line 15 skipping to change at page 13, line 20
provides the mechanisms to detect, verify, isolate, notify, and provides the mechanisms to detect, verify, isolate, notify, and
recover from the fault. recover from the fault.
3.1. Supervision 3.1. Supervision
ITU-T G.7710 [6] lists five basic categories of supervision that ITU-T G.7710 [6] lists five basic categories of supervision that
provide the functionality necessary to detect, verify, and notify a provide the functionality necessary to detect, verify, and notify a
fault. The categories are: Transmission Supervision, Quality of fault. The categories are: Transmission Supervision, Quality of
Service Supervision, Processing Supervision, Hardware Supervision, Service Supervision, Processing Supervision, Hardware Supervision,
and Environment Supervision. Each of the categories provides a set and Environment Supervision. Each of the categories provides a set
of recommendations to ensure the fault management process is of recommendations to ensure that the fault management process is
fulfilled. fulfilled.
3.2. Validation 3.2. Validation
ITU-T G.7710 [6] describes a fault cause as a limited interruption of ITU-T G.7710 [6] describes a fault cause as a limited interruption of
the required function. It is not reasonable for every fault cause to the required function. It is not reasonable for every fault cause to
be reported to maintenance personnel. The validation process is used be reported to maintenance personnel. The validation process is used
to turn fault causes (events) into failures (alarms). to turn fault causes (events) into failures (alarms).
3.3. Alarm Handling 3.3. Alarm Handling
skipping to change at page 14, line 37 skipping to change at page 13, line 42
Within an element management system, it is important to consider Within an element management system, it is important to consider
mechanisms to support severity assignment, alarm reporting control, mechanisms to support severity assignment, alarm reporting control,
and logging. and logging.
4. Configuration Management 4. Configuration Management
Configuration management provides the mechanisms to: Configuration management provides the mechanisms to:
o provision the MPLS-TP services o provision the MPLS-TP services
o setup security for the MPLS-TP services and MPLS-TP network o set up security for the MPLS-TP services and MPLS-TP network
elements elements
o provide the destination for fault notifications and performance o provide the destination for fault notifications and performance
parameters parameters
o configure and control OAM o configure and control OAM
Also associated with configuration management are hardware and Also associated with configuration management are hardware and
software provisioning and inventory reporting. software 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 (MP)), but also by Control Plane (CP) Systems (i.e., Management Plane (MP)), but also by Control Plane (CP)
protocols. The utilization of the control plane is not a mandatory protocols. The utilization of the control plane is not a mandatory
requirement (see MPLS-TP Requirements [2]) but it is often used by requirement (see MPLS-TP Requirements [2]), but it is often used by
network operators in order to make network configuration and Label network operators in order to make network configuration and Label
Switched Path (LSP) recovery 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 to 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 [10]. MP to CP ownership handover as "ownership handover" RFC 5493 [10]. MP to CP ownership handover
is 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
it has only minor applications (for example moving LSPs from one path because it has only minor applications (for example, moving LSPs from
to another as a maintenance operation). one path 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 [1]. networks, where the signaling protocol used is RSVP-TE (RFC 3209
The utilization of RSVP-TE enhancements are defined in [5]. [1]). The utilization of RSVP-TE enhancements are defined in [5].
MP and CP interworking includes also the exchange of information that MP and CP interworking also includes 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 operations related to Control Plane LSP.
is one of the most critical aspects because the MP always needs to Logging is one of the most critical aspects because the MP always
have an accurate history and status of each LSP and all Data Plane needs to have an accurate history and status of each LSP and all Data
resources involved in it. Plane 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 enables control important to provide flexible instrumentation that enables control
over the amount of performance data to be collected. Mechanisms for over the amount of performance data to be collected. Mechanisms for
limiting the quantity of information collected are well known and limiting the quantity of information collected are well known and
deployed in IETF standards (see RFC 2819 (RMON) [8] and RFC 4502 deployed in IETF standards (see RFC 2819 (RMON) [8] and RFC 4502
(RMON2) [9]). The details of the performance data collected (RMON2) [9]). The details of the performance data collected
(including loss and delay measurement data) are found in the MPLS-TP (including loss and delay measurement data) are found in the "Network
NM requirements [3] document. Management Requirements for MPLS-based Transport Networks" document
[3].
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. The definitions of demand and data that is collected proactively. The definitions of
on-demand and proactive measurement are provided for OAM in the on-demand and proactive measurement are provided for OAM in the
MPLS-TP NM requirements [3] document. "Network Management Requirements for MPLS-based Transport Networks"
document [3].
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
The authors/editors gratefully acknowledge the thoughtful review, The authors/editors gratefully acknowledge the thoughtful review,
comments and explanations provided by Diego Caviglia, Bernd Zeuner comments and explanations provided by Diego Caviglia, Bernd Zeuner
and Dan Romascanu. and Dan Romascanu.
7. IANA Considerations 7. Security Considerations
This memo includes no request to IANA.
8. Security Considerations
The ability for the authorized network operator to access EMF The ability for the authorized network operator to access EMF
interfaces (section 2.3) when needed is critical to proper operation. interfaces (Section 2.3) when needed is critical to proper operation.
Therefore the EMF interfaces need to be protected from denial of Therefore, the EMF interfaces need to be protected from denial-of-
service conditions or attack. The EMF Interfaces that use or access service conditions or attack. The EMF interfaces that use or access
private information should be protected from eavesdropping, mis- private information should be protected from eavesdropping, mis-
configuration, and/or mal-configuration by unauthorized network configuration, and/or mal-configuration by unauthorized network
elements, systems, or users. elements, systems, or users.
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 Section 4.3 of the "Security Framework for MPLS and GMPLS Networks"
[14] document provides a description of the attacks on the Operation document [14] provides a description of the attacks on the Operation
and Management Plane and also discusses the background necessary to and Management Plane and also discusses the background necessary to
understand security practices in Internet Service Provider understand security practices in Internet Service Provider
environments. The security practices described are applicable to environments. The security practices described are applicable to
MPLS-TP environments. MPLS-TP environments.
9. References 8. References
9.1. Normative References 8.1. Normative References
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and [1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001. RFC 3209, December 2001.
[2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009. September 2009.
[3] Mansfield, S. and K. Lam, "MPLS TP Network Management [3] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements", draft-ietf-mpls-tp-nm-req-06 (work in progress), Requirements for MPLS-based Transport Networks", RFC 5951,
October 2009. September 2010.
[4] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A [4] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
Framework for MPLS in Transport Networks", Framework for MPLS in Transport Networks", RFC 5921, July 2010.
draft-ietf-mpls-tp-framework-10 (work in progress),
February 2010.
[5] Caviglia, D., Ceccarelli, D., Li, D., and S. Bardalai, "RSVP-TE [5] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Signaling Extension For Management Plane To Control Plane LSP Bardalai, "RSVP-TE Signaling Extension for LSP Handover from
Handover In A GMPLS Enabled Transport Network.", the Management Plane to the Control Plane in a GMPLS-Enabled
draft-ietf-ccamp-pc-spc-rsvpte-ext-07 (work in progress), Transport Network", RFC 5852, April 2010.
February 2010.
[6] International Telecommunication Union, "Common equipment [6] 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.
[7] International Telecommunication Union, "Architecture and [7] International Telecommunication Union, "Architecture and
specification of data communication network", ITU- specification of data communication network",
T Recommendation G.7712/Y.1703, June 2008. ITU-T Recommendation G.7712/Y.1703, June 2008.
9.2. Informative References 8.2. Informative References
[8] Waldbusser, S., "Remote Network Monitoring Management [8] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000. Information Base", STD 59, RFC 2819, May 2000.
[9] Waldbusser, S., "Remote Network Monitoring Management [9] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2", RFC 4502, May 2006. Information Base Version 2", RFC 4502, May 2006.
[10] 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
skipping to change at page 18, line 38 skipping to change at page 17, line 34
M.3010, April 2005. M.3010, April 2005.
[12] International Telecommunication Union, "Principles for the [12] 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.
[13] International Telecommunication Union, "Considerations for a [13] International Telecommunication Union, "Considerations for a
telecommunication management network", ITU-T Recommendation telecommunication management network", ITU-T Recommendation
M.3013, February 2000. M.3013, February 2000.
[14] Fang, L. and M. Behringer, "Security Framework for MPLS and [14] Fang, L., "Security Framework for MPLS and GMPLS Networks",
GMPLS Networks", RFC 5920, July 2010.
draft-ietf-mpls-mpls-and-gmpls-security-framework-07 (work in
progress), October 2009.
[15] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. [15] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S.
Mansfield, ""The OAM Acronym Soup"", Mansfield, ""The OAM Acronym Soup"", Work in progress,
draft-ietf-opsawg-mpls-tp-oam-def-03 (work in progress), June 2010.
February 2010.
Authors' Addresses Authors' Addresses
Scott Mansfield (editor) Scott Mansfield (editor)
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
US US
Phone: +1 724 931 9316 Phone: +1 724 931 9316
 End of changes. 64 change blocks. 
171 lines changed or deleted 148 lines changed or added

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