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]