INTERNET-DRAFT                                               Lixia Zhang
Expires: May 1999                                            Andreas Terzis
<draft-ietf-rsvp-diagnostic-msgs-05.txt>
Expires: August 1999                                                UCLA
                                                     Subramaniam Vincent
                                                                   Cisco
<draft-ietf-rsvp-diagnostic-msgs-06.txt>                      Bob Braden
                                                                     ISI
                                                           November 1998
                                                     Subramaniam Vincent
                                                           Cisco Systems
                                                             Lixia Zhang
                                                                    UCLA
                                                           February 1999
                         RSVP Diagnostic Messages

                 <draft-ietf-rsvp-diagnostic-msgs-05.txt>

                 <draft-ietf-rsvp-diagnostic-msgs-06.txt>

Status of this Memo

This document is an Internet-Draft. Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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 progress."

The list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited. can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document specifies the RSVP diagnostic facility, which allows a
user to collect information about the RSVP state along the path.  This
specification describes the functionality, diagnostic message formats,
and processing rules.

1.  Introduction

   In

Changes

A summary of the basic RSVP protocol [RSVP], error messages are changes from the only means previous version (05) of this document
follows:

   - Added text in the Overview Section, to explain the role of the
     LAST-HOP node. Section 4.1 was also updated with rules for an end host DREQ
     processing at RSVP nodes downstream of the LAST-HOP.
   - The Next-Hop RSVP_HOP object was moved out of the DIAGNOSTIC
     object. It's new place is directly after the Session object and
     before the DIAGNOSTIC object. This was done to receive feedback regarding a failure simplify implementa-
     tion and to comply with object order in setting up
   either path state or reservation state.  An error message other RSVP messages. The IP
     address of this RSVP_HOP object now carries
   back only the information address of the
     interface from which the failed point, without any
   information about DREQ is sent. While the state at IP address is not
     (currently) used, this was done to conform with the use of RSVP_HOP
     objects in other hops before or after RSVP messages.
   - A minimum value for the
   failure. Path MTU field is defined.
   - In the absence description of failures, a host receives no feedback
   regarding the details of a reservation that has been put in place,
   such as whether, or where, or how, its own reservation request DIAG_SELECT object, new text is
   being merged with that of others.  Such missing added
     explaining where the information requested by object types can be
   highly desirable for debugging purpose, or for network
     collected from.
   - The text explaining the use of the Previous RSVP-Hop Router Address
     in the DIAG_RESPONSE object was changed. The previous version
     incorrectly said that this address was the address of the interface
     through which the DREQ would be forwarded. It is actually the
     address *to* which the DREQ message will be forwarded.
   - In the DIAGNOSTIC object, the LAST-HOP IP address was moved in
     front of the SENDER_TEMPLATE.
   - The H bit was removed. The existence of the ROUTE object signifies
     whether the DREQ should be returned hop-by-hop.
   - The "MTU too big" error was renamed to "packet too big" to reflect
     more closely the situation under which it is generated.
   - Section 4.1 (DREQ Packet Forwarding) was revamped
   - The Send_DREP() section was rewritten
   - Section 4.2 (DREP Forwarding) was updated.
   - Section 4.3 (MTU Selection and Adjustment) was updated.

1.  Introduction

In the basic RSVP protocol [RSVP], error messages are the only means for
an end host to receive feedback regarding a failure in setting up either
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, a host receives no feedback regarding the details of a reser-
vation that has been put in place, such as whether, or where, or how,
its own reservation request is being merged with that of others.  Such
missing information can be highly desirable for debugging purpose, or

for network resource management in general.

This document specifies the RSVP diagnostic facility, which is designed
to fill this information 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
of other RSVP control messages and produce no side-effects; that is,
they do not change any RSVP state at either nodes or hosts.  Similarly,
they provide not an error report but rather a collection of requested
RSVP state information.

The RSVP diagnostic facility was designed with the following goals:

   - To collect RSVP state information from every RSVP-capable hop along
     a path defined by path state, either for an existing reservation or
     before a reservation request is made.  More specifically, we want
     to be able to collect information about flowspecs, refresh timer
     values, and reservation merging at each hop along the path.

   - To collect the IP hop count across each non-RSVP cloud.

   - To avoid diagnostic packet implosion or explosion.

The following is specifically identified as a non-goal:

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

2.  Overview

The diagnostic facility introduces two new RSVP message types:
   Diagnostic Diagnos-
tic Request (DREQ) and Diagnostic Reply (DREP).  A DREQ message can be
originated by a client in a "requester" host, which may or may not be a
participant of the RSVP session to be diagnosed.  A client in the
requester host invokes the RSVP diagnostic facility by generating a DREQ
packet and sending it to towards the starting LAST-HOP node, which should be on the
RSVP path to be diagnosed. This DREQ packet specifies the RSVP session
and a sender host for that session.  The Starting from the LAST-HOP, the DREQ
packet collects information hop-by-hop as it is forwarded towards the
sender (see Figure 1), until it reaches the ending node.  Specifically,
each RSVP-capable hop adds to the DREQ message a response
(DIAG_RESPONSE) object containing local RSVP state for the specified
RSVP session.

When the DREQ packet reaches the ending node, the message type is

changed to Diagnostic Reply (DREP) and the completed response is sent to
the original requester node.  Partial responses may also be returned
before the DREQ packet reaches the ending node if an error condition
along the path, such as "no path state", prevents further forwarding of
the DREQ packet.  To avoid packet implosion or 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 seg-
ment 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 limit in the 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 or hop-by-hop along the reverse of the path taken by the
DREQ message to the LAST-HOP, and thence to the requester.  The 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.
Hop-by-hop return is accomplished using an optional ROUTE object, which
is built incrementally to contain a list of node addresses that the DREQ
packet has passed through.  The ROUTE object is then used in reverse as
a source route to forward the DREP hop-by-hop back to the LAST-HOP node.

A DREQ message always consists of a single unfragmented IP datagram.  On
the 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, the total length of a DREP message will exceed
the MTU size before reaching the sender; thus, the message has to be
fragmented.  Relying on IP fragmentation and reassembly, however, can be
problematic, especially when DREP messages are returned to the requester
hop-by-hop, in which case fragmentation/reassembly would have to be performed per-
formed at every hop.  To avoid such excessive overhead, we let the
requester define a default path MTU size that is carried in every DREQ
packet.  If an intermediate node finds that the default MTU size is bigger big-
ger than the MTU of the outgoing  link, incoming interface, it returns reduces the DREQ packet with default MTU
size to the
   corresponding error bit set. MTU size of the incoming interface. If an intermediate node
detects that a DREQ packet size has reached is larger than the default MTU size, it
returns to the requester (in either manner described above) a DREP fragment frag-
ment containing accumulated responses.  It then removes these responses
from the DREQ and continues to forward it.  The requester node can
reassemble the resulting DREP fragments into a complete DREP message.

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

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

3.  Diagnostic Packet Format

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

           +-----------------------------------+
           |        RSVP Common Header         |
           +-----------------------------------+
           |         Session object            |
           +-----------------------------------+
           |       DIAGNOSTIC object      Next-Hop RSVP_HOP object     |
           +-----------------------------------+
           |       DIAGNOSTIC object           |
           +-----------------------------------+
           |    (optional) DIAG_SELECT object  |
           +-----------------------------------+
           |    (optional) ROUTE object        |
           +-----------------------------------+
           | zero or more 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

The RSVP message common header is defined in [RSVP].  The following
   specific spe-
cific exceptions and extensions are needed for DREP and DREQ.

Type field: define:

          Type = 8: DREQ     Diagnostic Request

          Type = 9: DREP     Diagnostic Reply

RSVP length:

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

3.2.  Next-Hop RSVP_HOP Object

This RSVP_HOP object carries the LIH of the interface through which the
DREQ should be received at the upstream node. This object is updated
hop-by hop. It is used for the same reasons that a RESV message contains
an RSVP_HOP object: to distinguish logical interfaces and avoid problems

caused by routing asymmetries and non-RSVP clouds.

While the IP address is not really used during DREQ processing we
decided, for consistency with the use of RSVP_HOP object in other RSVP
messages, the IP address in the RSVP_HOP object to contain the address
of the interface through which a DREQ was sent.

3.3.  DIAGNOSTIC Object

A DIAGNOSTIC object contains the common diagnostic control information
in both DREQ and DREP messages.

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

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Max-RSVP-hops | RSVP-hop-count|         Reserved          |H|MF|            |MF|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Request ID                           |
 +---------------+---------------+---------------+---------------+
 |           Path MTU            |     Fragment offset Offset           |
 +---------------+---------------+---------------+---------------+
 |                                                               |
    |                     SENDER_TEMPLATE object                    |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         LAST-HOP Address                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                  Requester FILTER_SPEC                     SENDER_TEMPLATE object                    |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                       Next-Hop RSVP_HOP Object                 Requester FILTER_SPEC object                  |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here all IP addresses use the 4 byte IPv4 format, both explicitly in the
LAST-HOP Address and by using the IPv4 forms of the embedded FILTER_SPEC
and RSVP_HOP objects.

o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2

The format is the same, except all explicit and embedded IP addresses
are 16 byte IPv6 addresses.

The fields are as follows:

Max-RSVP-hops
   An octet specifying the maximum number of RSVP hops over which
      information infor-
   mation will be collected.  If an error condition in the middle of the
   path prevents the DREQ packet from reaching the specified ending
   node, the Max-RSVP-hops field may be used to perform an expanding-length expanding-
   length search to reach the point just before the problem.  If this
   value is 1, the LAST-HOP starting node and the ending node of the query will
   be the same.  If it is zero, there is no hop limit.

RSVP-hop-count

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

Fragment Offset

   Indicates where this DREP fragment belongs in the complete DREP
      message, mes-
   sage, measured in octets.  The first fragment has offset zero.
      Ignored in Frag-
   ment Offset is used to determine if a DREQ message.

   H flag

      Indicates how the reply should be returned.  When H = 0, DREP
      packets message containing zero
   DIAG_RESPONSE objects 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 node and thence to the requester processed at an RSVP capable node.

MF flag

   Flag means "more fragments".  It must be set to zero (0) in all DREQ
   messages.  It must be set to one (1) in all DREP packets that carry
   partial results and are returned by intermediate nodes due to the MTU
   limit.  When the DREQ message is converted to a DREP message in the
   ending node, the MF flag must remain zero.

Request ID

   Identifies an individual DREQ message and the corresponding DREP
      message mes-
   sage (or all the fragments of the reply message).

   One possible way to defining the Request ID would use 16 bits to
   specify the ID of the process making the query and 16 bits to
      distinguish distin-
   guish different queries from this process.

Path MTU

   Specifies a default MTU size in octets for DREP and DREQ messages.

   SENDER_TEMPLATE object
   This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and value should not be smaller than the port size of a sender for the session being diagnosed.  The "base" DREQ
   packet. A "base" DREQ packet is forwarded hop-by-hop towards this address.

   LAST-HOP Address

      The IP address of the LAST-HOP node.  The DREQ message starts
      collecting information at this node and proceeds toward the
      sender.

   Requester FILTER_SPEC Object

      This one that contains a Common Header, a
   Session object , a Next-Hop RSVP_HOP object, a DIAGNOSTIC object, an
   empty ROUTE object and a single default DIAG_RESPONSE (see below).
   The assumption made here is that a diagnostic packet of this size can
   always be forwarded without being fragmented.

LAST-HOP Address

   The IP address of the LAST-HOP node.  The DREQ message starts col-
   lecting information at this node and proceeds toward the sender.

SENDER_TEMPLATE object

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

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
      message(s) mes-
   sage(s) should be sent.

   Next-Hop RSVP_HOP Object

      An RSVP_HOP object carrying the IP address and LIH of the
      interface through which the DREQ will be received.  This object is
      updated hop-by hop.  It is used for the same reasons that a RESV
      message contains an RSVP_HOP object:  to distinguish logical
      interfaces and avoid problems caused by routing asymmetries.

3.3.

3.4.  DIAG_SELECT Object

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

A Diagnostic message may optionally contain a DIAG_SELECT object to
specify which specific RSVP objects should be reported in a
DIAG_RESPONSE object.  In the absence of a DIAG_SELECT object, the
DIAG_RESPONSE object added by the node will contain a default set of
object types (see DIAG_RESPONSE object below).

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

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    class      |     C-Type    |    class      |     C-Type    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                                                             //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    class      |     C-Type    |    class      |     C-Type    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When a DIAG_SELECT object is included in a DREQ message, each RSVP node
along the 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 zero is a 'wildcard', matching any C-Type associated
with the associated class.

Depending on the type of objects requested, a node can find the associ-
ated information in the path or reservation state stored for the session
described in the SESSION object. Specifically, information for the
RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC and FILTER_SPEC objects
can be extracted from the node's path state, while information for the
FLOWSPEC, CONFIRM, STYLE and SCOPE objects can be found in the node's
reservation state (if existent).

If the number of [Class, C-Type] pairs is odd, the last two octets of
the DIAG_SELECT object must be  zero.

3.4. A maximum DIAG_SELECT object is
one that contains the [Class, C-type] pairs for all the RSVP objects
that can be requested in a Diagnostic query.

3.5.  ROUTE Object

A diagnostic message may contain a ROUTE object, which is used to record
the route of the DREQ message and as a source route for returning the
DREP message(s) hop-by-hop.

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

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             reserved                          |    R-pointer  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                     RSVP Node List                            |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RSVP Node List

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

This message signifies how the object size.

   R-pointer reply should be returned.  If it does not
exist in the DREQ packet then DREP packets should be sent to the
response address directly. If it does exist, DREP packets must be
returned hop-by-hop along the reverse path to the LAST-HOP node and
thence to the requester node.

An empty ROUTE object is one that has an empty RSVP Node list and R-
pointer is equal to zero.

RSVP 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
   Used in DREP 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 message, RSVP Node List specifies all RSVP hops between the
LAST-HOP address specified in the DIAGNOSTIC object, and the last RSVP
node the DREQ message has visited.  In a DREP message, RSVP Node List
specifies all RSVP hops between the LAST-HOP and the node that returns
this DREP message.

3.5.

3.6.  DIAG_RESPONSE Object

Each RSVP node attaches DIAG_RESPONSE object to each DREQ message it
receives, before forwarding the message.  The DIAG_RESPONSE object
   contains con-
tains the state to be reported for this node.  It has a fixed-
   format 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              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   D-TTL       |M|R-err|  K    |      Timer value              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                  (optional) TUNNEL object                     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 //                       Response objects                      //
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.

This object has the same format, except that all explicit and embedded
IP addresses are IPv6 addresses.

The fields are as follows:

DREQ Arrival Time

   A 32-bit NTP timestamp specifying the time the DREQ message arrived
   at this node.  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 messages from the
   sender are expected to arrive, or 0 if unknown.

Outgoing Interface Address

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

Previous-RSVP-Hop Router Address

   Specifies the node IP address from which this node receives RSVP PATH
      messages mes-
   sages for this source, or 0 if unknown.  This is also the interface through
   to which the DREQ will be forwarded.

D-TTL

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

M flag

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

R-error

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

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

K

   The refresh timer multiple (defined in RSVP spec). [RSVP]).

Timer value

   The local refresh timer value in seconds.

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

A default DIAG_RESPONSE object is one containing the default list of
classes described above.

3.7.  TUNNEL Object

The optional TUNNEL object should be inserted when a DREQ message
arrives at an RSVP 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 map-
ping information allows the diagnosis client to conduct diagnosis over
the involved tunnel session, by invoking a separate Diagnostic query for
the corresponding Tunnel Session and Tunnel Sender.  Keep in mind, however, how-
ever, that multiple end-to-end sessions may all map to one pre-configured pre-config-
ured tunnel session that may have totally different parameter settings.

The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].

4.  Diagnostic Packet Forwarding Rules

4.1.  DREQ Packet Forwarding

DREQ messages are forwarded  hop-by-hop via unicast from the LAST-HOP
address to the Sender address, as specified in the DIAGNOSTIC object.
   At each hop,
If an RSVP capable node, other than the LAST-HOP node, receives a DREQ
message  that contains no DIAG_RESPONSE objects and has a zero Fragment
Offset, the node should forward the DREQ packet towards the LAST-HOP
without doing any of the processing mentioned below. The reason is that
such conditions apply only for nodes downstream of the LAST-HOP where no
information should be collected.

Processing begins when a DREQ message, DREQ_in, arrives at a node. The
following processing is performed before the DREQ
   message DREQ_in is forwarded to the next hop towards the sender: forwarded:

  1. Create a new DIAG_RESPONSE object. Compute the 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.
     Save the result in the D-TTL field of the DIAG_RESPONSE object.

  2. If no PATH state exists for Set the specified session, set R-error =
        0x01 DREQ Arrival Time and the Outgoing Interface Address in the
     DIAG_RESPONSE object.

     3.  If the path MTU value this node is too large, set "MTU too large" error
        bit, and change the MTU value to the MTU value of LAST-HOP, then the incoming
        interface for the sender.

     4. Attach Out-
     going Interface Address field in the DIAG_RESPONSE object to contains
     the end following value depending on the session being diagnosed.

        * If the session in question is a unicast session, then the Out-
          going Interface Address field contains the address of the DREQ message,
          interface LAST-HOP uses to send PATH messages and append response objects that describe data to the reservation in
        place
          receiver specified by the session address.

        * Otherwise, if it is a multicast session and there is at least
          one receiver for this session, LAST_HOP should use the address
          of one of local interfaces used to reach one of the receivers.

        * Otherwise Outgoing Interface Address should be zero.

     If no PATH state exists for the specified session.

        If session, set R-error =
     0x01 (No PATH state).

  3. Increment the DREQ RSVP-hop-count field in the DIAGNOSTIC message object
     by one.

  4. If the "No PATH state" bit is set, goto Send_DREP.

  5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in
     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
     DIAG_RESPONSE object will contain no FILTER_SPEC or FLOWSPEC or
     STYLE object. If neither PATH nor reservation state exists for the
     specified RSVP session, then no response objects will be appended
     to the DIAG_RESPONSE object.

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

  6. If the resulting value RSVP-hop-count is equal to Max-RSVP-hops, Max-RSVP-hops or if the
        current hop this node is the sender as identified by the Sender
        FILTER_SPEC object field in the DIAGNOSTIC object,
     sender, go to
        Send_DREP(), and then return.

     6. Send_DREP.

  7. If any error bit the Path MTU value is set, change larger than the type field in RSVP common
        header from DREQ to DREP, recompute MTU size of the checksum, and send incoming
     interface for the
        message back to sender being diagnosed, change the requester.  It is sent either hop-by-hop Path MTU value
     to the LAST-HOP address (if H = 1), or directly to MTU value of the requester
        address (if H = 0).

     7. incoming interface.

  8. If the resulting DREQ message size exceeds of DREQ_in plus the MTU limit, minus
        some margin to hold size of the address list new DIAG_RESPONSE
     object as described below,
        go to Send_DREP().

     8. If no error bit set, then if plus the H-bit size of an IP address ,if a ROUTE object exists, is set,
     larger than Path MTU set the "packet too big" (0x02) error bit in
     DIAG_RESPONSE, goto Send_DREP.

  9. If a ROUTE object exists, append the "Incoming Interface Address"
     to the end of the ROUTE object, increment R-Pointer by one, update
     the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object
     to be the Previous Hop from the Path State list of DIAG_RESPONSE object and update the message length
     field in the RSVP common header accordingly. Finally, forward the DREQ message
     DREQ_in to the next hop towards the
        source, sender, after recomputing the
     checksum.

   Send_DREP(): Return.

Send_DREP:

  1. If the H flag is off in size of DREQ_in plus the DIAGNOSTIC object, set
        target=response address given in size of the DREQ header, else set
        target = new DIAG_RESPONSE
     object plus the last size of an IP address ,if a ROUTE object exists, is
     larger than Path MTU set the "packet too big" (0x02) error bit in ROUTE.
     DIAG_RESPONSE, otherwise goto step 11.

  2. Make a copy of the DREQ message DREQ_in and change the type field in RSVP common
     header from DREQ to DREP. Trim all DIAG_RESPONSE objects from
     DREQ_in and adjust the Fragment Offset.

  3. If this host a ROUTE object is not present in the
        source, DREP message, decrement the R-
     pointer and set target address to the last address in the ROUTE
     object, otherwise set target address to the requester address. Set
     the MF flag on. bit, recompute the checksum and send the DREP message back
     to the target address.

  4. If the size of DREQ_in plus the size of DIAG_RESPONSE plus the size
     of an IP address ,if a ROUTE object exists, is so large such that (size smaller than Path
     MTU goto Step 9.

  5. Make a copy of DREQ_in and change the type field in RSVP common
     header from DREQ to DREP. If a ROUTE +  size
        of DIAG_RESPONSE object) > path MTU, then set object exists, replace the
     ROUTE object in DREQ_in with an empty ROUTE object. Turn on the "route
     "ROUTE object too big" (0x04) error bit, recompute bit in the checksum, send DIAG_RESPONSE.

  6. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-count
     is equal to Max-RSVP-hops or if this node is the sender, goto Step
     8.

  7. If a ROUTE object exists, append the "Incoming Interface Address"
     to the end of the ROUTE object, increment R-Pointer by one, update
     the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object
     to the list of DIAG_RESPONSE object, update the response message length
     field in the RSVP common header accordingly and go adjust the Fragment
     Offset. Finally, forward DREQ_in to 4, else the next hop towards the
     sender, after recomputing the checksum.

  8. Append the DIAG_RESPONSE object to the end of DREP. Set target
     address to the requester address. Turn on the MF bit. Update the
     packet length, recompute the checksum in the DREP message and send
     it towards the
        response message.

     3. target address. Return

  9. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-count
     is equal to Max-RSVP-hops or if this host node is not the source, then trim off all sender, goto Step
     11.

  10. If a ROUTE object exists, append the "Incoming Interface Address"
     to the end of the ROUTE object, increment R-Pointer by one, update
     the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE objects from object
     to the original DREQ message, adjust list of DIAG_RESPONSE object and update the
        "Fragment offset" value message length
     field in the RSVP common header accordingly,
        recompute accordingly. Finally, forward
     DREQ_in to the checksum, next hop towards the sender, after recomputing the
     checksum. Return.

  11. Append the DIAG_RESPONSE object to the end of DREQ_in. If a ROUTE
     object is present in the message, decrement the R-pointer and forward set
     target address to the last address in the ROUTE object, otherwise
     set target address to the modified requester address. Change the Type Field
     in the Common header from DREQ to DREP.Update the packet length,
     recompute the checksum in the DREP message and send it towards the source.

     4. Return. the
     target address. The MF bit in this case must be off.

4.2.  DREP Forwarding

When the H flag a ROUTE object is off, present, DREP 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 ROUTE
object. Otherwise, DREP messages are sent directly to the original
requester.

When a node receives a DREP message, it simply decreases R-pointer by
one (address length), recomputes the checksum and forwards the message
to the address pointed by R-pointer in the route list. If a node, other
than the LAST-HOP, receives a DREP packet where R-pointer is equal to
zero, it must send it directly to the requester.

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

4.3.  MTU Selection and Adjustment

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

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

   Whenever a DREQ message size approaches the specified MTU value, an
   intermediate RSVP node makes a copy of the message, converts it to a
   DREP message to send back, and then trims off the partial results
   from DREQ message and forwards it. It is possible
that the original Path MTU value is chosen larger than the actual MTU
value along some portion of the path being traced.  Therefore each
intermediate RSVP node must check the MTU value when processing a DREQ
message.  If the specified MTU value is larger than the MTU of the
incoming interface (that the DREQ message will be forwarded to), the
node

     (1) sets the R-error value,
     (2) changes the MTU value in the header to the smaller value.

Whenever a DREQ message size becomes larger than the Path MTU value, and
     (3) an
intermediate RSVP node makes a copy of the message, converts it to a
DREP message to send back, and then trims off the partial results from
the DREQ message message. If in this case also the DREQ cannot be forwarded
upstream due to a DREP large ROUTE object, the "ROUTE object too big" is set
and sends it back the ROUTE object is trimmed. As a result of the ROUTE object trim-
ming, DREP(s) will come hop-by-hop up to this node and will then immedi-
ately forwarded to the
        requester.

   In requester address.

Even if the rare case steps shown above are followed there are a few cases where some intermediate nodes do not check, or
   enforce upon, the MTU value carried in
fragmentation at the diagnostic messages, it IP layer will happen. For example, non-RSVP hops
with smaller MTUs may exist before LAST-HOP is
   possible that on reached, or if the way
response is sent directly back to requester (as opposed to hop by hop)
the requester, a DREP message may
   encounter take a link of smaller MTU.

   When this happens, the node follows steps (1) and (2) as outlined
   above, and trims off the extra part of the DREP message different route to fit in the
   smaller MTU of the link.  The trimming must be done at response
   object boundaries.  Such trimming of messages results in information
   loss.  However because the requester learns what is than the available MTU
   size, it can either ignore DREQ took

from the loss, or otherwise try again requester. Another case is when there exists a link with the MTU
smaller than the minimum Path MTU value. value defined in Section 3.2.

4.4.  Errors

If an error condition prevents a DREP message from being forwarded
   further, fur-
ther, the message is simply dropped.

If an error condition, such as lack of PATH state, prevents a DREQ
   message mes-
sage from being forwarded further, the node must change the current message mes-
sage 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 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 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 messages.  The querier may start by setting the H flag off, not includ-
ing a ROUTE object, which can give a faster response delivery and
reduced overhead at intermediate nodes.  However if no response is
received, the querier may resend the DREQ message with H
   flag turned on. a ROUTE object,
specifying that a hop-by-hop reply should be sent.

If the requester is a third party host and is separated from the
   LAST-HOP LAST-
HOP address by a firewall (either the requester is behind a firewall, or
the LAST-HOP is a node behind a firewall, or both), at this time we do
not know any other solution but to change the LAST-
   HOP LAST-HOP to a node that is
on the same side of the firewall as the requester.

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 val-
ues (when across lossy links), or frequent routing changes.

5.3.  Discovering Non-RSVP Clouds

The D-TTL field in each DIAG_RESPONSE object shows the number of routing
hops between adjacent RSVP 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 nodes by running run-
ning either unicast or multicast trace route.

5.4.  Discovering Reservation Merges

The flowspec value in a 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 DIAG_RESPONSE
objects differs, that is, a downstream node Rd has a smaller value than
its immediate upstream 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 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 diag-
nostic messages are more likely to be invoked when things are not
   working work-
ing 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, cor-
rectly, 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

Since this diagnosis facility was developed and added to RSVP after a
number of RSVP implementations were in place, it is possible, or even

likely, that when performing RSVP diagnosis, one may encounter one or
more RSVP-capable nodes that do not understand diagnostic messages and
drop them.  When this happens, the invoking client will get no response
from 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 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 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 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 ses-
sion 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. LAST-HOP.

The second problem is that traceroute provides the path from the
requester to the sender which, due to routing asymmetries, may be
   different dif-
ferent than the path traffic from the sender to the LAST_HOP LAST-HOP uses. There are
is (at least) one case where this asymmetry will cause the diagnosis to
fail. We present this case below.

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

                             Router A

                           Figure 2

Here the first hop upstream of the black hole is different on the
upstream path and the downstream path. Traceroute will indicate router A
as the previous hop (instead of router B which is the right one). Sending Send-
ing a DREQ to router A will result in A responding with R-
   error R-error 0x01 (No
PATH State). If the two paths converge again then the requester can use
the 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 problem-
atic scenarios described here.

6.  Comments on Diagnostic Client Implementation.

Following the design principle that nodes in the network should not hold
more than necessary state,  RSVP nodes are responsible only for
   forwarding forward-
ing Diagnostic messages and filling DIAG_RESPONSE objects.  Additional
diagnostic functionality should be carried out by the diagnostic
clients.  Furthermore, if the diagnostic function is invoked from a
third-party host, we should 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 DIAG_SELECT list, create a DREQ message and send to the
        LAST-HOP LAST-
     HOP RSVP node using raw IP message with protocol number 46 (RSVP).
     If the user specified that the response should be sent hop-by-hop
     include an empty ROUTE object to the DREQ message sent. Set the
     Path_MTU to the smaller of the user request and the MTU of the link
     through which the DREQ will be sent.

     The port of the UDP socket on which the Diagnostic Client is
     listening for replies should be included in the Requester FILTER_SPEC FIL-
     TER_SPEC object.

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

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

  3. Upon receiving a DREP 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. immedi-
     ately.

  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 frag-
     ments 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 increas-
     ing hop count as suggested in Section 5.6 in order to cross RSVP-capable RSVP-
     capable but diagnosis-incapable 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 Introduc-
tion Diagnostics messages produce no side-effects and therefore they

cannot change RSVP state in the 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 sug-
gested 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 pro-
vided 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

[RSVP] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997.

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

10.  Authors' Addresses

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

      Phone:    310-825-2695
      EMail:    lixia@cs.ucla.edu

   Andreas Terzis
   UCLA
   4677 Boelter Hall
   Los Angeles, CA 90095

   Phone:    310-267-2190
   Email:    terzis@cs.ucla.edu

   Bob Braden
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292
   Phone:    310 822-1511
   EMail:    braden@isi.edu

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

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

   Lixia Zhang
   UCLA
   4531G Boelter Hall
   Los Angeles, CA 90292  90095

   Phone:    310 822-1511    310-825-2695
   EMail:    braden@isi.edu    lixia@cs.ucla.edu