RSVP Diagnostic Messages (RFC2745)
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
A. Terzis: AUTHOR [+4]
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.
Network Working Group A. Terzis
Request for Comments: 2745 UCLA
Category: Standards Track B. Braden
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 (C) The Internet Society (2000). All Rights Reserved.
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.
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.
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