The RSVP Signaling Process
Prior to any RSVP signaling, the sender and receiver might have identified each other through their application and agreed to start a session. A conferencing application, for example, might offer a directory service that Client A can use to check if Client B is online and available for a call. The steps before RSVP signaling might look something like this:
• When Client A calls Client B, Client A simply selects Client B's name in the directory list and clicks a button to initiale the call.
• Client B receives a ringing alarm, indicating that Client A is calling, and clicks a button to accept the call.
• The clients negotiate the type of conferencing they will do—for example, audio only or audio plus video.
• After negotiating such conferencing parameters, they know how much bandwidth their session needs.
• At this point, the clients have progressed far enough to move to the RSVP reservation process:
— They know witb whom they are having a session.
— They know that the other side is ready to accept data.
— They know the kind of data they will exchange.
— They know the QoS needed for the data of the session.
NOTE The preceding steps are a simplistic view of an H.323 conference initialization between Client A and Client B.
RSVP Signaling Details: A Video Streaming Example
Consider the signaling between two clients and a router network, and assume that Client A is going to send Client B a packetized video stream. In other words, RSVP will be used to establish a reservation for the packets flowing from Client A (sender) to Client B (receiver). The RSVP terms sender and receiver are used to generalize the discussion for this example.
Sending Path Messages
The following steps describe the signaling flow from sender to receiver (see Figure 5-3):
Figure 5-3 RSVP Path Messages Flow Downstream Along the Normal Routed Path a
Client A (sender)
- RSVP database (path messages)
|
To |
From |
Previous hop |
Bandwidth |
|
Client B |
Client A |
Client A |
10 Kbps |
To start the RSVP process, a sender sends special RSVP packets called Path messages to the network. In its Path messages, the sender includes information that describes, by using various QoS metrics, the traffic it intends to send.
The Path messages flow through the network along the normal routed path of data from the sender's IP address to the receiver's IP address. This routed path from the sender to the receiver is the downstream direction of a session. Because RSVP uses the normal routed path to send Path messages, it depends on routing protocols such as EIGRP. OSPF, and RIP (RSVP is not a routing protocol). Path messages are sourced by the sender and propagated through the network on a periodic basis.
If the receiver's address is an IP multicast group address, the Path message Hows down the normal multicast distribution tree as any normal packet sent to the group address.
• When an RS'VP-enabled router receives the Path message, it keeps a record of the information contained in the message, as well as some other information such as the previous hop from which the message came. After storing this information in its memory (an RSVP database), the router forwards the message to the next router along the path to the receiver.
Sending Resv Messages
The following steps describe the signaling flow from receiver to sender (see Figure 5-4): Figure 5-4 RSVP Resv Messages Propagate Upstream Along the Reverse Route of the Path Messages
Client A (sender)
RESV
RESV
RESV
RESV
Post a comment