home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-rsvp-routing-01.txt < prev    next >
Text File  |  1996-11-27  |  25KB  |  768 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Internet Draft                                            Daniel Zappala
  8. Expiration: May 1997                                             USC/ISI
  9. File: draft-ietf-rsvp-routing-01.txt
  10.  
  11.  
  12.  
  13.                    RSRR: A Routing Interface For RSVP
  14.  
  15.  
  16.  
  17.                            November 26, 1996
  18.  
  19. Status of Memo
  20.  
  21.    This document is an Internet-Draft.  Internet-Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its areas,
  23.    and its working groups.  Note that other groups may also distribute
  24.    working documents as Internet-Drafts.
  25.  
  26.    Internet-Drafts are draft documents valid for a maximum of six months
  27.    and may be updated, replaced, or obsoleted by other documents at any
  28.    time.  It is inappropriate to use Internet-Drafts as reference
  29.    material or to cite them other than as "work in progress."
  30.  
  31.    To learn the current status of any Internet-Draft, please check the
  32.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  33.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  34.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  35.    Rim).
  36.  
  37. Abstract
  38.  
  39.    This memo describes a routing interface for RSVP.  The interface
  40.    allows RSVP to request information and services from routing in the
  41.    form of an asynchronous query-reply protocol.  The primary addition
  42.    to this version of the document is the inclusion of extensions for
  43.    shared trees appropriate to PIM and CBT.  Aside from these
  44.    extensions, the rest of the interface described in this document is
  45.    implemented in ISI's implementation of RSVP and Xerox PARC's
  46.    distribution of DVMRP.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Zappala                   Expiration: May 1997                  [Page 1]
  59.  
  60.  
  61.  
  62.  
  63. Internet Draft                    RSRR                     November 1996
  64.  
  65.  
  66. 1. Introduction
  67.  
  68.    This document describes an asynchronous routing interface by which
  69.    RSVP [6] may request forwarding information at each router in the
  70.    network.  We call this interface Routing Support for Resource
  71.    Reservations (RSRR), because it may conceivably be used by other
  72.    resource reservation protocols.  The primary addition to this version
  73.    of the document is the inclusion of extensions for shared trees
  74.    appropriate to PIM [3] and CBT [1].  Aside from these extensions, the
  75.    rest of the interface described in this document is implemented in
  76.    ISI's implementation of RSVP and Xerox PARC's distribution of DVMRP
  77.    [4].
  78.  
  79.    This document is written from the perspective of multicast routing;
  80.    however, the interface can also be used by RSVP to interact with a
  81.    unicast routing protocol.  This document elaborates on the
  82.    description contained in the RSVP spec [2].  Some familiarity with
  83.    RSVP is assumed.
  84.  
  85.    Section 2 presents a brief overview of RSVP functionality and
  86.    describes how RSVP uses route queries and route change notification.
  87.    Section 3 details a general interface model that routing protocols
  88.    can use to give configuration and forwarding information to RSVP.
  89.    Section 4 outlines the particular queries and responses that comprise
  90.    the routing interface, focusing on how RSVP uses this interface.
  91.    Finally, Section 5 details the specification of the interface
  92.    messages.
  93.  
  94. 2. RSVP Overview
  95.  
  96.    Using RSVP, sources send "Path" messages hop-by-hop to the
  97.    destination (Figure 1a).  Each router uses the "Path" message to
  98.    create reverse-path routing state and forwards the message toward the
  99.    destination.  Receivers send "Resv" messages toward sources,
  100.    following the reverse-path routing state (Figure 1b).  Each router
  101.    uses the "Resv" message to query admission control to accept or
  102.    reject the embedded reservation request.  Reservation messages
  103.    utilize various "styles" to allow sharing among different senders.
  104.    For example, the shared-explicit style targets a reservation at a
  105.    list of senders, and the wildcard style targets a reservation at all
  106.    upstream senders (Figure 1c).
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Zappala                   Expiration: May 1997                  [Page 2]
  118.  
  119.  
  120.  
  121.  
  122. Internet Draft                    RSRR                     November 1996
  123.  
  124.  
  125.  
  126.  
  127.          Sender                Sender               S2     S1    S3
  128.            -                     -                  -      -     -
  129.           | |                   | |                | |    | |   | |
  130.            - P                   - R                -      -     -
  131.            | P                   | R                R \   / R   / R
  132.            - P                   - R                 R  -  R  -  R
  133.           | |                   | |                    | |   | |
  134.          P - P                 R - R                    -     -
  135.         P / \ P               R /  \ R                 R \   / R
  136.        P /    -              R /    -                   R  -  R
  137.       P /    | |            R /    | |                    | |
  138.      P /    P -  P         R /    R -  R                   - R
  139.     P /    P / \  P       R /    R / \  R                  | R
  140.     -      -     -         -      -   -                    - R
  141.    | |    | |   | |       | |    | | | |                  | |
  142.     -      -     -         -      -   -                    -
  143.     R1     R2    R3        R1     R2  R3                Receiver
  144.  
  145.  
  146.    (a) PATH message   (b) RESV message merged    (c) RESV message branches
  147.        multicasted        as it follows path         as it travels toward
  148.        downstream         state upstream             multiple senders
  149.  
  150.                           Figure 1: RSVP Overview
  151.  
  152.  
  153.    RSVP does not use its own routing protocol; instead it uses
  154.    underlying routing protocols to determine where it should carry
  155.    resource reservations.  In keeping with this modularity, we have
  156.    designed the RSR interface, by which RSVP requests routing services
  157.    from various routing protocols (Figure 2).  Using this interface,
  158.    RSVP may acquire routing entries to allow it to send control messages
  159.    hop-by-hop, as well as request "route change notification".
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. Zappala                   Expiration: May 1997                  [Page 3]
  177.  
  178.  
  179.  
  180.  
  181. Internet Draft                    RSRR                     November 1996
  182.  
  183.  
  184.  
  185.                                     RSRR
  186.                                   Interface
  187.                         -----------       --------
  188.                         | Routing |<----->| RSVP |
  189.                         -----------       --------
  190.                              ^               ^
  191.                              |               |
  192.                              |               |
  193.                              v               v
  194.                       ===============================>
  195.  
  196.                          Figure 2: RSRR Interface
  197.  
  198.  
  199.  
  200.    RSVP acquires multicast routing entries by sending "route queries" to
  201.    the routing protocol.  RSVP uses the routing entries to simulate the
  202.    multicast of "PATH" messages.  Normally, an IP multicast packet sent
  203.    out one interface is looped back and sent out the other interfaces of
  204.    a router.  However, RSVP needs to send a different copy of a "PATH"
  205.    message out each outgoing interface.  Thus, rather than relying on IP
  206.    multicast, RSVP simulates its own multicast forwarding so that it can
  207.    specify a single interface to send a multicast packet, without any
  208.    loop back.
  209.  
  210.    When RSVP acquires routing entries, it may also ask routing to notify
  211.    it when a particular route changes.  RSVP uses route change
  212.    notification so that it can quickly adapt its reservations to changes
  213.    in the route between a source and destination.  For multicast
  214.    destinations, a route change consists of any local change in the
  215.    multicast tree for a source-group pair, including prunes and grafts
  216.    as well as routing changes due to failed or recovered links.  In all
  217.    of these cases, RSVP adapts to route changes by re-sending "Path" or
  218.    "Resv" messages where needed.  If routing can not support route
  219.    change notification, then RSVP must poll routing for route entries in
  220.    order to adapt to route changes.
  221.  
  222. 3. RSRR Interface Abstraction
  223.  
  224.    Because RSVP must learn about routing entries from a variety of
  225.    different routing protocols, we have adopted portions of the DVMRP
  226.    interface abstraction [4] as the means by which RSVP can communicate
  227.    with all routing protocols.  A routing entry for a source-destination
  228.    pair consists of an incoming virtual interface (or vif) and a set of
  229.    outgoing virtual interfaces.  A virtual interface is simply a number
  230.    that routing creates to refer to each of the interfaces (or virtual
  231.    interfaces) it uses to send and receive packets on the router.  Note
  232.  
  233.  
  234.  
  235. Zappala                   Expiration: May 1997                  [Page 4]
  236.  
  237.  
  238.  
  239.  
  240. Internet Draft                    RSRR                     November 1996
  241.  
  242.  
  243.    that the implementation of the virtual interface is hidden from RSVP;
  244.    whether the interface is a real interface, a pseudo-device, or a
  245.    tunnel is irrelevant.
  246.  
  247.    When RSVP receives a packet, it expects the forwarding engine to tell
  248.    it which virtual interface the packet arrived on.  This allows RSVP
  249.    to suppress forwarding of packets that routing has determined have
  250.    arrived via the wrong incoming virtual interface, while still
  251.    allowing local processing. When RSVP sends a packet, it expects that
  252.    it can tell the forwarding engine to forward the packet directly over
  253.    a particular vif, without performing any of the forwarding engine's
  254.    usual routing checks or lookups.  Together, these functions allow
  255.    RSVP to forward distinct packets hop-by-hop over each link in a
  256.    unicast or multicast path between a source and destination(s).
  257.  
  258.    The RSVP routing model defines a virtual interface using the
  259.    following attributes:
  260.  
  261.    id             a unique identifier,
  262.  
  263.    threshold      a TTL threshold,
  264.  
  265.    status         a bitmask status vector, and
  266.  
  267.    local_addr     a local address.
  268.  
  269.    RSVP uses the TTL threshold to control the scope of a control
  270.    message.  The use of administrative scoping (as with DVMRP) by a
  271.    routing protocol will affect the forwarding information given to
  272.    RSVP, but its implementation is transparent to RSVP.  The status
  273.    vector currently only defines whether the virtual interface has been
  274.    administratively disabled.
  275.  
  276. 4. RSRR Messages
  277.  
  278.    Before RSVP can obtain routing entries, it must first discover which
  279.    virtual interfaces (vifs) routing is using.  It does this by issuing
  280.    an Initial Query:
  281.  
  282.                              Initial_Query().
  283.  
  284.    Routing responds with an Initial Reply that includes the number of
  285.    vifs and a list of vifs and their attributes as defined by the RSVP
  286.    routing model:
  287.  
  288.                        Initial_Reply(num,vif_list).
  289.  
  290.    Once RSVP has received the Initial Reply, it can begin requesting
  291.  
  292.  
  293.  
  294. Zappala                   Expiration: May 1997                  [Page 5]
  295.  
  296.  
  297.  
  298.  
  299. Internet Draft                    RSRR                     November 1996
  300.  
  301.  
  302.    routing entries by sending a Route Query for a source-destination
  303.    pair:
  304.  
  305.                      Route_Query(source,destination).
  306.  
  307.    Routing responds by sending a Route Reply that includes the incoming
  308.    vif and an outgoing vif bitmask:
  309.  
  310.     Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask).
  311.  
  312.  
  313.    RSVP can request notification of route changes by sending a Route
  314.    Query with an additional notification flag:
  315.  
  316.               Route_Query(source,destination,notification).
  317.  
  318.    By setting the notification flag in the query, RSVP requests that
  319.    routing provide route change notification.  If routing is able to
  320.    provide this service, it sets a corresponding notification flag in
  321.    the Route Reply, otherwise it clears the flag.  If RSVP receives a
  322.    Route Reply with the notification bit set, it can assume that routing
  323.    will notify it -- via a spontaneous Route Reply -- when the routing
  324.    entry for the source-destination pair changes.  In the meantime, RSVP
  325.    can use the routing entry indefinitely.
  326.  
  327.    Routing incurs very little cost for providing route change
  328.    notification; essentially it only has to tag the subset of its
  329.    routing entries for which RSVP is interested in receiving
  330.    notification.  This amounts to keeping an extra bit for each routing
  331.    entry.  Since this service can be provided independently by each
  332.    router, its implementation is not subject to any interoperability
  333.    constraints.
  334.  
  335.    A routing protocol that uses shared trees (such as PIM[3] or CBT[1])
  336.    can help RSVP to decrease the size of the SCOPE object in wildcard
  337.    filter RESV messages.  RSVP uses a SCOPE object, listing all upstream
  338.    senders, to prevent looping of wildcard filter RESV messages [5]
  339.    (Figure 3a).  For shared trees, RSVP can use a SCOPE object that
  340.    includes a wildcard address, greatly reducing the size of the RESV
  341.    message.  A RESV message with a wildcard address would follow shared
  342.    tree state but never sender tree state (Figure 3b).  Routing can
  343.    indicate a particular sender is using a shared tree by setting the
  344.    shared flag in a Route Reply:
  345.  
  346.    Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask,shared).
  347.  
  348.    If at some later point this sender switches to a sender-based tree,
  349.    routing can send an updated Route Reply with this flag cleared.
  350.  
  351.  
  352.  
  353. Zappala                   Expiration: May 1997                  [Page 6]
  354.  
  355.  
  356.  
  357.  
  358. Internet Draft                    RSRR                     November 1996
  359.  
  360.  
  361.  
  362.  
  363.                S1     S2      S3               S1     S2      S3
  364.                -      -       -                 -      -       -
  365.               | |    | |     | |               | |    | |     | |
  366.                -      -       -                 -      -       -
  367.             R    \   / R     /  R            R    \   / R     /  R
  368.              R[1]  -  R[2]  -  R[3]           R[*]  -  R[*]  -  R[3]
  369.                   | |      | |                     | |      | |
  370.                    -        -                       -        -
  371.               R      \     / R                  R    \     / R
  372.                R[1,2]   -   R[3]                 R[*]   -   R[3]
  373.                        | |                             | |
  374.                         - R                             - R
  375.                         | R[1,2,3]                      | R[*,3]
  376.                         - R                             - R
  377.                        | |                             | |
  378.                         -                               -
  379.                      Receiver                        Receiver
  380.  
  381.            (a) wildcard RESV message       (b) wildcard RESV message with
  382.                carrying scope objects          senders #1,2 on a shared tree
  383.  
  384.             Figure 3: The Scope Object in Wildcard Reservations
  385.  
  386.  
  387.  
  388.    A routing protocol that uses shared trees can also help reduce the
  389.    amount of message passing between RSVP and routing.  RSVP normally
  390.    sends a separate Route Query for every active source in a group.  For
  391.    a shared tree, RSVP only needs to send one query, since all the
  392.    routing entries for a given destination will be the same.  Routing
  393.    can indicate that "all" senders are using a shared tree by setting
  394.    the all-shared flag:
  395.  
  396.    Route_Reply(source,destination,incoming_vif,outgoing_vif_bitmask,all_shared).
  397.  
  398.    If, at some later point, a sender switches to a sender-based tree
  399.    (i.e. with PIM), then routing can send an updated Route Reply with
  400.    this flag cleared.
  401.  
  402. 5. RSRR Specification
  403.  
  404.    This section details the format of RSRR messages received and sent by
  405.    a routing protocol.
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Zappala                   Expiration: May 1997                  [Page 7]
  413.  
  414.  
  415.  
  416.  
  417. Internet Draft                    RSRR                     November 1996
  418.  
  419.  
  420.    5.1 RSRR message format
  421.  
  422.       An RSRR message consists of:
  423.  
  424.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  425.       | Version       | Type          | Flags         | Num           |
  426.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  427.       |...                                                            |
  428.       |                                                               |
  429.  
  430.       Version
  431.               Routing Support for Resource Reservations Version.  This
  432.               document specifies version 1 of RSRR.
  433.  
  434.       Type
  435.               This document defines four message codes for RSRR:
  436.  
  437.                       1 = Initial Query
  438.                       2 = Initial Reply
  439.                       3 = Route Query
  440.                       4 = Route Reply
  441.  
  442.       The rest of the message is defined separately for each RSRR code.
  443.  
  444.    5.2 Initial Query
  445.  
  446.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  447.       | Version       | Type          | Flags         | Num           |
  448.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  449.  
  450.       Version as defined above.
  451.  
  452.       Type
  453.               1 = Initial Query
  454.  
  455.       Flags, Num
  456.               0
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Zappala                   Expiration: May 1997                  [Page 8]
  472.  
  473.  
  474.  
  475.  
  476. Internet Draft                    RSRR                     November 1996
  477.  
  478.  
  479.    5.3 Initial Reply
  480.  
  481.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  482.       | Version       | Type          | Flags         | Num           |
  483.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  484.       | Vif ID-1      |Vif Threshold-1| Vif Status-1                  |
  485.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  486.       | Vif Local Address-1                                           |
  487.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  488.       |...                                                            |
  489.       |                                                               |
  490.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  491.       | Vif ID-N      |Vif Threshold-N| Vif Status-N                  |
  492.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  493.       | Vif Local Address-N                                           |
  494.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  495.  
  496.       Version as defined above.
  497.  
  498.       Type
  499.               2 = Initial Reply
  500.  
  501.       Flags
  502.               0
  503.  
  504.       Num
  505.               Number of vifs being reported
  506.  
  507.       Vif ID-N
  508.               ID for the Nth vif
  509.  
  510.       Vif Threshold-N
  511.               The threshold ttl for the vif; an outgoing message must have a
  512.               ttl greater than the threshold to be sent
  513.  
  514.       Vif Status-N
  515.               A bit vector representing the vif status.  Currently only
  516.               the Disabled bit is defined:
  517.  
  518.               +-+-+-+-+-+-+-+-+
  519.               |             |D|
  520.               +-+-+-+-+-+-+-+-+
  521.  
  522.               D = 1 if vif is administratively disabled, 0 otherwise.
  523.  
  524.               The rest of the field is transmitted as zeroes.
  525.  
  526.       Vif Local Address-N
  527.  
  528.  
  529.  
  530. Zappala                   Expiration: May 1997                  [Page 9]
  531.  
  532.  
  533.  
  534.  
  535. Internet Draft                    RSRR                     November 1996
  536.  
  537.  
  538.               The local address of the physical interface corresponding to the
  539.               vif
  540.  
  541.    5.4 Route Query
  542.  
  543.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  544.       | Version       | Type          | Flags         | Num           |
  545.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  546.       | Destination Address                                           |
  547.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  548.       | Source Address                                                |
  549.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  550.       | Query Identifier                                              |
  551.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  552.  
  553.       Version as defined above
  554.  
  555.       Type
  556.               3 = Route Query
  557.  
  558.       Flags
  559.               Currently only the Notification Bit is defined:
  560.  
  561.               +-+-+-+-+-+-+-+-+
  562.               |             |N|
  563.               +-+-+-+-+-+-+-+-+
  564.  
  565.               N = 1 if RSVP requests route change notification for this query,
  566.               0 otherwise.
  567.  
  568.               The rest of the field is transmitted as zeroes.
  569.  
  570.       Num
  571.               0
  572.  
  573.       Destination Address
  574.               Group address being queried
  575.  
  576.       Source Address
  577.               Source address being queried
  578.  
  579.       Query Identifier
  580.               Identifier used by reservation protocol
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589. Zappala                   Expiration: May 1997                 [Page 10]
  590.  
  591.  
  592.  
  593.  
  594. Internet Draft                    RSRR                     November 1996
  595.  
  596.  
  597.    5.5 Route Reply
  598.  
  599.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  600.       | Version       | Type          | Flags         | Num           |
  601.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  602.       | Destination Address                                           |
  603.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  604.       | Source Address                                                |
  605.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  606.       | Query Identifier                                              |
  607.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  608.       | Incoming Vif                  |        Reserved               |
  609.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  610.       | Outgoing Vif Bitmask                                          |
  611.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  612.  
  613.       Version as defined above.
  614.  
  615.       Type
  616.               4 = Route Reply
  617.  
  618.       Flags
  619.               The currently defined flags are:
  620.  
  621.               +-+-+-+-+-+-+-+-+
  622.               |       | S |E|N|
  623.               +-+-+-+-+-+-+-+-+
  624.  
  625.               N is set if N is set in the corresponding route query and the
  626.               router can perform route change notification for the query.
  627.               Otherwise N is cleared.
  628.  
  629.               E is set if routing is unable to obtain routing information for
  630.               the route query.  Otherwise E is cleared.
  631.  
  632.               S has the binary value 01 if the listed sender is using a shared
  633.               tree, but some other senders for the same destination use sender
  634.               trees.  S has the binary value 10 if all senders for the
  635.               destination use shared trees.  Otherwise, S has the value 00.
  636.  
  637.               The rest of the field is transmitted as zeroes.
  638.  
  639.       Destination Address
  640.               group address of query = group address of reply
  641.  
  642.       Source Address
  643.               source address of query = source address of reply
  644.  
  645.  
  646.  
  647.  
  648. Zappala                   Expiration: May 1997                 [Page 11]
  649.  
  650.  
  651.  
  652.  
  653. Internet Draft                    RSRR                     November 1996
  654.  
  655.  
  656.       Query Identifier
  657.               identifier used by reservation protocol, copied from query message
  658.  
  659.       Incoming Vif
  660.               incoming Vif for (S,G) or default (S,*) if no group-specific
  661.                       state; invalid if E bit is set
  662.  
  663.       Reserved
  664.               transmitted as 0
  665.  
  666.       Outgoing Vif Bitmask
  667.               bitmask of outgoing Vifs for (S,G) or default (S,*) if no
  668.                       group-specific state; invalid if E bit is set
  669.  
  670. 6. Acknowledgments
  671.  
  672.    We would like to thank Bob Braden, Deborah Estrin, Bill Fenner, Scott
  673.    Shenker, and Lixia Zhang for their help with this work.
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707. Zappala                   Expiration: May 1997                 [Page 12]
  708.  
  709.  
  710.  
  711.  
  712. Internet Draft                    RSRR                     November 1996
  713.  
  714.  
  715. References
  716.  
  717. [1] A. J. Ballardie, P.F. Francis, and J. Crowcroft, "Core Based Trees",
  718.     In "ACM SIGCOMM", August 1993.
  719.  
  720. [2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource
  721.     ReSerVation Protocol (RSVP) - Version 1 Functional Specification",
  722.     work in progress, May 1996.
  723.  
  724. [3] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson,
  725.     Ching-Gung Liu, and Liming Wei, An Architecture for Wide-Area
  726.     Multicast Routing, In "ACM SIGCOMM", August 1994.
  727.  
  728. [4] D. Waitzman, C. Partridge, and S. Deering, "Distance Vector
  729.     Multicast Routing Protocol", RFC 1075, November 1988.
  730.  
  731. [5] Daniel Zappala, "RSVP Loop Prevention for Wildcard Reservations",
  732.     Work in Progress, February 1996.
  733.  
  734. [6] Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and
  735.     Daniel Zappala, "RSVP: A New Resource ReSerVation Protocol", "IEEE
  736.     Network", September 1993.
  737.  
  738.  
  739.  
  740. Security Considerations
  741.  
  742.    Security considerations are not discussed in this memo.
  743.  
  744. Author's Address
  745.  
  746.    Daniel Zappala
  747.    USC Information Sciences Institute
  748.    4676 Admiralty Way
  749.    Marina del Rey, CA 90292
  750.    EMail: daniel@isi.edu
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766. Zappala                   Expiration: May 1997                 [Page 13]
  767.  
  768.