Network Working Group John Yu, Zaffire Internet Draft Fong Liaw, Zaffire Expiration Date: May 2001 Eric Gray, BrightWave John Drake, Calient Networks Jonathan Lang, Calient Networks Ayan Banerjee, Calient Networks Greg Bernstein, Ciena Yakov Rekhter, Cisco Systems George Swallow, Cisco Systems Kireeti Kompella, Juniper Networks Robert Rennison, Laurel Networks, Yangguang Xu, Lucent Technology Dimitrios Pendarakis, Tellium Nooshin Komaee, Tellium Raj Jain, Nayna Networks Zhensheng Zhang, Sorrento Networks November, 2000 RSVP Extensions in Support of OIF Optical UNI Signaling draft-yu-mpls-rsvp-oif-uni-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]) in IETF. 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 Yu, et al. [page 1] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 ongoing work at the Optical Interworking Forum (OIF), however, not all of the concepts/requirements have been approved by the OIF. Yu, et al. [Page 2] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 Table of Contents 1 Introduction 2 Overview 2.1 Optical UNI (O-UNI) signaling requirements and RSVP objects 2.2 Basic RSVP protocol operation 2.3 Use of RSVP-TE and Generalized MPLS signaling for O-UNI 2.3.1 O-UNI interfaces, control channels, and addressing 2.3.2 Sending O-UNI RSVP messages 2.3.3 Receiving O-UNI RSVP messages 2.3.4 Reliable messaging 2.3.5 Reservation style 2.3.6 Lightpath identification 2.3.7 Lightpath creation 2.3.8 Lightpath modification 2.3.9 Lightpath deletion 2.3.10 Lightpath status enquiry and response 2.3.11 Node failure detection 3 RSVP Messages and Objects for O-UNI signaling 3.1 O-UNI RSVP Messages 3.1.1 ACK Message 3.1.2 Hello Message 3.1.3 Notify Message 3.1.4 Path Message 3.1.5 PathErr Message 3.1.6 PathTear Message 3.1.7 Resv Message 3.1.8 ResvConf Message 3.1.9 ResvErr Message 3.1.10 ResvTear Message 3.1.11 Srefresh Message 3.2 O-UNI RSVP objects format 3.2.1 Sender Template Object 3.2.2 Session Object 3.2.3 Session Attribute Object 3.2.3.1 Format without resource affinities 3.2.3.2 Format with resource affinities 3.2.4 Lightpath_ID Object 3.2.5 GENERALIZED LABEL Object 3.2.6 GENERALIZED LABEL REQUEST Object 3.2.7 LABEL SET Object 3.2.8 SUGGESTED LABEL Object 3.2.9 UPSTREAM LABEL Class 3.2.10 ERROR_SPEC Object 3.2.11 Filter Specification Object 3.2.12 FLOWSPEC Object 3.2.13 SENDER_TSPEC Object 3.2.14 INTEGRITY Object 3.2.15 COMPONENT_INTERFACE_ID Object 3.2.16 MESSAGE_ID Object 3.2.17 MESSAGE_ID_ACK Object 3.2.18 MESSAGE_ID_NAC Object 3.2.19 MESSAGE_ID_LIST Object 3.2.20 POLICY_DATA Class Yu, et al. [Page 3] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 3.2.21 RSVP HOP Object 3.2.22 TIME_VALUES Object 3.2.23 NOTIFY_REQUEST Object 4 References 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 (O-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 in alignment with the 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 The purpose of this document is to describe the use of RSVP [15], RSVP-TE [2], and GMPLS [4] to manage lightpaths at an optical User- Network Interface (O-UNI). The intent is to sufficiently describe information of the objects, packet formats, and procedures required to realize interoperable implementations, with the principle of leveraging the existing specifications as much as possible. A few new objects are defined to indicate lightpath attributes that are unique to O-UNI. This specification supports only signaling messages and procedures to establish point-to-point, uni-directional and bi-directional, lightpaths. Specification for any other type of lightpath is for further study. In this document and in [2, 4, 15], we define the directional terms "source" vs. "destination", "originating" vs. "terminating", "upstream" vs. "downstream", "previous hop" vs. "next hop", and "incoming interface" vs. "outgoing interface" with respect to the direction of light. Procedures different from [2,4] are underlined to highlight the differences between this document and [2,4]. 2.1 Optical UNI (O-UNI) signaling requirements and RSVP objects Yu, et al. [Page 4] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 As part of an optical UNI, the signaling protocol must have the capability to create, delete, and modify connections 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]. In particular, the optical UNI signaling requirements [3, 17] specify a set of attributes to be signaled during lightpath creation and modification. The following table summarizes the optical signaling attributes and the corresponding RSVP objects. Specific O-UNI related object formats and usage are described in Section 3. OPTICAL signaling attribute RSVP object ------------------------------+------------------------------- Bandwidth | Sender_Tspec [4] Contract ID | Policy Data [16] Destination address | Session [2] Directionality | Upstream Label [4] Diversity | Session Attribute [2] | and Generalized Label Request | Object [4] Framing Type | Generalized Label Request [4] Light_Path ID | Lightpath_ID Propagation Delay | Sender_Tspec [4] Return code | Error Spec [15] Service priority | Session Attribute [2] Source address | Sender Template [2] Source port/channel | Label Set/Suggest Label [4] Transparency | Generalized Label Request [4] User group ID | Policy Data [16] ------------------------------+--------------------------------- 2.2 Basic RSVP protocol operation There are two fundamental RSVP message types: Resv and Path [15]. An originating user node originates a lightpath establishment request by transmitting RSVP "Path" messages downstream along the direction of a lightpath. These Path messages create "path state" in each node along the way. In response to a Path message, the lightpath terminating user node sends RSVP reservation request (Resv) messages upstream towards the lightpath originator. These messages MUST follow exactly the reverse of the path(s) that the light will travel. They create and maintain "reservation state" in each node along the path(s). Resv messages will finally be delivered to the lightpath originating user node itself. This completes the establishment of a lightpath. Removal of a reservation state does not automatically removes its associated path state, but removal of a path state will remove the reservation states that are associated with it as well. Path messages are sent with the same source and destination addresses as the lightpath. On the other hand, Resv messages are sent hop-by- Yu, et al. [Page 5] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 hop; each RSVP-speaking node forwards a Resv message to the unicast address of a previous RSVP hop. For each RSVP message type, there is a set of rules for the permissible choice of object types. These rules are specified using Backus-Naur Form (BNF) augmented with square brackets surrounding optional sub-sequences. The BNF implies an order for the objects in a message. However, in many (but not all) cases, object order makes no logical difference. An implementation should create messages with the objects in the order shown for each message, and accept the objects in any permissible order. 2.3 Use of RSVP-TE and Generalized MPLS signaling for O-UNI The RSVP protocol operation for lightpath signaling is only specified over the ingress O-UNI and egress O-UNI. It is required the UNI-Ns to support the RSVP signaling specified in this document, while it is not required to support RSVP signaling within the network, provided the network can carry the signaling information between the two O- UNIs for the end-to-end lightpath signaling. 2.3.1 O-UNI interfaces, control channels, and addressing An O-UNI interface may identify one or more regular link(s), or one or more bundled link(s). Within a bundled link, there may be one or more component links that have the same characteristics. 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 the component interface identifier [11] MUST exist between the user and the network across any O-UNI. This common understanding may be dynamically derived (e.g. using LMP [5]), or pre-configured. In an O-UNI interface, each bundle link is associated with a control channel. Signaling protocol messages are exchanged over each control channel that is associated with a control channel interface. The control channel interface MAY be numbered (with an IP address) or May be unnumbered (in which case it is identified by a node's IP address and a unique identifier such as an ifindex value). Support for unnumbered O-UNI interface is optional. Furthermore, one or more control channels may transmit and receive their protocol messages via the same signaling transport control channel interface, which MAY be direct IP link (single IP hop) or over an IP network (multiple IP hop), as specified in [14]. 2.3.2 Sending O-UNI RSVP messages When sending an RSVP message over a directly connected signaling transport channel [14], the message format defined in [15] (section 3.3) is used, i.e. messages are sent as "raw" IP datagrams with protocol number 46. Yu, et al. [Page 6] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 RSVP Path, PathTear, and ResvConf messages are sent with an IP router alert option. The IP destination and source address of Path and PathTear messages are the lightpathÆs source and destination addresses. RSVP Resv, ResvTear, ResvErr, PathErr, Ack, Srefresh messages are routed hop-by-hop, and their IP destination address is set to the previous RSVP hop. The source address is the previous hop that sends the message, not the originating hop. The Notify message MAY be generated at any time to allow expedited notification of change in the status of a lightpath. The IP destination address is set to the IP address of the intended receiver. The Notify message is sent without the router alert option. When the UNI RSVP messages are delivered over a non-directly connected signaling transport channel (out-of-fiber, out-of-band, co- located or non-co-located), the messages shall be encapsulated in IP- in-IP header before the transmission [14]. 2.3.3 Receiving O-UNI RSVP messages A node SHALL verify a received O-UNI RSVP message as specified in [2,4]. In addition, if a Path message is to be processed by a receiving node, the receiving RSVP node SHALL verify that the IP address in the RSVP_HOP object matches one of its adjacent nodeÆs O- UNI interface identifiers and associates the message with the matched O-UNI interface. If a match does not exist, an error code ôrouting problemö SHALL be reported in a PathErr Message. 2.3.4 Reliable messaging To support reliable messaging across the O-UNI, the Message_ID object and Ack desired flag of [10] MUST be used in every O-UNI RSVP message. Message identification and acknowledgment is done on a per hop basis. All types of MESSAGE_ID objects contain a message identifier. The identifier MUST be unique on a per object generator's IP address basis. No more than one MESSAGE_ID object may be included in an RSVP message. Each message containing a MESSAGE_ID object may be acknowledged via a MESSAGE_ID_ACK object, when so indicated. MESSAGE_ID_ACK and MESSAGE_ID_NACK objects may be sent piggybacked in unrelated RSVP messages or in RSVP Ack messages. RSVP messages carrying any of the three object types may be included in an RSVP Bundled message. When included, each object is treated as if it were contained in a standard, non-bundled, RSVP message. If a MESSAGE_ID_ACK object of a RSVP Message cannot be piggybacked in a pending RSVP message immediately, a downstream (upstream) node SHALL generate an Ack message including the MESSAGE_ID_ACK object to Yu, et al. [Page 7] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 its upstream (downstream) node. This allows a faster confirmation for the message. 2.3.5 Reservation style A reservation request includes a set of options that are collectively called the reservation "style" [15]. One reservation option concerns the treatment of reservations for different traffic sources within the same session: make a "distinct" reservation for each upstream traffic source, or make a single reservation that is "shared" among all selected upstream traffic sources. The supported reservation styles at the O-UNI interface MAY be Fixed Format (FF) style and Shared-Explicit (SE) style to perform the "make-before-break" for lightpath modification. A FF-style reservation reserves the resource for a distinctive upstream traffic source. An FF-style reservation request creates a distinct reservation for traffic from a particular upstream source, not sharing them with other upstream traffic sources for the same session. An SE-style reservation reserves the resource for one or more upstream traffic sources. An SE-style reservation creates a single reservation shared by selected upstream traffic sources. It allows a receiver to explicitly specify the set of upstream traffic sources to be included. 2.3.6 Lightpath identification A new Lightpath_ID object is introduced to uniquely identify a lightpath throughout the optical network. It SHOULD be assigned by the network. 2.3.7 Lightpath creation To create a lightpath, the user O-UNI node creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 and inserts a GENERALIZED LABEL_REQUEST object into the Path message. The GENERALIZED LABEL_REQUEST object indicates that a label binding for this lightpath is requested and also provides an indication of the characteristics, such as desired link protection, encoding, of the light path. To create a bi-directional lightpath, an UPSTREAM LABEL Object MUST be inserted in the Path Message. Therefore, if the encoding type in a GENERALIZED LABEL REQUEST object indicates a bi-directional medium type, an UPSTREAM LABEL object MUST be inserted in the Path message; if no such an UPSTREAM LABEL object is inserted, an error code "incompatible" SHALL be reported in PathErr Message. Furthermore, during a lightpath creation, in order to provide the capability of lightpath modification later on after the ligthpath is established, it MUST insert a SESSION_ATTRIBUTE Object and indicates "SE Style desired" in the Flag field. Yu, et al. [Page 8] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 2.3.8 Lightpath modification Lightpath modification can only be initiated by a lightpathÆs originating user node on a lightpath that is established with a ôSE Style desiredö flag in SESSION ATTRIBUTE Object. It uses the bandwidth-increase "make before break" procedure as described in [2]. The following describes the procedure in more detail. To effect a modification, the lightpath originating user node picks a new LSP ID and forms a new SENDER_TEMPLATE. Thereafter the node sends a new Path Message using the original SESSION object and the new SENDER_TEMPLATE with the new characteristics of the lightpath. It continues to use the old lightpath and refresh the old Path message. The shared SESSION object and SE style allow the LSP to be established sharing resources with the old LSP. Once the user node receives a Resv message for the new LSP, it MUST transition traffic to it and tear down the old LSP by sending a PathTear message toward the network node. The lightpath modification is not required for UNI 1.0 [13]. It may be required in the future specification for OIF. 2.3.9 Lightpath deletion There are three scenarios for lightpath deletion: deletion from an originating user, deletion from a terminating user, and deletion from a network node. A lightpath originating user node SHALL send a PathTear message toward the network to delete a lightpath. A terminating user node SHALL send a ResvTear message toward its upstream nodes to delete a lightpath. Once a user node receives a ResvTear message for a lightpath, it MUST send a PathTear message toward the network to completely delete the lightpath. A network node MAY send a PathErr message with error code set to ônetwork initiated deletion, normalö to request the originating user node to delete the lightpath. If the network also removes its path state, it MUST set the Path_State_Removed flag in the PathErr message and also send a PathTear message toward downstream. 2.3.10 Lightpath status enquiry and response The purpose of lightpath status enquiry and response identified so far has been to allow adjacent user and network nodes to re- synchronize their lightpath states when necessary, in particular after a link or node failure. Potentially, there are a large number of lightpath states to be re-synchronized. Therefore, the procedure MUST allow the re-synchronization to occur efficiently. This specification uses the Srefresh message [10] for efficiency. Yu, et al. [Page 9] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 When a node decides that it is necessary to resynchronize its lightpath state with its adjacent node, it SHALL send Srefresh messages to refresh the Message_IDs of some or all active Resv and Path Messages. If a lightpath state has been deleted from the adjacent node before the re-synchronization, the adjacent node MUST respond with a Message_Id_Nack Object for the deleted lightpath. Once a user node receives a Message_Id_Nack, it SHALL send a Resv or Path message toward its adjacent node. This would trigger the standard RSVP resource reservation and recovery procedure. The above procedure may change the reservation states in a user or network node. The need for a non-state affecting procedure is for further study. 2.3.11 Node failure detection RSVP HELLO procedure [2] MAY be used when a nodeÆs link failure detection mechanism cannot detect node failure. The RSVP Hello extension enables RSVP nodes to detect when a neighboring node is not reachable. The mechanism provides node-to-node failure detection. When such a failure is detected it is handled much the same as a link layer communication failure. This mechanism is intended to be used when notification of link layer failure is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection. This procedure is OPTIONAL and does not require adjacent nodes to generate HELLO messages at the same time. 3. RSVP Messages and Objects for O-UNI signaling The following sections describe messages, procedures, and objects from [2, 4, 16, 15] that are O-UNI related. If this document does not explicit specify some aspects of messages, procedures, and objects related to the O-UNI interface, the procedure defined in [4], [2], [10], [16], and [15] SHALL apply in the order listed. An O-UNI node MUST support the following RSVP messages: Path, PathTear, PathErr, Resv, ResvTear, ResvConf, ResvErr, Ack, Srefresh, Notify An O-UNI node MAY support the following RSVP messages: Hello An O-UNI node MUST support the following RSVP objects: Error Spec [2, 4, 15], Flow Spec [15], Filter Spec [2], Generalized Label [4], Generalized Label Request [4], Component_interface_ID [11], Message_Id [10], Message_Id_Ack [10], Message_Id_Nack [10], Message_ID_List [10], Session [2], RSVP HOP [15], Sender Template Yu, et al. [Page 10] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 [2], Session Attribute [2], Sender_Tsepc [15], Time Value [15], Upstream Label [4] An O-UNI node MAY support the following RSVP objects: Integrity [15], Label Set [4], Policy Data [15], Suggested Label [4], Notify Request [4] 3.1 O-UNI RSVP Messages 3.1.1 ACK Message The ACK message is for reliable messaging across an O-UNI. It has the following format: ::= [ ] | [ [ | ] ... ] 3.1.2 Hello Message Hello message is for node failure detection. Hello message is optional. It has the following format: ::= [ ] [ [ | ] ... ] 3.1.3 Notify Message The Notify message provides a mechanism to inform ôtargetedö nodes of LSP related events. Notify messages are only generated after a Notify Request object has been received. In general, the Notify message differs from the currently defined error messages (i.e., PathErr and ResvErr messages of RSVP) in that it MAY be "targeted" to a node other than the immediate upstream or downstream neighbor and that it is a generalized notification mechanism. For UNI 1.0, the Notify Messages are only generated from the UNI-N to the UNI-C across the UNIs. The Notify message MAY be generated at any time to allow expedited notification of change in the status of a lightpath. Consequently, both the user and network sides of the Optical UNI MUST be prepared to receive a Notify message. The IP destination address is set to the IP address of the UNI-C. The Notify message is sent without the router alert option. The format of the Notify message is as follows ([4]): ::= [] ::== [] ::== [...] Yu, et al. [Page 11] draft-yu-mpls-rsvp-oif-uni-00.txt November 2000 The ERROR_SPEC object specifies the error and includes the IP address of either the UNI-N that detected the error or the UNI link that has failed. 3.1.4 Path Message The Path messages are used for lightpath creation or modification. The format for an O-UNI Path message is shown as follows: ::= [ ] [ [ | ] ... ] [ ] [