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: 2019-Feb-10
Document File: 23 page(s) / 31K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Terzis: AUTHOR [+3]

Related Documents

10.17487/RFC2745: DOI

Abstract

This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 7% 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.

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

Processing...
Loading...