Internet Draft
INTERNET-DRAFT                                               Lixia Zhang
Expiration: April 1997
<draft-ietf-rsvp-diagnostic-msgs-03.txt>                  Andreas Terzis
File: draft-ietf-rsvp-diagnostic-msgs-02.txt
Expiration: May 1998                                                UCLA
							     November, 1996
                                                           November 1997
                         RSVP Diagnostic Messages


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress." progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet- Drafts Internet-Drafts Shadow
   Directories on (US East Coast),
   (Europe), (US West Coast), or (Pacific

   Distribution of this memo is unlimited.

   This Internet Draft expires in May, 1998.


   This draft describes document specifies the RSVP diagnosis facility.  As the
   deployment of RSVP is spreading out, it has become becomes clear that a method
   for collecting information about the RSVP state along the path is
   needed.  This specification describes the required functionality, packet format, diagnostic
   message formats, and processing rules.

1.  Introduction

   In the original design of RSVP, the RSVP protocol, error messages are the
   only means for the end hosts to receive feedback information
   regarding a specific request that has failed, a failure in setting up
   either a PATH state or reservation state.  In the absence of
   failures, one receives no feedback regarding the details of a
   reservation that has been put in place, such as whether, or where, or
   how, one's own reservation request is merged with that of others.  In
   case of a failure, the error message carries back only the
   information from the failed point, without any information about the
   state at other hops before or after the failure.  Such missing
   information, however, can be highly desirable for debugging purpose,
   or may even be interesting to end applications.

In this memo we specify an for network resource management in general.

   This document specifies RSVP diagnostic facility messages that allows one to
   collect information of RSVP state along the path from a receiver to a
   specific sender.  Diagnostic messages are independent from any other
   RSVP control messages and produce no side-effects.  That is, they do
   not change any RSVP state at either routers or hosts.  A diagnostic reply is  Similarly,
   they do not represent an error report, report but a collection of requested RSVP state information.
   information as requested.

   We have the following design goals in mind:

     - To be able to collect RSVP state information at every hop along
        the path once where the PATH state has been set up, either for an
        existing reservation or before a reservation request is made;
        here the "hop" means RSVP-capable routers.

        More specifically, we want to be able to collect information
        about flowspec, refresh timer values, and reservation merging at
        each hop along the path.

     - To be able to collect the routing hop count for each non-RSVP cloud
  the path crosses.

     - To avoid diagnostic packet implosion or explosion.

   The following are specifically identified as non-goals:

     - Checking the resource availability along a path.  Such
        functionality may be useful for future reservation requests, but
        would require modifications to existing admission control module
        which is beyond the scope of RSVP.

2.  Overview

   We define two types of RSVP diagnostic packets, diagnostic request
   (DREQ) and reply (DREP).  To avoid packet implosion or explosion,
we restrict all  This diagnostic packets tool can be invoked by a
   client from any host that may or may not be a participant of the RSVP
   session to be unicast only (but see Section
5.2 diagnosed.  Thus generally speaking three nodes are
   involved in performing the diagnostic function:  the requester, the
   starting and the ending nodes of the diagnosis, as shown in Figure 1.
   It is possible that the client invoking the diagnosis function may
   reside directly on crossing firewalls).  If the requesting host LAST-HOP, in which case that the first two
   nodes are the the same.  The starting node of the diagnosis is at named
   "LAST-HOP", meaning the receiving
end last-hop of the delivery path that is segment to be queried, it sends a DREQ packet
to diagnosed,
   which can be either the last-hop receiving end or an intermediate router of the along
   a reserved path.  If the requester  The ending node is not the sender host in general,
   although one can also limit the length of the path segment to be
   diagnosed by specifying a
receiving host, it simply sends hop-count limit for the diagnosis messages.
   To avoid packet implosion or explosion, all diagnostic packets are
   forwarded via unicast only.

   A client invokes RSVP diagnostic functions by generating a DREQ
   packet and sending to some router the LAST-HOP node which should be on the
path.  The RSVP
   path to be diagnosed.  This DREQ packet specifies the RSVP session
   and a sending sender host to that session.  The router receiving the request adds to the DREQ packet a response data object containing its RSVP state for the
specified starts collecting
   information at the LAST-HOP node and proceeds toward the sender (see
   Figure 1).

    Receiver        LAST-HOP                                  Sender
           __           __         __     __     __     __       __
          |  |---------|  |------>|  |-->|  |-->|  |-->|  |---->|  |
          |__|         |__| DREQ  |__|   |__|   |__|   |__|     |__|
                        |            RSVP routers
                      |   | Requester

                           Figure 1

   Each RSVP-capable router receiving the DREQ packet adds to the packet
   a response data object containing the router's RSVP state for the
   specified RSVP session, and then forwards the request via unicast to
   the router that it believes is to be the proper previous hop for the given
   sender.  Each subsequent hop RSVP router attaches its own response data
   object to the end of the DREQ packet, then unicast-forwards forwards via unicast to
   the previous hop.  When the DREQ packet reaches the sender, the
   sender changes the packet type to Diagnostic Reply (DREP) and sends
   the completed response to the original requester.  The  Partial response
   may also be returned before reaching the DREQ packet reaches the sender if any
   error condition along the path, such as "no path state", prevents
   further forwarding of the request packet. DREQ packet, or if the specified hop-count
   for the diagnosis has been reached.

   DREP packets can be unicast back to the requester either directly, or
   in a hop-by-hop manner by reversing the exact path that the DREQ
   packet has taken.  The former is faster and more efficient, but the
   latter may be the only choice if the packets have to cross firewalls. firewalls,
   due to the way that firewalls operate.

   To facilitate the latter case, a DREQ packet may optionally carry a
   ROUTE object, which is a list of router addresses that the DREQ
   packet has passed through on the way to the sender; this ROUTE object
   is built incrementally as the DREQ packet passes through the
   intermediate routers.  The DREP packet can then be returned to the
   requester by reversing the path.

   When the path consists of many hops, it is possible that the total
   length of a DREP packet will exceed the path MTU size before reaching
   the sender, thus the packet has to be fragmented.  Relying on IP
   fragmentation and reassembly, however, can be troublesome, problematic, especially
   when DREP packets are returned to the requester hop-by-hop, in which
   case fragmentation/reassembly would have to be performed at each every
   hop.  To avoid such excessive overhead, we let the requester define a
   default path MTU size which is carried in every DREQ packet. If an
   intermediate router believes finds that the default MTU size is too big, bigger than
   that of the outgoing  link, it returns the DREQ packet with the
   corresponding error bit set.  If an intermediate router detects that
   a DREQ packet size reaches the MTU size, it trims off the sends a partial result and returns it DREP,
   consisting of the collected responses back, to the requester, requester and then forwards
   continues to forward the trimmed DREQ packet to the next hop towards
   the sender.

   Through out this memo document we use the word "DREQ packet", rather the
   word "message" to call a diagnostic request since it always consists
   of a single packet.  On the other hand, one DREQ packet can generate
   multiple DREP packets, each containing a fragment of the total reply.
   Furthermore, when discussing diagnostic packet handling, the
   terminology used refers to the direction of data packet flow, thus
   "outgoing interface" of a router is the interface a DREQ packet comes
   from. THE DREQ then gets forwarded to an "incoming interface",
   because DREQ packets travel in the reverse direction of the data

   Notice that one can forward DREQ packets only after the RSVP PATH
   state has been set up.  If no PATH state exists, one may resort to
   the traceroute or mtrace facility to examine whether the
   unicast/multicast routing is working correctly.

3.  Diagnostic Packet Format

   A diagnostic packet consists of the following parts:

           |        RSVP common header         |
           |  Diagnostic packet header object  |
           |         session object            |
           |    (optional) route SELECT object       |
           |    one    (optional) ROUTE object        |
           |    zero or more Response Object   |


3.1.  RSVP Message Common Header

   In the RSVP message common header,

                   0             1              2             3
     | Vers | Flags|    Type     |       RSVP Checksum       |
     |   Send_TTL  |   reserved  |          RSVP Length      |

   The Flags field is unused for now and must be set to zero.

   Type = 8: DREQ

   Type = 9: DREP

RSVP Checksum covers the entire packet body including this header.

   The RSVP Checksum algorithm is the same as the one used in IP checksum, that
is it is:
The 16 bit 16-bit one's complement of the one's
   complement sum of all the 16
bit words in the header. whole diagnosis message (including this
   header).  For purposes of computing the checksum, the value
of the checksum field is set to
   zero.  When receiving packets, the checksum MUST be verified before
   processing a packet.

   Send_TTL: the IP TTL value that a router puts in the IP packet header
   when forwarding the DREQ packet to the previous hop.

   RSVP length: the total length of this diagnostic packet in bytes,
   including the common header.  If this is a DREP packet and the MF
   flag in the diagnostic packet header (see below) is set, this length
   field indicate the length of this single DREP fragment, rather than
   the total length of the the complete DREP reply (which may not be
   known in advance).


3.2.  RSVP Diagnostic Packet Header Object

   Both DREQ and DREP headers are a concatenation of Diagnostic Packet
   Header Object and an RSVP Session object, as defined below:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |           length              |    class      |     c-type    |
    | Max-RSVP-hops | RSVP-hop-count| multicast TTL |         Reserved          |H|MF|
    |                          Message ID                           |
    |           path MTU            |     Fragment offset           |
    |                                                               |
    |                         Sender Filter Spec Filter-Spec                    |
    |                                                               |
    |                         LAST-HOP Address                      |
    |                                                               |
    |                  Response Address Filter-Spec                 |
    |                                                               |
    |                                                               |
    |                         Next-Hop RSVP_HOP Object              |
    |                                                               |
    |                                                               |
    +               Followed by RSVP Session Object                 |
    |                                                               |
   Length is the length of this diagnostic header object.

   Class = 30.

   C-type field is used to distinguish between IPv4 (C-type = 1) and
   IPv6 (Ctype = 2).  In the the IPv6 case adddreses addresses will be 16 bytes each.

   Max-RSVP-hops specifies the maximum number of RSVP hops that the
   requester wants to collect information from.  In case an error
   condition in the middle of the path prevents the DREQ packet from
   reaching the specified sender, one may use this field to perform an
   expanding-length search to reach the point just before the problem.

   The fragment offset field indicates where in the total reply this
   fragment belongs. The fragment offset is measured in octets. The
   first fragment has offset zero.

   RSVP-hop-count field records the number of RSVP hops that have been
   traversed so far.

Multicast TTL is used to limit the multicast scope when the response
address is a multicast address; see Section 5.2 for more details.
Otherwise this field must be set to zero.

   The H flag indicates how the reply should be returned.  When H = 0 and
the response address is a unicast address, 0,
   DREP packets should be sent to the response address directly via unicast If H = 0 and the response
address is a multicast address, DREP packets should be sent to the LAST-HOP
address via unicast. directly.  If H =
   1, DREP packets must be returned to the LAST-HOP address in a hop-by-hop hop-
   by-hop way.  The node specified by the LAST-HOP address then forwards
   DREP packets to the response address.

   The MF flag means "more fragment". fragments".  It must be set to zero in (0) on
   all DREQ
packets.  All packets, and set to one (1) on all DREP packets that carry
   partial results and are returned by intermediate routers rather
than due to the
   MTU limit.  When the sender must set converts a DREQ packet to DREP, the MF
   flag to 1; when the sender remains zero.  An intermediate router may also converts a DREQ
   packet to a DREP, DREP when the DREQ packet has traversed the specified
   number of Max-RSVP-hops, in which case the MF flag remains zero.

   Message ID identifies an individual DREQ packet and the corresponding
   reply (or all the fragments of the reply). A possible way of using
   the message ID is the 16 bits to specify the ID of the process doing
   the query and the low 16 bits to be the sequence number of the query.
   This way processes on the same machine can distinguish between each
   other's replies and between different copies of the same query.

   The path MTU is a 16-bit field that specifies a default MTU size for size, in
   number of bytes, that all diagnostic packets. packets must fit within.

   Sender Filter-Spec is the IP address plus the port of the sender
   being traced.  The DREQ packet proceeds hop-by-hop towards this

   LAST-HOP address is the IP address of the last hop at the receiving
   end for the path being traced.  The DREQ packet starts collecting
   information at this node and proceeds toward the sender.

   Response Address is Filter-Spec contains the IP address and the port to
   which the DREP packet(s) should be sent. This Response Address does not necessarily specify
   Filter-Spec specifies the node that
initiates process originating the request.

   The Next-Hop RSVP_HOP object carries the IP address of the interface
   to which the DREQ packet, although most often it would. must be forwarded to. This object is updated on a
   hop by hop basis, and is used for the same reasons that a RESV
   message contains an RSVP_HOP object. That is, to distinguish logical
   interfaces and avoid problems caused by routing asymmetries.

   The session object identifies the RSVP session for which the state
   information is being collected.

   Optionally, the diagnostic packet header may also contain a ROUTE object, as
defined below, immediately after SELECT object which
   carries a list of [Class, C-type] pairs, each pair specifies one type
   of RSVP object the Session object.  The ROUTE diagnosis invoking client wants to examine.  When
   a SELECT object is included in the DREQ packet, each RSVP router
   along the way should attach to be used the response object each type of the
   objects specified in the SELECT list.  In the absence of a SELECT
   object, the router will attach a set of default objects.

   The SELECT object has the following format:

    |          length               |    class      |     c-type    |
    |    class      |     c-type    |    class      |     c-type    |
    |            ...................                                |

   The Length field represents the total length of the object in number
   of bytes.

   Class = 33

   C-type field is not used at the moment and must be set to zero.

   The object payload part carries a list of  [Class, C-type] pairs.  In
   case where the requested number of objects is an odd number, the last
   two bytes must be set to zero.

   Optionally, the diagnostic packet may also contain a ROUTE object, as
   defined below. The ROUTE object is to be used to return DREP packets

    |          length               |  class        |     c-type    |
    |             reserved                          |    R-pointer  |
    |                                                               |
    +                     List of RSVP routers                      |
    |                                                               |

   The Length field represents the total length of the object in number
   of bytes, from which the number of addresses in the RSVP router list
   can be easily computed.

   Class = 31.

   C-type field is used to distinguish between IPv4 (C-type = 1) and
   IPv6 (Ctype = 2) ROUTE object.

   R-pointer is used in DREP packets only (see Section 4.2 for details),
   but is incremented as each hop adds its incoming interface address in
   the ROUTE object.

   In a DREQ packet, the List of RSVP routers lists all the RSVP hops
   between the LAST-HOP address, as specified in the Diagnostic packet
   header object, and the last RSVP router the DREQ packet has visited.
   In a DREP packet, List of RSVP routers lists all the RSVP hops
   between the LAST-HOP and the router that returns this DREP packet.


3.3.  Response Data Object

   When receiving a DREQ packet, each RSVP router attaches a "response
   data" object to it before forwarding on.  The response data object is
   defined as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |          length               |     class     |   C-type      |
    |                       DREQ Arrival Time                       |
    |                  Incoming Interface Address                   |
    |                  Outgoing Interface Address                   |
    |                 Previous-RSVP-Hop Router Address              |
    |                      reservation style                        |
    |   D-TTL       |M|R-err|  K    |      timer value              |
    |                                                               |
    |                         (TUNNEL object)                       |
    |                                                               |
    |                                                               |
    |                         Tspec object                          |
    |                                                               |
    |                                                               |
    |                        filter spec object                     |
    |                                                               |
    |                                                               |
    |                          flowspec object                      |
    |                                                               |

   Class = 32.

   Ctype 1 and 2 specify whether this is an IPv4 or IPv6 response data,

   DREQ Arrival Time is a 32-bit NTP timestamp specifying the arrival
   time of the DREQ packet at this router.  The 32-bit form of an NTP
   timestamp consists of the middle 32 bits of the full 64-bit form;
   that is, the low 16 bits of the integer part and the high 16 bits of
   the fractional part.

   Incoming Interface Address specifies the IP address of the interface
   on which packets from the sender, as defined in the Diagnostic Packet
   Header, are expected to arrive, or 0 if unknown.

   Outgoing Interface Address specifies the IP address of the interface
   from which the DREQ packet comes, and to which packets from the given
   sender and for the specified session address flow, or 0 if unknown.

   Previous-RSVP-Hop Router Address specifies the router from which this
   router receives RSVP PATH messages from for this source, or 0 if unknown.

   Notice that the response object format as shown above assumes IPv4
   addresses of 4-byte each; in case of IPv6 (indicated by C-type = 2),
   these three addresses will be 16 bytes each.

   Reservation style is the 4-byte value of RSVP Style Object as defined
   in the RSVP specification.

   D-TTL contains the routing hop count this DREQ packet traveled from
   the down-stream RSVP router to the current router.

   M is a single-bit flag which indicates whether the reservation, as
   described by the objects below, is merged with reservations from
   other downstream interfaces when being forwarded upstream.

   R-error is a 3-bit field that indicates error conditions at a router.
   Currently defined values are
           0x00: no error
           0x01: no PATH state
           0x02: MTU too big
           0x04: ROUTE object too big

   K is the refresh timer parameter defined in RSVP, and timer value is
   the local refresh timer value in seconds.

   The remaining parts, Tspec, filter spec, and flowspec objects follow the
definitions given in RSVP specification.  The latter two may next part, TUNNEL object, is an optional one which should be absent
(see Section 4.1 on
   inserted when a DREQ forwarding). Also note packet arrives at an RSVP router that the length of these acts as a
   tunnel exit point. The TUNNEL object provides mapping between the
   end-to-end RSVP session that is varying so being diagnosed and the lengths used on RSVP session
   over the diagram above are not

4. Diagnostic Packet Forwarding Rules

4.1 DREQ Packet Forwarding

DREQ packets are forwarded via hop-by-hop unicast from tunnel. This mapping information allows the LAST-HOP
address diagnosis client
   to conduct diagnosis over the Source address as specified in the diagnostic packet
header.  Each hop performs the following processing before forwarding
the packet to involved tunnel session when so
   desired, by invoking a separate Diagnostic query for the
   corresponding Tunnel Session and Tunnel Sender.  Keep in mind,
   however, that multiple end-to-end sessions may all map to one pre-
   configured tunnel session which may have totally different parameter

   The tunnel object is defined in the RSVP Tunnel Specification
   [RSVPTUN], with the following format:

    |          length               |  class        |     c-type    |
    |                                                               |
    |           Session object (for the end-to-end session)         |
    |                                                               |
    |                                                               |
    |           Sender Filter-Spec (for the tunnel sender)          |
    |                                                               |

                                           SESSION_ASSOC Object

   Class=192.  Ctype 1 specifies IPv4 sessions, Ctype 2 specifies IPv6
   sessions, and Ctypes 3 and 4 specify sessions with IPSEC Generalized
   Port Id for IPv4 and IPv6 respectively.

   The remaining parts, Tspec, filter spec, and flowspec objects follow
   the definitions given in RSVP specification. The latter two may be
   absent (see Section 4.1 on DREQ forwarding). In the case of a SE
   reservation the filter spec is actually the set of all filter specs
   that share the reservation. The flowspec describes the actual
   reservation in place.

   Also note that the length of these object is varying so the lengths
   used on the diagram above are not representative.

4.  Diagnostic Packet Forwarding Rules

4.1.  DREQ Packet Forwarding

   DREQ packets are forwarded via hop-by-hop unicast from the LAST-HOP
   address to the Sender address as specified in the diagnostic packet
   header.  Each hop performs the following processing before forwarding
   the packet to the next hop towards the sender:


     1. Compute the routing hop count from the previous RSVP hop. This
        is done by subtracting the value of the TTL value in the IP
        header from Send_TTL in RSVP common header.  The result is then
        saved in the D-TTL field of the response data object.


     2. If no PATH state exists for the specified session, set R-error =
        0x01 in the Response Data object.


     3. If the path MTU value is too large, set "MTU too large" error
        bit, and change the MTU value to the MTU value of the incoming
        interface for PATH messages for the current router.


     4. Attach the response data object to the end of the DREQ packet.
        If the DREQ packet contains a SELECT object, attach one copy of
        each of the objects specified in the SELECT.  Otherwise attach
        Tspec, filter spec, and flowspec objects in to the response object object.
        Tspec, filter spec, and flowspec objects describe the
        reservation in place at the Outgoing Interface for the specified

        If no reservation state exists for the specified RSVP session,
        the response object will contain no filter-spec or flowspec object; it should
  still include the Tspec object for the specified sender that has been
  carried to the router in the sender's PATH messages.

        If neither PATH nor reservation state exists for the specified
        RSVP session, then the response object contains none of the
        Tspec, filter or flow spec object.

5 Increase the packet length field in the RSVP common header accordingly.


     5. If any error bit is set, change the type field in RSVP common
        header from DREQ to DREP, recompute the checksum and send the
        packet back to either the LAST-HOP address (if H = 1, or response address is a multicast address), 1), or to the
        response address directly via unicast (if H = 0).


     6. Increment the RSVP-hop-count field in the diagnostic packet
        header by one.

        If the resulting value is equal to that of Max-RSVP-hops, or if
        the current hop is the sender as identified by the "Source
        Address" in the RSVP diagnostic header, go to Send_DREP(), and
        then return.


     7. If the resulting DREQ packet size exceeds the MTU limit, minus
        some margin to hold the address list object as described below,
        go to Send_DREP().


     8. If no error bit set ,then if the H-bit is set set, append the
        "Incoming Interface Address" to the end of the ROUTE object,
        increment R-Pointer by one one, update the Next-Hop RSVP_HOP object
        to be the Previous Hop from the Path State and update the packet
        length field in the RSVP  common header accordingly. Finally
        forward the DREQ packet to the next hop towards the
  source. source,
        after recomputing the checksum.


     1. If the H flag in the Diagnostic Header header is off, set
        target=response address given in the DREQ header, else set
        target = the last address in ROUTE.

     2. Make a copy of the DREQ packet and change the type field in RSVP
        common header from DREQ to DREP.  If this host is not the source
        set the MF flag on.

        If the ROUTE object is so large such that (size of ROUTE +  size
        of response data object) > path MTU, then set the "route too
        big" error bit, recompute the checksum, send the response packet, packet
        and go to 7, 4, else recompute the checksum and send the response

     3. If this host is not the source, then trim off all the response
        data objects from the original DREQ packet, adjust the "Fragment
        offset" value in the RSVP common header accordingly and forward
        the modified DREQ packet towards the source. source, after recomputing
        the checksum.

     4. Return.


4.2.  DREP Forwarding

   When the H flag is off, DREP packets are sent directly to the
   original requester.  When H flag is on, however, they are forwarded
to towards the requester, by reversing the route as listed in
   the Route object.

   When a router receives a DREP packet, it simply decreases R-pointer
   by one (address length), and forward the packet to the address
   pointed by R-pointer in the route list.

   When the LAST-HOP router receives a DREP packet, it sends the packet
   to the Response address.


4.3.  MTU Selection and Adjustment

   Because the DREQ packet carries the allowed MTU size of previous hops
   that the DREP packets will later traverse, this unique feature allows
   the easy semantic fragmentation as described above.  Whenever the
   DREQ packet grows to approach the size of MTU, it can be trimmed
   before being forwarded again.

   When a requester sends a DREQ packet, the path MTU field in the RSVP
   Diagnostic Packet header can be set to a configured default value.
   Whenever a DREQ packet size approaches the specified MTU value, an
   intermediate RSVP router makes a copy of the packet, converts it to a
   DREP packet to send back, and then trims off the partial results from
   DREQ packet and forwards it.

   It is possible that the original MTU value is chosen larger than the
   actual MTU value along some portion of the path being traced.
   Therefore each intermediate RSVP router must check the MTU value when
   processing a DREQ packet.  If the specified MTU value is larger than
   the MTU of the incoming interface (that the DREQ packet will be
   forwarded to), the router

     (1) sets the R-error value,
     (2) changes the MTU value in the header to the smaller value, and
     (3) converts the DREQ packet to a DREP and sends it back to the

   In the rare case that where some intermediate routers do not check, or
   enforce upon, the MTU value carried in the diagnostic packets, it is
   possible that on the way back to the requester, a DREP packet may
   encounter a link of smaller MTU.

   When this happens, the router follows steps (1) and (2) as outlined
   above, and trims off the extra part of the DREP packet to fit in the
   smaller MTU of the link.  The trimming must be done at response
   object boundaries.  Such trimming of packets results in information
   loss.  However because the requester learns what is the available MTU
   size, it can either ignore the loss, or otherwise try again with the
   smaller MTU value.


4.4.  Errors

   If an error condition prevents a DREP packet from being forwarded
   further, the packet is simply dropped.

   If an error condition, such as lack of PATH state, prevents a DREQ
   packet from being forwarded further, the router must change the
   current packet to DREP type and return it to the response address.

5.  Problem Diagnosis by Using RSVP Diagnostic Facility

5.1 Broken Intermediate Router

A broken (or legacy) intermediate RSVP router may simply not
understand diagnostic packets, and drop them.  The querier would then
get no response at all from its requests.  It may then choose to first
do a multicast traceroute (in case of multicast) to get information
about the route length, and then perform an RSVP diagnosis search
by gradually increasing the value of M_TTL field until it no longer
receives a response.


5.1.  Across Firewalls

   Firewalls can may cause problems in diagnostic packet forwarding.  Let us
   look at two different cases.

   First, let us assume that the querier is resides on a receiving host of
   the session to be examined.  In this case, firewalls should not
   prevent the forwarding of the diagnostic packets in a hop-by-hop
   manner, assuming that proper holes have been punched on the firewall
   to allow hop-by-hop forwarding of other RSVP packets.  The querier
   may start by setting the H flag off, which can give a faster response
   delivery and reduced overhead at intermediate routers.  However if no
   response is received, the querier may resend the DREQ packet with H
   flag turned on.

   If the requester is a third party host and is separated from the
   LAST-HOP address by a firewall (either the requester is behind a
   firewall, or the LAST-HOP is a router behind a firewall, or both), at
   this time I we do not know any other solution but attempting to use multicast.

To send a DREQ packet across a firewall (or firewalls), the request
should be multicast to change the group being examined (since the last hop
router listens LAST-
   HOP to a node that group).  All routers except the correct last
hop router, as identified by is on the LAST-HOP address in same side of the DREQ
header, should ignore any DREQ request received via multicast.

To receive a DREP packet across a firewall (or firewalls), as the querier
should set

5.2.  Examination of RSVP Timers

   One can easily collect information about the response address to a well-known multicast address
allocated specifically for DREP packets.  In this case, all current timer value at
   each RSVP hop along the reply
packets way.  This will be first unicast to the LAST-HOP address specified very helpful in situations
   when the
diagnostic header, which in turn multicasts them reservation state goes up and down frequently, to find out with a scope as
specified by the multicast TTL value in the Diagnostic Packet Header
Object.  This multicast TTL scope should be set to a value sufficient
for the response from the LAST-HOP router to reach the querier.
However we must also carefully limit this value to a small number,
because there is only one well-known multicast address for this
purpose, therefore all the queriers from all other
sessions will receive the multicast DREP packets as well.  If the
querier still cannot receive the DREP packet when the TTL reaches the
limit, then one must consider using a node closer to the LAST-HOP
address instead.

5.3 Examination of RSVP Timers

One can easily collect information about the current timer value at each
RSVP hop along the way.  This will be very helpful in situations when
the reservation state goes up and down frequently, to find out whether
   whether the state changes are due to improper setting of timer
   values, or K values (when across lossy links), or frequent routing


5.3.  Discovering Non-RSVP Clouds

   The D-TTL field in each response data block shows the number of
   routing hops between adjacent RSVP routers.  Therefore any value
   greater than one indicates a non-RSVP clouds in between.  Together
   with the arrival timestamps (assuming NTP works), this value can also
   give some vague, though not necessarily accurate, indication of how
   big that cloud might be.  One might also find out all the
   intermediate non-RSVP routers by running either unicast or multicast
   trace route.


5.4.  Discovering Reservation Merges

   The flowspec value in a response data block specifies the amount of
   resources (whatever that means by the yet to be defined flowspec) being reserved for the data stream defined by the filter
   spec in the same data block.  When this value of adjacent response
   data blocks differs, that is, a downstream router Rd has a smaller
   value than its immediate upstream router Ru, it indicates a merge of
   reservation with RSVP request(s) from other down stream interface(s)
   at Rd.  Further, in case of SE style reservation, one can examine how
   the different SE scopes get merged at each hop.

   In particular, if a receiver sends a DREQ packet before sending its
   own reservation, it can discover (1)how (1) how many RSVP hops there are
   along the path between the specified source sender and itself, (2)how (2) how many
   of the hops already have some reservation by other receivers, and
(3)possibly foresee (3)
   possibly a rough prediction of how its reservation request might get
   merged with other existing ones.


5.5.  Error Diagnosis

   In addition to examining the state of a working reservation, RSVP
   diagnostic packets are more likely to be invoked when things are not
   working correctly.  For example, a receiver has reserved an adequate
   pipe for a specified incoming data stream, yet the observed delay or
   loss ratio is much higher than expected.  In this case the receiver
   can use the diagnostic facility to examine the reservation state at
   each RSVP hop along the way to find out whether the RSVP state is set
   up correctly, whether there is any blackhole along the way, way that
   caused RSVP message losses, or whether there are non-RSVP clouds, and where,
   where they are, that may have caused the performance problem.

6. Further Work

A missing piece from the current design

5.6.  Crossing "Legacy" RSVP Routers

   Given that this diagnosis function is the handling developed and added to RSVP
   after a number of diagnostic
packets across routers RSVP implementations have been in place, it is
   possible, or even likely, that are when performing RSVP diagnosis, one
   may encounter one or more RSVP-capable but routers that do not support
RSVP understand
   diagnostic messages.

7. Acknowledgment

The idea packets, thus drop them.  When this happens, the invoking
   client will get no response from its requests.

   One way to by-pass such "legacy" RSVP routers is running an iteration
   of developing a diagnostic facility for RSVP was first
proposed diagnosis by Mark Handley using information from traceroute, or mtrace in
   case of UCL.  Many thanks multicast.  When an RSVP diagnostic query times out (see next
   section), one may first use traceroute to Lee Breslau of get the list of routers
   along the path, and then gradually increases the value of Max-RSVP-
   hops field in the DREQ packet, starting from a low value until one no
   longer receives a response.  One can then try RSVP diagnosis again by
   starting with the first router (which is further upstream towards the
   sender) after the unresponding one.

6.  Comments on Diagnostic Client Implementation.

   Following the design principle that routers in the network should not
   hold more than necessary state,  RSVP nodes are responsible only for
   forwarding Diagnostic packets and filling Response Data Objects.
   Additional diagnostic functionalities should be carried out by the
   Diagnostic Clients.  Furthermore, if the diagnostic function is
   invoked from a third-party host, we should not not require that host
   be running RSVP daemon to perform the function.  Below we sketch out
   the basic functions that a diagnostic client daemon should carry out.

     1. Take input from the user about the session to be diagnosed, the
        last-hop and the sender address, the Max-RSVP-hops, and possibly
        the SELECT list, create a DREQ packet and send to the LAST-HOP
        RSVP node using raw IP packet with protocol number 46 (RSVP).
        The port of the UDP socket that the Diagnostic Client is
        listening to for replies, should be included in the Response
        Address Filter-Spec.

     2. Set a retransmission timer, waiting for the reply (one or more
        DREP packets). Listen to the UDP port specified in the Response
        Address Filter-Spec for responses from the LAST-HOP RSVP node.

        The LAST-HOP RSVP node upon receiving DREP packets sends them to
        the the Diagnostic Client as UDP packets, using the port
        supplied to in the Response Address Filter-Spec.

     3. Upon receiving a DREP packet to an outstanding diagnostic
        request, the client should clear the retransmission timer, check
        to see if the reply contains the complete result of the
        requested diagnosis.  If so, it should pass the result up to the
        invoking entity immediately.

     4. Reassemble DREP fragments.  If the first reply to an outstanding
        diagnostic request contains only a fragment of the expected
        result, the client should set up a reassembly timer in a way
        similar to IP packet reassembly timer.  If the timer goes off
        before all fragments arrive, the client should pass the partial
        result to the invoking entity.

     5. Use retransmission and reassembly timers to gracefully handle
        packet losses and reply fragment scenarios.  In the absence of
        response to the first diagnostic request, a client should
        retransmit the request a few times.  If all the retransmissions
        also fail, the client should invoke traceroute or mtrace to
        obtain the list of hops along the path segment to be diagnosed,
        and then perform an iteration of diagnosis with increasing hop
        count as suggested in Section 5.6 in order to cross RSVP-capable
        but diagnosis-incapable routers.

     6. If all the above efforts fail, the client must notify the
        invoking entity.

7.  Acknowledgments

   The idea of developing a diagnostic facility for RSVP was first
   suggested by Mark Handley of UCL.  Many thanks to Lee Breslau of
   Xerox PARC and John Krawczyk of Baynetworks for their valuable
   comments on the first draft of this memo.  Lee and Breslau, Bob Braden Braden,
   and John Krawczyk contributed further comments after the LA IETF, March 1996 IETF.
   Vincent Subramaniam and John Krawczyk caught a number Steven Berson provided valuable comments on
   variable drafts of
errors just prior to this post. the memo.  We would also like to thank Vincent
Subramanian acknowledge Intel
   for providing a research grant as a partial support for his comments on this second draft of the memo. work.

8.  References

   [RSVPTUN] L. Zhang, A. Terzis, "RSVP Operation Over IP Tunnels ",
   Internet Draft draft-ietf-rsvp-tunnel-02.txt, November, 1997.

9.  Authors' Addresses

      Lixia Zhang
      4531G Boelter Hall
      Los Angeles, CA  90024  90095

      Phone:    310-825-2695

      Andreas Terzis
      4677 Boelter Hall
      Los Angeles, CA 90024 90095
      Phone:    310-267-2190