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

Versions: 00 01 02                                                      
Internet Draft                                            Daniel Zappala
Expiration: May 1997                                             USC/ISI
File: draft-ietf-rsvp-routing-01.txt



                   RSRR: A Routing Interface For RSVP



                           November 26, 1996

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 a routing interface for RSVP.  The interface
   allows RSVP to request information and services from routing in the
   form of an asynchronous query-reply protocol.  The primary addition
   to this version of the document is the inclusion of extensions for
   shared trees appropriate to PIM and CBT.  Aside from these
   extensions, the rest of the interface described in this document is
   implemented in ISI's implementation of RSVP and Xerox PARC's
   distribution of DVMRP.











Zappala                   Expiration: May 1997                  [Page 1]


Internet Draft                    RSRR                     November 1996


1. Introduction

   This document describes an asynchronous routing interface by which
   RSVP [6] may request forwarding information at each router in the
   network.  We call this interface Routing Support for Resource
   Reservations (RSRR), because it may conceivably be used by other
   resource reservation protocols.  The primary addition to this version
   of the document is the inclusion of extensions for shared trees
   appropriate to PIM [3] and CBT [1].  Aside from these extensions, the
   rest of the interface described in this document is implemented in
   ISI's implementation of RSVP and Xerox PARC's distribution of DVMRP
   [4].

   This document is written from the perspective of multicast routing;
   however, the interface can also be used by RSVP to interact with a
   unicast routing protocol.  This document elaborates on the
   description contained in the RSVP spec [2].  Some familiarity with
   RSVP is assumed.

   Section 2 presents a brief overview of RSVP functionality and
   describes how RSVP uses route queries and route change notification.
   Section 3 details a general interface model that routing protocols
   can use to give configuration and forwarding information to RSVP.
   Section 4 outlines the particular queries and responses that comprise
   the routing interface, focusing on how RSVP uses this interface.
   Finally, Section 5 details the specification of the interface
   messages.

2. RSVP Overview

   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                   Expiration: May 1997                  [Page 2]


Internet Draft                    RSRR                     November 1996




         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


   RSVP does not use its own routing protocol; instead it uses
   underlying routing protocols to determine where it should carry
   resource reservations.  In keeping with this modularity, we have
   designed the RSR interface, by which RSVP requests routing services
   from various routing protocols (Figure 2).  Using this interface,
   RSVP may acquire routing entries to allow it to send control messages
   hop-by-hop, as well as request "route change notification".
















Zappala                   Expiration: May 1997                  [Page 3]


Internet Draft                    RSRR                     November 1996



                                    RSRR
                                  Interface
                        -----------       --------
                        | Routing |<----->| RSVP |
                        -----------       --------
                             ^               ^
                             |               |
                             |               |
                             v               v
                      ===============================>

                         Figure 2: RSRR Interface



   RSVP acquires multicast routing entries by sending "route queries" to
   the routing protocol.  RSVP uses the routing entries to simulate the
   multicast of "PATH" messages.  Normally, an IP multicast packet sent
   out one interface is looped back and sent out the other interfaces of
   a router.  However, RSVP needs to send a different copy of a "PATH"
   message out each outgoing interface.  Thus, rather than relying on IP
   multicast, RSVP simulates its own multicast forwarding so that it can
   specify a single interface to send a multicast packet, without any
   loop back.

   When RSVP acquires routing entries, it may also ask routing to notify
   it when a particular route changes.  RSVP uses route change
   notification so that it can quickly adapt its reservations to changes
   in the route between a source and destination.  For multicast
   destinations, a route change consists of any local 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.  In all
   of these cases, RSVP adapts to route changes by re-sending "Path" or
   "Resv" messages where needed.  If routing can not support route
   change notification, then RSVP must poll routing for route entries in
   order to adapt to route changes.

3. RSRR Interface Abstraction

   Because RSVP must learn about routing entries from a variety of
   different routing protocols, we have adopted portions of the DVMRP
   interface abstraction [4] as the means by which RSVP can communicate
   with all routing protocols.  A routing entry for a source-destination
   pair consists of an incoming virtual interface (or vif) 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



Zappala                   Expiration: May 1997                  [Page 4]


Internet Draft                    RSRR                     November 1996


   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 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 use of administrative scoping (as with DVMRP) by a
   routing protocol will affect the forwarding information given to
   RSVP, but its implementation is transparent to RSVP.  The status
   vector currently only defines whether the virtual interface has been
   administratively disabled.

4. RSRR Messages

   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 and their attributes as defined by the RSVP
   routing model:

                       Initial_Reply(num,vif_list).

   Once RSVP has received the Initial Reply, it can begin requesting



Zappala                   Expiration: May 1997                  [Page 5]


Internet Draft                    RSRR                     November 1996


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


   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 -- via a spontaneous Route Reply -- when the routing
   entry for the source-destination pair changes.  In the meantime, RSVP
   can use the routing entry indefinitely.

   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.

   A routing protocol that uses shared trees (such as PIM[3] or CBT[1])
   can help RSVP to 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 [5]
   (Figure 3a).  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 3b).  Routing can
   indicate a particular sender is using a shared tree by setting the
   shared flag in a Route Reply:

   Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask,shared).

   If at some later point this sender switches to a sender-based tree,
   routing can send an updated Route Reply with this flag cleared.



Zappala                   Expiration: May 1997                  [Page 6]


Internet Draft                    RSRR                     November 1996




               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 3: The Scope Object in Wildcard Reservations



   A routing protocol that uses shared trees can also help reduce the
   amount of message passing between RSVP and routing.  RSVP normally
   sends a separate Route Query for every active source in a group.  For
   a shared tree, RSVP only needs to send one query, since all the
   routing entries for a given destination will be the same.  Routing
   can indicate that "all" senders are using a shared tree by setting
   the all-shared flag:

   Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask,all_shared).

   If, at some later point, a sender switches to a sender-based tree
   (i.e. with PIM), then routing can send an updated Route Reply with
   this flag cleared.

5. RSRR Specification

   This section details the format of RSRR messages received and sent by
   a routing protocol.






Zappala                   Expiration: May 1997                  [Page 7]


Internet Draft                    RSRR                     November 1996


   5.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 rest of the message is defined separately for each RSRR code.

   5.2 Initial Query

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

      Version as defined above.

      Type
              1 = Initial Query

      Flags, Num
              0














Zappala                   Expiration: May 1997                  [Page 8]


Internet Draft                    RSRR                     November 1996


   5.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                   Expiration: May 1997                  [Page 9]


Internet Draft                    RSRR                     November 1996


              The local address of the physical interface corresponding to the
              vif

   5.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                   Expiration: May 1997                 [Page 10]


Internet Draft                    RSRR                     November 1996


   5.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                   Expiration: May 1997                 [Page 11]


Internet Draft                    RSRR                     November 1996


      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

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                   Expiration: May 1997                 [Page 12]


Internet Draft                    RSRR                     November 1996


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, May 1996.

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

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

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

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



Security Considerations

   Security considerations are not discussed in this memo.

Author's Address

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















Zappala                   Expiration: May 1997                 [Page 13]