RSVP Diagnostic Messages
RFC 2745

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                          A. Terzis
Request for Comments: 2745                                          UCLA
Category: Standards Track                                      B. Braden
                                                                     ISI
                                                              S. Vincent
                                                           Cisco Systems
                                                                L. Zhang
                                                                    UCLA
                                                            January 2000

                        RSVP Diagnostic Messages

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

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

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 reservation 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 purposes, or for network resource
   management in general.

Terzis, et al.              Standards Track                     [Page 1]
RFC 2745                RSVP Diagnostic Messages            January 2000

   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 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 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 towards the 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.
   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.

Terzis, et al.              Standards Track                     [Page 2]
RFC 2745                RSVP Diagnostic Messages            January 2000

   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