WDIFF

draft-aboulmagd-ccamp-transport-lmp-00.txt --> draft-aboulmagd-ccamp-transport-lmp-01.txt

CCAMP WG

Network Working Group Osama Aboul-Magd
Internet Draft Nortel Networks
Document: draft-aboulmagd-ccamp-transport-lmp- Feb. , 2003
00.txt
01.txt
Category: Informational Deborah Brungard
AT&T

Jonathan Lang
Rincon Networks

Dimitri
Papadimitriou
Alcatel

June, 2003

A Transport Network View to LMP

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.

This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft

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.

1. Abstract

The Link Management Protocol (LMP) has bee defined at been developed as part of the IETF
Generalized MPLS (GMPLS) protocol suite to
facilitate the management of transport network manage Traffic
Engineering (TE) links. The GMPLS control plane (routing and
signaling) uses TE links for establishing Label Switched Paths
(LSPs). This memo describes the sake relationship of
supporting IP traffic over transport network. The the LMP development
has been progressing procedures
to ædiscoveryÆ as defined in the context of GMPLS related International Telecommunication
Union (ITU), i.e. G.8080, G.7714, and G.7714.1, and on-going ITU-T
work.

The This document provides an overview of LMP was developed with a packet centric view in mind. Since it
is intended for the control context of transport network it is essential to
bridge the gap between the two views. It is
the objective of this
draft to project LMP in a ITU-T Automatically Switched Optical Networks (ASON) [G.8080]
and transport network context [G.805] terminology and to relate relates it to the ITU-

Aboul-Magd Expires Dec. 2003 1
Draft-aboulmagd-transport-lmp-01.txt June 2003

T discovery work that has been going on at to promote a common understanding for progressing
the ITU. work of IETF and ITU-T.

2. Conventions used in this document

Aboul-Magd Informational- Sept. 2003 1
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 2003

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 [2].

3. Transport Network Architecture

Traditionally Terminology

The reader is assumed to be familiar with the development of transport network standards, e.g.
SONET, SDH, OTN, etc. have been progressing at T1X1 terminology in [LMP]
and at the ITU-T
SG 15. To facilitate the development of those standards the [LMP-TEST]. The following ITU have
developed network architecture terminology/abbreviations are used
in recommendation G.805. The G.805
architecture is closely followed by this document:

Link: a subset of ports at the SG 15 in developing its
transport network recommendations.

G.805 defines layered network architecture which defines edge of a client-
server architecture. The architecture is recursive so subnetwork or access group
that it can be
applied at different network layers are associated with one layer acts as a corresponding subset of ports at the
server while the layer above it defines the client.

The basic components edge
of the G.805 architecture are ôsubnetworksö
and ôlinksö. A another subnetwork is defined as or access group.

OTN: Optical transport network

PDH: Plesiosynchronous digital hierarchy

SDH: Synchronous digital hierarchy.

Subnetwork: a set of ports which are available for the purpose of transferring ôcharacteristic
informationö. A link consists of a subset of ports at the edge of
one subnetwork (or ôaccess groupö) and is associated with a
corresponding subset of ports at the edge of another subset or
access group.

Two types of connections are defined. Link connection (LC) is a
fixed and inflexible while
routingÆ characteristic informationÆ.

Subnetwork Connection (SNC): a subnetwork connection (SNC) is flexible
and connection that is setup and
released using management or control plane. A
network connection is then plane procedures.

Link Connection (LC): a transport entity that transfers information
between ports across a link.

Network Connection (NC): A concatenation of subnetwork and link and subnetwork
connections.

G.805 defines a set

Connection Termination Point (CTP): A Connection Termination Point
(CTP) represents the state of a Connection Point (CP) (M.3100). The
CP is a reference points for point representing the purpose end point of
identification in the management a link
connection and represents the control plane. North input port of an Adaptation
function.

Termination Connection Point (TCP): A link reference point that
represents the output of a Trail Termination source function or the
input to a
subnetwork connection is delimited by connection points (CP). Trail Termination sink function. A network connection is delimited by
represents a termination transport entity between TCPs.

Subnetwork Point (SNP): SNP is an abstraction that represents an
actual or potential underlying connection point
(TCP). A link (CP) or termination

Aboul-Magd Expires Dec. 2003 2
Draft-aboulmagd-transport-lmp-01.txt June 2003

connection in point (TCP) for the client layer is represented by a
pair purpose of adaptation functions and a trail in the server layer
network. control plane
representation.

Subnetwork Point Pool (SNPP): A trail represents set of SNP that are grouped together
for the transfer purpose of monitored adapted
characteristics information routing.

4. Introduction

The GMPLS control plane consists of several building blocks as
described in [GMPLS-ARCH]. The building blocks include signaling,
routing, and link management for establishing LSPs. For scalability
purposes, multiple physical resources can be combined to form a
single traffic engineering (TE) link for the client layer purposes of path
computation by Constrained SPF and by GMPLS control plane signaling.
As manual provisioning and management of these links is impractical,
LMP was specified to manage TE links. Two mandatory management
capabilities of LMP are control channel management and TE link
property correlation. Additional optional capabilities include
verifying physical connectivity and fault management. LMP [LMP]
defines the messages and procedures for GMPLS TE link management.
[LMP-TEST] defines SONET/SDH specific messages and procedures for
link verification.

G.8080 Amendment 1 defines control plane discovery as two separate
processes, one process occurs within the transport plane space and
the other process occurs within the control plane space. The ITU-T
has developed Recommendation G.7714 ÆGeneralized automatic discovery
techniquesÆ defining the functional processes and information
exchange related to transport plane discovery aspects: i.e., layer
adjacency discovery and physical media adjacency discovery. Specific
methods and protocols are not defined in [G.7714]. ITU-T
Recommendation G.7714.1 æProtocol for automatic discovery in SDH and
OTN networksÆ defines a protocol and procedure for transport plane
layer adjacency discovery (e.g. discovering the transport plane
layer end point relationships and verifying their connectivity). The
ITU-T is currently working to extend discovery to control plane
aspects including defining a Recommendation on framework
architecture for discovery and a Recommendation on ÆControl plane
initial establishment, reconfiguration.

5. Transport Network Architecture

A generic functional architecture for transport networks is defined
in the ITU-T Recommendation G.805. This recommendation describes
the functional architecture of transport networks in a technology
independent way. This architecture forms the basis for a set of
technology specific architectural recommendations for transport
networks (e.g., SDH, PDH, OTN, etc.)

The architecture defined in G.805 is designed using a layered model
with a client-server relationship between layers. The architecture
is recursive in nature; a network layer is both a server to the
client layer above it and a client to the server layer below it.

Aboul-Magd Expires Dec. 2003 3
Draft-aboulmagd-transport-lmp-01.txt June 2003

There are two basic building blocks defined in G.805: Æsubnetworksæ
and ÆlinksÆ. A subnetwork is defined as a set of ports which are
available for the purpose of routing Æcharacteristic informationæ. A
link consists of a subset of ports at the edge of one subnetwork (or
Æaccess groupÆ) and is associated with a corresponding subset of
ports at the edge of another subnetwork or access group.

Two types of connections are defined in G.805: Ælink connectionÆ
(LC) and Æsubnetwork connectionÆ (SNC). A link connection is a fixed
and inflexible connection, while a subnetwork connection is flexible
and is setup and released using management or control plane
procedures. A network connection is defined as a concatenation of
subnetwork and link connections. Figure 1 illustrates link and
subnetwork connections.

(++++++++) (++++++++)
( SNC ) LC ( SNC )
(o)--------(o)----------(o)--------(o)
( ) CP CP ( )
(++++++++) (++++++++)

subnetwork subnetwork

Figure 1: Subnetwork and Link Connections

G.805 defines a set of reference points for the purpose of
identification in both the management and the control plane. These
identifiers are NOT required to be the same. A link connection or a
subnetwork connection is delimited by connection points (CP). A
network connection is delimited by a termination connection point
(TCP). A link connection in the client layer is represented by a
pair of adaptation functions and a trail in the server layer
network. A trail represents the transfer of monitored adapted
characteristics information of the client layer network between
access points (AP). A trail is delimited by two access points, one
at each end of the trail. Figure 2 shows a network connection and
its relationship with link and subnetwork connections. Figure 2 also
shows the CP and TCP reference points.

|<-------Network Connection---------->|
| |
| (++++++++) (++++++++) |
|( SNC ) LC ( SNC ) |
(o)--------(o)----------(o)--------(o)|
TCP( )| CP CP |( )TCP
(++++++++) | | (++++++++)
| |
| Trail |
|<-------->|

Aboul-Magd Expires Dec. 2003 4
Draft-aboulmagd-transport-lmp-01.txt June 2003

| |
--- ---
\ / \ /
- -
AP 0 0 AP
| |
(oo)------(oo)

Figure 2: Network Connection and Reference Points

For management plane purpose purpose, the G.805 reference points are
represented by a set of management objects described in ITU
recommendation M.3100. Connection termination points (CTP) and trail
termination points (TTP) are the management plane objects for CP and
TCP (or AP??) respectively.

In the same way as in M.3100, the transport resources in G.805 are
identified for the purpose of control plane by entities suitable for

Aboul-Magd Informational- Sept. 2003 2
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 2003
connection control. G.8080 introduces the reference architecture for
the control plane of the automatic switched optical networks (ASON).
G.8080 introduces a set of reference points relevant to the ASON
control plane and their relationship to the corresponding points in
the transport plane. A Subnetwork subnetwork point (SNP) is an abstraction that
represents an actual or potential underlying CP or an actual and or
potential TCP. A set of SNPs that are grouped together for the
purpose of routing is called SNP pool (SNPP). Similar called SNP pool (SNPP). Similar to LC and SNC,
the SNP-SNP relationship may be static and inflexible (this is
referred to as SNP link connection) or it can be dynamic and
flexible (this is referred to as SNP subnetwork connection).

6. G.8080 Discovery Framework

G.8080 provides a reference control plane architecture based on the
descriptive use of functional components representing abstract
entities and abstract component interfaces. The description is
generic and no particular physical partitioning of functions is
implied. The input/output information flows associated with the
functional components serve for defining the functions of the
components and are considered to be conceptual, not physical.
Components can be combined in different ways and the description is
not intended to limit implementations. Control plane discovery is
described in G.8080 by using three components: Discovery Agent (DA),
Termination and adaptation performer (TAP), and Link Resource
Manager (LRM).

The objective of the discovery framework in G.8080 is to LC and SNC, establish
the SNP-SNP relationship may be static and inflexible (this is
referred to as SNP between CP-CP link connection) or it can be dynamic connections (transport plane)
and
flexible (this is referred to as SNP subnetwork connection).

4. G.8080 Discovery Framework SNP-SNP link connections (control plane). The fundamental
characteristics of G.8080 discovery framework is the separation
between the control and the transport plane name spaces. The
separation between the two name spaces has the advantage that the

Aboul-Magd Expires Dec. 2003 5
Draft-aboulmagd-transport-lmp-01.txt June 2003

discovery of each the transport plane can be performed independent from
that of the other place. It facilitates the commissioning control plane (and vise-versa) of the
transport plane other, and
independent from the control plane. The separation of the method used in each name spaces space. This allows
assigning link connections in the control plane names to be completely
independent of without the method used to distribute link
connection being physically connected.

Discovery encompasses two separate processes: transport names plane
discovery, i.e. CP-to-CP and TCP-to-TCP connectivity and (2) control
plane discovery, i.e. SNP-to-SNP and SNPP-to-SNPP links.

G.8080 Amendment 1 defines the discovery agent (DA) as the entity
responsible for the discovery in the transport plane. The DS DA
operates in the transport name space only and provides the
separation between that space and the control plane names. A local
DA is is only aware of the CPs and TCPs that are assigned to him. it. The DA
holds the CP-CP link connection in the transport plane to enable
SNP-SNP link connections to be bound to them later.

Control plane discovery takes place entirely within the control
plane name space (SNPs). Link Resource Manager (LRM) hold the SNP-
SNP binding information necessary for the control plane name of the
link connection, while termination adaptation performer (TAP) holds
the relation between the control plane name (SNP) and the transport
plane name (CP) of the resource.

5. Overview of G.7714.1

G.7714.1 describes the methods, procedures, and transport plane
mechanisms for discovering layer adjacency for ASON. It includes
discovery of the relationship of the link connection end points and
verifying their connectivity. It applies to Single Layer in the
context of the transport name space. The result of the discovery
process is a Link Connection name, which includes a pair of
Transport end points + Discovery Agent names. G7714.1 allows both
in-service discovery using server layer trail overhead, and out-of-
service discovery at the client layer.

Aboul-Magd Informational- Sept. 2003 3
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 2003

Information relevant to discovery are the DA ID and the TCP ID. a later time. The
DA ID is allowed to
CP-CP relationship may be either a DA address discovered (e.g. per G.7714.1) or provided
by a DA name. The DA management system.

Control plane discovery takes place entirely within the control
plane name
can then be resolved to a DA address. space (SNPs). The TCP ID contains Link Resource Manager (LRM) holds the
identifier
SNP-SNP binding information necessary for the TCP being discovered. This has only local
significance within control plane name of
the link connection, while the termination adaptation performer
(TAP) holds the relation between the control plane name (SNP) and
the scope transport plane name (CP) of the DA.

Discovery information is exchanged in resource. Figure 3 shows the Discovery
relationship and Discovery
Response message. The discovery response message is sent in response
to the different entities for transport and control
discoveries.

LRM LRM
+-----+ holds SNP-SNP Relation +-----+
| |-------------------------| |
+-----+ +-----+
| |
v v
+-----+ +-----+
| o | SNPÆs in SNPP | o |
| | | |
| o | | o |
| | | |
| o | | o |
+-----+ +-----+
| |
v v Control Plane
+-----+ +-----+ Discovery message. It contains both
| | Termination and | |
---|-----|-------------------------|-----|---------
| | Adaptation Performer | |
+-----+ (TAP) +-----+ Transport Plane
Discovery

Figure 3: Discover in the received Control and the sent
DA ID and ICP ID. Mis-wiring can Transport Planes

Aboul-Magd Expires Dec. 2003 6
Draft-aboulmagd-transport-lmp-01.txt June 2003

A discovery process may then be detected if validate the TCP-ID
corresponding to resulting SNP link
connections. The degree of validation required is dependent on the remote end point
integrity of the link connection is not relationships initially provided by the same in both messages.

Once a bi-directional link has been discovered it should be checked
against transport
plane (or management provided policy plane), and the integrity of the process used
to determine if correct TCP-link
connection end points map CTPs to SNPs. Specific information that needs to be
exchanged, and specific protocol procedures for SNP and SNPP link
association and validation have not been correctly connected.

6. specified yet in ITU-T.

7. LMP and G.8080 G8080 Discovery

The Link Management Protocol (LMP) has bee defined at the IETF to
facilitate the management

7.1 LMP and G.8080 Terminology Mapping

GMPLS is a set of transport network IP-based protocols, including LMP, providing a
control plane for discovery multiple data plane technologies, including
optical/transport networks and their resources (i.e. wavelengths,
timeslots, etc.) and without assuming any restriction on the control
plane architecture (see [GMPLS-ARCH]). Whereas, G.8080 defines a
control plane reference architecture for optical/ transport network elements. The
networks. Being developed in separate standards forums, and with
different scope, they use different terms and definitions.

Terminology mapping between LMP development has been
progressing and ASON (G.805/G.8080) is an
important step towards the understanding of the two architectures
and allows for potential cooperation in areas where cooperation is
possible. To facilitate this mapping, we differentiate between the context
two types of GMPLS related work.

LMP was developed with a IP framework data links in mind. However many transport
elements do not support IP natively and LMP. According to LMP, a data link may be
considered by each node that it terminates on as either a result the concepts of æportÆ or
a æcomponent linkÆ. The LMP need to be adapted notions of port and component link are
supported by the G.805/G.8080 architecture. G.8080 refers to a
component link as a variable adaptation function i.e. a single
server layer trail dynamically supporting different multiplexing
structures. Note that when the transport world. Since data plane delivers its own
addressing space, LMP functions Interface_IDs and Data Links IDs are intended for used as
handlers by the control of transport network it is essential plane to
relate the concepts and functions between the IP actual CP Name and transport views.
It CP-to-CP
Name, respectively.

Aboul-Magd Expires Dec. 2003 7
Draft-aboulmagd-transport-lmp-01.txt June 2003

where:
- Data Link ID: <Local Interface ID; Remote Interface ID>
- TE Link ID: <Local Link ID; Remote Link ID>

.2 LMP in a transport
network context and to relate it to the discovery work that has been
going on at the ITU. G.8080 Discovery Relationship

LMP currently consists of four procedures. Those procedures primary procedures, of which, the
first two are mandatory and the control last two are optional:

1. Control channel maintenance, link management
2. Link property correlation, link connection
verification, and fault management. One fundamental difference
between correlation
3. Link verification
4. Fault management

LMP procedures that are relevant to G.8080 control plane discovery
are control channel maintenance and link property correlation. Key
to understanding G.8080 discovery frame work aspects in relation to LMP is that
LMP procedures are specific for an IP-based control plane
abstraction of the transport plane.

LMP control channel management is used to establish and maintain
control channel connectivity between LMP adjacent nodes. In GMPLS,
the absence of control channels between two adjacent nodes are not required to
use the
explicit separation same physical medium as the TE links between transport and those nodes.
The control channels that are used to exchange the GMPLS control-
plane names.

The part information exist independently of the TE links they manage
(i.e., control channels may be in-band or out-of-band, provided the
associated control points terminate the LMP that is relevant packets). The Link
Management Protocol (LMP) was designed to G.7714.1 is manage TE links,
independently of the link connection
verification part. In both cases in-band discovery message physical medium capabilities of the data links.
This is used.
LMP uses an in-band Test done using a Config message for this purpose that exchange followed by a
lightweight keep-alive message exchange.

Aboul-Magd Expires Dec. 2003 8
Draft-aboulmagd-transport-lmp-01.txt June 2003

Link property correlation is used to
transmit the local Interface ID aggregate multiple data links
into a single TE Link and to synchronize the remote end of the link.
TestStatus message link properties.

Link verification is used that copies to verify the received Interface ID and
transmits physical connectivity of the local Interface ID to
data links and verify the other end mapping of the link. While
Interface ID in LMP Interface-ID to Link-ID (CP
to SNP). The Local to Remote associations can be IPv4, IPv6, obtained using a
priori knowledge or unnumbered, using the TCP ID in
G.7714.1 Link verification procedure.

Fault management is a transport layer ID that may or may not use any of
those format.

Aboul-Magd Informational- Sept. 2003 4
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 2003

LMP procedures that are relevant primarily used to G.8080 control plane discovery
are control channel maintenance suppress alarms and link property correlation. This
feature is used to synchronize
localize failures. It is an optional LMP procedure, itÆs use will
depend on the TE Link properties specific technologyÆs capabilities.

LMP supports distinct transport and verify control plane name spaces with
the
TE (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE
object allows transport plane names to be associated with interface
identifiers [LMP-TEST].

Aspects of LMP link configuration. Link Property Correlation verification appear similar to G.7714.1
discovery, however the two procedures are different. G.7714.1
provides full discovery of all intra and inter the transport plane layer relationships along adjacencies. It
provides a
potential connection, requiring that generic procedure to discover the connectivity of two end
points in the transport plane. Whereas, LMP link verification
procedure is a single connection control plane driven procedure and assumes either (1)
a priori knowledge of the associated data planeÆs local and remote
end point connectivity and Interface_IDs (e.g. via management
application manages multiples layers. One plane
or use of the problems G.7714.1), or (2) support of this
approach is that All connection management applications must
understand the engineering constraints of remote node for
associating the technology used to
implement each layer (e.g. at least four different implementations
are supported at data interface being verified with the Photonic layer). ItÆs not clear either how content of
the
topology information can be shared with other applications or how TRACE object (inferred mapping). For SONET/SDH transport
networks, LMP verification uses SONET/SDH Trail Trace identifier
(see G.783).

As G.7714.1 supports the network can be partitioned.

Control use of transport plane discovery is described in G.8080 although no
recommendation has been started yet. The Control
independent of the platform providing the capability. Furthermore
G.7714.1 it supports use of a Discovery process
described Agent located in G.8080 involves an external
system and the interactions between use of text-oriented man-machine language to provide
the DA, TAP
and LRM as follows: SNPs are pre-assigned interface. Therefore, G.7714.1 limits the discovery messages to SNPPs (which are
equivalent
printable characters defined by T.50 and requires Base64 encoding
for the TCP-ID and DA ID. External name-servers may be used to LMP TE-Links). When
resolve the association CTP-SNP G.7714.1 TCP name. Whereas, LMP is
received from based on the TAP, use of
an IP-based control plane, and the CTP-CTP relationship have been found
as per G.7714.1, LMP interface ID uses IPv4, IPv6,
or unnumbered interface IDs (no encoding restrictions).

In summary, comparing the SNP-SNP relation is discovered as well as their
associated SNPP-SNPP relation-ship. This relation LMP link verification with G.8080, LMP
link verification process is then verified
by communicating in the end-point LRMs. Specific information that need G.8080 control plane discovery
space, e.g. SNP link validation as described in 6.3/G.8080. And
analogous to be exchanged or particular procedures have not been addressed
yet. There the description in G.8080, it is indeed optional, dependent on
the room to use LMP messages and procedures degree of validation required for
this purpose. an operatorÆs use scenario.

8. Security Considerations

Aboul-Magd Expires Dec. 2003 9
Draft-aboulmagd-transport-lmp-01.txt June 2003

This draft doesnÆt introduce any security issues.

9. References

1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.

2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997

10. Acknowledgments

3 [LMP] J.P.Lang (Editor), "Link Management Protocol," draft-ietf-
ccamp-lmp-09.txt, June 2003.

4 [LMP-TEST] J.P.Lang et al., "SONET/SDH Encoding for Link
Management Protocol (LMP) Test messages," draft-ietf-ccamp-lmp-
test-sonet-sdh-03.txt, May 2003.

5 [GMPLS-ARCH] Eric Mannie (Editor), Generalized Multi-protocol
Label Switching Architecture,draft-ietf-ccamp-gmpls-
architecture-07.txt, May 2003.

6 [G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic
discovery techniques.

7 [G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic
discovery in SDH and OTN networks.

8 [G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the
automatically switched optical network (ASON).

9 [G.805] ITU-T G.805 (2000), Generic functional architecture of
transport netowrks.

0. Acknowledgement

The author authors would like to thank Astrid Luzano and Luzano, Don Fedyk Fedyk, and John
Drake for their valuable comments.

11.

1. Author's Addresses

Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station C

Aboul-Magd Informational- Sept. 2003 5
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 2003 ÆCÆ
Ottawa, Ontario, Canada
K1Y-4H7
Tel: 613-763-5827
E.mail:
Phone: +1 613 763-5827
Email: osama@nortelnetworks.com

Deborah Brungard

Aboul-Magd Informational- Sept. Expires Dec. 2003 6
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 10
Draft-aboulmagd-transport-lmp-01.txt June 2003

AT&T
Rm. D1-3C22
200 S. Laurel Ave.
Middletown, NJ 07748, USA
Email: dbrungard@att.com

Jonathan P. Lang
Rincon Networks
Santa Barbara, CA
Email : jplang@ieee.org

Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-84-91
Email: dimitri.papadimitriou@alcatel.be

Aboul-Magd Expires Dec. 2003 11
Draft-aboulmagd-transport-lmp-01.txt June 2003

Full Copyright Statement

"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into into.

Aboul-Magd Informational- Sept. Expires Dec. 2003 7 12
----