Network Working Group Eric Gray, Fong Liaw, John Yu Internet Draft Zaffire Expiration Date: February 2001 John Drake, Jonathan Lang Calient Networks Yakov Rekhter, George Swallow Cisco Systems Kireeti Kompella Juniper Networks Bala Rajagopolan Tellium Raj Jain Nayna Networks Osama Aboul-Maged Nortel Networks Greg Bernstein Ciena Zhensheng Zhang Sorrento Networks July, 2000 RSVP Extensions in Support of OIF Optical UNI Signaling draft-gray-mpls-rsvp-oif-uni-ext-00.txt 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. Abstract This draft defines a signaling mechanism based on RSVP-TE ([2]) to support an Optical User Network Interface (UNI). This effort is in part driven by work in the OIF as well as the recent draft on signaling requirements for the optical UNI ([3]), and is consistent with recent work on Generalized MPLS (see [4], [5], [6], and [7]). The main function of this draft is to identify the relevant mechanisms in RSVP-TE (including further extensions) to satisfy functional requirements for an Optical UNI. This draft reflects ongoing work at the Optical Interworking Forum (OIF), however, not all of the concepts/requirements have been approved by the OIF. Gray, et al Page 01 1. Introduction There has recently been a significant effort amongst carriers, service providers, and vendors in the optical networking space to eliminate proprietary control protocols and develop a common control plane. The Optical Internetworking Forum (OIF) has initiated work on an Optical User-Network Interface (Optical UNI) as a step in this direction. Recently, a draft [3] was submitted to the IETF defining proposed requirements and abstract messages for the Optical UNI. This document describes how a signaling mechanism based on RSVP-TE [2] may be used for an Optical UNI. In particular, we identify the mechanisms already defined for RSVP-TE that can be used to satisfy the proposed requirements of [3]. This work is also based on recent Internet Drafts defining Generalized MPLS signaling (e.g. - [4]). 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 [8]. 2. Overview RSVP-TE is one of the candidate protocols described in [3] for Optical UNI signaling implementation. As part of this Optical UNI, the signaling protocol must have the capability to create, delete, and modify lightpaths across a network, as well as query the status of an existing lightpath. Most of these capabilities may be directly supported by re-using existing procedures, messages, and objects defined in RSVP-TE [2] and in Generalized MPLS Signaling [4]. This document further extends [2] and [4] to support Optical UNI signaling requirements as following: - Use of DREQ and DREP message and procedure as defined in [9] for Lightpath status enquiry and response. - Use of Message_ID and Message_Ack objects, Ack_desire flag, and Ack message as defined in [10] to support confirmation of Lightpath deletion and reliable messaging. - PathTear and ResvTear MUST be used to delete a lightpath. This specification does not specify procedures to support the following proposed requirements listed in [3]: - Concept of "indirect interface" as defined in [3]. It is envisioned that such a requirement can be better serviced via a network management station. - Different source and destination user groups. Instead, this specification allows specifying a single user group using resource affiliation defined in [2]. Gray, et al Page 02 - Procedures for client registration. 2.1 Use of RSVP-TE and Generalized MPLS signaling for Optical UNI 2.1.1 In-band and out-of-band signaling channels Optical UNI requires support of in-band and out-of-band signaling channels. The in-band signaling channel is supported by the use of a regular link; and the concept of out-of-band signaling channel is supported by the use of bundled links [8] where a bundled link consists of a control channel and one or more component links. When out-of-band signaling channel is used, the procedure, messages, and objects apply to a bundled link as defined in [4], [11], [12], and [5] shall be used. 2.1.2 Reliable messaging To support reliable messaging across the UNI, the Message_ID and Message_Ack objects, Ack message, and Ack desired flag of [10] MUST be used in UNI RSVP messages. Acknowledgements apply to hop-by-hop, as opposed to end-to-end, message delivery. 2.1.2 Lightpath creation Lightpath creation uses the procedure described in section 2.2 "Operation of LSP tunnels" of [2]. Additional objects and their use and procedure are defined in Sections 3 and 4 of [4]. 2.1.3 Lightpath modification Lightpath modification uses procedure as described in section 2.5 "Rerouting of Traffic Engineered Tunnels" of [2]. 2.1.4 Lightpath deletion Lightpath deletion can be done by either the client that originated or terminated the lightpath. The lightpath originator will use the PathTear message while the lightpath terminator will use the ResvTear message. Acknowledgement mechanisms of [10] MUST be used to provide confirmation. 2.1.5 Lightpath status enquiry and response Any client interested in the lightpath status shall send a Diagnostic Request (DREQ) message toward the termination end point of the lightpath. The DREQ message specifies the Session Object, Sender Template Object, and an ending node. Starting at the last hop of the lightpath, the DREQ message is sent along the lightpath toward the sender and start collecting information hop-by-hop in the DREQ. When the DREQ message reaches the ending node, the message type is changed to Diagnostic Reply (DREP) and forwarded to the original requestor node. The DREQ originator can select specific RSVP objects to be collected by including a DIAG_SELECT object in the DREQ message. The Gray, et al Page 03 full procedure of DREQ and DREP messages is described in [9]. 3. RSVP Message Extensions for OPTICAL UNI signaling In addition to objects defined in [2] and [4], new objects may need to be defined to address additional requirements. Additional objects defined in this specification are OPTIONAL with respect to RSVP and RSVP-TE. 3.1 Propagation Delay Object If a propagation delay is desired, the lightpath originator shall include a Propagation_Delay_object and an ADSPEC object in its Path Message for the lightpath. Network nodes along the lightpath must update the ADSPEC and compare the result with the propagation delay object. If the result is comformant, the node shall forward the Path message downstream. Otherwise, it shall generate a PathErr message carrying error code "XXX" (TBD) and discard the Path message. 3.2 Labels Generalized MPLS signaling [4] defines several types of labels that may be represented in a Generalized Label object. For Optical applications a label may be arbitrarily associated with all or part of a component link, or may be a superset of multiple component links. A common understanding of the meaning of a Generalized Label - in particular the meaning of the link ID portion of the Generalized Label - must exist between the user and the network across any Optical UNI. This common understanding may be dynamically derived (e.g. using LMP [5]), or it may be configured. This specification uses the Generalized Label, Generalized Label Request, Upstream Label, Suggested Label and Label Set objects defined in [4]. 4. RSVP objects related to OPTICAL signaling requirements Optical UNI signaling requirements [3] specify a set of attributes to be signaled during lightpath creation and modification. The following table summarizes the RSVP objects that are used to signaling a particular OPTICAL signaling attribute. Gray, et al Page 04 OPTICAL signaling attribute RSVP object ------------------------------+------------------------------- Light_Path ID | Session [2] Source termination point | Sender Template (or Session) [2] Destination termination point | Session [2] Source Termination Point Port | Label Set/Suggest Label [4] Destination Termination Label | Egress Label [4] Contract ID | Session Attribute/Name [2] Framing | Generalized Label Request [4] Bandwidth | Generalized Label Request [4] Transparency | Generalized Label Request [4] Directionality | Upstream Label [4] Service Level | Session Attribute [2] Diversity | Session Attribute [2] | and Generalized Label Request | Object [4] Return code | Error Spec Source user group ID | Session Attributes/LSP_TUNNEL_RA [2] Destination user group ID | Session Attributes/LSP_TUNNEL_RA [2] Propagation Delay | Propagation Delay (TBD) ------------------------------+--------------------------------- 5. RSVP messages related to OPTICAL UNI signaling 5.1 Path Message As described in [4], RSVP-TE signaling for support of lightpath creation allows for labels to be suggested by the upstream LSR that is sending a Path message. In addition, the upstream node may provide a label for use in bi-directional setup. The format for the Path message to be used for the OPTICAL UNI is given below. ::= [ ] [ ] [ ] [