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", , work in progress. [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", , work in progress. [LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with Generalized MPLS TE", , work in progress. [LMP] J. Lang (Ed.), "Link Management Protocol (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", , 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", , 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)", , work in progress. [ASON-RTG] D. Brungard (Ed.), "Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON)", , work in progress. [TRANSPORT-LMP] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., Papadimitriou, D., "A Transport Network View of 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", , work in progress. [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and Farrel, A., "GMPLS Based 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