Internet Draft






Internet Draft                                            Daniel Zappala
Expiration: January 1999                            University of Oregon
File: draft-ietf-rsvp-routing-02.txt                           Jeff Kann
                                                                 USC/ISI



                   RSRR: A Routing Interface For RSVP



                              1 July 1998

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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Abstract

   This memo describes version 2 of RSRR, a routing interface for RSVP.
   By using this interface, RSVP may obtain forwarding information from
   routers and use it to place reservation state within the network.
   Version 1 of this interface was designed primarily for RSVP
   interaction with IPv4 multicast routing protocols.  Version 2 adds
   support for IPv4 unicast as well as IPv6 unicast and multicast
   routing.  A backwards compatibility mechanism is provided.











Zappala, Kann           Expiration: January 1999                [Page 1]




Internet Draft                    RSRR                         June 1998


1. Introduction

   This document describes Routing Support for Resource Reservations
   (RSRR), an abstract interface by which RSVP [5] may obtain routing
   information.  RSVP is a resource reservation protocol used by hosts
   to request Quality of Service from the network.  RSVP does not
   include a routing protocol; instead it may use any underlying routing
   protocol(s) to determine where it should carry resource reservations.
   The RSRR interface provides RSVP with forwarding table entries and
   notifies it when those entries change.  This document elaborates on
   the routing support described in the RSVP spec [2].

   This document describes version 2 of RSRR.  In addition to IPv4
   multicast routing protocols, which were covered extensively in the
   version 1 document, version 2 explicitly addresses IPv4 unicast
   routing and adds support for IPv6 unicast and multicast routing.
   Version 2, like version 1, also provides RSVP with information on the
   interfaces known to RSRR.  Finally, version 2 includes a backwards-
   compatibility mechanism that allows RSVP to determine the version of
   RSRR that a routing daemon is using.

   Section 2 gives an overview of RSVP functionality and its
   requirements for routing and kernel support.  Section 3 describes
   RSRR as an abstract service interface.  Section 4 describes how this
   interface might typically be implemented within RSVP.  Appendix A
   gives a specification of RSRR used for communication between RSVP and
   routing daemons. Appendix B lists the RSRR version 1 specification,
   which version 2 implementations must also support.  This is included
   for reference, since some implementations may support multiple
   versions.  Appendix C lists the implementation status of RSRR.


2. RSVP Overview and RSRR Motivation

   Using RSVP, sources send "Path" messages hop-by-hop to the
   destination (Figure 1a).  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 (Figure 1b).  Each router
   uses the "Resv" message to query admission control to accept or
   reject the embedded reservation request.  Reservation messages
   utilize various "styles" to allow sharing among different senders.
   For example, the shared-explicit style targets a reservation at a
   list of senders, and the wildcard style targets a reservation at all
   upstream senders (Figure 1c).






Zappala, Kann           Expiration: January 1999                [Page 2]




Internet Draft                    RSRR                         June 1998


         Sender                Sender               S2     S1    S3
           -                     -                  -      -     -
          | |                   | |                | |    | |   | |
           - P                   - R                -      -     -
           | P                   | R                R \   / R   / R
           - P                   - R                 R  -  R  -  R
          | |                   | |                    | |   | |
         P - P                 R - R                    -     -
        P / \ P               R /  \ R                 R \   / R
       P /    -              R /    -                   R  -  R
      P /    | |            R /    | |                    | |
     P /    P -  P         R /    R -  R                   - R
    P /    P / \  P       R /    R / \  R                  | R
    -      -     -         -      -   -                    - R
   | |    | |   | |       | |    | | | |                  | |
    -      -     -         -      -   -                    -
    R1     R2    R3        R1     R2  R3                Receiver


   (a) PATH message   (b) RESV message merged    (c) RESV message branches
       multicasted        as it follows path         as it travels toward
       downstream         state upstream             multiple senders

                          Figure 1: RSVP Overview


   With proper operating system support, a router could pull an RSVP "
   Path" message out of the forwarding engine, do RSVP processing, and
   then resume forwarding the message.  However, multicast "Path"
   messages have unique requirements.  After RSVP performs its
   processing, it may need to send a different copy of the "Path"
   message out each outgoing interface.  Normally, IP multicast
   replicates datagrams and sends identical copies out each of the
   outgoing interfaces.  Thus, RSVP does not use regular IP multicast
   forwarding and instead needs to replicate the "Path" messages on its
   own and simulate its own multicast forwarding.

   To accomplish this objective, RSVP needs to obtain forwarding table
   entries from the routing protocol; this is what the RSRR interface is
   for.  In addition, the operating system must support several basic
   functions for RSVP.  First, RSVP needs to know which interface a
   "Path" message arrives on.  This allows RSVP to suppress forwarding
   of multicast packets that routing has determined have arrived via the
   wrong incoming interface. It also needs to receive all multicast
   "Path" messages, even if they arrive on the wrong interface; this
   allows RSVP processing to occur for local receivers.  Second, RSVP
   must be allowed to insert the original source address of the "Path"
   message in its IP header This allows the "Path" message to be



Zappala, Kann           Expiration: January 1999                [Page 3]




Internet Draft                    RSRR                         June 1998


   processed by downstream routers as if it came from the original
   source.  Finally, when RSVP sends a multicast packet, it expects that
   it can tell the operating system to forward the packet directly over
   a particular interface, without performing any of the usual multicast
   routing checks and without looping the packet back to other
   interfaces.  These operating system functions, combined with RSRR,
   allow RSVP to forward distinct packets hop-by-hop over each link in a
   multicast path between a source and destination(s).

   When obtaining forwarding table entries from RSRR, RSVP also needs to
   know whether the multicast routing protocol is using sender-rooted
   (e.g shortest-path) trees or shared trees (e.g. with the PIM [3] or
   CBT [1] multicast routing protocols).  For shared trees, RSVP only
   needs to obtain and store one route for all senders to the group.  In
   addition, RSVP must mimic the IP multicast forwarding model.  This
   means that for bidirectional shared trees, a packet can be accepted
   over any interface and is forwarded over all other interfaces listed
   in the route.

   When running over shared trees, RSVP can also significantly decrease
   the size of the "scope" object in wildcard filter "Resv" messages.
   RSVP uses a "scope" object, listing all upstream senders, to prevent
   looping of wildcard filter "Resv" messages [4] (Figure 2a).  For
   shared trees, RSVP can use a " scope" object that includes a wildcard
   address, greatly reducing the size of the "Resv" message.  A "Resv"
   message with a wildcard address would follow shared tree state but
   never sender tree state (Figure 2b).
























Zappala, Kann           Expiration: January 1999                [Page 4]




Internet Draft                    RSRR                         June 1998


               S1     S2      S3               S1     S2      S3
               -      -       -                 -      -       -
              | |    | |     | |               | |    | |     | |
               -      -       -                 -      -       -
            R    \   / R     /  R            R    \   / R     /  R
             R[1]  -  R[2]  -  R[3]           R[*]  -  R[*]  -  R[3]
                  | |      | |                     | |      | |
                   -        -                       -        -
              R      \     / R                  R    \     / R
               R[1,2]   -   R[3]                 R[*]   -   R[3]
                       | |                             | |
                        - R                             - R
                        | R[1,2,3]                      | R[*,3]
                        - R                             - R
                       | |                             | |
                        -                               -
                     Receiver                        Receiver

           (a) wildcard RESV message       (b) wildcard RESV message with
               carrying scope objects          senders #1,2 on a shared tree

           Figure 2: The "Scope" Object in Wildcard Reservations




3. Abstract Service Interface

   We describe RSRR as an abstract service interface because it may be
   realized in several different ways.  For example, some
   implementations may use system calls if the operating system can
   supply the functionality of RSRR.  In a typical implementation, RSVP
   might use the RSRR abstraction as the basis of an interface to a
   routing support module (see Section 4), in addition to using the RSRR
   protocol (see Appendix A) to communicate with multicast routing
   protocol daemons.

   To achieve this generality, the following interface description uses
   the term "RSRR client" to indicate the entity requesting routes and
   the term "RSRR server" to indicate the responding entity.  The client
   is typically the RSVP daemon and the server is typically a routing
   protocol daemon or the operating system.

   The first thing an RSRR client must do is determine the set of
   network interfaces the RSRR server is using.  This allows the client
   to make sense of the routes it acquires from the server.  RSRR
   represents network interfaces -- which may be physical interfaces,
   tunnels, or any other operating system mechanism -- as "virtual



Zappala, Kann           Expiration: January 1999                [Page 5]




Internet Draft                    RSRR                         June 1998


   interfaces" or "vifs".  A vif has the following attributes:


     id             a unique identifier,

     threshold      a TTL threshold,

     prefix         a CIDR prefix,

     status         a bitmask status vector,

     family         the address family,

     length         the address length, and

     local_addr     a local address.


This information represents what the RSRR client (e.g. RSVP) needs to
simulate IP multicast forwarding.  IP multicast uses the "TTL threshold"
to control the scope of packets, checking it on a per-packet basis.  A
newer form of administrative scoping is enforced on a per-route basis,
so it is reflected in the routes themselves and is thus transparent to
the RSRR client.  The server may also define a "status" vector for any
other information it needs to pass to the client.

The RSRR client obtains the set of network interfaces by issuing an
Interface Query of the form:

      Interface_Query().

The server responds with an Interface Reply that includes the number of
vifs and a list of the vifs with their attributes as defined above:

      Interface_Reply(num, vif_list).

The RSRR server automatically notifies the client if the set of inter-
faces or their status changes.  Notification is in the form of a sponta-
neous Interface Reply.

Once the RSRR client has received the Initial Reply, it can begin
requesting routes by sending a Route Query for a source-destination
pair:

      Route_Query(source, destination, notification).

The RSRR server responds by sending a Route Reply:




Zappala, Kann           Expiration: January 1999                [Page 6]




Internet Draft                    RSRR                         June 1998


      Route_Reply(source, destination, notification, incoming_vif,
     outgoing_vif_bitmask, tree_type).

Multicast routes consist of an "incoming vif" and an "outgoing vif bit-
mask".  Unicast routes consist of a single bit set in the "outgoing vif
bitmask" to indicate the next hop; the "incoming vif" is always zero and
should be ignored by the client.  In addition, for unicast queries and
replies the "source" address is zero.

By setting the "notification" flag in the Route Query, the RSRR client
may ask the server to notify it when a route changes.  A multicast route
change is a change in the "incoming vif" or "outgoing vif bitmask", i.e.
joins, prunes, link failures and link recoveries are all included.  A
unicast route change is a change in the "outgoing vif bitmask".  If the
server is able to provide this service, it sets a corresponding "notifi-
cation" flag in the Route Reply, otherwise it clears the flag.  If the
client receives a Route Reply with the "notification" flag set, it can
assume that routing will notify it -- via a spontaneous Route Reply --
when the route for the source-destination pair changes.  In the mean-
time, the RSRR client can assume the route has not changed.  If the RSRR
server can not support route change notification, then the client must
poll routing for forwarding table entries in order to learn of route
changes.

The "tree type" flag in the Route Reply is used only for multicast
routes.  It has one of the following values:

o    sender

o    unidirectional shared

o    hybrid unidirectional shared

o    bidirectional shared

o    hybrid bidirectional shared

The tree type indicates how forwarding occurs on the tree and thus how
to interpret the route contained in the Route Reply.  The "sender" value
indicates that a separate multicast tree is constructed for each sender.
Typically this is a shortest-path tree, but it may also be built using
QoS routing, alternate paths, or other methods.  In this case, packets
must arrive via the "incoming vif" and are then sent on all of the vifs
listed in the "outgoing vif bitmask".  A " unidirectional shared" tree
is constructed for the entire group, but data flows in only one direc-
tion -- from the root of the tree down to all group members.  The for-
warding model for the "unidirectional shared" tree is the same as for a
sender tree; the difference is that senders transmit data to the root of



Zappala, Kann           Expiration: January 1999                [Page 7]




Internet Draft                    RSRR                         June 1998


the tree along separate branches. At routers where these branches are
located, a Route Reply with the "sender" tree type will be returned.  A
"bidirectional shared" tree allows data to be sent by any group member.
An incoming packet may arrive on any interface, and it is sent on all
remaining vifs listed in the "outgoing vif bitmask".  For this tree
type, the " incoming vif" is set to zero and should be ignored.

Hybrid multicast trees are those where some senders use a shared tree
and others use a sender tree.  If the tree type is set to one of the
hybrid types, this indicates that the sender listed in the Route Reply
is using the shared tree given by the route.  Senders that are using a
sender tree will have a "sender" tree type.  Note that for hybrid trees
the RSRR client must issue queries for each sender in case that sender
is using a separate tree.  This is in contrast to the case where all
senders use a shared tree, in which case the RSRR client does not need
to issue separate Route Queries for each of them.

Hybrid trees have the further consequence that senders can change tree
types over time.  Changes of this sort are handled by route change noti-
fication.  For example, if a sender on a hybrid shared tree later
switches to a sender-based tree, the RSRR server will send an updated
Route Reply with a new route and a new tree type.  Likewise, if all
senders are using a shared tree, but later one switches to a shortest-
path tree, the RSRR server will send two Route Replies -- one for the
shared tree that changes the tree type to hybrid, and one for the sender
that is now using a sender tree.


4. Implementing RSRR within RSVP

   A typical RSVP implementation could use the RSRR abstraction to build
   a routing support module that handles interface configuration and
   routing queries for IPv4 and IPv6 unicast and multicast routing
   information.  Figure 3 shows how the routing support module would
   interact with RSVP and other router components.  The module has three
   interfaces, all of which are modeled on the RSRR abstract service
   interface.  First, RSVP's core processing routines request interface
   configuration and forwarding table entries from the routing support
   module.  The module then collects this information from several
   sources.  It uses operating system calls when the kernel is able to
   provide the required information.  Otherwise, it uses the RSRR Proto-
   col to collect this information from a routing protocol daemon.
   Appendix A specifies the RSRR protocol for interprocess communica-
   tion.  For example, ISI's current implementation gets unicast inter-
   faces and routes from the kernel, while it gets multicast interfaces
   and routes using the RSRR protocol.





Zappala, Kann           Expiration: January 1999                [Page 8]




Internet Draft                    RSRR                         June 1998


              RSVP Daemon
              ___________
             | Core RSVP |
             | Processing|
             | Routines  |
             |-----------|
             |    ^ Routing Support       Routing Daemon
             |    | Interface       (IPv4/IPv6 Unicast/Multicast)
             |    v      |          ___________________________
             | --------- |  RSRR    | ______     |             |
             | |Routing|<---------->||      |    |  Core       |
             | |Support| | Protocol || RSRR |<-->|  Routing    |
             | |Module | |          || Task |    |  Routines   |
             | |_______| |          ||______|    |             |
             |___________|          |____________|_____________|
                   ^                                   ^
                   | Operating System Calls            |
                   |                                   |
                   v                                   v
           =======================================================
                  Kernel

                   Figure 3: RSVP Routing Support Module



5. Conclusion

   Using RSRR version 2 and the routing support module has made it eas-
   ier to upgrade RSVP to include IPv6 support by packaging interface
   configuration and route acquisition for IPv4 and IPv6 unicast and
   multicast routing into one module.

   The impact of RSRR on a routing daemon is low.  The daemon only has
   to handle RSRR protocol queries when an RSVP session is created and
   when a route for an RSVP session changes. The daemon incurs very lit-
   tle cost for providing route change notification; essentially it only
   has to tag the subset of its routes for which RSVP is interested in
   receiving notification.  This amounts to keeping an extra bit for
   each routing entry.  Furthermore, the RSRR services can be provided
   independently by each router, so its implementation is not subject to
   any interoperability constraints.


6. Acknowledgments

   We would like to thank Bob Braden, Deborah Estrin, Bill Fenner, Scott
   Shenker, and Lixia Zhang for their help with this work.



Zappala, Kann           Expiration: January 1999                [Page 9]




Internet Draft                    RSRR                         June 1998


References

[1] A. J. Ballardie, P.F. Francis, and J. Crowcroft, "Core Based Trees",
    In "ACM SIGCOMM", August 1993.

[2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource
    ReSerVation Protocol (RSVP) - Version 1 Functional Specification",
    work in progress, March 1997.

[3] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson,
    Ching-Gung Liu, and Liming Wei, "An Architecture for Wide-Area Mul-
    ticast Routing", In "ACM SIGCOMM", August 1994.

[4] Daniel Zappala, "RSVP Loop Prevention for Wildcard Reservations",
    Work in Progress, February 1996.

[5] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and
    Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol", "IEEE
    Network", September 1993.
































Zappala, Kann           Expiration: January 1999               [Page 10]




Internet Draft                    RSRR                         June 1998


Appendices

A. RSRR Protocol Specification

   This section details the RSRR version 2 messages format to be
   exchanged between RSVP and a routing protocol.

   RSVP would like to use version 2 of RSRR to communicate with routing
   protocols, but fall back to version 1 if routing does not support
   version 2.  One way to do this would be to issue an Interface Query
   for version 2 and wait to see if routing responds.  If routing is
   using version 1 this message will be dropped and, after a timeout,
   RSVP could send a version 1 query.

   However, to avoid this delay, we have included a mechanism in RSRR
   for backwards compatibility.  RSVP issues an Interface Query using
   version 1, but sets the Num field to the maximum version of RSRR that
   RSVP supports.  The routing protocol, if it supports only version 1,
   will ignore this field and respond with an Interface Reply for ver-
   sion 1.  A routing protocol supporting version 2 and higher should
   examine this field and respond using a version equal to the minimum
   of Num and the maximum supported version of RSRR.  This mechanism
   allows RSVP and routing to communicate using the maximum version of
   RSRR that they both support.  Note that routing protocols implement-
   ing version 2 or higher should also be able to support queries for
   lower versions of RSRR.  For reference, the version 1 RSRR specifica-
   tion is listed in Appendix A.


A.1 RSRR message format

   An RSRR message consists of:

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

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

   Type
           This document defines four message codes for RSRR:

                   1 = Interface Query
                   2 = Interface Reply



Zappala, Kann           Expiration: January 1999               [Page 11]




Internet Draft                    RSRR                         June 1998


                   3 = Route Query
                   4 = Route Reply

   The rest of the message is defined separately for each RSRR code.


A.2 Interface Query

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

   Version
           1   For compatibility reasons.

   Type
           1 = Interface Query

   Flags
           A bit vector that specifies what RSVP requests, currently
           only Notification bit is defined.

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

           N = 1 if RSVP requests notification of interfaces changes

   Num
           Maximum supported RSRR version





















Zappala, Kann           Expiration: January 1999               [Page 12]




Internet Draft                    RSRR                         June 1998


A.3 Interface Reply

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

   Version
           2

   Type
           2 = Interface Reply

   Flags
           1 = Error occurred during initial query, 0 otherwise

   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

   Prefix
           The CIDR prefix for the address

   Vif Status-N
           A bit vector representing the vif status:

           +-+-+-+-+-+-+-+-+
           |       |N|P|U|M|



Zappala, Kann           Expiration: January 1999               [Page 13]




Internet Draft                    RSRR                         June 1998


           +-+-+-+-+-+-+-+-+

           N = 1 if notification will be made in case of vif changes.
           P = 1 if vif is physical interface, 0 if it is virtual.
           U = 1 if vif is unicast-disabled, 0 if it is enabled.
           M = 1 if vif is multicast-disabled, 0 if it is enabled.

           The rest of the field is transmitted as zeroes.

   Address Family
           The address family of the following address.

   Address Length
           The length of the following address in octets.

   Vif Local Address-N
           The local address of the physical interface corresponding to the
           vif


A.4 Route Query

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

   Version
           2

   Type
           3 = Route Query

   Flags
           Currently only the Notification Bit is defined:

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

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



Zappala, Kann           Expiration: January 1999               [Page 14]




Internet Draft                    RSRR                         June 1998


           0 otherwise.

           The rest of the field is transmitted as zeroes.

   Num
           0

   Address Family
           The address family of the following address.

   Address Length
           The length of the following address in octets.

   Destination Address
           Destination address being queried (unicast or multicast)

   Source Address
           Source address being queried (null for unicast)

   Query Identifier
           Identifier used by reservation protocol






























Zappala, Kann           Expiration: January 1999               [Page 15]




Internet Draft                    RSRR                         June 1998


A.5 Route Reply

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version       | Type          | Flags         | Num           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Address Family                | Address Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination Address                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Address                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Query Identifier                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Incoming Vif  | Tree Type     | Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                Outgoing Vif Bitmask                           |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version
           2

   Type
           4 = Route Reply

   Flags
           The currently defined flags are:

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

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



Zappala, Kann           Expiration: January 1999               [Page 16]




Internet Draft                    RSRR                         June 1998


           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.

   Address Family
           The address family of the following address.

   Address Length
           The length of the following address in octets.

   Destination Address
           destination address of query = destination address of reply

   Source Address
           source address of query = source address of reply (null if unicast)

   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

   Tree Type
           the currently defined values are:

           0       sender tree
           1       unidirectional shared tree
           2       hybrid unidirectional shared tree
           3       bidirectional shared tree
           4       hybrid bidirectional shared tree

   Reserved
           transmitted as 0

   Outgoing Vif Bitmask
           bitmask of outgoing Vifs for (S,G) or default (S,*) if no
           group-specific state; invalid if E bit is set; RSVP
        should handle entire bitmask size or otherwise warn
        user that some routing information may be lost


B. RSRR V1 Protocol Specification







Zappala, Kann           Expiration: January 1999               [Page 17]




Internet Draft                    RSRR                         June 1998


B.1 RSRR V1 Message Format

   An RSRR v1 message consists of:

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

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

   Type
           This appendix defines four message codes for RSRR:

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

   The rest of the message is defined separately for each RSRR code.


B.2 Initial Query

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

   Version as defined above.

   Type
           1 = Initial Query

   Flags, Num
           0













Zappala, Kann           Expiration: January 1999               [Page 18]




Internet Draft                    RSRR                         June 1998


B.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



Zappala, Kann           Expiration: January 1999               [Page 19]




Internet Draft                    RSRR                         June 1998


           The local address of the physical interface corresponding to the
           vif


B.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







Zappala, Kann           Expiration: January 1999               [Page 20]




Internet Draft                    RSRR                         June 1998


B.5 Route Reply

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Version       | Type          | Flags         | Num           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination Address                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Source Address                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Query Identifier                                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Incoming Vif                  |        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Outgoing Vif Bitmask                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version as defined above.

   Type
           4 = Route Reply

   Flags
           The currently defined flags are:

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

           N is set if N is set in the corresponding route query and the
           router 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.

           S has the binary value 01 if the listed sender is using a shared
           tree, but some other senders for the same destination use sender
           trees.  S has the binary value 10 if all senders for the
           destination use shared trees.  Otherwise, S has the value 00.

           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




Zappala, Kann           Expiration: January 1999               [Page 21]




Internet Draft                    RSRR                         June 1998


   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

   Reserved
           transmitted as 0

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


C. Implementations

   Code supporting RSRR that has been and is being developed includes:

o    ISI's RSVP version 4.2 and Xerox PARC's distribution of
     DVMRP/mrouted version 3.8 support RSRR version 1, minus support for
     shared trees

o    ISI plans to release a future version of RSVP with support for RSRR
     version 2,

o    UO plans to add support for RSRR version 2 to Merit's GateD multi-
     cast version 5, specifically testing shared tree support with IPv4
     PIM sparse mode.  This code should be general enough to support
     other multicast protocols implemented within GateD.

Security Considerations

   Security considerations are not discussed in this memo.

Authors' Addresses

   Daniel Zappala
   Department of Computer and Information Science
   University of Oregon
   Eugene, OR 97403
   EMail: zappala@cs.uoregon.edu

   Jeff Kann
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292
   EMail: kann@isi.edu



Zappala, Kann           Expiration: January 1999               [Page 22]




Internet Draft                    RSRR                         June 1998





















































Zappala, Kann           Expiration: January 1999               [Page 23]