Multimedia Networking

7.9.2 A Few Simple Examples

Home
Introduction
7.1 Multimedia Networking Applications
7.1.1 Examples of Multimedia Applications
7.1.2 Hurdles for Multimedia in Today's Internet
7.1.3 How Should the Internet Evolve to Support Multimedia Better?
7.1.4 Audio and Video Compression
7.2 Streamimg Stored Audio and Video
7.2.1 Accessing Audio and Video Through a Web Server
7.2.2 Sending Multimedia from a Streaming Server to a Helper Application
7.2.3 Real-Time Streaming Protocol (RTSP)
7.3 Making the Best of the Best-Effort Service: An Internet Phone Example
7.3.1 The Limitations of a Best-Effort Service
7.3.2 Removing Jitter at the Receiver for Audio
7.3.3 Recovering from Packet Loss
7.4 Protocols for Real-Time Interactive Applications
7.4.1 RTP
7.4.2 RTP Control Protocol (RTCP)
7.4.3 SIP
7.4.4 H.323
7.5 Distributing Multimedia: Content Distribution Networks
7.6 Beyond Best Effort
7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP
7.6.2 Scenario 2: A 1 Mbps Audio Application and a High-Priority FTP Transfer
7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer
7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link
7.7 Scheduling and Policing Mechanisms
7.7.1 Scheduling Mechanisms
7.7.2 Policing: The Leaky Bucket
7.8 Intergrated Services and Differentiated Services
7.8.1 Intserv
7.8.2 Diffserv
7.9 RSVP
7.9.1 The Essence of RSVP
7.9.2 A Few Simple Examples
A Few Simple Exammples
RSVP operates in a two-pass manner.  A transmitting source will advertise its content by sending RSVP path messages through a multicast tree, indicating the bandwidth required for the content, the soft-state timeout interval, and information about the upstream path  ot the sender.  Each receiver sends an RSVP reservation message upstream into the multicast tree.  This reservation message specifies the rate at which the receiver would llike to receive the data from the source.  When the reservation message reaches a router, the router adjusts its packet scheduler to accommodate the reservation.  It then sends a reservation upstream.  The amount of bandwidth reserved upstream from the router depends on the bandwidth reserved downstream.

kurose_320719_c07f36.gif

Call Admission
The amount of bandwidth on a link that a router reserves should not exceed the link's capacity.  Thus whenever a router receives a new reservation message, it must first determine if its downstream links on the multicast tree can accommodate the reservation.  This admission test is performed whenever a router receives a reservation message.  If the admission test fails, the router rejects the reservation an;d returns an error message to the appropriate receiver(s).
 
RSVP does not define the admission test, but it assumes that the routers perform such a test and that RSVP can interact with the test.