Illustrated TCP/IP by Matthew G. Naugle Wiley Computer Publishing, John Wiley & Sons, Inc. ISBN: 0471196568   Pub Date: 11/01/98

Chapter 336
A Simple Example

An RSVP multicast example is given with the thought of real-time and nonreal-time. Multicast tends to be a bandwidth hog and as so, is the first example used.

Before a session can be created, it must be identified. This is accomplished using the DestAddress, ProtocolID and DestPort [optional], which must be propagated to all the senders and receivers. The following occurs during a session setup:

•  The receiver joins a multicast group using IGMP.

•  An RSVP-aware application starts to send Path messages to the multicast destination address, which will be received by all receivers in the multicast group.

•  A receiver sends a Resv message, specifying the desired flow descriptors. These will be received by the sender.

•  The sender starts sending the data packets.

Once the request has been accepted and processed, the resources are reserved, but they are in a soft state. A soft state is one that has an entry, but requires some maintenance to stay alive. If this maintenance is not applied, the entry will be deleted. This soft state maintains the reservation, and it is the Path and Resv messages that are used to maintain this soft state. This means the resources established can be modified dynamically as changes occur. This soft state is maintained by RSVP sending refresh messages along the path to indicate to the routers and nodes to keep the resources maintained. If these Refresh messages are not received, an RSVP resource times out and is deleted.

A Simple Example

This slide shows the flow of the actual reservation message from the RSVP App host.

A Simple Example (continued)