Network Working Group Jonathan P. Lang (Chromisys) Internet Draft Krishna Mitra (Chromisys) Expiration Date: September 2000 John Drake (Chromisys) Extensions to RSVP for optical networking draft-lang-mpls-rsvp-oxc-00.txt 1. 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. 2. Abstract Dynamically provisionable optical crossconnects (OXCs) will play an active role in future optical networks and the MPL(ambda)S control plane will be used to establish, teardown, and reroute optical trails through the network. This document specifies extensions to RSVP to address some of the unique requirements of such optical trails. Specifically, we propose extensions to RSVP that allow an upstream node to make a Label suggestion to a downstream node when establishing an optical trail and allow both directions of a bi- directional optical trail to be established simultaneously. A new message type is also defined so that an RSVP node can notify (possibly non-adjacent) RSVP nodes when network failures occur, without affecting the RSVP states of intermediate RSVP nodes. Finally, we propose a modification to allow bundle messages to be sent to non-adjacent RSVP nodes. Lang/Mitra/Drake [Page 1] Internet Draft draft-lang-mpls-rsvp-oxc-00.txt March 2000 3. Conventions used in this document In this document, we follow the naming convention of [2] and use OXC to refer to all categories of optical crossconnects, irrespective of the internal switching fabric. We use the term source node to refer to an RSVP node that initiates the optical trail establishment and the term destination node to refer to the RSVP node that terminates the trail at the other end of the network. Furthermore, we call the message path from the source node to the destination node the downstream direction and the reverse path from the destination node back to the source node the upstream direction. Note that for bi- directional connections our terminology is such that there is only one source node and one destination node. 4. Introduction Future optical networks will consist of label switched routers (LSRs) and optical crossconnects (OXCs) that internetwork using the MPL(ambda)S control plane. Support for provisioning and restoration of end-to-end optical trails within this type of network imposes new requirements on the signaling protocols. Specifically, optical trails will require small setup latency, support for bi-directional trails, and rapid restoration of trails in case of network failures. This document builds on work already done for traffic engineering in MPLS and proposes solutions for these requirements. The modifications proposed in this document enhance the extensions of RSVP-TE [3] to support the following functions: 1. Reduction of trail establishment latency by allowing resources to be configured in the downstream direction. 2. Establishment of bi-directional trails as a single process instead of establishing two uni-directional trails, one in each direction, each being a separate process. Normally, both directions of a bi-directional trail have the same traffic engineering requirements and need to be routed over the same physical route. As a result, they cannot be treated as two separate trail requests. 3. Fast failure notification to a node responsible for trail restoration can be achieved so that restoration techniques can be quickly initiated. For example, for end-to-end path restoration, the source is responsible for rerouting failed trails, and must be notified when the trail's resources are involved in a failure. The organization of the remainder of this document is as follows. In Section 5, we propose a Label suggestion to reduce the trail establishment latency. In Section 6, we present modifications to RSVP so that both directions of a bi-directional trails can be provisioned simultaneously. In Section 7, we introduce a new Notify message that is to notify nodes when failures occur in the network. Finally, in Section 8, we discuss a modification to the bundle message [3] to allow transmission between non-adjacent nodes. Lang/Mitra/Drake [Page 2] Internet Draft draft-lang-mpls-rsvp-oxc-00.txt March 2000 5. Label suggestion Currently in RSVP, the Label object for an optical trail is returned in the Resv message. A unique feature of OXCs is that selecting a (fiber, lambda) Label (see [4]) for a trail requires configuring the OXC so that an input is switched to an output, and all data that arrives over the input must go to the same output. This is different from traditional LSRs where multiple flows from the same input maybe be assigned different Labels and subsequently switched to different outputs. A consequence of this is that when an OXC is initially configured, Labels can be assigned to each input and output and protocols (such as LMP [5]) can be used to exchange Label mappings between adjacent nodes. A consequence of the inherent receiver-oriented nature of RSVP is that the internal configuration of an OXC in the downstream direction cannot be initiated until it receives the Resv message from the downstream node. The ability to begin configuring an OXC before receiving a Label object in the Resv message can provide a significant reduction in the setup latency, especially in OXCs with non-negligible configuration time. To accomplish this, we propose that an upstream OXC suggest a (fiber, lambda) Label for the downstream node to use by including the suggested Label object in the Label Request object [3] of the Path message. The Label object will contain the downstream nodeÆs Label for the bearer channel, which can be obtained through the Link Management Protocol (LMP) [5]. This will allow the upstream OXC to begin its internal configuration before receiving the Resv message from the downstream node. If, however, the downstream node ignores the suggested Label and passes a different Label upstream, the upstream OXC must reconfigure itself so that it uses the label specified by the downstream node. 5.1. Label Request The LABEL_REQUEST object format is shown below, where we have defined a new C_Type for a suggested Label. Class = 19, C_Type = 5 (suggested label) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Media Type | L3PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Media Type: The Link Media Type is the two-octet media type values in IS-IS/OSPF Link Media Type TLV defined in [4]. Lang/Mitra/Drake [Page 3] Internet Draft draft-lang-mpls-rsvp-oxc-00.txt March 2000 L3PID: The L3PID is an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. Label Object: The Label object is the suggested Label for the downstream node. 6. Bidirectional Optical Paths In future optical networks, it may be desirable to establish bi- directional optical paths across the network. Using RSVP-TE [3], this requires establishing two unidirectional paths: an initial path from the source to the destination and a subsequent path from the destination back to the source. This approach has two disadvantages: the latency to establish the bi-directional path requires three source/destination transit times, and the time window between reserving the resources in the downstream direction and reserving them in the upstream direction may be large (as much as two times the source/destination transit time), decreasing the probability of successfully establishing the overall bi-directional path. To address the disadvantages of establishing bi-directional paths using current techniques in RSVP, we propose that a Label object is added to the Path message in the downstream direction. In this way, the upstream direction of the bi-directional path is established on the first pass from the source to the destination, reducing the latency of the reservation process. Furthermore, if suggested Labels are used for the downstream direction of the bi-directional path (see Section 5), then the time between reserving resources in the upstream and downstream directions can be eliminated, increasing the overall probability of success for the bi-directional path. The format of the Path message is as follows (where we assume the extensions of [3] are also implemented): ::= [ ] [] [