CCAMP Working Group S. Belotti Internet Draft D. Papadimitriou Document: draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Alcatel N. Larkin Data Connection Z. Lin Lucent D. Pendarakis Tellium Expiration Date: December 2002 June 2002 Generalized MPLS (GMPLS) RSVP-TE 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). This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 1 GMPLS RSVP-TE for ASON June 2002 introduces additional extensions to these signaling protocols to support the capabilities of an ASON network. This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-T in support of ITU's ASON standardization effort. 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. However, 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] and Automatic Discovery [G7714]. These include generic capabilities such as call and connection separation and more specific capabilities such as support of soft permanent connections. This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using RSVP-TE. It introduces extensions to GMPLS RSVP-TE to support the capabilities as specified in the above referenced documents. Specifically, this document assumes the messages and objects defined by [RFC2205], [RFC2961], [RFC3209], [GMPLS-SIG], [GMPLS-RSVPTE], [GMPLS-SDHSONET], [GMPLS-SDHSONETEXT], [GMPLS-OTN] and [OIF-UNI1] as the basis for the protocols, with extensions in addition to those already defined by these 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 Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 2 GMPLS RSVP-TE for ASON June 2002 of an automated control plane for supporting connection management services for the transport/data 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 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 interface models between networks (e.g., Interior NNI (I- NNI), Exterior NNI (E-NNI), UNI). The modeling framework 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 relationship of ASON to GMPLS may be found in [IPO-RQTS] in addition to more details concerning some of the terms used in this document. 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 may be found in [IPO-RQTS], which includes a summary of the key requirements from the ITU-T ASON Recommendations, as well as a discussion of the applicability of the GMPLS protocol suite. In addition to the above referenced document, [ASSESS] provides a detailed assessment of requirements against the GMPLS RSVP-TE protocol. In general, as currently defined the GMPLS RSVP-TE protocol is applicable to the ASON model. The purpose of this document is to define the additional methods and objects (i.e. the delta) to fulfill some of the specific requirements of the ASON model. 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 (in this case GMPLS RSVP-TE signaling Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 3 GMPLS RSVP-TE for ASON June 2002 is used to set up the connection between ingress and egress network node). For the SPC, the communication method between the EMS/NMS and the ingress node is not the subject of standardization and is, thus, beyond the scope of this document. The user end-to-end connection is thus created by associating the incoming interface of the ingress network node with the switched connection within the network and the outgoing interface of the egress 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, 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. 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 it 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. A property of a call is its ability to contain multiple connections, where each connection may be of different types 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). Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 4 GMPLS RSVP-TE for ASON June 2002 The concept of the call is needed in order to allow for a better flexibility in how users set up connections and how service providers offer services to users. In essence, a call allows: - Support for a general case of virtual concatenation where each connection can travel on different diverse paths - 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 protection and restoration; for example a pair of primary and backup connections may belong to the same call. There is a relationship of the CALL_ID to the CIRCUIT_ID as presented in [LBM-TDM]; however note that a call may contain multiple circuits, and as such has wider scope than the circuit ID. Consequently, a call (referenced by a CALL_ID) may include more than one circuit (referenced by CIRCUIT_ID), i.e., a call can encompass several contiguously concatenated connections and virtually concatenated connections. 4. Support for Soft Permanent Connection In the scope of ASON, to support soft permanent connection (SPC) for RSVP-TE, one new sub-type for the GENERALIZED_UNI is defined. The GENERALIZED_UNI object is defined in [OIF-UNI1]. This new sub-type has the same format and structure as the EGRESS_LABEL (the sub-type is the suggested value for the new sub-object): - SPC_LABEL (Type=4, Sub-type=2 [TBA]) 5. Support for Call 5.1 Call Identifier and Call Capability 5.1.1 Call Identifier Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 5 GMPLS RSVP-TE for ASON June 2002 To identify a call, a new object is defined for RSVP-TE. The CALL_ID object carries the call identifier. The value is globally unique, and may be assigned by the call originator (the Class-num is the suggested value for the new object): CALL_ID (Class-num = 227 [TBA], C-type = 1) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length |Class-Num (227)| C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Call identifier | ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the following C-types are defined: - C-type = 1: generic [Length*4-32]-bit identifier An example structure for the call identifier (to guarantee global uniqueness) is to concatenate the tuple (source address, destination address, local identifier) or (source address, local identifier) as the call identifier. As an example, the address may be 160-bit field. The minimum length of the call identifier is 4 octets. The value of the call identifier is assigned by the originating call controller. 5.1.2 Call Capability This document does not cover extensions to support the call capability. Such support may be provided in a separate draft. This document only provides extensions to support logical call and connection separation. 5.2 What Does Current GMPLS Provide The signaling mechanism defined in [RFC2961], [RFC3209] and [GMPLS- SIG] supports automatic connection management; however it does not provide capability to support the call model. A call may be viewed as a special purpose connection that requires a different subset of information to be carried by the messages. This information is Lin draft-lin-ccamp-gmpls-ason-rsvpte-00.txt 6 GMPLS RSVP-TE for ASON June 2002 targeted to the call controller for the purpose of setting up a call/connection association. 5.3 Support for Basic Call and Connection To support basic call capability, a call identifier is introduced to various message sets. This basic call capability helps introduce the call model; however, additional extensions may be needed to fully support the canonical call model. For example, in a global network, supporting a call model requires agreements on global naming and addressing structure used for call endpoints, as well as various call capability sets. Within the context of this document, every call (during steady state) may have one (or more) associated connections. A zero connection call is defined as a transient state, e.g., during a break-before-make restoration event. In the scope of ASON, to support a logical call and connection separation, a new call identifier is needed as described above. The new CALL_ID object is carried by the Path, Resv, PathTear, PathErr, and Notify message. The new CALL_ID object (along with other objects associated with a call, e.g., GENERALIZED_UNI) is processed by the call controller, while other objects included in these messages are processed by the connection controller as described in [GMPLS- RSVPTE]. Processing of the CALL_ID (and related) object is described in this document. Note: unmodified message formats are not listed. 5.3.1 Modification to Path Message