2.10 Host Model

2.10 Host Model

Before a session can be created, the session identification
(DestAddress, ProtocolId [, DstPort]) must be assigned and
communicated to all the senders and receivers by some out-of-band
mechanism. When an RSVP session is being set up, the following
events happen at the end systems.

H1

A receiver joins the multicast group specified by
DestAddress, using IGMP.

Suppose that a new sender starts sending data (H6) but there
are no multicast routes because no receivers have joined the
group (H1). Then the data will be dropped at some router
node (which node depends upon the routing protocol) until
receivers(s) appear.

Suppose that a new sender starts sending Path messages (H2)
and data (H6) simultaneously, and there are receivers but no
Resv messages have reached the sender yet (e.g., because its
Path messages have not yet propagated to the receiver(s)).
Then the initial data may arrive at receivers without the
desired QoS. The sender could mitigate this problem by
awaiting arrival of the first Resv message (H5); however,
receivers that are farther away may not have reservations in
place yet.

If a receiver starts sending Resv messages (H4) before
receiving any Path messages (H3), RSVP will return error
messages to the receiver.

The receiver may simply choose to ignore such error messages,
or it may avoid them by waiting for Path messages before
sending Resv messages.

A specific application program interface (API) for RSVP is not
defined in this protocol spec, as it may be host system dependent.
However, Section 3.11.1 discusses the general requirements and
outlines a generic interface.