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