CCAMP WG Osama Aboul-Magd
Internet Draft Nortel Networks
Document: draft-aboulmagd-ccamp-transport-lmp- Feb. , 2003
00.txt
Category: Informational
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 the IETF to
facilitate the management of transport network for the sake of
supporting IP traffic over transport network. The LMP development
has been progressing in the context of GMPLS related work.
The LMP was developed with a packet centric view in mind. Since it
is intended for the control 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 transport network context and to relate it
to the discovery work that has been going on at the ITU.
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 the development of transport network standards, e.g.
SONET, SDH, OTN, etc. have been progressing at T1X1 and at the ITU-T
SG 15. To facilitate the development of those standards the ITU have
developed network architecture in recommendation G.805. The G.805
architecture is closely followed by the SG 15 in developing its
transport network recommendations.
G.805 defines layered network architecture which defines a client-
server architecture. The architecture is recursive so that it can be
applied at different network layers with one layer acts as the
server while the layer above it defines the client.
The basic components of the G.805 architecture are ôsubnetworksö
and ôlinksö. A subnetwork is defined as 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 a subnetwork connection (SNC) is flexible
and is setup and released using management or control plane. A
network connection is then a concatenation of subnetwork and link
connections.
G.805 defines a set of reference points for the purpose of
identification in the management and the control plane. A link 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.
For management plane 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 control
plane and their relationship to the corresponding points in the
transport plane. A Subnetwork point (SNP) is an abstraction that
represents an actual or potential underlying CP or an actual and
potential TCP. A set of SNPs that are grouped together for the
purpose of routing is 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).
4. G.8080 Discovery Framework
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 discovery of each plane can be performed independent from that
of the other place. It facilitates the commissioning of the
transport plane independent from the control plane. The separation
of the name spaces allows control plane names to be completely
independent of the method used to distribute transport names
G.8080 Amendment 1 defines the discovery agent (DA) as the entity
responsible for the discovery in the transport plane. The DS
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.
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. The
DA ID is allowed to be either a DA address or a DA name. The DA name
can then be resolved to a DA address. The TCP ID contains the
identifier for the TCP being discovered. This has only local
significance within the scope of the DA.
Discovery information is exchanged in the Discovery and Discovery
Response message. The discovery response message is sent in response
to the Discovery message. It contains both the received and the sent
DA ID and ICP ID. Mis-wiring can then be detected if the TCP-ID
corresponding to the remote end point of the link connection is not
the same in both messages.
Once a bi-directional link has been discovered it should be checked
against management provided policy to determine if correct TCP-link
connection end points have been correctly connected.
6. LMP and G.8080 Discovery
The Link Management Protocol (LMP) has bee defined at the IETF to
facilitate the management of transport network for discovery and
control transport network elements. The LMP development has been
progressing in the context of GMPLS related work.
LMP was developed with a IP framework in mind. However many transport
elements do not support IP natively and as a result the concepts of
LMP need to be adapted to the transport world. Since LMP functions
are intended for the control of transport network it is essential to
relate the concepts and functions between the IP and transport views.
It is the objective of this draft to project LMP in a transport
network context and to relate it to the discovery work that has been
going on at the ITU.
LMP consists of four procedures. Those procedures are the control
channel maintenance, link property correlation, link connection
verification, and fault management. One fundamental difference
between LMP and G.8080 discovery frame work is the absence of the
explicit separation between transport and control plane names.
The part of LMP that is relevant to G.7714.1 is the link connection
verification part. In both cases in-band discovery message is used.
LMP uses an in-band Test message for this purpose that is used to
transmit the local Interface ID to the remote end of the link.
TestStatus message is used that copies the received Interface ID and
transmits the local Interface ID to the other end of the link. While
Interface ID in LMP can be IPv4, IPv6, or unnumbered, the TCP ID in
G.7714.1 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 to G.8080 control plane discovery
are control channel maintenance and link property correlation. This
feature is used to synchronize the TE Link properties and verify the
TE link configuration. Link Property Correlation provides full
discovery of all intra and inter layer relationships along a
potential connection, requiring that a single connection management
application manages multiples layers. One of the problems of this
approach is that All connection management applications must
understand the engineering constraints of the technology used to
implement each layer (e.g. at least four different implementations
are supported at the Photonic layer). ItÆs not clear either how the
topology information can be shared with other applications or how
the network can be partitioned.
Control plane discovery is described in G.8080 although no
recommendation has been started yet. The Control Discovery process
described in G.8080 involves the interactions between the DA, TAP
and LRM as follows: SNPs are pre-assigned to SNPPs (which are
equivalent to LMP TE-Links). When the association CTP-SNP is
received from the TAP, and the CTP-CTP relationship have been found
as per G.7714.1, the SNP-SNP relation is discovered as well as their
associated SNPP-SNPP relation-ship. This relation is then verified
by communicating the end-point LRMs. Specific information that need
to be exchanged or particular procedures have not been addressed
yet. There is indeed the room to use LMP messages and procedures for
this purpose.
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
The author would like to thank Astrid Luzano and Don Fedyk for their
valuable comments.
11. 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
Ottawa, Ontario, Canada
K1Y-4H7
Tel: 613-763-5827
E.mail: osama@nortelnetworks.com
Aboul-Magd Informational- Sept. 2003 6
Draft-aboulmagd-ccamp-transport-lmp-00.txt Feb, 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
Aboul-Magd Informational- Sept. 2003 7