The method to
address changes in membership of multicast groups . In order for a
receiver to receive a multicast transmission, it must first become a
member of a multicast group. A multicast tree is then built with all
members of the group in the tree.
- Allow applications to specify aggregate resource needs
In some applications like audio
conferencing there is no need of allocation to all the senders because
at a time only one sender is active, so the
requirement is aggregate rather than per flow basis.
Making efficient
use of limited bandwidth or lowering bandwidth charges. A receiver
should decide which packets are sent over its reserved resources. So, a
receiver, may change the source of packets at any time, without having
to request a new reservation. This eliminates any risk of losing the
reserved resources. Some applications like video conferencing switch
the channels during the communication, so this should be taken care of.
Here also there is no need to reserve resources to all the senders as
only one channel is active at a time.
- Adapt to the changes in the network routes
Suppose a route is chosen and the
resources are reserved to the receivers along the
path, now if a particular router goes down, then the network should
choose another path and again start the resource allocation process.
The
number of control messages must not grow automatically at the same rate
as the group size. Rather, there should be parameters that can be
adjusted to control the amount of overhead that is created. An example
would be a message to refresh a reservation. There should not have to
be one message from every transmitting source.
It should be a separate modular
unit from other multicast architectural capabilties. RSVP should
work on networks that implement different routing algorithms.
Furthermore any further improvement in the underlying network should
not change the signalling protocol.