CCAMP Working Group D. Papadimitriou Internet Draft Alcatel Document: draft-lin-ccamp-gmpls-ason-rqts-00.txt Z. Lin Lucent O. Aboul-Magd Nortel D. Pendarakis Tellium Expiration Date: February 2003 August 2002 Requirements for Generalized MPLS (GMPLS) Usage and Extensions For Automatically Switched Optical Network (ASON) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs). Lin 1 ASON Requirements for GMPLS August 2002 This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies functions to be covered by these signaling protocols to support the capabilities of an ASON network. This document provides additional requirements on the GMPLS signaling protocols to support the ASON functionality. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction The GMPLS suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SDH/SONET as well as Optical Transport Networks (OTNs), and for setting up connections with monitoring capabilities. In addition, there are certain capabilities that are needed to support applications as described in ITU-T ASTN (Automatically Switched Transport Networks) Requirements [G807], ASON (Automatically Switched Optical Networks) Architecture and Requirements [G8080], Distributed Connection Management [G7713]. These include generic capabilities such as call and connection separation and more specific capabilities such as support of soft permanent connections. More details about these requirements may also be found in [IPO-RQTS] and [ASON-RQTS]. This document concentrates on the signaling aspects of the GMPLS suite of protocols. It discusses functional requirements that would lead to additional extensions to GMPLS to support the capabilities as specified in the above referenced documents. 3.1 Relationship of ASON to GMPLS The Automatic Switched Optical Network (ASON) architecture (as specified by various ITU-T Recommendations) describes the application of an automated control plane for supporting connection management services for the transport plane. The ASON architecture is described based on the functions supported, and the interactions of various functions with each other. These include specification of the call and connection controllers, as well as link resource managers (for a Lin 2 ASON Requirements for GMPLS August 2002 detailed description see [G8080]). The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments (e.g., inter-carrier, intra-carrier), supporting different types of interfaces (e.g., Interior NNI (I-NNI), Exterior NNI (E-NNI), UNI). The ASTN meta-modeling framework and the ASON architectural model provided in ITU-T may be used as a foundation for developing and/or extending the protocols to support specific functions of ASON. A full description of the ASON terms and relationship between ASON model and GMPLS protocol suite may be found in [IPO-RQTS]. Automation of the connection management services may be realized in a number of ways, including the use of the suite of GMPLS protocols to support distributed connection management. 3.2 Applicability of GMPLS to ASON Most of the applicability statements regarding how the GMPLS suite of protocols may be applied to the ASON architecture can be found in [IPO-RQTS], which includes a summary of the ASON functions as well as a detailed discussion of the applicability of the GMPLS protocol suite. Note: Because ITU-T is currently specifying additional capabilities to the ASON architecture, additional extensions may be needed in the future. This is however beyond the scope of this document. 3.3 Soft Permanent Connection (SPC): A Synopsis An SPC is a combination of a permanent connection at the source user- to-network side, a permanent connection at the destination user-to- network side, and a switched connection within the network. Establishment of the switched connection within the network is typically initiated by an EMS or NMS, which communicates with the ingress node and instructs it to set-up the connection using the distributed signaling protocol. For the SPC, the communication method between the EMS/NMS and the ingress node is beyond the scope of this document. The user end-to-end connection is thus created by associating the incoming interface of the switched connection initiating (also referred to as ingress node) network node with the switched connection within the network and the outgoing interface of the Lin 3 ASON Requirements for GMPLS August 2002 switched connection terminating (also referred to as egress node) network node. An SPC connection is illustrated in the following Figure, which shows user's node A connected to a provider's node B via link #1, user's node Z connected to a provider's node Y via link #3, and a (abstract) link #2 connecting provider's node B and node Y. +---+ +---+ +---+ +---+ | A |--1--| B |-----2-//------| Y |--3--| Z | +---+ +---+ +---+ +---+ In this instance, the connection on link #1 and link #3 are both provisioned (permanent connections that may be simple links), i.e., they are set up by means beyond the distributed control plane. In contrast, the connection over link #2 is set up using the distributed control plane. Thus the SPC is composed of the concatenation of link #1, #2 and #3. Thus to support the capability to request a SPC connection: - The GMPLS signaling protocol must be capable of supporting the ability to indicate the label information used when setting up the destination provisioned connection. - In addition because of the multi-domain nature of ASON networks, the GMPLS signaling protocol must also be capable of supporting indicating the service level and diversity requested for the SPC (see [OIF-UNI1] for a definition). In the case where a SPC may span multiple domains in an ASON network there may also be a need to indicate both the source and destination controllers managing the SPC request. These may be done via the source and destination controller addresses. 3.4 Call: A Synopsis A call may be simply described as: "An association between endpoints that supports an instance of a service" [G8080]. Thus a call can be considered as a service provided to the user endpoints, where multiple calls may exist between any two endpoints. Each call may have multiple connections. The call concept provides an abstract relationship between two users, where this relationship describes (or verifies) the extent to which the users are willing to offer (or accept) service to each other. A call therefore does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which future connections may be made. Lin 4 ASON Requirements for GMPLS August 2002 A property of a call is its ability to contain multiple connections, where each connection may be of a different type and where each connection may exist independently of other connections within the call, i.e., each connection is setup and released with separate Path/Resv messages. For example, a call may contain a mix of basic connection, virtual concatenated connections and contiguous concatenated connections (see [GMPLS-SDHSONET] for corresponding connection signaling extensions). The concept of the call allows for a better flexibility in how users set up connections and how network offers services to users. In essence, a call allows: - Support for virtual concatenation where each connection can travel on different diverse paths - allows the use of a public and private addressing space (hosts using public space while network using only internal private addressing space) - Better upgrading strategy for service provider control plane operation, where a call control (service provisioning) may be separate from switches and connections (where the connection control may reside) - Verification and authentication of a call (with both network call controller as well as destination user) prior to connection, which may result in less wasted resources - General treatment of multiple connections which may be associated for the purpose of recovery; for example a pair of primary and backup connections may belong to the same call. Thus to support the introduction of the call concept, the GMPLS signaling protocol must be extended to include a call identifier and extended to include specifying the call capability. A possible structure for the call identifier (to guarantee global uniqueness) is to concatenate a globally unique fixed ID (e.g., may be composed of country code, carrier code) with an operator specific ID (where the operator specific ID may be composed of a unique access point code û such as source LSR address û and a local identifier). Therefore, a foreseeable structure may be + . 4. Support For Behaviors during Control Plane Failures Various types of control plane failures may occur within an automatically switched optical network. These failures may impact the Lin 5 ASON Requirements for GMPLS August 2002 control plane as well as the data plane. Requirements placed on the control plane by [G8080] and [G7713] include: - Any control plane failure must not result in releasing an established transport plane connection - The management system should be allowed to override the default behaviors of the control plane - Upon recovery from a control plane failure, the recovered control plane node must have the ability to recover the status of the established transport plane connections - Upon recovery from a control plane failure, the recovered control plane node must have the ability to recover the connectivity information of its neighbors - Upon recovery from a control plane failure, connections in the process of been established (i.e. pending connection setup requests) may be released - Upon recovery from a control plane failure, connections in the process of been released must be released 5. Support For Label Usage Labels are defined in GMPLS to provide information on the resources used on link local basis for a particular connection. The labels may range from specifying a particular timeslot, a particular wavelength to a particular port/fiber. In the context of the automatic switched optical network, the value of a label MAY not be consistently the same across a link. For example, the figure below illustrates the case where two GMPLS/ASON-enabled nodes (A and Z) are interconnected across two non-GMPLS/ASON-enabled nodes (B and C), where these nodes are all SDH/SONET nodes providing, e.g., a VC-4 service. +-----+ +-----+ | | +---+ +---+ | | | A |---| B |---| C |---| Z | | | +---+ +---+ | | +-----+ +-----+ Labels have an associated structure imposed on them for local use based on [GMPLS-SDHSONET] and [GMPLS-OTN]. Once the local label is exchanged with its neighboring control plane node, the structure of the local label MAY not be significant to the neighbor node since the association between the local and the remote label may not necessarily be the same. This issue does not present a problem in a simple point-to-point connections between two control plane-enabled nodes where the timeslots are mapped 1:1 across the interface. Lin 6 ASON Requirements for GMPLS August 2002 However, in the scope of the ASON, once a non-GMPLS capable sub- network is introduced between these nodes (as in the above figure, where the sub-network provides re-arrangement capability for the timeslots) label scoping MAY become an issue. In this context, there is an implicit assumption that the data plane connections between the GMPLS capable edges already exist prior to any connection request. For instance node A's outgoing VC-4's timeslot #1 (with SUKLM label=[1,0,0,0,0]) as defined in [GMPLS- SONETSDH]) may be mapped onto node BÆs outgoing VC-4's timeslot #6 (label=[6,0,0,0,0]) may be mapped onto node C's outgoing VC-4's timeslot #4 (label=[4,0,0,0,0]). Thus by the time node Z receives the request from node A with label=[1,0,0,0,0], the node Z's local label and the timeslot no longer corresponds to the received label and timeslot information. As such to support the general case, the scope of the label value is considered local to a control plane node. A label association function can be used by the control plane node to map the received (remote) label into a locally significant label. The information necessary to allow mapping from received label value to a locally significant label value may be derived in several ways: - Via manual provisioning of the label association - Via discovery of the label association Either method may be used. In the case of dynamic association, this implies that the discovery mechanism operates at the timeslot/label level before the connection request is processed at the ingress node. Note that in the simple case where two nodes are directly connected, no association may be necessary (in particular, for directly connected TDM interfaces no mapping function is required due to the label structure (see [GMPLS-SDHSONET] and [GMPLS-OTN]). In such instances, the label association function provides a one-to-one mapping of the received to local label values. 6. Additional Error Cases To support the ASON network, the following additional category of error cases are defined: - Errors associated with basic call and soft permanent connection support. For example, these may include incorrect assignment of IDs for the Call or an invalid interface ID for the soft permanent connection. Lin 7 ASON Requirements for GMPLS August 2002 - Errors associated with policy failure during processing of the new call and soft permanent connection capabilities. These may include unauthorized request for the particular capability. - Errors associated with incorrect specification of the service level and diversity. 7. Security Considerations The separation of the call and connection as required for the ASON model will introduce a new level of management hierarchy to the connection setup. A connection cannot be established until a call with the same call identifier value has been set up. Policy and authentication procedures can be applied to the establishment of the call and then can be restricted to connection establishment within the context of a call. 8. Acknowledgements The authors would like to thank Jerry Ash, Greg Bernstein, Adrian Farrel, Nic Larkin, and Lyndon Ong for their comments and contributions to the draft. 9. References 9.1 Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [G8080] ITU-T Rec. G.8080/Y.1304, Architecture for the Automatically Switched Optical Network (ASON), November 2001 [G7713] ITU-T Rec. G.7713/Y.1704, Distributed Call and Connection Management (DCM), November 2001 [OIF-UNI1] OIF-UNI-01.0, User Network Interface (UNI) 1.0 Signaling Specification Lin 8 ASON Requirements for GMPLS August 2002 [GMPLS-SIG] P. Ashwood-Smith, Generalized MPLS - Signaling Functional Description, draft-ietf-mpls-generalized-signaling-08.txt, April 2002, Work in progress [GMPLS-SDHSONET] E. Mannie and D.Papadimitriou (Editors), GMPLS Extensions for SONET and SDH Control, draft-ietf-ccamp-gmpls-sonet- sdh-05.txt, June 2002, Work in progress [GMPLS-OTN] D. Papadimitriou, GMPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709- 01.txt, June 2002, Work in progress 9.2 Informative References [G807] ITU-T Rec. G.807/Y.1301, Requirements For Automatic Switched Transport Networks (ASTN), July 2001 [GMPLS-SDHSONETEXT] E. Mannie and D.Papadimitriou (Editors), GMPLS Extensions to Control Non-Standard SONET and SDH Features, draft- ietf-ccamp-gmpls-sonet-sdh-extensions-03.txt, June 2002, Work in progress [IPO-RQTS] O. Aboul-Magd, Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols, draft-ietf-ipo-ason-02.txt, March 2002, Work in progress [ASON-RQTS] Y. Xue, Carrier Optical Services Requirements, draft- ietf-ipo-carrier-requirements-02.txt, March 2002 10. Author's Addresses Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station "C" Ottawa, Ontario, Canada K1Y-4H7 Tel: + 1 613 763 5827 Email: osama@nortelnetworks.com Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy Email: sergio.belotti@netit.alcatel.it Lin 9 ASON Requirements for GMPLS August 2002 Zhi-Wei Lin Lucent 101 Crawfords Corner Road Holmdel, NJ 07733 USA Email: zwlin@lucent.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Email: Dimitri.Papadimitriou@alcatel.be Dimitrios Pendarakis Tellium 2 Crescent Place Oceanport, NJ 07757-0901 Email: dpendarakis@tellium.com Lin 10 ASON Requirements for GMPLS August 2002 Full Copyright Statement "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Lin 11