Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

RSVP Diagnostic Messages (RFC2745)

IP.com Disclosure Number: IPCOM000003342D
Original Publication Date: 2000-Jan-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 19 page(s) / 49K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Terzis: AUTHOR [+4]

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 6% of the total text.

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.

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