Network Working Group Igor Bryskin
Category: Informational Independent Consultant
Expires: September 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-01.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 intended 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. Network Presences
Transport node [Data Plane] is a logical network device that is
capable of originating and/or terminating of a data flow and/or
switching it on the route to its destination.
Network controller (controller) [Control Plane] is a logical entity
that models all control plane intelligence (routing, TE and
signaling protocols, path computation, etc). A single controller
can manage one or several transport nodes.
Node [Control & Data Planes] is an association of a transport node
and a controller that manages the transport node.
Bryskin and Farrel Page 3
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
Control plane network [Control Plane] is an IP network used for
delivery of control plane (protocol) messages exchanged by
controllers.
The ITU term for the control plane network is Data Connection
Network (DCN).
3.2. Resources
Non-packet based 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-packet based resources are timeslots, lambda
channels, etc.
Packet based 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 packet based resources are forwarding queues,
schedulers, etc.
Layer Resource (Resource) [Data Plane]. A non-packet based 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 packet based resources (i.e. one per label in
the label stack). Therefore, we define layer resource (or simply
resource) irrespective of underlying data plane technology as a
basic data plane construct. It is defined by a combination of a
particular data encoding type and switching/terminating bandwidth
granularity.
All other definitions provided in this memo are tightly bound to the
resource. Examples of layer resources are: PSC1, PSC4, ATM VP, ATM
VC, Ethernet, VC-12, VC-4, Lambda 10G, Lambda 40G.
ITU-T terms for resource:
- Connection point (cp) in the context of link discovery and resource
management (allocation, binding into cross-connects, etc.);
- Link connection or trail termination in the context of routing,
path computation and signaling.
3.3. Labels
Label [Control Plane] is an abstraction that represents a resource in
the control plane.
In ITU terms a label is the portion of an SNP name that follows the
SNPP name. A label represents a subnetwork point (SNP) in the
context of a subnetwork point pool (SNPP). Generally, a label
Bryskin and Farrel Page 4
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
identifies a client layer SNP within an SNPP supported by a single
server layer access point. In some cases, for example SONET/SDH
labels, there may be multiple layers between the SNPP and the
single access point.
3.4. Data Links
Unidirectional data link end [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 link end is a collection
of the same client layer connection points supported by a single
trail termination (access point).
Bidirectional data link end [Data Plane] is an association of two
unidirectional data link ends 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.
Unidirectional data link [Data Plane] is an association of two
unidirectional data link ends 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 unidirectional data link is unidirectional link.
Bidirectional data link [Data Plane] is an association of two
bidirectional data link ends 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. Link interfaces
Unidirectional link interface [Data Plane] is an abstraction that
connects a transport node to a unidirectional data link end and
represents (hides) the data plane intelligence like switching,
termination and adaptation in one direction. In GMPLS, link
interfaces are often referred to as "GMPLS interfaces" and it
should be understood that these are data plane interfaces and the
term does not refer to the ability of a control plane interface to
handle GMPLS protocols.
Bryskin and Farrel Page 5
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
A single unidirectional data link end could be connected to a
transport node by multiple link interfaces with some of them, for
example, realizing switching function, while others realize the
function of termination/adaptation.
In ITU terminology, a unidirectional link interface is a switching
function provided by matrix, and/or a trail termination function
bound to an adaptation function for which adapted client layer
connection points are bound to a matrix. The link interface type
may be identified by the cross-connected client layer, or by the
adapted client layer, or by the terminated server layer, or by a
combination of these depending on the context. In some cases, a
unidirectional link interface comprises a set of trail termination
and adaptation pairs, for which some connection points are bound to
trail terminations and others to matrices.
Bidirectional link interface [Data Plane] is an association of two or
more unidirectional link interfaces that connects a transport node
to a bi-directional data link end and represents the data plane
intelligence like switching, termination and adaptation in both
directions.
3.6. 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 layer 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 data
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.
Bryskin and Farrel Page 6
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
3.7. Layers
Layer [Data Plane] is a set of resources of the same type that could
be used for establishing a connection or used for connectionless
data delivery.
Using ITU terminology, a layer is a set of (related) networking
technologies, each of which is defined by its distinct
characteristic information.
Note. In GMPLS, the existence of non-blocking switching function in a
transport node in a particular layer is modeled explicitly as one of
the functions of link interfaces connecting the transport node to its
data links, while in ITU-T the switching function is modeled
explicitly as subnetwork.
3.8. Switching, Termination and Adaptation Capabilities
Switching capability [Data Plane] is a property of a link interface
that connects a particular data link to a transport node. This
property characterizes the interface's ability to cooperate with
other link interfaces connecting data links within the same layer
to the same transport node for the purpose of binding resources in
cross-connects. Switching capability is advertised as an attribute
of the TE link local end associated with the link interface.
Termination capability [Data Plane] is a property of a link interface
that connects a particular data link to a transport node. This
property characterizes the interface's ability to terminate
connections within the layer the data link belongs to.
Adaptation capability [Data Plane] is a property of a link interface
that connects a particular data link to a transport node. This
property characterizes the interface's ability to perform a nesting
function - to use a locally terminated connection that belongs to
one layer as a data link for some other layer(s).
The need for advertisement of adaptation and termination capabilities
within GMPLS has been recognized and work is in progress to determine
how these will be advertised. It is likely that they will be
advertised as a single combined or separate attributes of the TE link
local end associated with the link interface.
In the ITU ASON architecture switching capability is modeled as a
matrix, and termination and adaptation capabilities are modeled as
the termination and adaptation functions respectively accessible from
a particular link.
Bryskin and Farrel Page 7
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
3.9. TE Links and FAs
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 reflect zero, one or several data link ends 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 in a particular layer.
In contrast to data link, which provides network flexibility in a
particular layer and, therefore, is a "real" topological element,
TE link is a logical routing element. For example, an LSP path is
computed in terms of TE links (or more precisely, in terms of TE
link ends), while the LSP is provisioned over (that is, resources
are allocated from) data links.
The ITU term for a TE link is SNPP link.
Virtual TE link is a TE link associated with zero data links.
TE link end advertising [Control Plane]. A controller managing a
particular transport node advertises local TE link ends. Any
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 TE links in the group (examples:
protection capabilities, SRLGs, etc), separate information related
to each TE link (examples: switching capability, data encoding,
unreserved bandwidth, etc) as well as information related to
inter-layer relationships of the advertised resources (example:
termination and adaptation capabilities) should the control plane
decide to use them as termination of higher layer data links. These
higher layer data links, however, are not real yet - they are
Bryskin and Farrel Page 8
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
abstract until the underlying connections are established in lower
layers. LSPs created in lower layers for the purpose of providing
data links (extra network flexibility) in higher layers are called
hierarchical connections/LSPs or simply hierarchies. LSPs created
for the purpose of providing data links in the same layer are
called stitching segments. Hierarchies and stitching segments
could, but do not have to be advertised as TE links. Naturally, if
they are advertised as TE links, they are made available for path
computations performed on any controller within the TE domain into
which they are advertised. Hierarchies and stitching segments could
be advertised either individually or in TE bundles. A hierarchy or
a stitching segment could be advertised as a TE link either into
the same or a separate TE domain compared to the one within which
it was provisioned.
A set of hierarchical LSPs that are and/or could be created in a
particular layer to provide network flexibility (data links) in
other layer(s) is called Virtual network topology (VNT).
The ITU term for a hierarchical LSP/hierarchy is trail.
Forwarding Adjacency (FA) [Control Plane] is a TE link that does not
require a direct routing adjacency (peering) between controllers
managing either of its ends in order to guarantee control plane
connectivity (control channel) between the controllers. An example
of an FA is a hierarchy or stitching segment advertised as a TE
link into the same TE domain within which it was dynamically
provisioned. In such cases, the control plane connectivity between
the controllers at the ends of hierarchy/stitching segment is
guaranteed by the concatenation of control channels interconnecting
the ends of each of its constituents. In contrast, a hierarchy or
stitching segment advertised as a TE link into a different TE
domain compared to one where it was provisioned, generally requires
a direct routing adjacency to be established within the TE domain
where the TE link is advertised in order to guarantee control plane
connectivity between the TE link ends, and, therefore, is not an
FA.
3.10. TE Domain
TE link attribute is a parameter of the set of resources associated
with a TE link end that is significant in the context of path
computation.
Full TE visibility is a situation when a controller receives all
unmodified TE advertisements from any other controller from a
particular set of controllers.
Bryskin and Farrel Page 9
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
Limited TE visibility is a situation when a controller receives
summarized TE information or does not receive one at all from some
of controllers on the network.
TE domain is a set of controllers each of which has full TE
visibility within the set.
TE database (TED) is a memory structure within a controller that
contains all TE advertisements generated by all controllers within
a particular TE domain.
Virtual network integration is a set of collaborative mechanisms
within a single node driving multiple (at least two) layers and the
adaptation between the layers.
Horizontal network integration is a set of collaborative mechanisms
within a single instance of the control plane driving multiple (at
least two) TE domains or between different instances of the control
plane.
3.11. Component Links and Bundles
Component link end [Control Plane] is a grouping of labels
representing resources of a particular layer that is not advertised
as an individual TE link end. A component link end could represent
one or more data link ends or any subset of resources that belong
to one or more data link ends. 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.
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
component 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.
Bryskin and Farrel Page 10
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
3.12. Regions
TE region [Control Plane] is a set of one or more layers that are
associated with the same type of data plane technology. Examples of
regions are: IP, ATM, TDM, photonic, fiber switching, etc. Regions
and region boundaries are significant for the signaling sub-system
of the control plane because LSPs are signaled substantially
differently (i.e. use different signaling object formats and
semantics) in different regions. Furthermore, advertising, routing
and path computation could be performed differently in different
regions. For example, computation of paths across photonic regions
requires a wider set of constraints (e.g. optical impairments,
wavelength continuity, etc) and needs to be performed in different
terms (e.g. in terms of individual resources - lambda channels,
rather than in terms of TE links) compared to path computation in
other regions like IP or TDM.
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
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.
Bryskin and Farrel Page 11
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
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. Ben Mack-Crane and Jonathan Sadler
provided very help reviews and discussions of ASON terms.
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.
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.
Bryskin and Farrel Page 12
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
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.
[GMPLS-ISIS] Kompella, K., and Rekhter, Y. (Ed.), "IS-IS
Extensions in Support of Generalized MPLS",
<draft-ietf-isis-gmpls-extensions>, work in
progress.
Bryskin and Farrel Page 13
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
[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.
12. Authors' Addresses
Igor Bryskin
Independent Consultant
EMail: i_bryskin@yahoo.com
Bryskin and Farrel Page 14
draft-ietf-ccamp-gmpls-ason-lexicography-01.txt March 2005
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 15
Datatracker
draft-ietf-ccamp-gmpls-ason-lexicography-01
Internet-Draft
