Network Working Group Hing-Kam Lam
Internet Draft Alcatel-Lucent
Expires: August, 2009 Scott Mansfield
Intended Status: Informational Eric Gray
Ericsson
March 2, 2009
MPLS TP Network Management Framework
draft-mansfield-mpls-tp-nm-framework-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
This memo provides information for the Internet community. It
does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with BCP 78 and
BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 2, 2009.
Mansfield, et al Expires September 2, 2009 [Page 1]
Internet-Draft MPLS-TP NM Framework March 2, 2009
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe
your rights and restrictions with respect to this document.
Abstract
This document provides the network management framework the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
Mansfield, et al Expires September 2, 2009 [Page 2]
Internet-Draft MPLS-TP NM Framework March 2, 2009
Table of Contents
1. Introduction................................................4
1.1. Terminology............................................4
2. Management Architecture Consideration.......................5
2.1. Network Management Architecture........................5
2.2. Element Management Architecture........................6
2.3. Standard Management Interfaces.........................7
2.4. Management Channel.....................................7
3. Fault Management Considerations.............................7
4. Configuration Management Considerations.....................7
5. Performance Management Considerations.......................7
6. Security Considerations.....................................8
7. IANA Considerations.........................................8
8. Acknowledgments.............................................8
9. References..................................................8
9.1. Normative References...................................8
9.2. Informative References.................................8
10. Author's Addresses.........................................9
Mansfield, et al Expires September 2, 2009 [Page 3]
Internet-Draft MPLS-TP NM Framework March 2, 2009
1. Introduction
This document provides a framework for using the MPLS-TP NM
requirements [1] for managing the elements and networks that
support a Transport Profile for MPLS.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [3].
MPLS-TP NE: a network element (NE) that supports MPLS-TP
functions
MPLS-TP network: a network in which MPLS-TP NEs are deployed
Equipment Management Function (EMF): the management functions
within an NE. See ITU-T G.7710 [2].
Data Communication Network (DCN): a network that supports Layer
1 (physical), Layer 2 (data-link), and Layer 3 (network)
functionality for distributed management communications related
to the management plane, for distributed signaling
communications related to the control plane, and other
operations communications (e.g., order-wire/voice
communications, software downloads, etc.).
Management Communication Network (MCN): A DCN supporting
management plane communication is referred to as a Management
Communication Network (MCN).
Signaling Communication Network (SCN): A DCN supporting control
plane communication is referred to as a Signaling Communication
Network (SCN).
Communication Channel (CC): a logical channel between network
elements (NEs) that can be used - e.g. - management plane
applications or control plane applications. The physical channel
supporting the CC is technology specific. An example of physical
channels supporting the CC is a DCC channel within SDH.
Management Communication Channel (MCC): a CC dedicated for
management plane communications.
Mansfield, et al Expires September 2, 2009 [Page 4]
Internet-Draft MPLS-TP NM Framework March 2, 2009
Signaling Communication Channel (SCC): a CC dedicated for
control plane communications. The SCC may be used for GMPLS/ASON
signaling and/or other control plane messages (e.g., routing
messages).
2. Management Architecture Consideration
The management of the MPLS-TP network could be based on a multi-
tiered distributed management systems, for example as described
in ITU-T M.3010 [4] and M.3060 [5]. Each tier provides a
predefined level of network management capabilities. The lowest
tier of this organization model includes the MPLS-TP Network
Element that provides the transport service and the Operations
System (OS) at the Element Management Level. The management
application function within the NEs and OSs provides the
management support. The management application function at each
entity can include agents only, managers only, or both agents
and managers. The management application function that include
managers are capable of managing an agent included in other
management application functions.
The management communication to peer NEs and/or Operations
System (OSs) is provided via the message communication function
within each entity (e.g. NE and OS). The user can access the
management of the MPLS-TP transport network via a Local Craft
Terminal (LCT) attached to the NE or via a Work Station (WS)
attached to the OS.
2.1. Network Management Architecture
A transport Management Network (MN) MAY consist of several
transport-technology-specific Management Networks. Notation used
in G.7710 [2] for a transport-technology-specific MN is x.MN,
where x is the transport specific technology. For example, a
MPLS-TP specific MN might be MPLS-TP.MN. Where there is no
ambiguity, we will use "MN" for an MPLS-TP specific MN, and
"MPLS-TP.MN" (or "MPLS-TP MN") and "MN" where both are used in a
given context.
The management of the MPLS-TP network is be separable from the
management of the other technology-specific networks, and
operate independently of any particular client or server layer
management plane.
A MPLS-TP Management Network could be partitioned into MPLS-TP
Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just
"MSN" where usage is unambiguous) for consideration of
Mansfield, et al Expires September 2, 2009 [Page 5]
Internet-Draft MPLS-TP NM Framework March 2, 2009
scalability (e.g. geographic or load balancing) or
administrative (e.g. administrative or ownership).
The MPLS-TP MSN could be connected to other parts of the MN
through one or more LCTs and/or OSs. The message communication
function of an MPLS-TP NE initiates/terminates, routes, or
otherwise processes management messages over CCs or via an
external interface.
Multiple addressable MPLS-TP NEs could be present at a single
physical location (i.e. site or office). The inter-site
communications link between the MPLS-TP NEs will normally be
provided by the CCs. Within a particular site, the NEs could
communicate via an intra-site CC or via a LAN.
2.2. Element Management Architecture
The Equipment Management Function (EMF) of a MPLS-TP NE provides
the means through which a management system manages the NE.
The EMF interacts with the NE's transport functions and control
functions (i.e., control plane functions that reside in the NE)
by exchanging Management Information (MI) across the Management
Point (MP) Reference Points. The EMF may contain a number of
functions that provide a data reduction mechanism on the
information received across the MP Reference Points.
The EMF includes functions such as Date & Time and the FCAPS
(Fault, Configuration, Accounting, Performance and Security)
management functions. The EMF provides event message processing,
data storage and logging. The management Agent, a component of
the EMF, converts internal management information (MI signals)
into Management Application messages and vice versa. The Agent
responds to Management Application messages from the message
communication function by performing the appropriate operations
on (for example) the Managed Objects in a Management Information
Base (MIB), as necessary. The message communication function
contains communications functions related to the outside world
of the NE (i.e. Date & Time source, Management Plane, Control
Plane, Local Craft Terminal and Local Alarms).
The Date & Time functions keep track of the NE's date/time which
is used by the FCAPS management functions to e.g. time stamp
event reports.
Mansfield, et al Expires September 2, 2009 [Page 6]
Internet-Draft MPLS-TP NM Framework March 2, 2009
2.3. Standard Management Interfaces
The MPLS-TP NM requirement document [1] places no restriction
on which management interface to be used for managing an MPLS-
TP network. It is possible to provision and manage an end-to-
end connection across a network where some segments are
created/managed/deleted, for example by netconf/XML or snmp/smi
and other segments by CORBA/IDL interfaces. Use of any network
management interface for one management related purpose does
not preclude use of another network management interface for
other management related purposes, or the same purpose at
another time However, an MPLS-TP NE is not expected to actively
support more than one management protocol in any given
deployment. The protocol to be supported is at the discretion
of the operator.
2.4. Management Channel
The Communication Channel (CC) provides a logical channel
between NEs for transferring Management and/or Signaling
information. Note that some technologies provide separate
communication channels for Management (MCC) and Signaling (SCC).
. MPLS-TP NEs communicate via the DCN. The DCN connects NEs
with management systems, NEs with NEs, and management
systems with management systems.
3. Fault Management Considerations
A fault is an anomaly in the network or network element. Fault
management provides the mechanisms to detect, verify, isolate,
notify, and recover from the fault.
4. Configuration Management Considerations
Configuration management provides the mechanisms to provision the
MPLS-TP services, setup security for the MPLS-TP services and MPLS-TP
network elements, and provides the destination for fault
notifications and performance parameters.
5. Performance Management Considerations
Performance statistics can overwhelm a management network, so it is
important to provide flexible instrumentation that provides control
over the amount of performance data to be collected. A distinction
is made between performance data that is collected on-demand and data
that is collected proactively. On-demand measurement provides the
Mansfield, et al Expires September 2, 2009 [Page 7]
Internet-Draft MPLS-TP NM Framework March 2, 2009
operator the ability to issue a command to initiate a measurement.
Proactive measurement is something that happens continuously overtime
after being configured with a periodicity and storage requirements.
6. Security Considerations
Provisions to any of the network mechanisms designed to satisfy
the requirements described herein are required to prevent their
unauthorized use. Likewise, these network mechanisms MUST
provide a means by which an operator can prevent denial of
service attacks if those network mechanisms are used in such an
attack.
Solutions MUST provide mechanisms to prevent this private
information from being accessed by unauthorized eavesdropping,
or being directly obtained by an unauthenticated network
element, system or user.
Performance of diagnostic functions and path characterization
involves extracting a significant amount of information about
network construction that the network operator MAY consider
private.
7. IANA Considerations
<insert IANA considerations, if any, here)
8. Acknowledgments
9. References
9.1. Normative References
[1] Lam, H.K., et al., "MPLS TP Network Management
Requirements", work in progress.
[2] ITU-T Recommendation G.7710/Y.1701, "Common equipment
management function requirements", July, 2007.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
9.2.Informative References
[4] ITU-T Recommendation M.3010, "Principles for a
telecommunication management network", April 2005.
Mansfield, et al Expires September 2, 2009 [Page 8]
Internet-Draft MPLS-TP NM Framework March 2, 2009
[5] ITU-T Recommendation M.3060/Y.2401, "Principles for the
Management of Next Generation Networks", March 2006.
10.Author's Addresses
Editors:
Scott Mansfield
Ericsson
5000 Ericsson Drive
Warrendale, PA, 15086
Phone: +1 724 742 6726
EMail: Scott.Mansfield@Ericsson.com
Hing-Kam (Kam) Lam
Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ, 07974
Phone: +1 908 582 0672
Email: hklam@Alcatel-Lucent.com
Eric Gray
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 978 275 7470
Email: Eric.Gray@Ericsson.com
Author(s):
Contributor(s):
Mansfield, et al Expires September 2, 2009 [Page 9]