Network Working Group Igor Bryskin
Category: Informational Consultant
Expires: August 2005 Adrian Farrel
Old Dog Consulting
March 2005
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
draft-ietf-ccamp-gmpls-ason-lexicography-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
Abstract
Generalized Multiprotocol Label Switching (GMPLS) has been developed
by the IETF to facilitate the establishment of Label Switched Paths
(LSPs) in a variety of physical technologies and across several
architectural models. The ITU-T has specified an architecture for
the management of Automatically Switched Optical Networks (ASON).
This document provides a lexicography for the interpretation of GMPLS
terminology within the context of the ASON architecture.
It is important to note that GMPLS is applicable in a far wider set
of contexts than just ASON. Thus the definitions presented in this
document do not provide exclusive or complete interpretations of the
GMPLS concepts. The intention of this document is simply to allow the
GMPLS terms to be applied within the ASON context.
Bryskin and Farrel Page 1
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
1. Introduction
Generalized Multiprotocol Label Switching (GMPLS) has been developed
by the IETF to facilitate the establishment of Label Switched Paths
(LSPs) in a variety of physical technologies such as Packet Switching
Capable (PSC), Layer Two Switching Capable (L2SC), Time Division
Multiplexing (TDM), Lambda Switching Capable (LSC). and Fiber
Switching Capable (FSC).
GMPLS is deliberately specified to allow it to be applicable in
several key architectures including the Integrated Model, the Overlay
Model, and the Augmented Model. More information on these
architectural models and on GMPLS can be found in [RFC3945].
The ITU-T has specified an architecture for the management of
Automatically Switched Optical Networks (ASON). This architecture
forms the basis of many recommendations within the ITU-T.
Because the GMPLS and ASON architectures were developed by different
people in different standards bodies, and because the architectures
have very different historic backgrounds (the Internet, and telephone
and transport networks respectively), the terminology used is
different. In order to demonstrate that GMPLS is a suitable
technology to satisfy the requirements of the ASON architecture it is
necessary to examine the terminology and provide a mapping between
GMPLS and ASON terms.
This document provides a lexicography for the interpretation of GMPLS
terminology within the context of the ASON architecture. It does not
provide wider definitions of the GMPLS terms which can already be
found in existing RFCs. Thus the definitions presented in this
document do not provide exclusive or complete interpretations of the
GMPLS concepts. The intention of this document is simply to allow the
GMPLS terms to be applied within the ASON context.
Note that the limitation of GMPLS to the ASON architecture in this
document is in no sense intented to imply that GMPLS applicability is
limited to the ASON architecture, nor that the ASON model is
preferable to any other model that can be supported by GMPLS.
Bryskin and Farrel Page 2
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
2. Terminology Sources
2.1. GMPLS Terminology Sources
GMPLS Terminology is principally defined in [RFC3945]. Other
documents provide further key definitions including [GMPLS-RTG],
[BUNDLE], [LSP-HIER] and [LMP].
The reader should be familiar with these other documents before
attempting to use this document to provide a mapping to between GMPLS
and ASON.
For details of GMPLS signaling please refer to [RFC3471] and
[RFC3473]. For details of GMPLS routing, please refer to [GMPLS-OSPF]
and [GMPLS-ISIS].
2.2. ASON Terminology Sources
The ASON architecture is specified in ITU-T Recommendation G.8080
[G-8080]. This is developed from generic functional architectures and
requirements specified in [G-805], [G-807] and [G-872].
The reader must be familiar with these documents before attempting to
apply the lexicography set out here.
2.3. Common Terminology Sources
The work in this document builds on the shared view of ASON
requirements and requirements expressed in [ASON-SIG], [ASON-RTG] and
[TRANSPORT-LMP].
3. Lexicography
3.1. Resources
Non-PSC resource [Data Plane] is a channel of certain bandwidth that
could be allocated in a network data plane of a particular
technology for the purpose of user traffic delivery. Examples of
non-PSC resources are timeslots, lambda channels, etc.
PSC resource [Data Plane] is an abstraction hiding means related to
delivery of traffic with particular parameters (most importantly,
bandwidth) with particular QoS over PSC media. Examples of PSC
resources are forwarding queues, schedulers, etc.
Layer Resource (Resource) [Data Plane]. A non-PSC data plane
technology may yield resources in different network layers. For
example, some TDM devices can operate with VC-12 timeslots, some
with VC-4 timeslots and some with VC4-4c timeslots. There are also
multiple layers of PSC resources (i.e. one per label in the label
Bryskin and Farrel Page 3
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
stack). Therefore, we define layer resource (or simply resource)
irrespective of underlying data plane technology as a basic data
plane construct. All other definitions provided in this memo are
tightly bound to the resource. Examples of resources are: PSC1,
PSC4, ATM VP, ATM VC, Ethernet, VC-12, VC-4, Lambda 10G, Lambda
40G. Each resource type is assigned with a number indicating its
position in the resource hierarchy - the lower this number the
coarser is the granularity of the resource. For instance, the
resource type of VC-4 is lower than one of an VC-12 but higher than
the resource type of a 2.5G lambda.
ITU-T terms for resource:
- Connection point (cp) in the context of link discovery;
- Link connection in the context of routing, path computation and
signaling.
3.2. Labels
Label [Control Plane] is an abstraction that represents a resource in
the control plane.
The ITU term for label is sub network point (snp).
3.3. Ports
Unidirectional data port [Data Plane] is a set of resources of a
particular layer that belong to the same transport node and could
be allocated for transfer of traffic in this layer to the same
neighbor in the same direction.
In ITU-T terminology a unidirectional data port is a collection of
the same client layer connection points supported by a single trail
termination (access point).
Bidirectional data port [Data Plane] is an association of two
unidirectional data ports of a particular layer that belong to the
same transport node and could be used for transfer of traffic in
this layer to/from the same neighbor in both directions.
3.4. Links
Unidirectional data link [Data Plane] is an association of two
unidirectional data ports of a particular layer belonging to two
transport nodes adjacent in this layer that could be used for
transfer of traffic between the two transport nodes in one
direction.
The ITU term for a unidirecitonal data link is unidirectional link.
Bryskin and Farrel Page 4
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
Bidirectional data link [Data Plane] is an association of two
bidirectional data ports of a particular layer belonging to two
transport nodes adjacent in this layer that could be used for
transfer of traffic between the two transport nodes in both
directions.
The ITU term for a bidirectional data link is bidirectional link.
In the ITU ASON architecture a unidirectional/bidirectional data link
is supported by a single unidirectional/bidirectional trail
3.5. Connections
Unidirectional connection (LSP) [Data Plane] is a single resource or
a set of cross-connected resources of a particular layer that could
deliver traffic in this ayer between a pair of transport nodes in
one direction
Bidirectional connection (LSP) [Data Plane] is an association of two
unidirectional connections that could simultaneously deliver
traffic in a particular layer between a pair of transport nodes in
opposite directions.
In the context of GMPLS both unidirectional constituents of a
bidirectional connection (LSP) take identical paths in terms of TE
links and could be provisioned concurrently.
The ITU term for a connection is connection.
The ITU term for a connection end is connection point (cp).
Connection (LSP) segment [Data Plane] is a single resource or a set
of cross-connected resources that constitutes a segment of a
connection.
The ITU term for a connection segment is connection.
The ITU does not distinguish between connection and connection
segment.
3.6. Layers
Layer [Data Plane] is a complete set of resources of the same type
that could be used for establishing a connection or used for
connectionless data delivery.
The ITU term is layer network.
Note. In GMPLS, the existence of non-blocking switching function in a
transport node in a particular layer is inferred from advertising of
Bryskin and Farrel Page 5
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
TE link ends of this layer that belong to this transport node, while
in ITU-T the switching function is modeled explicitly as subnetwork.
3.7. Switching Capability and Adaptation
Switching capability [Data Plane] is an ability of a transport node
to cross-connect resources of a particular layer. It could be also
defined as the node's ability to be part of connections in a
particular layer.
Adaptation capability [Data Plane] is an ability of a transport node
to use a resource of particular (usually, but not necessarily
lower) layer as a data port of a different (usually, but not
necessarily higher) layer. It could be also defined as the node's
ability to use a connection provisioned in a particular layer as a
data link in a different layer. In the PSC environment adaptation
usually involves data encapsulation and/or multiplexing techniques
at connection source, and decapsulation or/and demultiplexing at
connection destination.
In the ITU ASON architecture switching capability is modeled as a
matrix, and adaptation capability is modeled by the combination of
termination and adaptation functions accessible from a particular
link.
3.8. TE Links
TE link end [Control Plane] is a grouping for the purpose of
advertising and routing of labels representing resources of a
particular layer.
The ITU term for a TE link end is snp pool (snpp).
Such a grouping allows for decoupling of path selection from resource
assignment. Specifically, a path could be selected in a centralized
way in terms of TE link ends, while the resource assignment (resource
reservation and label allocation) could be performed in a distributed
way during the connection setup. A TE link end may, but does not need
to, reflect a data port in the data plane. A TE link end is
associated with exactly one switching capability or, in other words,
with exactly one layer.
TE link [Control Plane] is a grouping of two TE link ends associated
with two neighboring transport nodes (that is, directly
interconnected by one or more data links) in a particular layer.
The ITU term for a TE link is snpp link.
Bryskin and Farrel Page 6
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
TE link end advertising [Control Plane]. A routing controller
managing a particular transport node advertises local TE link ends.
Any routing controller in the TE domain makes a TE link available
for its local path computation if it receives consistent
advertisements of both TE link ends. Strictly speaking, there is no
such a thing as TE link advertising - only TE link end advertising.
TE link end advertising may contain information about multiple
switching capabilities. This, however, should not be interpreted as
advertising of a multi-layer TE link end, rather, as joint
advertisement of ends of multiple parallel TE links, each
representing resources in separate layers. The advertisement may
contain attributes shared by all links in the group (examples:
protection capabilities, SRLGs, etc), separate information related
to each link (examples: switching capability, data encoding,
unreserved bandwidth, etc) as well as information related to
inter-layer relationships of the advertised resources (example:
adaptation capabilities) should the control plane decide to use
them as termination of higher layer TE links. These higher layer TE
links, however, are not real yet - they are abstract/virtual until
the underlying connections are established and separate Forwarding
Adjacency (see below) TE links are advertised.
Forwarding Adjacency (FA) [Control Plane] is a TE link that
represents in the control plane a dynamically provisioned
connection in a particular layer used as a data link in the same
layer (via splicing) or a different layer (via adaptation). An FA
is advertised in the same way as a TE link - that is, by
advertising and synchronizing both FA's ends. An FA is advertised
using the same or different instance of TE routing protocol as was
used for advertising of TE links that were selected as a path for
the connection.
Stitching Forwarding Adjacency (Stitching FA) [Control Plane] is a
special case of FA when it is associated with and advertised for
the same layer as the underlying connection
Stitching [Control Plane] is a control plane operation that enables
using a connection in a particular layer as a TE link in the same
layer.
3.9. Component Links and Bundles
Component link end [Control Plane] is a grouping of labels
representing resources of a particularlayer that is not advertised
by TE link advertising. Component link ends may be discovered
through means other than TE routing protocols (LMP, local
configuration, management plane automated tools, etc.). In all
other respects, a component link end is equivalent to a TE link
end.
Bryskin and Farrel Page 7
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
Component link end [Control Plane] is a grouping of labels
representing resources of a particular layer that is not advertised
by TE link advertising. In all other respects, a component link end
is equivalent to a TE link end.
Component link [Control Plane] is a grouping of two or more component
link ends associated with neighboring transport nodes (that is,
directly interconnected by one or more data links) in a particular
layer. Component links are equivalent to TE links except that the
link ends are not advertised.
TE bundle [Control Plane] is an association of several parallel (that
is, connecting the same pair of transport nodes) component links
whose attributes are identical or whose differences sufficiently
negligible that the TE domain can view the entire association as a
single TE link. A TE bundle is advertised in the same way as a TE
link, that is, by representing the associated component link ends
as a single TE link end (TE bundle end) which is advertised.
3.10. Regions
TE region [Control Plane] is an association of all TE links and
bundles pertinent to a particular switching capability. A TE region
represents exactly one data plane layer (not a data plane
technology). Examples of regions are: PSC1, PSC4, ATM VP, ATM VC,
Ethernet, VC4, VC4-4c, Lambda 10G, Lambda 40G.
4. Guidance on the Application of this Lexicography
As discussed in the introduction to this document, this lexicography
is intended to bring the concepts and terms associated with GMPLS
into the context of the ITU's ASON architecture. Thus, it should help
those familiar with ASON to see how they may use the features and
functions of GMPLS in order to meet the requirements of an ASON
system. For example, a service provider wishing to establish a
protected end-to-end service, might read [SEG-PROT] and [E2E-PROT]
and wish to understand how the GMPLS terms used relate to the ASON
architecture so that he can confirm that he will satisfy his
requirements.
This document is not a substitute for obtaining a clear understanding
of GMPLS. It should not be assumed that a deep knowledge of the ASON
architecture combined with this document will allow the reader to
comprehend GMPLS. Rather, this lexicography will enable a reader who
is familiar with the ASON architecture to make a rapid transition to
GMPLS within the ASON context.
This lexicography should not be used in order to obtain or derive
definitive definitions of GMPLS terms because GMPLS is applicable in
a wider context than just the ASON architecture. To obtain
Bryskin and Farrel Page 8
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
definitions of GMPLS terms that are applicable across all GMPLS
architectural models, the reader should refer to the RFCs listed in
the references sections of this document. [RFC3945] provides an
overview of the GMPLS architecture and should be read first.
5. IANA Considerations
This informational document defines no new code points and requires
no action by IANA.
6. Management Considerations
Both GMPLS and ASON networks require management. Both GMPLS and ASON
specifications include considerable efforts to provide operator
control and monitoring, as well as OAM functionality.
These concepts are, however, out of scope of this document.
7. Security Considerations
Security is also a significant requirement of both GMPLS and ASON
architectures.
Again, however, this informational document is intended only to
provide a lexicography, and the security concerns are, therefore, out
of scope.
8. Acknowledgements
The authors would like to thank participants in the IETF's CCAMP
working group and the ITU-T's Study Group 15 for their help in
producing this document. In particular, all those who attended the
Study Group 15 Question 14 Interim Meeting in Holmdel, New Jersey
during January 2005.
Many thanks to Ichiro Inoue of NTT for his useful review and input,
and to Scott Brim and Dimitri Papadimitriou for lengthy and
constructive discussions.
9. Intellectual Property Consideration
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.
Bryskin and Farrel Page 9
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
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.
10. Normative References
[RFC3945] E. Mannie (Ed.). "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
2004.
[GMPLS-RTG] Kompella, K. and Rekhter, Y., "Routing Extensions in
Support of Generalized Multi-Protocol Label
Switching", <draft-ietf-ccamp-gmpls-routing>, work
in progress.
[BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering",
<draft-ietf-mpls-bundle>, work in progress.
[LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with
Generalized MPLS TE",
<draft-ietf-mpls-lsp-hierarchy>, work in progress.
[LMP] J. Lang (Ed.), "Link Management Protocol (LMP)",
<draft-ietf-ccamp-lmp>, work in progress.
11. Informational References
[RFC3471] L. Berger (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] L. Berger (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3471, January 2003.
[GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Ed.), "OSPF
Extensions in Support of Generalized MPLS",
<draft-ietf-ccamp-ospf-gmpls-extensions>, work in
progress.
Bryskin and Farrel Page 10
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
[GMPLS-ISIS] Kompella, K., and Rekhter, Y. (Ed.), "IS-IS
Extensions in Support of Generalized MPLS",
<draft-ietf-isis-gmpls-extensions>, work in
progress.
[ASON-SIG] Papadimitriou, D., Drake, J., Ash, J., Farrel, A.,
and Ong, L., "Requirements for Generalized MPLS
(GMPLS) Signaling Usage and Extensions for
Automatically Switched Optical Network (ASON)",
<draft-ietf-ccamp-gmpls-ason-reqts>, work in
progress.
[ASON-RTG] D. Brungard (Ed.), "Requirements for Generalized
MPLS (GMPLS) Routing for Automatically Switched
Optical Network (ASON)",
<draft-ietf-ccamp-gmpls-ason-routing-reqts>, work in
progress.
[TRANSPORT-LMP] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
Papadimitriou, D., "A Transport Network View of LMP"
<draft-ietf-ccamp-transport-lmp>, work in progress.
[E2E-PROT] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.),
"RSVP-TE Extensions in support of End-to-End
Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery",
<draft-ietf-ccamp-gmpls-recovery-e2e-signaling>,
work in progress.
[SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and
Farrel, A., "GMPLS Based Segment Recovery",
<draft-ietf-ccamp-gmpls-segment-recovery>, work in
progress.
For information on the availability of the following documents,
please see http://www.itu.int.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-805] ITU-T Recommendation G.805 (2000), Generic
functional architecture of transport networks.
[G-807] ITU-T Recommendation G.807/Y.1302 (2001),
Requirements for the automatic switched transport
network (ASTN).
[G-872] ITU-T Recommendation G.872 (2001), Architecture of
optical transport networks.
Bryskin and Farrel Page 11
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
12. Authors' Addresses
Igor Bryskin
Independent Consultant
EMail: i_bryskin@yahoo.com
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
13. Disclaimer of Validity
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.
14. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Bryskin and Farrel Page 12
Datatracker
draft-ietf-ccamp-gmpls-ason-lexicography-00
Internet-Draft
