[Search] [txt|ps|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02                                                      
Internet Draft                                            Deborah Estrin
Expiration: December 1995                                        USC/ISI
File: draft-ietf-rsvp-routing-00.txt                       Scott Shenker
                                                                    PARC
                                                          Daniel Zappala
                                                                 USC/ISI



                        Routing Support For RSVP



                             June 30, 1995

Status of 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 inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "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 memo describes an interface between RSVP and routing protocols.
   The interface allows RSVP to request information and services from
   routing in the form of an asynchronous query-reply protocol.













Estrin, et al.         Expiration: December 1995                [Page 1]


Internet Draft                RSVP Routing                     June 1995


1. Introduction

   This document describes an interface between RSVP [4] [3] and routing
   protocols.  The interface allows RSVP to request information and
   services from routing in the form of an asynchronous query-reply
   protocol.  This document describes the design of the interface and
   details a specification of a portion of the interface based on our
   experience using RSVP with DVMRP [2] as a supporting multicast
   routing protocol.  The routing services we discuss represent only a
   subset of the functionality that RSVP may need; we are continuing to
   investigate other services.  This document assumes familiarity with
   RSVP.

   First, Section 2 presents a brief overview of relevant RSVP
   functionality and some routing problems RSVP encounters.  These
   problems lead to a set of RSVP's requirements for routing, presented
   in Section 3.  Section 4 details a general routing model that RSVP
   can use to interact with a variety of different routing protocols.
   Section 5 outlines the particular queries and responses that comprise
   the interface between RSVP and routing, focusing on how RSVP uses
   this interface.  Section 6 discusses the costs and limitations placed
   on routing if it implements the services requested by RSVP.  Finally,
   Section 7 details the specification of the interface messages.

2. RSVP Overview

   Using RSVP, sources send "Path" messages hop-by-hop to the
   destination.  Each router uses the "Path" message to create reverse-
   path routing state and forwards the message toward the destination.
   Receivers send "Resv" messages toward sources, following the
   reverse-path routing state.  Each router uses the "Resv" message to
   query admission control and accept or reject the embedded reservation
   request.  All of the routing and reservation state is "soft-state";
   RSVP refreshes the soft-state periodically and removes it after a
   period of inactivity.

   Note that after RSVP processes a "Path" message at a router, it re-
   sends it as if it originated from the original sender.  For multicast
   destinations, the forwarding entry depends on both the source and the
   destination; thus RSVP can only resume forwarding of the "Path"
   message if it knows the necessary routing entry.  RSVP may also need
   to send a different "Path" message out each outgoing interface on
   multicast routers.  It needs this functionality to establish
   reverse-path routing information, to advertise service
   characteristics [1] over different branches of a multicast tree, to
   send multicast Path messages over non-RSVP clouds, and to pack
   multicast Path messages.  Thus, for this functionality, RSVP may also
   need to know the necessary routing entry.



Estrin, et al.         Expiration: December 1995                [Page 2]


Internet Draft                RSVP Routing                     June 1995


   RSVP has no knowledge of route changes, other than by capturing them
   with periodic "Path" messages.  In addition, once a route changes,
   RSVP has no guarantee that the new path can be reserved at a level
   equal to the old one.  Thus, route changes may lead to a long-term
   service disruption.  Figure 1 shows an example of how this may
   happen.  Receiver R1 has reserved a branch of the existing multicast
   tree.  A link comes back into service, causing routing to find a new
   shortest path.  Multicast routing adapts to this change and the
   reservation protocol sends a reservation up the new route.  The
   reservation fails, however, and R1 is left without a reserved route.


                S
                |
               [ ]
               / S
              /   S
             /     S
           [ ]     [ ]             S  : multicast tree for S
          X T       S
          ^ T       S              T  : link comes back into
          M T       S                   service
           [ ]SSSSS[ ]
           S      S               ^  : attempt to use "better"
      ^   S      S                M    route
      M  S      S
       [ ]     [ ]                 X  : reservation failure
        S       S
      ^ S       S
      M S       S
       [ ]     [ ]
        |       |
        R1      R2

            Figure 1: Service Disruption Caused by Route Change


   RSVP is also limited to establishing reservations over whichever path
   routing chooses.  Most routing protocols maintain a single, shortest
   path between a source and destination.  We refer to this shortest
   path as the "default route".  If RSVP is unable to attain a
   reservation over the default route, then it has no recourse.

3. RSVP Requirements

   To address these limitations, we have designed an interface between
   RSVP and routing.  Using this interface, RSVP may acquire routing
   entries to allow it to send control messages hop-by-hop, as well as



Estrin, et al.         Expiration: December 1995                [Page 3]


Internet Draft                RSVP Routing                     June 1995


   request routing services that provide it with extra functionality.
   We express the interface design as a set of requirements that RSVP
   places on routing.  The initial set of requirements includes:

   o    supplying on demand the forwarding entry for a source-
        destination pair,

   o    providing notification of route changes for supplied routes,

   o    keeping a working route in place once a reservation has been
        secured, barring any failed links or routers along the route,
        and

   o    constructing on demand explicit routes when a reservation
        request is rejected along the default route. [Note 1]


   We expect this list of requirements to grow as we continue to
   investigate how routing can support RSVP.

   RSVP needs to learn about routing entries for the reasons discussed
   in Section 2.  Note that for unicast routing RSVP does not need to
   learn about routing entries; routing is based on destination only and
   not on the source-destination pair.  However, in order to provide a
   common interface to all routing protocols, we do not distinguish
   between unicast and multicast destinations.

   RSVP requires notification of route changes so that it can adapt its
   reservations to changes in the route between a source and
   destination.  It can do this by re-sending "Path" or "Resv" messages
   where needed.  For multicast destinations, a route change consists of
   any change in the multicast tree for a source-group pair, including
   prunes and grafts as well as routing changes due to failed or
   recovered links.  If routing can not support route change
   notification, then RSVP must poll routing for route entries in order
   to adapt to route changes.

   Once RSVP secures a reservation over a route, it may request that
   routing "pin" the route by not adapting to route changes other than
   those caused by link or node failures.  By providing this service,
   routing allows RSVP to provide applications with a service commitment
   that is interrupted only by failure along the committed path. If
   routing can not support route pinning, then RSVP must adapt to
   routing changes and may notify applications that its service
_________________________
[Note 1] We use the term explicit routes in place of source routes
because they may be used by receivers as well as sources.




Estrin, et al.         Expiration: December 1995                [Page 4]


Internet Draft                RSVP Routing                     June 1995


   commitment is interruptable.  As part of this service, routing may
   also provide "smooth switching" from a reserved non-default route to
   a reserved default route.  This may allow routing to reduce its
   overhead of maintaining non-default routes while still satisfying
   RSVP's requirement.

   Finally, if RSVP is unable to attain a reservation over the default
   route, it may request that routing provide an alternate route between
   the source and destination.  By providing this service, routing and
   RSVP can cooperate to find a route that satisfies a receiver's
   service request.  Routing can choose routes based on feedback from
   RSVP concerning previous reservation availability.  Routing also has
   the option of rejecting an alternate path request if there are no
   available paths.  Figure 2 shows an example of using an alternate
   route.  Receiver R2 has already reserved a branch of the existing
   multicast tree.  Receiver R1 joins the tree, but its reservation
   attempt fails.  Routing supplies a new route and the second
   reservation attempt succeeds.


                S
                |
               [ ]
               / S
              /   S
             /     S
           [ ]     [ ]             S  : multicast tree for S
          X |       S
          ^ |       S              ^  : first reservation attempt
          M |  N>   S              M
           [ ]-----[ ]
           /      S               X  : reservation failure
       ^  /^     S
       M / N    S                 ^  : second reservation attempt
       [ ]     [ ]                 N
        |       S
      ^ | ^     S
      M | N     S
       [ ]     [ ]
        |       |
        R1      R2

                     Figure 2: Using Alternate Routes








Estrin, et al.         Expiration: December 1995                [Page 5]


Internet Draft                RSVP Routing                     June 1995


4. RSVP Routing Model

   Because RSVP must learn about routing entries from a variety of
   different routing protocols, we have adopted portions of the DVMRP
   routing model [2] as an abstraction through which RSVP can
   communicate with all routing protocols.  A routing entry for a
   source-destination pair consists of an incoming virtual interface and
   a set of outgoing virtual interfaces.  A virtual interface is simply
   a number that routing creates to refer to each of the interfaces (or
   virtual interfaces) it uses to send and receive packets on the
   router.  Note that the implementation of the virtual interface is
   hidden from RSVP; whether the interface is a real interface, a
   pseudo-device, or a tunnel is irrelevant.

   When RSVP receives a packet, it expects the forwarding engine to tell
   it which virtual interface the packet arrived on.  This allows RSVP
   to suppress forwarding of packets that routing has determined have
   arrived via the wrong incoming virtual interface, while still
   allowing local processing. When RSVP sends a packet, it expects that
   it can tell the forwarding engine to forward the packet directly over
   a particular vif, without performing any of the forwarding engine's
   usual routing checks or lookups.  Together, these functions allow
   RSVP to forward distinct packets hop-by-hop over each link in a
   unicast or multicast path between a source and destination(s).

   The RSVP routing model defines a virtual interface (or vif) using the
   following attributes:

   id             a unique identifier,

   threshold      a TTL threshold,

   status         a bitmask status vector, and

   local_addr     a local address.

   RSVP uses the TTL threshold to control the scope of a control
   message.  The status vector currently only defines whether the
   virtual interface has been administratively disabled.

5. Routing Support

   The following sections describe the routing support messages
   exchanged by RSVP and routing.







Estrin, et al.         Expiration: December 1995                [Page 6]


Internet Draft                RSVP Routing                     June 1995


   5.1 Obtaining Routing Entries

      Before RSVP can obtain routing entries, it must first discover
      which virtual interfaces (vifs) routing is using.  It does this by
      issuing an Initial Query:

                              Initial_Query().

      Routing responds with an Initial Reply that includes the number of
      vifs and a list of vifs as defined by the RSVP routing model:

                        Initial_Reply(num,vif_list).

      Once RSVP has received the Initial Reply, it can begin requesting
      routing entries by sending a Route Query for a source-destination
      pair:

                      Route_Query(source,destination).

      Routing responds by sending a Route Reply that includes the
      incoming vif and an outgoing vif bitmask:

      Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask).


   5.2 Route Change Notification

      RSVP can request notification of route changes by sending a Route
      Query with an additional notification flag:

                Route_Query(source,destination,notification).

      By setting the notification flag in the query, RSVP requests that
      routing provide route change notification.  If routing is able to
      provide this service, it sets a corresponding notification flag in
      the Route Reply, otherwise it clears the flag.  If RSVP receives a
      Route Reply with the notification bit set, it can assume that
      routing will notify it when the routing entry for the source-
      destination pair changes.  In the meantime, RSVP can use the
      routing entry indefinitely.

   5.3 Route Pinning

      Once RSVP has reserved a route, it may request route pinning by
      sending a Service Query to the last-hop router using a service
      bitmask to indicate the service requested:

           Service_Query(source,destination,service_bitmask,vif).



Estrin, et al.         Expiration: December 1995                [Page 7]


Internet Draft                RSVP Routing                     June 1995


      The Service Query may optionally include the vif between the
      last-hop router and the host to indicate where the service begins.

      The service bitmask codes two types of service: route pinning and
      smooth switching.  If routing can provide route pinning, then RSVP
      can assume that the current route from the source to the
      destination will remain unchanged until a link or node along the
      route fails.  If routing can provide smooth switching, then RSVP
      can assume that routing will not switch from the pinned route to a
      default route until (a) the default route is reserved or (b) the
      pinned route fails.  Smooth switching requires considerable
      coordination between RSVP and routing; whether this is a viable
      service is related to whether the network has enough information
      to know how to respond, and whether another route reserved for the
      same per-hop service will provide the same end-to-end QoS.

      If RSVP requests route pinning, then routing attempts to pin the
      route and returns a Service Reply in the same format with the
      service bitmask set to indicate whether it could perform the
      desired service.  Routing may take a relatively longer time to
      return a Service Reply than other replies because it may have to
      contact other routers to determine whether it can provide the
      requested service.  In addition, if routing returns a Service
      Reply indicating the route is pinned, it may later send an
      unsolicited Service Reply indicating that the route is no longer
      pinned.  This may occur if a link or node fails, or if other
      constraints prevent routing from continuing to pin the route.

   5.4 Alternate Routes

      If RSVP fails to obtain a reservation over the default route, it
      may request an alternate route by sending a Service Query to the
      last-hop router as defined above.  The service bitmask indicates
      RSVP's request for an alternate route.  Routing returns a Service
      Reply indicating in the service bitmask whether it has provided
      the requested service.

      To provide routing with feedback on the reservation status of
      routes, RSVP sends routing status reports to routing:

          Status_Report(source,destination,status,vif,status_info).

      At last-hop routers, RSVP tells routing whether a reservation over
      the current route was successful, using a status of "success" or
      "failure."  The status info may contain failure information or the
      level of reservation attained; routing can use this as input to
      its route selection process.




Estrin, et al.         Expiration: December 1995                [Page 8]


Internet Draft                RSVP Routing                     June 1995


      RSVP also sends routing status reports to help it when
      coordinating alternate path requests.  At every router, RSVP tells
      routing whether it has reserved the incoming link for a particular
      route, using a status of "unreserved" or "reserved."  Routing
      assumes that all links are unreserved until told otherwise.  When
      a receiver joins a multicast tree, it may re-route unreserved
      branches of the tree if it carries an explicit route for a
      different branch.  However, receivers may not re-route reserved
      branches; routing should maintain stability for receivers that
      have already obtained a reservation.

6. Service Costs and Limitations

   Each of the functions described above introduces routing costs and
   limitations.

   Routing incurs very little cost for providing route change
   notification; essentially it only has to tag the subset of its
   routing entries for which RSVP is interested in receiving
   notification.  This amounts to keeping an extra bit for each routing
   entry.  Since this service can be provided independently by each
   router, its implementation is not subject to any interoperability
   constraints.

   Providing route pinning introduces substantial costs for some routing
   protocols.  If a routing protocol uses aggregation and maintains
   routes based on a group of sources (for example a subnet), then
   pinning a route requires extra source-specific state that would not
   otherwise be kept.  Routing must continue to maintain the aggregated
   route for non-pinned sources.

   Routers that implement route pinning will also encounter some basic
   operational limitations of the service.  For example, pinning a
   portion of the multicast tree for one receiver has the side effect of
   pinning those links for all other downstream receivers.  Some
   protocols may require that all routers between the source and
   destination must support route pinning in order to provide the
   service.  In addition, if a router starts to pin a route during a
   route change, it may pin the wrong route.  In some situations,
   routing may pin the route back onto itself, forming a black hole.
   The routing protocol needs added protocol mechanisms to keep pinning
   from disrupting the integrity of routing.

   Routers that implement alternate path routing encounter the same
   costs and limitations as with route pinning.  One significant
   difference is that the likelihood of forming black holes is much
   greater.  Consider Figure 3, where receivers R1 and R2 both want to
   use an alternate route for a multicast tree of sender S.  Routing



Estrin, et al.         Expiration: December 1995                [Page 9]


Internet Draft                RSVP Routing                     June 1995


   uses an explicitly-routed graft for each receiver.  Depending on the
   sequence of links that the two grafts travel, they may form a black
   hole in the multicast tree.


                S
                |
               [ ]
               / \
             N/   \M
             /     \
           [ ]     [ ]             M  : intended explicit
            |       |                   explicit route for R1
           N|       |M
            |  <N3  |              N  : intended explicit
           [ ]-----[ ]                  route for R2
           / \    ^/
        ^ / M3\ N2/M           ^   ^  : sequence of grafts for
       M2/    v\ /             Mn  Nn   R1,R2
       [ ]     [ ]
        |       |
      ^ |       |^
      M1|       |N1
       [ ]     [ ]
        |       |
        R1      R2

                 Figure 3: Black Hole With Explicit Route



   Because routing must manage to prevent black holes in order to
   provide both route pinning and alternate path routing, we present a
   solution here for routing protocols that implement these services
   using grafts.  When a receiver requests a pinned route or an explicit
   alternate route, the last-hop router sends a graft containing the
   service request upstream along the intended route.  Each router that
   receives the graft creates the appropriate pinning or alternate path
   state and attaches to this state a "connected" bit.  The bit is
   initially cleared, signifying that the graft has not yet propagated
   to the sender or to another connected portion of the tree.  Once the
   graft reaches the sender or another connected portion of the tree,
   the entire downstream branch becomes "connected" to a valid portion
   of the route.  Routing sends a message downstream to set all of the
   appropriate connected bits.  Any graft that reaches an "unconnected"
   portion of a route must be rejected and sent back downstream to erase
   any state.




Estrin, et al.         Expiration: December 1995               [Page 10]


Internet Draft                RSVP Routing                     June 1995


7. Routing Support Specification

   This section details the format of messages exchanged by RSVP and
   routing.  We refer to this simple protocol as Routing Support for
   Resource Reservations (RSRR).  We only include those messages that
   are currently being exchanged by the RSVP prototype and DVMRP.  We do
   not include message formats for the Service Query, Service Reply, or
   Status Report because we do not yet have enough implementation
   experience with them.

   7.1 RSRR message format

      An RSRR message consists of:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Version       | Type          | Flags         | Num           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |...                                                            |
      |                                                               |

      Version
              Routing Support for Resource Reservations Version.  This
              document specifies version 1 of RSRR.

      Type
              This document defines four message codes for RSRR:

                      1 = Initial Query
                      2 = Initial Reply
                      3 = Route Query
                      4 = Route Reply

      The Flags field, the Num field, and the rest of the message, are defined
      separately for each RSRR code.

   7.2 Initial Query

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Version       | Type          | Flags         | Num           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version as defined above.

      Type
              1 = Initial Query

      Flags, Num
              0



Estrin, et al.         Expiration: December 1995               [Page 11]


Internet Draft                RSVP Routing                     June 1995


   7.3 Initial Reply

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Version       | Type          | Flags         | Num           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vif ID-1      |Vif Threshold-1| Vif Status-1                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vif Local Address-1                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |...                                                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vif ID-N      |Vif Threshold-N| Vif Status-N                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vif Local Address-N                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version as defined above.

      Type
              2 = Initial Reply

      Flags
              0

      Num
              Number of vifs being reported

      Vif ID-N
              ID for the Nth vif

      Vif Threshold-N
              The threshold ttl for the vif; an outgoing message must have a
              ttl greater than the threshold to be sent

      Vif Status-N
              A bit vector representing the vif status.  Currently only
              the Disabled bit is defined:

              +-+-+-+-+-+-+-+-+
              |             |D|
              +-+-+-+-+-+-+-+-+

              D = 1 if vif is administratively disabled, 0 otherwise.

              The rest of the field is transmitted as zeroes.

      Vif Local Address-N



Estrin, et al.         Expiration: December 1995               [Page 12]


Internet Draft                RSVP Routing                     June 1995


              The local address of the physical interface corresponding to the
              vif

   7.4 Route Query

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Version       | Type          | Flags         | Num           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Destination Address                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Source Address                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Query Identifier                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version as defined above

      Type
              3 = Route Query

      Flags
              Currently only the Notification Bit is defined:

              +-+-+-+-+-+-+-+-+
              |             |N|
              +-+-+-+-+-+-+-+-+

              N = 1 if RSVP requests route change notification for this query,
              0 otherwise.

              The rest of the field is transmitted as zeroes.

      Num
              0

      Destination Address
              Group address being queried

      Source Address
              Source address being queried

      Query Identifier
              Identifier used by reservation protocol

   7.5 Route Reply

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Version       | Type          | Flags         | Num           |



Estrin, et al.         Expiration: December 1995               [Page 13]


Internet Draft                RSVP Routing                     June 1995


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Destination Address                                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Source Address                                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Query Identifier                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Incoming Vif                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Outgoing Vif Bitmask                                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Version as defined above.

      Type
              2 = Route Reply

      Flags
              Currently only the Error bit and the Notification bit
              are defined:

              +-+-+-+-+-+-+-+-+
              |           |E|N|
              +-+-+-+-+-+-+-+-+

              N is set if N is set in the corresponding route query and N can
              perform route change notification for the query.  Otherwise N is
              cleared.

              E is set if routing is unable to obtain routing information for
              the route query.  Otherwise E is cleared.

              The rest of the field is transmitted as zeroes.

      Destination Address
              group address of query = group address of reply

      Source Address
              source address of query = source address of reply

      Query Identifier
              identifier used by reservation protocol, copied from query message

      Incoming Vif
              incoming Vif for (S,G) or default (S,*) if no group-specific
                      state; invalid if E bit is set

      Outgoing Vif Bitmask



Estrin, et al.         Expiration: December 1995               [Page 14]


Internet Draft                RSVP Routing                     June 1995


              bitmask of outgoing Vifs for (S,G) or default (S,*) if no
                      group-specific state; invalid if E bit is set

8. Acknowledgments

   We would like to thank Lixia Zhang for repeating the word
   "requirements" over and over again.  We would also like to thank Bob
   Braden and Van Jacobson for their ideas, Bill Fenner for his help
   with the DVMRP implementation, and the IETF community for valuable
   feedback.

References

[1] S. Shenker, "Network Element Service Specification Template",
    Internet Draft, March 1995.

[2] D. Waitzman, C. Partridge, and S. Deering, "Distance Vector
    Multicast Routing Protocol", RFC 1075, November 1988.

[3] L. Zhang, R. Braden, D. Estrin, S. Herzog, and S. Jamin, "Resource
    ReSerVation Protocol (RSVP) - Version 1 Functional Specification",
    Internet Draft, March 1995.

[4] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala, "RSVP:
    A New Resource ReSerVation Protocol", "IEEE Network", September
    1993.



Security Considerations

   Security considerations are not discussed in this memo.

Authors' Addresses

   Deborah Estrin
   Computer Science Department
   University of Southern California
   Los Angeles, CA 90089-0871
   EMail: estrin@usc.edu











Estrin, et al.         Expiration: December 1995               [Page 15]


Internet Draft                RSVP Routing                     June 1995


   Scott Shenker
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304
   EMail: shenker@parc.xerox.com


   Daniel Zappala
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292
   EMail: daniel@isi.edu







































Estrin, et al.         Expiration: December 1995               [Page 16]