draft-ietf-mpls-tp-nm-framework-03.txt   draft-ietf-mpls-tp-nm-framework-04.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: July 16, 2010 H. Lam, Ed. Expires: July 23, 2010 H. Lam, Ed.
Alcatel-Lucent Alcatel-Lucent
January 12, 2010 January 19, 2010
MPLS-TP Network Management Framework MPLS-TP Network Management Framework
draft-ietf-mpls-tp-nm-framework-03 draft-ietf-mpls-tp-nm-framework-04
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-TP management network. MPLS-TP management network.
skipping to change at page 2, line 17 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 July 16, 2010. This Internet-Draft will expire on July 23, 2010.
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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Management Architecture . . . . . . . . . . . . . . . . . . . 5 2. Management Architecture . . . . . . . . . . . . . . . . . . . 5
2.1. Network Management Architecture . . . . . . . . . . . . . 6 2.1. Network Management Architecture . . . . . . . . . . . . . 6
2.2. Element Management Architecture . . . . . . . . . . . . . 7 2.2. Element Management Architecture . . . . . . . . . . . . . 7
2.3. Standard Management Interfaces . . . . . . . . . . . . . . 10 2.3. Standard Management Interfaces . . . . . . . . . . . . . . 11
2.4. Management and Control specific terminology . . . . . . . 11 2.4. Management and Control specific terminology . . . . . . . 12
2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 11 2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 12
3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 12 3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 14
4. Configuration Management . . . . . . . . . . . . . . . . . . . 13 4. Configuration Management . . . . . . . . . . . . . . . . . . . 14
4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 13 4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 14
5. Performance Management . . . . . . . . . . . . . . . . . . . . 14 5. Performance Management . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This document provides a framework for using the MPLS-TP NM This document provides the network management framework for the
requirements [1] for managing the elements and networks that support Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
a Transport Profile for MPLS. Requirements for network management in an MPLS-TP network are
documented in MPLS-TP NM requirements [3], and this document explains
This framework relies on the management terminology from the ITU-T to how network elements and networks that support MPLS-TP can be managed
describe the management architecture that could be used for an using solutions that satisfy those requirements.
MPLS-TP management network.
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
Communication Channel (CCh): A logical channel between network This framework relies on the management terminology from the ITU-T to
elements (NEs) that can be used in (for example) management plane describe the management architecture that could be used for an
applications or control plane applications. For MPLS-TP, the MPLS-TP management network. The terminology listed below are taken
physical channel supporting the CCh is the MPLS-TP Management from/based on the definitions found in ITU-T G.7710 [6], ITU-T G.7712
Communication Channel (MCC). [7] and ITU-T M.3013 [11].
Data Communication Network (DCN): A network that supports Layer 1 o Communication Channel (CCh): A logical channel between network
(physical), Layer 2 (data-link), and Layer 3 (network) functionality elements (NEs) that can be used in (for example) management plane
for distributed management communications related to the management applications or control plane applications. For MPLS-TP, the
plane, for distributed signaling communications related to the physical channel supporting the CCh is the MPLS-TP Management
control plane, and other operations communications (e.g., order-wire/ Communication Channel (MCC).
voice communications, software downloads, etc.).
Equipment Management Function (EMF): The management functions within o Data Communication Network (DCN): A network that supports Layer 1
an NE. See ITU-T G.7710 [2]. (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.).
See ITU-T G.7712 [7].
Local Craft Terminal (LCT): An out-of-band device that connects to an o Equipment Management Function (EMF): The management functions
NE for management purposes. within an NE. See ITU-T G.7710 [6].
Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a o Local Craft Terminal (LCT): An out-of-band device that connects to
subset of the capabilities of an MPLS LSP in order to meet the an NE for management purposes. See ITU-T G.7710 [6].
requirements of an MPLS transport network as described in the MPLS-TP
framework [3].
Management Application Function (MAF): An application process that o Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a
participates in system management. See ITU-T G.7710 [2]. 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 [4].
Management Communication Channel (MCC): A CCh dedicated for o Management Application Function (MAF): An application process that
management plane communications. participates in system management. See ITU-T G.7710 [6].
Message Communication Function (MCF): The communications process that o Management Communication Channel (MCC): A CCh dedicated for
performs functions such as information interchange and relay. See management plane communications. See ITU-T G.7712 [7].
ITU-T M.3013 [7].
Management Communication Network (MCN): A DCN supporting management o Message Communication Function (MCF): The communications process
plane communication is referred to as a Management Communication that performs functions such as information interchange and relay.
Network (MCN). See ITU-T M.3013 [11].
MPLS-TP NE: A network element (NE) that supports MPLS-TP functions. o Management Communication Network (MCN): A DCN supporting
Another term that is used for a network element is node. In terms of management plane communication is referred to as a Management
this document, the term node is equivalent to NE. Communication Network (MCN). See ITU-T G.7712 [7].
MPLS-TP network: A network in which MPLS-TP NEs are deployed. o MPLS-TP NE: A network element (NE) that supports MPLS-TP
functions. Another term that is used for a network element is
node. In terms of this document, the term node is equivalent to
NE.
Network Element Function (NEF): The set of functions necessary to o MPLS-TP network: A network in which MPLS-TP NEs are deployed.
manage a network element.
Operations System (OS): A system that performs the functions that o Network Element Function (NEF): The set of functions necessary to
support processing of information related to operations, manage a network element. See ITU-T M.3010 [9].
administration, maintenance, and provisioning (OAM&P) for the
networks, including surveillance and testing functions to support
customer access maintenance.
Signaling Communication Network (SCN): A DCN supporting control plane o Operations System (OS): A system that performs the functions that
communication is referred to as a Signaling Communication Network support processing of information related to operations,
(SCN). administration, maintenance, and provisioning (OAM&P) (see The OAM
Acronym Soup [13]) for the networks, including surveillance and
testing functions to support customer access maintenance. See
ITU-T M.3010 [9].
Signaling Communication Channel (SCC): A CCh dedicated for control o Signaling Communication Network (SCN): A DCN supporting control
plane communications. The SCC may be used for GMPLS/ASON signaling plane communication is referred to as a Signaling Communication
and/or other control plane messages (e.g., routing messages). Network (SCN). See ITU-T G.7712 [7].
o Signaling Communication Channel (SCC): A CCh dedicated for control
plane communications. The SCC may be used for GMPLS/ASON
signaling and/or other control plane messages (e.g., routing
messages). 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 [8] and ITU-T M.3060/Y.2401 [9]. Each tier provides a ITU-T M.3010 [9] and ITU-T M.3060/Y.2401 [10]. 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 include managers are 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 Operations Systems
(OSs) is provided via the Message Communication Function (MCF) within (OSs) is provided via the Message Communication Function (MCF) within
each entity (e.g. NE and OS). The user can access the management of 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) 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. 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 based on ITU-T G.7710 [2] 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.
______________________________ _________________________________ ______________________________ _________________________________
|.-------.-------.----.-------.||.--------.--------.----.--------.| |.-------.-------.----.-------.||.--------.--------.----.--------.|
|: : : : :||: : : : :| |: : : : :||: : : : :|
skipping to change at page 10, line 45 skipping to change at page 11, 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 [1] document places no restriction on The MPLS-TP NM requirements [3] document places no restriction on
which management interface is to be used for managing an MPLS-TP which management interface is to be used for managing an MPLS-TP
network. It is possible to provision and manage an end-to-end network. It is possible to provision and manage an end-to-end
connection across a network where some segments are created/managed/ connection across a network where some segments are created/managed/
deleted, for example by netconf or snmp and other segments by CORBA deleted, for example by netconf or snmp and other segments by CORBA
interfaces. Use of any network management interface for one interfaces. Use of any network management interface for one
management related purpose does not preclude use of another network management related purpose does not preclude use of another network
management interface for other management related purposes, or the management interface for other management related purposes, or the
same purpose at another time. The protocol(s) to be supported are at same purpose at another time. The protocol(s) to be supported are at
the discretion of the operator. the discretion of the operator.
skipping to change at page 13, line 10 skipping to change at page 14, line 10
3. Fault Management 3. Fault Management
A fault is the inability of a function to perform a required action. A fault is the inability of a function to perform a required action.
This does not include an inability due to preventive maintenance, This does not include an inability due to preventive maintenance,
lack of external resources, or planned actions. Fault management lack of external resources, or planned actions. Fault management
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 [2] 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 the fault management process is
fulfilled. fulfilled.
3.2. Validation 3.2. Validation
ITU-T G.7710 [2] 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
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.
skipping to change at page 13, line 47 skipping to change at page 14, line 47
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 (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 [4]) 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 [8]. MP to CP ownership handover is
is then considered a requirement where a Control Plane is in use that 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 [5]. networks, where the signaling protocol used is RSVP-TE RFC 3209 [1].
The utilization of RSVP-TE enhancements are defined in [6]. 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 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
skipping to change at page 15, line 29 skipping to change at page 16, line 29
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 and Bernd comments and explanations provided by Diego Caviglia and Bernd
Zeuner. Zeuner.
7. Contributors 7. IANA Considerations
8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
Provisions to any of the network mechanisms designed to satisfy the Provisions to any of the network mechanisms designed to satisfy the
requirements described herein need to prevent their unauthorized use requirements described herein need to prevent their unauthorized use
and provide a means for an operator to prevent denial of service and provide a means for an operator to prevent denial of service
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 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 [12] document provides a description of the attacks on Operations,
Administration and Maintenance (OAM) (see The OAM Acronym Soup [13])
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.1. Normative References 9. References
[1] Mansfield, S. and K. Lam, "MPLS TP Network Management 9.1. Normative References
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and
S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009.
[3] 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 Telecommunication Union, "Common equipment [4] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
management function requirements", ITU-T Recommendation G.7710/
Y.1701, July 2007.
[3] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
Framework for MPLS in Transport Networks", Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-07 (work in progress), draft-ietf-mpls-tp-framework-07 (work in progress),
December 2009. December 2009.
[4] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and [5] Caviglia, D., Ceccarelli, D., Li, D., and S. Bardalai, "RSVP-TE
S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009.
[5] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[6] Caviglia, D., Ceccarelli, D., Li, D., and S. Bardalai, "RSVP-TE
Signaling Extension For Management Plane To Control Plane LSP Signaling Extension For Management Plane To Control Plane LSP
Handover In A GMPLS Enabled Transport Network.", Handover In A GMPLS Enabled Transport Network.",
draft-ietf-ccamp-pc-spc-rsvpte-ext-05 (work in progress), draft-ietf-ccamp-pc-spc-rsvpte-ext-06 (work in progress),
January 2010. January 2010.
10.2. Informative References [6] International Telecommunication Union, "Common equipment
management function requirements", ITU-T Recommendation G.7710/
Y.1701, July 2007.
[7] International Telecommunication Union, "Considerations for a [7] International Telecommunication Union, "Architecture and
telecommunication management network", ITU-T Recommendation specification of data communication network", ITU-
M.3013, February 2000. T Recommendation G.7712/Y.1703, June 2008.
[8] International Telecommunication Union, "Principles for a 9.2. Informative References
[8] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent Connections
and Switched Connections in a Generalized Multiprotocol Label
Switching (GMPLS) Network", RFC 5493, April 2009.
[9] International Telecommunication Union, "Principles for a
telecommunication management network", ITU-T Recommendation telecommunication management network", ITU-T Recommendation
M.3010, April 2005. M.3010, April 2005.
[9] International Telecommunication Union, "Principles for the [10] 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.
[10] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, [11] International Telecommunication Union, "Considerations for a
"Requirements for the Conversion between Permanent Connections telecommunication management network", ITU-T Recommendation
and Switched Connections in a Generalized Multiprotocol Label M.3013, February 2000.
Switching (GMPLS) Network", RFC 5493, April 2009.
[11] Fang, L. and M. Behringer, "Security Framework for MPLS and [12] Fang, L. and M. Behringer, "Security Framework for MPLS and
GMPLS Networks", GMPLS Networks",
draft-ietf-mpls-mpls-and-gmpls-security-framework-07 (work in draft-ietf-mpls-mpls-and-gmpls-security-framework-07 (work in
progress), October 2009. progress), October 2009.
[13] Andersson, L., Helvoort, H., Bonica, R., and D. Romascanu,
"The OAM Acronym Soup",
draft-ietf-opsawg-mpls-tp-oam-def-02 (work in progress),
January 2010.
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
Email: scott.mansfield@ericsson.com Email: scott.mansfield@ericsson.com
 End of changes. 45 change blocks. 
122 lines changed or deleted 139 lines changed or added

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