Internet Draft Internet Engineering Task Force R. Guerin/S. Kamat/E. Rosen INTERNET DRAFT IBM/IBM/Cisco 29 July 1997 Extended RSVP-Routing Interface draft-guerin-ext-rsvp-routing-intf-00.txt Status of This Memo This document is an Internet-Draft. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes an extended interface between RSVP and routing, whose purpose is to support a broader range of routing mechanisms than allowed by the current recommended interface [Zap96]. The extensions being proposed aim at ensuring that RSVP provides routing with ALL the information that routing may need in order to make its decision. Guerin, et al. Expires 3 February 1998 [Page i] Internet Draft Extended RSVP-Routing Interface 29 July 1997 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Interface Requirements 2 2.1. Explicit Route Support . . . . . . . . . . . . . . . . . 3 2.2. QoS Routing Support . . . . . . . . . . . . . . . . . . . 3 3. Conclusions 7 Guerin, et al. Expires 3 February 1998 [Page ii] Internet Draft Extended RSVP-Routing Interface 29 July 1997 1. Introduction The purpose of RSVP is to set up resource reservations for specified ``flows''. In order to do so, the RSVP module at a given router must be able to find out a flow's ``next hop''. RSVP does not do any routing itself; the only way it can find out a flow's next hop is through an interface to routing. RSVP messages must carry enough information about a flow to enable routing to determine the next hop for that flow. RSVP must pass this information to routing, and routing must pass back the next hop. In the internet routing schemes which are most commonly deployed today, a packet's next hop is a function of its destination address, or perhaps of both its source and destination addresses. In the existing interface between RSVP and routing, RSVP passes these addresses to routing, and routing passes back the corresponding next hop. While this interface may be sufficient for existing routing schemes, there are IETF working groups actively working on enhanced routing schemes for which this interface is not sufficient. In the context of policy routing, for example, it may be desirable to use different routes for flows belonging to different applications -- perhaps video conference traffic should use a different route than web traffic, even if the packets of these two flows have the same source and destination addresses. Alternatively, certain applications may be restricted to using only secure links. If RSVP is to support this type of routing, its interface to routing must allow it to pass information such as port numbers in addition to IP addresses. In general, we want RSVP to make available to routing ALL the information that might be of relevance for routing to make its decision. However, RSVP should NOT need to know which bits in the packet header are significant to routing. To maintain true independence from routing, RSVP should, therefore, pass the entire header across its routing interface, and even this may not suffice in all cases. For example, when MPLS or QoS routing with explicit routes are in use, the choice of a next hop will typically depend on information above and beyond what is specified in the network and transport layer headers. With both MPLS and explicit QoS routes, different routes may have been selected for flows with identical network/transport layer headers, and it is important that RSVP allow conveying of this information. A possible approach that preserves the independence of RSVP from routing is to allow RSVP to pass ``opaque'' objects across its interface to routing. These objects would not be interpreted by RSVP and would carry information meaningful only to a particular Guerin, et al. Expires 3 February 1998 [Page 1] Internet Draft Extended RSVP-Routing Interface 29 July 1997 routing scheme, i.e., enable the identification of the specific next hop for the flow. It should be noted that the assignment of different routes to individual flows headed to the same destination address implies that the forwarding decision itself is extended to support such a differentiation. In the case of QoS routes for RSVP flows, this could be achieved by linking the flow classifier and forwarding functions, i.e., include information such as source and destination address and port numbers into the forwarding decisions. In this case, the extension of the forwarding function is achieved using information already present in the network and transport headers. In other instances such as MPLS, where the forwarding decision is made on the basis of labels, it is necessary to correlate label and route information. This can again be achieved through the use of opaque objects carried by RSVP, e.g., a ``route'' and a ``label'' object, that should both be made available to routing. This document describes an extended interface between RSVP and routing, which is capable of supporting routing enhancements such as QoS routing, policy routing, MPLS, etc. In the next section, we motivate further the need for an expanded interface between RSVP and routing, and illustrate its use in the case of explicit and QoS routes. In Section III, we present a candidate interface that provides the desired functionality. 2. Interface Requirements In general, the interface between RSVP and routing should allow communication of any information necessary to characterize individual flows, as well as all the information that may be needed to identify an appropriate route for a given flow. For example, this would include, in addition to source and destination addresses and port numbers, information such as TSpec, ADSPEC, EXPLICIT_ROUTE object, and an MPLS label (if any). The basic principle to be applied to the design of this interface, is that RSVP should not second guess what routing needs in order to make appropriate decisions. In particular, it is preferable that the interface between RSVP and routing allow passing of more information than may be strictly needed by routing, and that routing discard any unnecessary information. In Section III, we outline a possible definition for such an extended interface, but illustrate first how additional information made available across this interface can be used in the context of two specific examples. Guerin, et al. Expires 3 February 1998 [Page 2] Internet Draft Extended RSVP-Routing Interface 29 July 1997 2.1. Explicit Route Support Currently, there is no provision to carry explicit route information within RSVP control messages. However, in the context of unicast flows, explicit routes could be specified through a new Explicit_Route object in RSVP. A possible format for the Explicit_Route object is described in [GKR97] wich shows an Explicit_Route object consisting of a (loose) source route and a pointer indicating the current position within the source route. This object, like policy objects, is opaque to RSVP. It can be generated anywhere on the path of a flow, and specifies a subset of links on which the flow is to be routed. RSVP's only responsibility and involvement is to carry the object in PATH messages, and to make it available to routing. Processing of the Explicit-Route object is performed entirely by routing, that uses the information contained in the object to determine the next hop on which the PATH message should be forwarded. In doing so, routing will identify the outgoing link currently pointed to in the Explicit_Route object, and update the pointer before returning the modified Explicit_Route object and the next hop information to RSVP. This is similar to the interactions that take place between RSVP and policy, where RSVP provides policy with an incoming policy object, and where policy returns to RSVP both an outgoing policy object and a policy decision (accept, reject, etc.). Support for explicit routes, therefore, only requires from RSVP that it make available to routing the information needed by routing to identify the appropriate next hop. This does not impact RSVP's semantics or functionality, or increase its involvement in routing decisions. It only requires that RSVP carry the relevant information in an opaque object, just as it does for policy information, and that it make that object available to routing. 2.2. QoS Routing Support Another case which benefits from an extended interface between RSVP and routing is that of QoS routing. The objective of a QoS sensitive path selection is to choose for each flow the path that has the best likelihood of meeting the flow's QoS requirements, while still making efficient use of network resources. The first step towards achieving this goal is to make the QoS requirements of individual flows known to routing. In particular, knowledge of a sender TSpec can help routing estimate the likely resource requirements of the flow and choose a path for the flow accordingly. Hence, it is important that RSVP make that information available to routing when initiating its Route_Query. Guerin, et al. Expires 3 February 1998 [Page 3] Internet Draft Extended RSVP-Routing Interface 29 July 1997 Another important aspect of QoS routing is QoS path management, that deals with maintaining or adjusting existing paths to ensure that they remain adequate. In particular, this involves preventing service disruption to existing flows by avoiding unnecessary rerouting of these flows when their current resource reservations are satisfactory, while also reacting appropriately to link or reservation failures that affect the flow's quality of service guarantees. Path management can be performed by either RSVP or routing. However, in order to avoid burdening RSVP with functions that fall outside of the scope of a resource reservation setup protocol, path management should be the responsibility of QoS routing and not of RSVP. This is consistent with the use of the notify flag defined in the current interface between RSVP and routing, where routing is responsible for detecting the failure of the path of an existing flow and asynchronously notifying RSVP of this event. In the case of QoS path management, additional failure conditions need to be considered, e.g., reservation failures, so that a single flag is not sufficient to support this function. This is best illustrated by an example that will motivate the need for extended notification capabilities between RSVP and routing. Consider the case where QoS routing has selected a path for a given flow, and pins it, i.e., remembers that the flow has been assigned to this path, to avoid continuous rerouting of the flow as the network load conditions change. Pinning prevents unwanted changes, but requires additional steps to unpin the path in case of failures. For example, it may turn out that when flow actually attempts to reserve resources on the path it has been assigned (a RESV message is sent), the reservation fails at some link. Alternatively, a link failure at a node may also invalidate an existing path. In those instances, it is important that RSVP and routing be able to notify each other of any such event (RSVP would notify routing of a reservation failure and routing would inform RSVP of a link failure), so that alternate paths can be explored. Rerouting around a failure can be attempted either at the node where the failure occurred (local repair), or at some upstream node (local repair fails or is not attempted). If rerouting is to take place at an upstream node, that node must then be informed that it needs to perform such a task. This can be achieved [GKH97] through the use of PATH_ERR messages with specific error codes (reservation failure or link failure), but this would again require that RSVP notify routing of the receipt of such a message. In general, QoS path management is best supported using a generic asynchronous notification interface between RSVP and routing. In the next section, we outline a possible interface definition Guerin, et al. Expires 3 February 1998 [Page 4] Internet Draft Extended RSVP-Routing Interface 29 July 1997 that satisfies this requirement, and allows communication of all the information that routing may need to make flow specific path assignments. III. RSVP Routing Interface The interface described here is an extension of the asynchronous query reply interface described in [Zap96]. As motivated in the previous section, the extension involves: 1. inclusion of additional parameters in Route_Query and Route_Reply to enable reservation setup on explicit paths and paths selected using QoS routing, and 2. addition of two new APIs RSVP_Event and Routing_Event that can be used by RSVP and routing, respectively, to asynchronously notify each other of events that are significant for QoS path management. Details on the interface are provided next. - Route_Query interface is of the form: Route_Query( flow_id, Network header, Transport Header, notify_flag, sender_TSPEC, ADSPEC, opaque_object1, opaque_object2, ...) Route_Query is used by RSVP to find the outgoing interface for sending out a PATH message. * flow_id is a local handle that defines the context for RSVP query for a flow. It is used to match the later asynchronous Query_Reply and Routing_Event messages from routing. * network and transport headers are used by routing to individuate flows * TSpec and ADSPEC information facilitate selection of a path likely to meet the QoS requirements of the flow * a variable number of opaque objects that RSVP PATH message may carry without any interpretation are also passed to routing. An example of such object is the explicit route object defined in [GKR97]. - Routing responds to a Route_Query with a Route_Reply that identifies the outgoing interface(s) on which the PATH message is Guerin, et al. Expires 3 February 1998 [Page 5] Internet Draft Extended RSVP-Routing Interface 29 July 1997 to be forwarded and provides a list of opaque objects that should be transmitted in the outgoing PATH message. Thus Route_Reply is of the form: Route_Reply(flow_id, notify_flag, outgoing_interface_mask, opaque_object1, opaque_object2, ...) * notify_flag is used to inform RSVP of the status of a route notification request made in the corresponding Route_Query, i.e., whether it is supported or not. - In addition to extensions to Route_Query and Route_Reply, the interface also allows RSVP and routing to asynchronously notify each other of significant events in their respective domains. Specifically, this is supported through two generic API's as follows: 1. RSVP_Event(flow_id, event_code, event_value) RSVP_Event is used by RSVP to notify routing of a specific event concerning a flow. The following events are defined for this purpose: * local reservation failure (event_code, event_value TBD) * receipt of a PATH_ERR message with an error code that indicates a link or reservation failure downstream, or inability to support the requested explicit route. The actual type of error would be specified through the use of (event_codes, event_values TBD). event_value would typically include the IP address of the node where the failure occurred as specified in the Error_Node field of the received PATH_ERR message. * removal of a PATH state due to time out or receipt of a PATH_TEAR message. (event_code, event_value TBD) * change in PHOP or IP_TTL value in the path state of a flow. (event_code, event_value TBD) (NB. This event has significance for loop avoidance in case of QoS path management when hop by hop routing instead of explicit routes are used. See [GKH97] for details. It is listed here for the sake of completeness.) Conversely, routing will notify RSVP using the following API: 2. Routing_Event(flow_id, event_code, event_value) Guerin, et al. Expires 3 February 1998 [Page 6] Internet Draft Extended RSVP-Routing Interface 29 July 1997 Currently, only one following event is defined that generalizes the existing notify flag. * failure of the current path that needs to be notified to upstream routers. (event_code, event_value TBD). Routing will use this event to notify RSVP of a local link failure that affects the path of the specified flow. Upon being notified of such a failure, RSVP is expected to either query routing anew to attempt to locally reroute the flow (if supported), or to send a PATH_ERR message with the appropriate event_code (link failure) to upstream routers so that rerouting can be attempted there. 3. Conclusions This document provides a rationale for extending the interface between RSVP and routing, so as to support additional routing capabilities. The examples of explicit routes and QoS routes were presented to both illustrate and motivate the needs for such an extension. References [CDF+97] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, and A. Viswanathan. A Framework for Multi-Protocol Label Switching (draft-ietf-mpls-framework-00.txt). INTERNET-DRAFT, Internet Engineering Task Force, May 1997. [GKH97] R. Guerin, S. Kamat, and S. Herzog. QoS Path Management with RSVP, (draft-guerin-qos-path-mgt-rsvp-00.txt). INTERNET-DRAFT, Internet Engineering Task Force, March 1997. [GKR97] R. Guerin, S. Kamat, and E. Rosen. Setting up Reservations on Explicit Paths Using RSVP (draft-guerin-expl-path-rsvp-00.txt). INTERNET-DRAFT, Internet Engineering Task Force, July 1997. [Zap96] D. Zappala. RSRR: A Routing Interface for RSVP (draft-ietf-rsvp-routing-01.ps). INTERNET-DRAFT, Internet Engineering Task Force - RSVP WG, November 1996. Guerin, et al. Expires 3 February 1998 [Page 7] Internet Draft Extended RSVP-Routing Interface 29 July 1997 Authors' Address Roch Guerin IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 EMAIL: guerin@watson.ibm.com VOICE +1 914 784-7038 FAX +1 914 784-6205 Sanjay Kamat IBM T.J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598 EMAIL: sanjay@watson.ibm.com VOICE +1 914 784-7402 FAX +1 914 784-6205 Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 EMAIL: erosen@cisco.com Guerin, et al. Expires 3 February 1998 [Page 8]