Internet Engineering Task Force S. Mansfield, Ed.
Internet-Draft E. Gray, Ed.
Intended status: Informational Ericsson
Expires: April 26, 2010 H. Lam, Ed.
Alcatel-Lucent
October 23, 2009
MPLS-TP Network Management Framework
draft-ietf-mpls-tp-nm-framework-01
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2010.
Copyright 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 for the
Mansfield, et al. Expires April 26, 2010 [Page 1]
Internet-Draft MPLS-TP NM Framework October 2009
Transport Profile for Multi-Protocol Label Switching (MPLS-TP).
This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an
MPLS-TP management network.
The management of the MPLS-TP network could be based on multi-tiered
distributed management systems. This document provides a description
of the network and element management architectures that could be
applied and also describes heuristics associated with fault,
configuration, and performance aspects of the management system.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Management Architecture . . . . . . . . . . . . . . . . . . . 4
2.1. Network Management Architecture . . . . . . . . . . . . . 4
2.2. Element Management Architecture . . . . . . . . . . . . . 6
2.3. Standard Management Interfaces . . . . . . . . . . . . . . 9
2.4. Management and Control specific terminology . . . . . . . 10
2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 10
3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 12
4. Configuration Management . . . . . . . . . . . . . . . . . . . 12
4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 12
5. Performance Management . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Mansfield, et al. Expires April 26, 2010 [Page 2]
Internet-Draft MPLS-TP NM Framework October 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.
This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an
MPLS-TP management network.
1.1. Terminology
Communication Channel (CCh): 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 CCh is technology specific. An example of physical
channels supporting the CCh is a DCC channel within SDH.
Data Communication Network (DCN): a network that supports Layer 1
(physical), Layer 2 (data-link), and Layer 3 (network) functionality
for distributed management communications related to the management
plane, for distributed signaling communications related to the
control plane, and other operations communications (e.g., order-wire/
voice communications, software downloads, etc.).
Equipment Management Function (EMF): the management functions within
an NE. See ITU-T G.7710 [2].
Local Craft Terminal (LCT): An out-of-band device that connects to an
NE for management purposes.
Management Application Function (MAF): An application process that
participates in system management. See ITU-T G.7710 [2].
Management Communication Channel (MCC): A CCh dedicated for
management plane communications.
Message Communication Function (MCF): The communications process that
performs functions such as information interchange and relay. See
ITU-T M.3013 [6].
Management Communication Network (MCN): A DCN supporting management
plane communication is referred to as a Management Communication
Network (MCN).
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.
Mansfield, et al. Expires April 26, 2010 [Page 3]
Internet-Draft MPLS-TP NM Framework October 2009
MPLS-TP network: a network in which MPLS-TP NEs are deployed.
Network Element Function (NEF): The set of functions necessary to
manage a network element.
Operations System (OS): A system that performs the functions that
support processing of information related to operations,
administration, maintenance, and provisioning (OAM&P) for the
networks, including surveillance and testing functions to support
customer access maintenance.
Signaling Communication Network (SCN): A DCN supporting control plane
communication is referred to as a Signaling Communication Network
(SCN).
Signaling Communication Channel (SCC): a 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).
2. Management Architecture
The management of the MPLS-TP network could be based on a multi-
tiered distributed management systems, for example as described in
ITU-T M.3010 [7] and ITU-T M.3060/Y.2401 [8]. Each tier provides a
predefined level of network management capabilities. The lowest tier
of this organization model includes the MPLS-TP Network Element that
provides the transport service and the Operations System (OS) at the
Element Management Level. The management application function within
the NEs and OSs provides the management support. The management
application function at each entity can include agents only, managers
only, or both agents and managers. The management application
function that include managers are capable of managing an agent
included in other management application functions.
The management communication to peer NEs and/or Operations Systems
(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. Management network
partitioning (Figure 1) below from ITU-T G.7710 [2] shows an example
of management network partitioning. Notation used in G.7710 for a
transport technology specific MN is x.MN, where x is the transport
Mansfield, et al. Expires April 26, 2010 [Page 4]
Internet-Draft MPLS-TP NM Framework October 2009
specific technology. In the example "O.MSN" is equivalent to an
optical management subnetwork, and "S.MSN" is equivalent to an SDH
management subnetwork. A MPLS-TP specific MN might be abbreviated as
MPLS-TP.MN. Where there is no ambiguity, we will use "MN" for an
MPLS-TP specific MN, and "MPLS-TP.MN" (or "MPLS- TP MN") and "MN"
where both are used in a given context.
______________________________ ______________________________
|.-------.-------.----.-------.||.-------.-------.----.-------.|
|: : : : :||: : : : :|
|:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:S.MSN-1:S.MSN-2: .. :S.MSN-n:|
|: : : : :||: : : : :|
'-============================-''-============================-'
_______________________________
|.-------.-------.-----.-------.|
|: : : : :|
|:x.MSN-1:x.MSN-2: ... :x.MSN-n:|
|: : : : :|
'-=============================-'
Management Network Partitioning
Figure 1
The management of the MPLS-TP network is be separable from the
management of the other technology-specific networks, and operate
independently of any particular client or server layer management
plane.
A MPLS-TP Management Network could be partitioned into MPLS-TP
Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just "MSN"
where usage is unambiguous) for consideration of scalability (e.g.
geographic or load balancing) or administrative (e.g. administrative
or ownership).
The MPLS-TP MSN could be connected to other parts of the MN through
one or more LCTs and/or OSs. The message communication function
(MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise
processes management messages over CChs 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 CChs. Within a particular site, the NEs could communicate via
an intra-site CCh or via a LAN.
Mansfield, et al. Expires April 26, 2010 [Page 5]
Internet-Draft MPLS-TP NM Framework October 2009
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 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, FCAPS (Fault,
Configuration, Accounting, Performance and Security) management, and
Control Plane functions. The EMF provides event message processing,
data storage and logging. The management Agent, a component of the
EMF, converts internal management information (MI signals) into
Management Application messages and vice versa. The Agent responds
to Management Application messages from the message communication
function by performing the appropriate operations on (for example)
the Managed Objects in a Management Information Base (MIB), as
necessary. The message communication function contains
communications functions related to the outside world of the NE (i.e.
Date & Time source, Management Plane, Control Plane, Local Craft
Terminal and Local Alarms).
The Date & Time functions keep track of the NE's date/time which is
used by the FCAPS management functions to e.g. time stamp event
reports.
Below are diagrams that illustrate the components of the element
management function of a network element. The high-level
decomposition of the NEF picture (Figure 2) provides the breakdown of
the Network Element Function, then the equipment management function
picture (Figure 3) provides the details of Equipment Management
Function, and finally the message communication function picture
(Figure 4) details the Message Communication Function.
Mansfield, et al. Expires April 26, 2010 [Page 6]
Internet-Draft MPLS-TP NM Framework October 2009
____________________________________________________
| Network Element Function (NEF) |
| _________________________________________ |
|| | |
|| Transport Plane Atomic Functions | |
||_________________________________________| |
| | |
| | Management |
| | Information |
| | |
| ___________________|_________________ |
| | (from date/time)<-----------+ |
| | Equipment | | |
| | Management (to/from management)<--------+ | |
| | Function | | | |
| | (EMF) (to/from control)<-----+ | | |
| | | | | | |
| | (to local alarm)---+ | | | |
| |_____________________________________| | | | | |
| | | | | |
| +--------------------------------------+ | | | |
| | +---------------------------------------+ | | |
| | | +----------------------------------------+ | |
| | | | +-----------------------------------------+ |
| | | | | Date & Time _________________ |external
| | | | | Interface | Message | |time
| | | | +-------------- Communication <-----------------------
| | | | | Function (MCF) | |
| | | | Management | | |management
| | | +----------------> | |element
| | | Plane Interface <---------------------->
| | | | | |
| | | Control Plane | | |
| | +------------------> | |
| | Interface | | |control
| | | | |element
| | Local Alarm | <---------------------->
| +--------------------> | |
| Interface | | |to local
| | | |alarms
| |_________________--------------------->
|____________________________________________________|
High-level decomposition of NEF
Figure 2
Mansfield, et al. Expires April 26, 2010 [Page 7]
Internet-Draft MPLS-TP NM Framework October 2009
______________________________________________________
| _______________________________________ |
| Equipment | Management Application ||
| Management | Function (MAF) ||
| Function | _________________ ||
| (EMF) || | __________________||
| ___________||_______________ | | ||
| | | | | Date & Time ||
| | Date & Time Functions | | | Interface ||<-- 1
| |____________________________| | |__________________||
| ___________||_______________ | __________________||
| | | | | ||
| | Fault Management | | | Management ||
| |____________________________| | | Plane Interface ||<-> 2
| ___________||_______________ | |__________________||
| | | | ||
| | Configuration Management | | __________________||
| |____________________________| | | ||
| ___________||_______________ | | Control ||
| | | | | Plane Interface ||<-> 3
| | Account Management | | |__________________||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Performance Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Security Management | | ||
| |____________________________| | ||
| ___________||_______________ | ||
| | | | ||
| | Control Plane Function | | ||
| |____________________________| | ||
| || | __________________||
| || | | ||
| || | | Local Alarm ||
| +----->| Agent | | Interface ||--> 4
| v ||_________________| |__________________||
| .-===-. |_______________________________________||
| | MIB | |
| `-._.-' |
|______________________________________________________|
Equipment Management Function
Figure 3
Mansfield, et al. Expires April 26, 2010 [Page 8]
Internet-Draft MPLS-TP NM Framework October 2009
_________________
| |
| Message |
| Communication |
| Function (MCF) |
| _______________ |
Date & Time || || external
1 <--------------|| Date & Time ||<--------------
Information || Communication || time source
||_______________||
| |
| _______________ |
Management || || management
Plane || Management || element
2 <------------->|| Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| |
| _______________ | control
Control Plane || || element
3 <------------->|| Control Plane ||<------------->
Information || Communication || (e.g. - EMS,
||_______________|| peer NE)
| : |
| : |
| : |
| _______________ |
Local Alarm || || to local
4 -------------->|| Local Alarm ||-------------->
Information || Communication || alarms...
||_______________||
|_________________|
Message Communication Function
Figure 4
2.3. Standard Management Interfaces
The MPLS-TP NM requirements [1] document places no restriction on
which management interface is to be used for managing an MPLS-TP
network. It is possible to provision and manage an end-to-end
connection across a network where some segments are created/managed/
deleted, for example by netconf or snmp and other segments by CORBA
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. The protocol(s) to be supported are at
Mansfield, et al. Expires April 26, 2010 [Page 9]
Internet-Draft MPLS-TP NM Framework October 2009
the discretion of the operator.
2.4. Management and Control specific terminology
Data Communication Network (DCN) is the common term for the network
used to transport Management and Signaling information between:
management systems and network elements, management systems to other
management systems, and networks elements to other network elements.
The Management Communications Network (MCN) is the part of the DCN
which supports the transport of Management information for the
Management Plane. The Signaling Communications Network (SCN) is the
part of the DCN which supports transport for signaling information
for the Control Plane. As shown in the communication channel
terminology picture (Figure 5) each technology has its own
terminology that is used for the channels that support management and
control plane information transfer. For MPLS-TP, the management
plane uses the Management Communication Channel (MCC) and the control
plane uses the Signaling Communication Channel (SCC).
2.5. Management Channel
The Communication Channel (CCh) provides a logical channel between
NEs for transferring Management and/or Signaling information. Note
that some technologies provide separate communication channels for
Management (MCC) and Signaling (SCC).
MPLS-TP NEs communicate via the DCN. The DCN connects NEs with
management systems, NEs with NEs, and management systems with
management systems.
Mansfield, et al. Expires April 26, 2010 [Page 10]
Internet-Draft MPLS-TP NM Framework October 2009
Common Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(CCh) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Communication
Channel (CCh) for Transport of Information
Management Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(MCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Management
Communication Channel (MCC) for Transport
of Management Information
Control Terminology ____
__________ __________ | |
| | | | /->| NE | \ ____
|Management| |Operations| / |____| \ | |
|Station | <---> |System | |(SCC) | NE |
|__________| |__________| \ _|__ / |____|
\->| | /
| NE |
|____|
Network Elements use a Control/Signaling
Communication Channel (SCC) for Transport
of Signaling Information
Communication Channel Terminology
Figure 5
3. Fault Management
A fault is the inability of a function to perform a required action.
This does not include an inability due to preventive maintenance,
Mansfield, et al. Expires April 26, 2010 [Page 11]
Internet-Draft MPLS-TP NM Framework October 2009
lack of external resources, or planned actions. Fault management
provides the mechanisms to detect, verify, isolate, notify, and
recover from the fault.
3.1. Supervision
ITU-T G.7710 [2] lists five basic categories of supervision that
provide the functionality necessary to detect, verify, and notify a
fault. The categories are: Transmission Supervision, Quality of
Service Supervision, Processing Supervision, Hardware Supervision,
and Environment Supervision. Each of the categories provides a set
of recommendations to ensure the fault management process is
fulfilled.
3.2. Validation
ITU-T G.7710 [2] describes a fault cause as a limited interruption of
the required function. It is not reasonable for every fault cause to
be reported to maintenance personnel. The validation process is used
to turn fault causes (events) into failures (alarms).
3.3. Alarm Handling
Within an element management system, it is important to consider
mechanisms to support severity assignment, alarm reporting control,
and logging.
4. Configuration Management
Configuration management provides the mechanisms to provision the
MPLS-TP services, setup security for the MPLS-TP services and MPLS-TP
network elements, and provides the destination for fault
notifications and performance parameters. Inventory reporting is
also considered part of configuration management.
Associated with configuration management are hardware and software
provisioning and inventory reporting.
4.1. LSP ownership handover
MPLS-TP networks can be managed not only by Network Management
Systems (i.e. management plane), but also by control plane protocols.
The utilization of the control plane is not a mandatory requirement
(see MPLS-TP Requirements [3]) but it is often used by network
operators in order to make network configuration and LSP recovery
both faster and simpler.
Mansfield, et al. Expires April 26, 2010 [Page 12]
Internet-Draft MPLS-TP NM Framework October 2009
In networks where both CP and MP are provided, an LSP could be
created by either (CP or MP). The entity creating an LSP owns the
data plane resources comprising that LSP. Only the owner of an LSP
is typically able modify/delete it. This results in a need for
interaction between the MP and CP to allow either to manage all the
resources of a network.
Network operators might prefer to have full control of the network
resources during the set-up phase and then allow the network to be
automatically maintained by the control plane. This can be achieved
by creating LSPs via the management plane and subsequently
transferring LSP ownership to the control plane. This is referred to
as "ownership handover" RFC 5493 [9]. MP to CP ownership handover 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
that is recommended - but not required - for (G)MPLS networks because
it has only minor applications (for example moving LSPs from one path
to another as a maintenance operation).
The LSP handover procedure has already been standardized for GMPLS
networks, where the signaling protocol used is RSVP-TE RFC 3209 [4].
The utilization of RSVP-TE enhancements are defined in [5].
MP and CP interworking includes also the exchange of information that
is either requested by the MP, or a notification by the CP as a
consequence of a request from the MP or an automatic action (for
example a failure occurs or an operation is performed). The CP is
asked to notify the MP in a reliable manner about the status of the
operations it performs and to provide a mechanism to monitor the
status of control plane objects (e.g. TE Link status, available
resources), and to log control plane LSP related operations. Logging
is one of the most critical aspects because the MP always needs to
have an accurate history and status of each LSP and all data plane
resources involved in it.
5. Performance Management
Performance statistics could 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 operator with the ability to do
performance measurement for maintenance purpose such as diagnosis or
to provide detailed verification of proactive measurement. It is
Mansfield, et al. Expires April 26, 2010 [Page 13]
Internet-Draft MPLS-TP NM Framework October 2009
used typically on specific LSP service instances for a limited time,
thus limiting its impact on network performance under normal
operations. Therefore on demand measurement does not result in
scaling issues.
Proactive measurement is used continuously over time after being
configured with periodicity and storage information. Data collected
from proactive measurement are usually used for verifying the
performance of the service. Proactive performance monitoring has the
potential to overwhelm both the process of collecting performance
data at a network element (for some arbitrary number of service
instances traversing the NE), and the process of reporting this
information to the OS. As a consequence of these considerations,
operators would typically limit the services to which proactive
performance measurement would be applied to a very selective subset
of the services being provided and would limit the reporting of this
information to statistical summaries (as opposed to raw or detailed
performance statistics).
6. Acknowledgements
The authors/editors gratefully acknowledge the thoughtful review,
comments and explanations provided by Diego Caviglia and Bernd
Zeuner.
7. Contributors
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Provisions to any of the network mechanisms designed to satisfy the
requirements described herein need to prevent their unauthorized use
and provide a means for an operator to prevent denial of service
attacks if those network mechanisms are used in such an attack.
Solutions need to provide mechanisms to prevent private information
from being accessed by unauthorized eavesdropping, or being directly
obtained by an unauthenticated network element, system or user.
Performance of diagnostic functions and path characterization
involves extracting a significant amount of information about network
Mansfield, et al. Expires April 26, 2010 [Page 14]
Internet-Draft MPLS-TP NM Framework October 2009
construction that the network operator considers private.
10. References
10.1. Normative References
[1] Mansfield, S. and K. Lam, "MPLS TP Network Management
Requirements", draft-ietf-mpls-tp-nm-req-06 (work in progress),
October 2009.
[2] International Telecommunications Union, "Common equipment
management function requirements", ITU-T Recommendation G.7710/
Y.1701, July 2007.
[3] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
Ueno, "MPLS-TP Requirements", draft-ietf-mpls-tp-requirements-10
(work in progress), August 2009.
[4] 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.
[5] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Bardalai, "RSVP-TE Signaling Extension For Management Plane To
Control Plane LSP Handover In A GMPLS Enabled Transport
Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-04 (work in
progress), September 2009.
10.2. Informative References
[6] International Telecommunications Union, "Considerations for a
telecommunications management network", ITU-T Recommendation
M.3013, February 2000.
[7] International Telecommunications Union, "Principles for a
telecommunication managemetn network", ITU-T Recommendation
M.3010, April 2005.
[8] International Telecommunications Union, "Principles for the
Management of Next Generation Networks", ITU-T Recommendation
M.3060/Y.2401, March 2006.
[9] 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.
Mansfield, et al. Expires April 26, 2010 [Page 15]
Internet-Draft MPLS-TP NM Framework October 2009
Authors' Addresses
Scott Mansfield (editor)
Ericsson
250 Holger Way
San Jose, CA 95134
US
Phone: +1 724 931 9316
Email: scott.mansfield@ericsson.com
Eric Gray (editor)
Ericsson
900 Chelmsford Street
Lowell, MA 01851
US
Phone: +1 978 275 7470
Email: eric.gray@ericsson.com
Hing-Kam Lam (editor)
Alcatel-Lucent
600-700 Mountain Ave
Murray Hill, NJ 07974
US
Phone: +1 908 582 0672
Email: hklam@alcatel-lucent.com
Mansfield, et al. Expires April 26, 2010 [Page 16]
