that the table maps ASON terms to GMPLS terms that refer to
equivalent objects, but in many cases there is not a one-to-one
mapping. Additional information beyond discovery terminology can be
found in [LEXICO].
+----------------+--------------------+-------------------+
| ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms |
| | Port | Component Link |
+----------------+--------------------+-------------------+
| CP | TE Resource; | TE Resource; |
| | Interface (Port) | Interface. |
| | |(Comp. link) |
+----------------+--------------------+-------------------+
| CP Name | Interface ID | Interface ID(s) |
| | no further sub- | resources (such as|
| | division for(label)| timeslots, etc.) |
| | resource allocation| on this interface |
| | | are identified by |
| | | set of labels |
+----------------+--------------------+-------------------+
| CP-to-CP Link | Data Link | Data Link |
+----------------+--------------------+-------------------+
| CP-to-CP Name | Data Link ID | Data Link ID |
+----------------+--------------------+-------------------+
| SNP | TE Resource | TE Resource |
+----------------+--------------------+-------------------+
| SNP Name | Link ID | Link ID |
+----------------+--------------------+-------------------+
| SNP LC | TE Link | TE Link |
+----------------+--------------------+-------------------+
| SNP LC Name | TE Link ID | TE Link ID |
+----------------+--------------------+-------------------+
| SNPP | TE Link End | TE Link End |
| | (Port) | (Comp. Link) |
+----------------+--------------------+-------------------+
| SNPP Name | Link ID | Link ID |
+----------------+--------------------+-------------------+
| SNPP Link | TE Link | TE Link |
+----------------+--------------------+-------------------+
| SNPP Link Name | TE Link ID | TE Link ID |
+----------------+--------------------+-------------------+
where composite identifiers are:
- Data Link ID: <Local Interface ID; Remote Interface ID>
- TE Link ID: <Local Link ID; Remote Link ID>
Composite Identifiers are defined in the RFC 4204 [LMP]. LMP
discovers data links and identifies them by the pair of local and
remote interface IDs. TE links are composed of data links or
component TE links. TE links are similarly identified by pair of
local and remote link ID.
4.2.1. TE Link Definition and Scope
In the table, TE link/resource is equated with the concept of SNP,
SNP LC, SNPP, and SNPP link. The definition of the TE link is broad
in scope, and it is useful to repeat it here. The original
definition appears in [GMPLS-RTG]:
"A TE link is a logical construct that represents a way to group/map
the information about certain physical resources (and their
properties) that interconnects LSRs into the information that is used
by Constrained SPF for GMPLS path computation, and GMPLS signaling".
While this definition is concise, it is probably worth pointing out
some of the implications of the definition.
A component of the TE link may follow different paths between the
pair of LSRs. For example, a TE link comprising multiple STS-3cs,
the individual STS-3cs component links may take identical or
different physical (OC-3 and/or OC-48) paths between LSRs.
The TE link construct is a logical construction encompassing many
layers in networks [RFC3471]. A TE link can represent either
unallocated potential or allocated actual resources. Further
allocation is represented by bandwidth reservation, and the resources
may be real or, in the case of packets, virtual to allow for
overbooking or other forms of statistical multiplexing schemes.
Since TE links may represent large numbers of parallel resources,
they can be bundled for efficient summarization of resource capacity.
Typically, bundling represents a logical TE link resource at a
particular Interface Switching Capability. Once TE link resources
are allocated, the actual capacity may be represented as LSP
hierarchical (tunneled) TE link capability in another logical TE link
[HIER].
TE links also incorporate the notion of a Forwarding Adjacency (FA)
and Interface Switching Capability [RFC3945]. The FA allows
transport resources to be represented as TE links. The Interface
Switching Capability specifies the type of transport capability such
as Packet Switch Capable (PSC), Layer-2 Switch Capable (L2SC), Time-
Division Multiplex (TDM), Lambda Switch Capable (LSC), and Fiber-
Switch Capable (FSC).
A TE link between GMPLS-controlled optical nodes may consist of a
bundled TE link, which itself consists of a mix of point-to-point
component links [BUNDLE]. A TE link is identified by the tuple (link
Identifier (32-bit number), Component link Identifier (32-bit
number), and generalized label (media specific)).
4.3. LMP and G.8080 Discovery Relationship
LMP currently consists of four primary procedures, of which the first
two are mandatory and the last two are optional:
1. Control channel management
2. Link property correlation
3. Link verification
4. Fault management
LMP procedures that are relevant to G.8080 control plane discovery
are control channel management, link property correlation, and link
verification. Key to understanding G.8080 discovery 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 control channels between two adjacent nodes are not required to
use the same physical medium as the TE links between those nodes.
The control channels that are used to exchange the GMPLS control
plane 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 packets). The Link
Management Protocol [LMP] was designed to manage TE links,
independently of the physical medium capabilities of the data links.
Link property correlation is used to aggregate multiple data links
into a single TE link and to synchronize the link properties.
Link verification is used to verify the physical connectivity of the
data links and verify the mapping of the Interface-ID to Link-ID (CP
to SNP). The local-to-remote associations can be obtained using a
priori knowledge or using the link verification procedure.
Fault management is primarily used to suppress alarms and to localize
failures. It is an optional LMP procedure; its use will depend on
the specific technology’s capabilities.
[LMP] supports distinct transport and control plane name spaces with
the (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 verification appear similar to G.7714.1
discovery; however, the two procedures are different. G.7714.1
provides discovery of the transport plane layer adjacencies. It
provides a generic procedure to discover the connectivity of two
endpoints in the transport plane. On the other hand, the LMP link
verification procedure is a control-plane-driven procedure and
assumes either (1) a priori knowledge of the associated data plane’s
local and remote endpoint connectivity and Interface_IDs (e.g., via
management plane or use of G.7714.1), or (2) support of the remote
node for associating the data interface being verified with the
content of the TRACE object (inferred mapping). For SONET/SDH
transport networks, LMP verification uses the SONET/SDH Trail Trace
identifier (see [G.783]).
G.7714.1 supports the use of transport plane discovery independent of
the platform using the capability. Furthermore, G.7714.1 specifies
the use of a Discovery Agent that could be located in an external
system and the need to support the use of text-oriented man-machine
language to provide the interface. Therefore, G.7714.1 limits the
discovery messages to printable characters defined by [T.50] and
requires Base64 encoding for the TCP-ID and DA ID. External name-
servers may be used to resolve the G.7714.1 TCP name, allowing the
TCP to have an IP, Network Service Access Protocol (NSAP), or any
other address format. On the other hand, LMP is based on the use of
an IP-based control plane, and the LMP interface ID uses IPv4, IPv6,
or unnumbered interface IDs.
4.4. Comparing LMP and G.8080
LMP exists to support GMPLS TE resource and TE link discovery. In
section 4.2.1, we elaborated on the definition of the TE link. LMP
enables the aspects of TE links to be discovered and reported to the
control plane, more specifically, the routing plane. G.8080 and
G.7714 are agnostic to the type of control plane and discovery
protocol used. LMP is a valid realization of a control plane
discovery process under a G.8080 model.
G.7714 specifies transport plane discovery with respect to the
transport layer CTPs or TCPs using ASON conventions and naming for
the elements of the ASON control plane and the ASON management plane.
This discovery supports a centralized management model of
configuration as well as a distributed control plane model; in other
words, discovered items can be reported to the management plane or
the control plane. G.7714.1 provides one realization of a transport
plane discovery process.
Today, LMP and G.7714, G7714.1 are defined in different standards
organizations. They have evolved out of different naming schemes and
architectural concepts. Whereas G.7714.1 supports a transport plane
layer adjacency connectivity verification that can be used by a
control plane or a management plane, LMP is a control plane procedure
for managing GMPLS TE links (GMPLS’s control plane representation of
the transport plane connections).
5. Security Considerations
Since this document is purely descriptive in nature, it does not
introduce any security issues.
G.8080 and G.7714/G.7714.1 provide security as associated with the
Data Communications Network on which they are implemented.
LMP is specified using IP, which provides security mechanisms
associated with the IP network on which it is implemented.
6. Informative References
[LMP] Lang, J., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[LMP-TEST] Lang, J. and D. Papadimitriou, "Synchronous Optical
Network (SONET)/Synchronous Digital Hierarchy (SDH)
Encoding for Link Management Protocol (LMP) Test
Messages", RFC 4207, October 2005.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-RTG] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[HIER] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[LEXICO] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within The Context of the
ITU-T’s Automatically Switched Optical Network (ASON)
Architecture", Work in Progress, January 2006.
For information on the availability of the ITU-T documents, please
see http://www.itu.int.
[G.783] ITU-T G.783 (2004), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks.
[G.805] ITU-T G.805 (2000), Generic functional architecture of
transport networks.
[G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic
discovery techniques.
[G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic
discovery in SDH and OTN networks.
[G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the
automatically switched optical network (ASON).
[M.3100] ITU-T M.3100 (1995), Generic Network Information Model.
[T.50] ITU-T T.50 (1992), International Reference Alphabet.
7. Acknowledgements
The authors would like to thank Astrid Lozano, John Drake, Adrian
Farrel and Stephen Shew for their valuable comments.
The authors would like to thank ITU-T Study Group 15 Question 14 for
their careful review and comments.
Authors’ Addresses
Don Fedyk
Nortel Networks
600 Technology Park Drive
Billerica, MA, 01821
Phone: +1 978 288-3041
EMail: dwfedyk@nortel.com
Osama Aboul-Magd
Nortel Networks
P.O. Box 3511, Station ’C’
Ottawa, Ontario, Canada
K1Y-4H7
Phone: +1 613 763-5827
EMail: osama@nortel.com
Deborah Brungard
AT&T
Rm. D1-3C22
200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com
Jonathan P. Lang
Sonos, Inc.
223 E. De La Guerra
Santa Barbara, CA 93101
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
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).