INTERNET-DRAFT                                               Lixia Zhang
Expires: May 1999                                         Andreas Terzis
Expiration: February 1999
<draft-ietf-rsvp-diagnostic-msgs-05.txt>                            UCLA
                                                     Subramaniam Vincent

                                                              Bob Braden
                                                           November 1998
                         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".

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).

   Distribution of this memo is unlimited.

   This Internet Draft expires in February, 1999.


   This document specifies the RSVP diagnosis facility.  As the
   deployment of RSVP is spreading out, it becomes clear that diagnostic facility, which allows a method
   for collecting
   user to collect information about the RSVP state along the path is
   needed. path.
   This specification describes the functionality, diagnostic message
   formats, and processing rules.

1.  Introduction

   In the original design of the basic RSVP protocol, protocol [RSVP], error messages are the only means
   for the an end hosts host to receive feedback information regarding a specific request that has failed, a failure in setting up
   either a PATH path state or reservation state.  An 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.  In the absence of failures, one a host receives no feedback
   regarding the details of a reservation that has been put in place,
   such as whether, or where, or how, one's its own reservation request is
   being 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, information can be
   highly desirable for debugging purpose, or for network resource
   management in general.

   This document specifies the RSVP diagnostic messages that allows one facility, which is
   designed to
   collect fill this information of gap.  The diagnostic facility can
   be used to collect and report RSVP state information along the path
   from a receiver to a specific sender.  It uses Diagnostic messages
   that are independent from any of other RSVP control messages and produce no side-effects.  That
   side-effects; that is, they do not change any RSVP state at either routers
   nodes or hosts.  Similarly, they do provide not represent an error report but
   rather a collection of requested RSVP state
   information as requested.

   We have information.

   The RSVP diagnostic facility was designed with the following design goals in mind: goals:
     - To be able to collect RSVP state information at from every RSVP-capable hop
        the a path where the PATH state has been set up, defined by path state, either for an existing
        reservation or before a reservation request is made;
        here the "hop" means RSVP-capable routers. made.  More
        specifically, we want to be able to collect information about flowspec,
        flowspecs, refresh timer values, and reservation merging at each
        hop along the path.

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

     - To avoid diagnostic packet implosion or explosion.

   The following are is specifically identified as non-goals: a non-goal:

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

2.  Overview

   We define

   The diagnostic facility introduces two types of new RSVP diagnostic packets, diagnostic request message types:
   Diagnostic Request (DREQ) and reply Diagnostic Reply (DREP).  This diagnostic tool  A DREQ
   message can be invoked originated by a client from any host that in a "requester" host, which
   may or may not be a participant of the RSVP session to be diagnosed.  Thus generally speaking three nodes are
   A client in performing the diagnostic function: the requester, requester host invokes the
   starting RSVP diagnostic facility
   by generating a DREQ packet and sending it to 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 the LAST-HOP, in which case that the first two
   nodes are the the same.  The starting node of the diagnosis is named
   "LAST-HOP", meaning the last-hop of the path segment to be diagnosed,
   which can be either the receiving end or an intermediate router along
   a reserved path.  The ending node is the sender host in general,
   although one can also limit the length of the path segment to be
   diagnosed by specifying a 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 the LAST-HOP node which should be on starting node,
   which should be on the RSVP path to be diagnosed.  This DREQ packet
   specifies the RSVP session and a sender host to for that session.  The
   DREQ packet starts collecting collects information at the LAST-HOP node and proceeds toward hop-by-hop as it is forwarded
   towards the sender (see Figure 1).

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

                           Figure 1

   Each RSVP-capable router receiving 1), until it reaches the DREQ packet ending node.
   Specifically, each RSVP-capable hop adds to the packet DREQ message a
   response data (DIAG_RESPONSE) object containing the router's local RSVP state for the
   specified RSVP session, and then forwards the request via unicast to
   the router that it believes to be the previous hop for the given
   sender.  Each subsequent RSVP router attaches its own response data
   object to the end of the DREQ packet, then forwards via unicast to
   the previous hop. session.  When the DREQ packet reaches the sender, the
   sender changes ending
   node, the packet message type is changed to Diagnostic Reply (DREP) and sends the
   completed response is sent to the original requester. requester node.  Partial response
   responses may also be returned before the DREQ packet reaches the sender
   ending node if any an error condition along the path, such as "no path
   state", prevents further forwarding of the DREQ packet, packet.  To avoid
   packet implosion or if explosion, all diagnostic packets are forwarded
   via unicast only.

   Thus, there are generally three nodes (hosts and/or routers) involved
   in performing the diagnostic function: the requester node, the
   starting node, and the ending node, as shown in Figure 1.  It is
   possible that the client invoking the diagnosis function may reside
   directly on the starting node, in which case that the first two nodes
   are the same.  The starting node is named "LAST-HOP", meaning the
   last-hop of the path segment to be diagnosed.  The LAST-HOP node can
   be either a receiver node or an intermediate node along the path.
   The ending node is usually the specified sender host.  However, the
   client can limit the length of the path segment to be diagnosed by
   specifying a hop-count
   for limit in the diagnosis has been reached. DREQ message.

                       LAST-HOP                  Ending
          Receiver        node                     node           Sender
              __           __         __            __              __
             |  |---------|  |------>|  |--> ...-->|  |--> ...---->|  |
             |__|         |__| DREQ  |__|   DREQ   |__|   DREQ     |__|
                           ^                         .              |
                           |                         .              |
                           | DREQ                    . DREP         | DREP
                           |                         .              |
                          _|_               DREP     V              V
             Requester   |   | <------------------------------------
             (client)    |___|

                              Figure 1
   DREP packets can be unicast from the ending node back to the
   requester either directly, directly or
   in a hop-by-hop manner by reversing along the reverse of the exact path that
   taken by the DREQ
   packet has taken. message to the LAST-HOP, and thence to the
   requester.  The former direct return is faster and more efficient, but the
   hop-by-hop reverse-path route may be the only choice if the packets
   have to cross firewalls,
   due to the way that firewalls operate.

   To facilitate the latter case, a DREQ packet may optionally carry a firewalls.  Hop-by-hop return is accomplished using an
   optional ROUTE object, which is built incrementally to contain a list
   of router node addresses that the DREQ packet has passed through on the way to the sender; this through.  The ROUTE
   object is built incrementally then used in reverse as a source route to forward the DREQ packet passes through the
   intermediate routers.  The DREP packet can then be returned
   hop-by-hop back to the
   requester by reversing LAST-HOP node.

   A DREQ message always consists of a single unfragmented IP datagram.
   On the path. other hand, one DREQ message can generate multiple DREP
   packets, each containing a fragment of the total DREQ message.  When
   the path consists of many hops, it is possible that the total length of a DREP packet message
   will exceed the path MTU size before reaching the sender, thus sender; thus, the packet
   message has to be fragmented.  Relying on IP fragmentation and
   reassembly, however, can be problematic, especially when DREP packets
   messages are returned to the requester hop-by-hop, in which case
   fragmentation/reassembly would have to be performed at every hop.  To
   avoid such excessive overhead, we let the requester define a default
   path MTU size which that is carried in every DREQ packet.  If an
   intermediate router node finds that the default MTU size is bigger than
   that the
   MTU of the outgoing  link, it returns the DREQ packet with the
   corresponding error bit set.  If an intermediate router node detects that a
   DREQ packet size reaches the MTU size, it sends a partial DREP,
   consisting of the collected responses back, to the requester and then
   continues to forward the trimmed DREQ packet to the next hop towards
   the sender.

   Through out this document we use the word "DREQ packet", rather the
   word "message" to call a diagnostic request since packet size has reached the MTU size, it always consists
   of returns to the
   requester (in either manner described above) a single packet.  On DREP fragment
   containing accumulated responses.  It then removes these responses
   from the other hand, one DREQ packet and continues to forward it.  The requester node can generate
   reassemble the resulting DREP packets, each containing fragments into a fragment of the total reply.
   Furthermore, when complete DREP message.

   When discussing diagnostic packet handling, the this document uses
   direction terminology used refers that is consistent with the RSVP functional
   specification [RSVP], relative to the direction of data packet flow, thus
   "outgoing interface" of a router is the interface flow.
   Thus, a DREQ packet comes
   from. THE DREQ then gets enters a node through an "outgoing interface" and
   is forwarded to towards the sender through an "incoming interface",
   because DREQ packets travel in the reverse direction of to the data

   Notice that one can forward DREQ packets can be forwarded only after the RSVP PATH path
   state has been set up.  If no PATH 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

   Like other RSVP messages, DREQ and DREP messages consist of the an RSVP
   Common Header followed by a variable set of typed RSVP data objects.
   The following parts: sequence must be used:

              |        RSVP common header Common Header         |
              |  Diagnostic packet header         Session object            |
              |         session       DIAGNOSTIC object           |
              |    (optional) SELECT DIAG_SELECT object  |
              |    (optional) ROUTE object        |
              | zero or more Response Object   | DIAG_RESPONSE objects|

   The session object identifies the RSVP session for which the state
   information is being collected.  We describe each of the other parts.

3.1.  RSVP Message Common Header

   In the

   The RSVP message common header,

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

   The Flags field header is unused defined in [RSVP].  The following
   specific exceptions and extensions are needed for now DREP and must be set to zero. DREQ.

   Type = 8: DREQ field: define:

         Type = 9: DREP
   The RSVP Checksum is the 16-bit one's complement of the one's
   complement sum of the whole diagnosis message (including this
   header).  For computing the checksum, the checksum field is set to
   zero.  When receiving packets, the checksum MUST be verified before
   processing a packet.

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

         Type = 9: DREP     Diagnostic Reply

   RSVP length: the total length of this diagnostic packet in bytes,
   including the common header.

      If this is a DREP packet message and the MF flag in the diagnostic packet header DIAGNOSE object
      (see below) is set, this length field indicate indicates the length of this single
      DREP fragment, fragment rather than the total length of the the complete DREP
      reply message (which may not cannot generally be known in advance).

3.2.  RSVP Diagnostic Packet Header  DIAGNOSTIC Object


   A DIAGNOSTIC object contains the common diagnostic control
   information in 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 messages.

   o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1

    |           length              |    class      |     c-type    |
    | Max-RSVP-hops | RSVP-hop-count|         Reserved          |H|MF|
    |                          Message                          Request ID                           |
    |           path           Path MTU            |     Fragment offset           |
    |                                                               |
    |                         Sender Filter-Spec                     SENDER_TEMPLATE object                    |
    |                                                               |
    |                         LAST-HOP Address                      |
    |                                                               |
    |                  Response Address Filter-Spec                  Requester FILTER_SPEC object                 |
    |                                                               |
    |                                                               |
    |                       Next-Hop RSVP_HOP Object                |
    |                                                               |
    |                                                               |
    +               Followed

   Here all IP addresses use the 4 byte IPv4 format, both explicitly in
   the LAST-HOP Address and by RSVP Session Object                 |
    |                                                               |

   Length is using the length of this diagnostic header object.

   Class = 30.

   C-type field is used to distinguish between IPv4 (C-type = 1) forms of the embedded
   FILTER_SPEC and RSVP_HOP objects.

   o IPv6 (Ctype DIAGNOSTIC object: Class = 2).  In 30, C-Type = 2

   The format is the IPv6 case same, except all explicit and embedded IP addresses will be
   are 16 bytes each. byte IPv6 addresses.

   The fields are as follows:

   Max-RSVP-hops specifies

      An octet specifying the maximum number of RSVP hops that the
   requester wants to collect over which
      information from.  In case will be collected.  If an error condition in the
      middle of the path prevents the DREQ packet from reaching the
      specified sender, one may use this ending node, the Max-RSVP-hops field may be used to
      perform an expanding-length search to reach the point just before
      the problem.

   The fragment offset field indicates where  If this value is 1, the LAST-HOP node and the ending
      node will be the same.  If it is zero, there is no hop limit.


      Records the number of RSVP hops that have been traversed so far.
      If LAST-HOP and ending nodes are the same, this value will be 1 in
      the total reply resulting DREP message.

   Fragment Offset

      Indicates where this
   fragment belongs. The fragment offset is DREP fragment belongs in the complete DREP
      message, 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.

      Ignored in a DREQ message.

   H flag indicates

      Indicates how the reply should be returned.  When H = 0, DREP
      packets should be sent to the response address directly.  If H =
      1, DREP packets must be returned hop-by-hop along the reverse path
      to the LAST-HOP address in a hop-
   by-hop way.  The node specified by the LAST-HOP address then forwards
   DREP packets and thence to the response address.

   The requester node.

   MF flag

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


   Request ID identifies

      Identifies an individual DREQ packet message and the corresponding
   reply DREP
      message (or all the fragments of the reply). A reply message).

      One possible way of using to defining the message Request ID is the would use 16 bits to
      specify the ID of the process doing making 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 queries from this process.

   Path MTU is a 16-bit field that specifies

      Specifies a default MTU size, size in
   number of bytes, that all diagnostic packets must fit within.

   Sender Filter-Spec is octets for DREP and DREQ messages.


      This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address plus and
      the port of the a sender for the session being traced. diagnosed.  The DREQ
      packet proceeds is forwarded hop-by-hop towards this address.

   LAST-HOP address is the Address

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

   Response Address Filter-Spec

   Requester FILTER_SPEC Object

      This IPv4/IPv6 FILTER_SPEC object contains the IP address and the
      port from which the request originated and to which the DREP packet(s)
      message(s) should be sent. This Response Address
   Filter-Spec specifies the process originating the request.


   Next-Hop RSVP_HOP Object

      An RSVP_HOP object carries carrying the IP address and LIH of the
   to through which the DREQ must will be forwarded to. received.  This object is
      updated on a
   hop by hop basis, and hop-by hop.  It is used for the same reasons that a RESV
      message contains an RSVP_HOP object. That is, object:  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

3.3.  DIAG_SELECT Object

   o DIAG_SELECT Class = 33, C-Type = 0.

   A Diagnostic message may optionally contain a SELECT object which
   carries a list of [Class, C-type] pairs, each pair specifies one type
   of RSVP DIAG_SELECT object the diagnosis invoking client wants to examine.  When
   a SELECT object is included in the DREQ packet, each
   specify which specific RSVP router
   along the way should attach to the response object each type of the objects specified should be reported in the SELECT list. a
   DIAG_RESPONSE object.  In the absence of a SELECT DIAG_SELECT object, the router
   DIAG_RESPONSE object added by the node will attach contain a default set of default objects.
   object types (see DIAG_RESPONSE object below).

   The SELECT DIAG_SELECT object has contains a list of [Class, C-type] pairs, in
   the following format:

    |          length    class      |     C-Type    |    class      |     c-type     C-Type    |
    //                                                             //
    |    class      |     c-type     C-Type    |    class      |     c-type    |
    |            ...................     C-Type    |

   The Length field represents the total length of the

   When a DIAG_SELECT object in number
   of bytes.

   Class = 33

   C-type field is not used at included in a DREQ message, each RSVP
   node along the moment and must be set to zero.

   The object payload part carries path will add a DIAG_RESPONSE object containing
   response objects (see below) whose classes and C-Types match entries
   in the DIAG_SELECT list (and are from matching path and reservation
   state).  A C-type octet of  [Class, C-type] pairs.  In
   case where zero is a 'wildcard', matching any C-Type
   associated with the associated class.

   If the requested number of objects [Class, C-Type] pairs is an odd number, odd, the last two bytes octets of
   the DIAG_SELECT object must be set to  zero.

   Optionally, the

3.4.  ROUTE Object

   A diagnostic packet message may also contain a ROUTE object, as
   defined below. The ROUTE object which is to be used to return
   record the route of the DREQ message and as a source route for
   returning the DREP packets message(s) hop-by-hop.

    |          length               |  class        |     c-type    |

   o IPv4 ROUTE object: Class = 31, C-Type = 1.

    |             reserved                          |    R-pointer  |
    |                                                               |
    +                     List of                     RSVP routers Node List                            |
    |                                                               |
   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. Node List

      A list of RSVP node IPv4 addresses.  The number of addresses in
      this list can be computed from the object size.

   R-pointer is used

      Used in DREP packets messages only (see Section 4.2 for details), but it
      is incremented as each hop adds its incoming interface address in
      the ROUTE object.

   o IPv6 ROUTE object: Class = 31, C-Type = 2

   The same, except RSVP Node List contains IPv6 addresses.

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

3.3.  Response Data message.

3.5.  DIAG_RESPONSE Object

   When receiving a DREQ packet, each

   Each RSVP router node attaches a "response
   data" DIAG_RESPONSE object to each DREQ message it
   receives, before forwarding on. the message.  The response data DIAG_RESPONSE 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      |
   contains the state to be reported for this node.  It has a fixed-
   format header and then a variable list of RSVP state objects, or
   "response objects".

   o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.

    |                       DREQ Arrival Time                       |
    |                  Incoming Interface Address                   |
    |                  Outgoing Interface Address                   |
    |                 Previous-RSVP-Hop Router Address              |
    |                      reservation style                        |
    |   D-TTL       |M|R-err|  K    |      timer      Timer value              |
    |                                                               |
    |                         (TUNNEL object)                       |
    |                                                               |
    |                                                               |
    |                         Tspec object                          |
    |                                                               |
    |                                                               |
    |                        filter spec                  (optional) TUNNEL object                     |
    |                                                               |
    |                                                               |
    |                          flowspec object                      |
    //                       Response objects                      //
    |                                                               |

   o IPv6 DIAG_RESPONSE object: Class = 32.

   Ctype 1 32, C-Type = 2.

   This object has the same format, except that all explicit and 2 specify whether this is an IPv4 or
   embedded IP addresses are IPv6 response data,
   respectively. addresses.

   The fields are as follows:

   DREQ Arrival Time is a

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

   Incoming Interface Address specifies

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

   Outgoing Interface Address specifies

      Specifies the IP address of the interface
   from through which the DREQ packet comes,
      message arrived and to which packets messages from the given sender and
      for the specified session address flow, or 0 if unknown.

   Previous-RSVP-Hop Router Address specifies

      Specifies the router node from which this
   router node receives RSVP PATH
      messages 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 this source, or 0 if unknown.  This is also the 4-byte value of RSVP Style Object as defined
      interface through which the RSVP specification. DREQ will be forwarded.

   D-TTL contains the routing hop count

      The number of IP hops this DREQ packet message traveled from the down-stream down-
      stream RSVP router node to the current router. node.

   M is a flag

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

   R-error is a

      A 3-bit field that indicates error conditions at a router. node.
      Currently defined values are are:

           0x00: no error
           0x01: no PATH state
           0x02: MTU too big
           0x04: ROUTE object too big

   K is the

      The refresh timer parameter defined multiple (defined in RSVP, and timer RSVP spec).

   Timer value is
      The local refresh timer value in seconds.

   The next part, TUNNEL set of response objects to be included at the end of the
   DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is an
   present.  If no DIAG_SELECT object is present, the response objects
   belong to the default list of classes:

           SENDER_TSPEC object         FILTER_SPEC object
           FLOWSPEC object         STYLE object

   Any C-Type present in the local RSVP state will be used.  These
   response objects may be in any order but they must all be at the end
   of the DIAG_RESPONSE object.

3.6.  TUNNEL Object

   The optional one which TUNNEL object should be inserted when a DREQ packet message
   arrives at an RSVP router node that acts as a tunnel exit point.

   The TUNNEL object provides mapping between the end-to-end RSVP
   session that is being diagnosed and the RSVP session over the tunnel.
   This mapping information allows the diagnosis client to conduct
   diagnosis over the involved tunnel session when so
   desired, session, 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 pre-configured tunnel session which that 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
   different parameter settings.

   The tunnel object is varying so the lengths
   used on defined in the diagram above are not representative. RSVP Tunnel Specification

4.  Diagnostic Packet Forwarding Rules

4.1.  DREQ Packet Forwarding

   DREQ packets messages are forwarded via  hop-by-hop via unicast from the LAST-HOP
   address to the Sender address address, as specified in the diagnostic packet
   header.  Each hop performs DIAGNOSTIC object.
   At each hop, the following processing is performed before forwarding the packet DREQ
   message is forwarded to the next hop towards the sender:

     1. Compute the routing IP 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 the RSVP common header.  The  Save the result is then
        saved in the
        D-TTL field of the response data DIAG_RESPONSE object.

     2. If no PATH state exists for the specified session, set R-error =
        0x01 in the Response Data DIAG_RESPONSE 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. sender.

     4. Attach the response data DIAG_RESPONSE 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, message,
        and flowspec objects to the append response object.
        Tspec, filter spec, and flowspec objects that describe the reservation in
        place at the Outgoing Interface for the specified session.

        If the DREQ message contains a DIAG_SELECT object, the response
        object classes are those specified in the DIAG_SELECT;
        otherwise, they are SENDER_TSPEC, FILTER_SPEC, STYLE, and
        FLOWSPEC objects.  If no reservation state exists for the
        specified RSVP session, the response DIAG_RESPONSE object will contain no filter-spec
        FILTER_SPEC or flowspec FLOWSPEC or STYLE object. If neither PATH nor
        reservation state exists for the specified RSVP session, then the no
        response object contains none of objects will be appended to the
        Tspec, filter or flow spec DIAG_RESPONSE object.

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

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

     6. If any error bit is set, change the type field in RSVP common
        header from DREQ to DREP, recompute the checksum checksum, and send the
        message back to the requester.  It is sent either hop-by-hop to
        the LAST-HOP address (if H = 1), or directly to the
        response requester
        address directly via unicast (if H = 0).

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


     1. If the H flag is off in the Diagnostic Header header is off, DIAGNOSTIC object, 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 message and change the type field in
        RSVP common header from DREQ to DREP.  If this host is not the source
        source, set the MF flag on.

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

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

     4. Return.

4.2.  DREP Forwarding

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

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

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

4.3.  MTU Selection and Adjustment

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

   When a requester sends a DREQ packet, message, the path MTU field in the RSVP
   Diagnostic Packet header can be set to a configured default value.

   Whenever a DREQ packet message size approaches the specified MTU value, an
   intermediate RSVP router node makes a copy of the packet, message, converts it to a
   DREP packet message to send back, and then trims off the partial results
   from DREQ packet message 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 node must check the MTU value when
   processing a DREQ packet. message.  If the specified MTU value is larger than
   the MTU of the incoming interface (that the DREQ packet message will be
   forwarded to), the router node

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

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

   When this happens, the router node follows steps (1) and (2) as outlined
   above, and trims off the extra part of the DREP packet message to fit in the
   smaller MTU of the link.  The trimming must be done at response
   object boundaries.  Such trimming of packets messages 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 message from being forwarded
   further, the packet message is simply dropped.

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

5.  Problem Diagnosis by Using RSVP Diagnostic Facility

5.1.  Across Firewalls

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

   First, let us assume that the querier resides on a receiving host of
   the session to be examined.  In this case, firewalls should not
   prevent the forwarding of the diagnostic packets messages 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. messages.  The querier
   may start by setting the H flag off, which can give a faster response
   delivery and reduced overhead at intermediate routers. nodes.  However if no
   response is received, the querier may resend the DREQ packet message 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 node behind a firewall, or both), at
   this time we do not know any other solution but to change the LAST-
   HOP to a node that is on the same side of the firewall as the

5.2.  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 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 DIAG_RESPONSE object shows the number of
   routing hops between adjacent RSVP routers. nodes.  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 nodes by running either unicast or multicast
   trace route.

5.4.  Discovering Reservation Merges

   The flowspec value in a response data block DIAG_RESPONSE object specifies the amount of
   resources being reserved for the data stream defined by the filter
   spec in the same data block.  When this value of adjacent response
   data blocks
   DIAG_RESPONSE objects differs, that is, a downstream router node Rd has a
   smaller value than its immediate upstream router node 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 message before sending its
   own reservation, it can discover (1) how many RSVP hops there are
   along the path between the specified sender and itself, (2) how many
   of the hops already have some reservation by other receivers, and (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 messages 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 that
   caused RSVP message losses, or whether there are non-RSVP clouds, and
   where they are, that may have caused the performance problem.

5.6.  Crossing "Legacy" RSVP Routers

   Given that

   Since this diagnosis function is facility was developed and added to RSVP after a
   number of RSVP implementations have been were in place, it is possible, or even
   likely, that when performing RSVP diagnosis, one may encounter one or
   more RSVP-capable routers nodes that do not understand diagnostic packets, thus messages
   and drop them.  When this happens, the invoking client will get no
   response from its requests.

   One way its requests.

   One way to by-pass such "legacy" RSVP nodes is to perform RSVP
   diagnosis repeatedly, guided by information from traceroute, or
   mtrace in case of multicast.  When an RSVP diagnostic query times out
   (see next section), one may first use traceroute to get the list of
   nodes along the path, and then gradually increase the value of Max-
   RSVP-hops field in the DREQ message, starting from a low value until
   one no longer receives a response.  One can then try RSVP diagnosis
   again by starting with the first node (which is further upstream
   towards the sender) after the unresponding one.

   There are two problem with the method mentioned above in the case of
   unicast sessions. Both problems are related to the fact that
   traceroute information provides the path from the requester to the
   sender. The first problem is that the LAST_HOP may not on the path
   from the requester to the sender. In this case we can get information
   only from the portion of the path from the LAST_HOP to the sender
   which intersects with the path from the requester to the sender. If
   routers that are not on the intersection of the two paths don't have
   PATH state for the session being diagnosed then they will reply with
   R-error=0x01. The requester can overcome this problem by sending a
   DREQ to every router on the path (from itself to the sender) until it
   reaches the first router that belongs to the path from the sender to
   the LAST_HOP.

   The second problem is that traceroute provides the path from the
   requester to by-pass such "legacy" RSVP routers is running an iteration
   of RSVP diagnosis by using information the sender which, due to routing asymmetries, may be
   different than the path traffic from traceroute, or mtrace in
   case of multicast.  When an RSVP diagnostic query times out (see next
   section), the sender to the LAST_HOP uses.
   There are (at least) one may first use traceroute case where this asymmetry will cause the
   diagnosis to get fail. We present this case below.

                                   Downstream Path                Sender
                                   __         __            __       __
      Receiver             +------|  |<------|  |<-- ...---|  |-----|  |
         __          __   /       |__|       |__|          |__|     |__|
        |  |--....--|X |_/                    ^
        |__|        |__|      Router B       |
                   Black          __         |
                   Hole    +----->|  |---->---+
                                  |__| Upstream Path

                                Router A

                              Figure 2

   Here the list first hop upstream of routers
   along the path, black hole is different on the
   upstream path and then gradually increases the value downstream path. Traceroute will indicate
   router A as the previous hop (instead of Max-RSVP-
   hops field in router B which is the DREQ packet, starting from a low value until one no
   longer receives right
   one). Sending a response.  One can then try RSVP diagnosis again by
   starting DREQ to router A will result in A responding with R-
   error 0x01 (No PATH State). If the first router (which is further upstream towards two paths converge again then the
   sender) after
   requester can use the unresponding one. solution proposed above to get any (partial)
   information from the rest of the path.

   We don't have, for the moment, any complete solutions for the
   problematic scenarios described here.

6.  Comments on Diagnostic Client Implementation.

   Following the design principle that routers nodes in the network should not
   hold more than necessary state,  RSVP nodes are responsible only for
   forwarding Diagnostic packets messages and filling Response Data Objects. DIAG_RESPONSE objects.
   Additional diagnostic functionalities functionality should be carried out by the
   Diagnostic Clients.
   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 DIAG_SELECT list, create a DREQ packet message and send to the
        LAST-HOP RSVP node using raw IP packet message with protocol number 46
        (RSVP).  The port of the UDP socket that on which the Diagnostic
        Client is listening to for replies, replies should be included in the Response
        Address Filter-Spec.
        Requester FILTER_SPEC object.

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

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

     3. Upon receiving a DREP packet message 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. nodes.

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

7.  Security Considerations

   RSVP Diagnostics, as any other diagnostic tool, can be a security
   threat since it can reveal possibly sensitive RSVP state information
   to unwanted third parties.

   We feel that the threat is minimal, since as explained in the
   Introduction Diagnostics messages produce no side-effects and
   therefore they cannot change RSVP state in the routers. nodes. In this respect
   RSVP Diagnostics is less a security threat than other diagnostic
   tools and protocols such as SNMP.

   Furthermore, processing of Diagnostic messages can be disabled if it
   is felt that is a security threat.

8.  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 Breslau, Bob Braden,
   and John Krawczyk contributed further comments after March 1996 IETF.
   Steven Berson provided valuable comments on various drafts of the
   memo. We would also like to acknowledge Intel for providing a
   research grant as a partial support for this work. Subramaniam
   Vincent did most of this work while a graduate research assistant at
   the USC Information Sciences Institute (ISI).

9.  References

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

10.  Authors' Addresses

      Lixia Zhang
      4531G Boelter Hall
      Los Angeles, CA  90095

      Phone:    310-825-2695

      Andreas Terzis
      4677 Boelter Hall
      Los Angeles, CA 90095

      Phone:    310-267-2190

      Subramaniam Vincent
      Cisco Systems
      275, E Tasman Drive, MS SJC04/2/1
      San Jose, CA 95134.
      Phone:    408 525 3474

      Bob Braden
      USC Information Sciences Institute
      4676 Admiralty Way
      Marina del Rey, CA 90292

      Phone:    310 822-1511