Skip to main content

Analysis on RSVP Regarding Multicast
draft-fu-rsvp-multicast-analysis-01

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Xiaoming Fu , Cornelia Kappler , Hannes Tschofenig
Last updated 2002-10-25
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

RSVP version 1 has been designed for optimum support multicast. However, in reality multicast is being used much less frequently than anticipated. Still, even for unicast (one sender, one receiver) full-fledged multicast-enabled RSVP signaling must be used. As pointed out in the NSIS requirement draft, multicast would not be necessarily required for an NSIS signaling protocol. This draft analyses ingredients of RSVP Version 1 which are affected by multicast, and derives how these ingredients may look like if multicast is not supported in the generic RSVP signaling protocol and adapt related functionalities accordingly - we call the resulting feature set 'RSVP Lite', a potentially more light-weight version of RSVP.

Authors

Xiaoming Fu
Cornelia Kappler
Hannes Tschofenig

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)