[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                      Igor Bryskin
Category: Informational                                      Consultant

Expires: July 2005                                        Adrian Farrel
                                                     Old Dog Consulting

                                                          February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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-bryskin-ccamp-gmpls-ason-lexicography-01.txt         February 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


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/