|
|
|
|
|
|
|
|
|
|
 
|
 
|
RSVP, RTP, and IP Multicast each helps support rich content and real-time multimedia over the Internet:
IP Multicast can be used by both RSVP and RTP. RTP can function independently of RSVP, although, in most cases, RSVP will provide improved quality to RTP connections as well.
Today, implementations of these protocols can be licensed for use in products or as prototypes for testing and evaluation. This paper describes these protocols and some of the goals that drove their design.
An RSVP session is identified by the IP destination address (unicast or multicast address), port number, and protocol (UDP or TCP). RSVP handles unicast and multicast sessions in much the same way. RSVP sessions are unidirectional and receiver-oriented; the reservation request is initiated by the receiver. When the RSVP session is a multicast session, RSVP defines how reservations are merged on network links where a single flow is destined to multiple receivers. Just as IP Multicast routing can eliminate the need to transmit multicast data more than once on a single network link, RSVP does not require the user to make distinct reservations for each receiver. RSVP realizes these efficiencies when installing reservations in routers by merging reservation requests along the multicast distribution tree to the source.
The RSVP reservation request is for a particular Quality of Service (QoS) for session data being received. QoS is defined by a flowspec for a given service model. Depending on the service model, the flowspec specifies both the rate and delay bounds for session data, or it specifies only the rate. The service models are defined by the IETF Integrated Services Working Group.
RSVP implementations generally implement one of two service models: Guaranteed Service or Controlled-Load Service. In the Guaranteed Service model, routers should forward packets strictly within the delay bounds specified by a receiver’s flowspec. A service level that strictly adjusts service to operate within a fixed bound may result in lower network utilization, or may result in a more complex implementation than an alternative model that simply gives RSVP session data priority over other traffic types. The Controlled-Load service model makes no guarantees regarding delay or throughput, but admits new RSVP sessions only up to the point that delay observed for any RSVP session’s packet approximates what would be observed on an unloaded system.
Controlled-Load service most closely resembles the model that Bay Networks and Cisco Systems demonstrated in their respective RSVP routers at the Interop+Networld RSVP Showcase in September, 1995. Bay and Cisco were joined in this RSVP interoperability demonstration by host software vendors Intel, Silicon Graphics, Starlight Networks, and Sun Microsystems. The demonstrations showed quality audio and video presentations on host computers when the audio and video data were sent as RSVP session data through a congested Internet. But when the data was sent without the benefit of an RSVP reservation, the continuity of audio and video was lost and the host presentations were unintelligible.
This performance was achieved, not by RSVP since it is just a signaling protocol for admitting or refusing reservations, but by scheduling mechanisms that were implemented in the Internet routers. Weighted Fair Queuing in Cisco Systems routers and Class-Based Queuing in Bay Networks routers (coupled with effective admission-control policies) ensured timely delivery of audio and video packets from RSVP sessions. The RSVP service built on the scheduling and admission control of the routers worked well on the small test bed of a half-dozen routers at the 1995 Interop+Networld show.
In order to provide robust, quality audio/video delivery, the RTP protocol specific fields contain time stamp and sequence information. These fields can be used by a destination PC to reconstruct the temporal properties of RTP packet streams. RTP has a companion protocol for monitoring and management called Real-Time Transport Control Protocol (RTCP), in which sender reports and receiver reports are sent periodically so that RTP host computers can use RTCP reports to get feedback on how well RTP packets are being delivered, end-to-end. Host computers may adjust transmissions to adapt to network conditions. Work is underway to define a management information base for RTP management data, much of which is collected through RTCP.
The interoperability of applications is facilitated by providing RTP profile and payload formats for a variety of audio and video encodings. Payload formats are defined for common encodings such as H.261 video and pulse code modulation (PCM) audio, G.711. Two new payload formats have been defined for low-bit rate audio, G.723, and video, H.263. G.723 can provide voice-quality audio at a rate as low as 4 Kbps. H.263 is not merely low-bit rate; it is a scalable bit rate encoding that can present video at rates below 20 Kbps, and increasingly improved video quality up to about 600 Kbps. RTP profiles specify how application programs should handle particular media to permit robust handling of H.263 video and yield superior video quality at very low rates. These new low-bit rate codecs (encoders/decoders of digital audio or video) are enabling the widespread use of audio/video applications in the workplace by reducing the need for high bandwidth applications.
![[RTP Streams Can Use RSVP Services to Reduce Loss and Delay]](pix/image2.gif)
Figure 1. (Conceptual) RTP Streams Can Use RSVP Services to Reduce Loss and Delay
RTP is designed to work with a variety of network protocols, but it is being used almost exclusively with User Datagram Protocol (UDP) and IP. RTP does not require RSVP or IP multicast services. RSVP reduces end-to-end latency and loss. Conceptually, RSVP provides an end-to-end pipe of improved service for audio/video streams transported using RTP (Figure 1).
When IP Multicast services are included, RTP can transport audio/video data to a large population of users on a worldwide scale. RTP is also designed to be scaled from low-end to high-end computer systems. When each RTP session is mapped to a single media, receivers may selectively receive some media, but not others, to accommodate differences in the capabilities of host computers. RTP has a goal of being an adaptable and scalable media transport protocol, well-suited to the heterogeneous nature of today’s private intranets and the public Internet as a whole.
Data from an IP Multicast session that is addressed to a community of users in a particular locale can be sent over a common network path to that location, eliminating the need for separate transmissions to each user. Data is not sent over paths where there are no users who have joined the IP Multicast session, and data can be routed so as to maximize the number of recipients that can be serviced by a single transmission (Figure 2).
![[An IP Multicast Flow Through Multicast Routers]](pix/image1.gif)
Figure 2. An IP Multicast Flow Through Multicast Routers
IP Multicast routing protocols form a distribution tree: the leaves of the tree are the computer hosts that have joined the IP Multicast group, and the interior branches of the tree are computer routers that forward the IP Multicast data to an adjacent router or host, or which split the transmission to multiple routers or hosts to widely distribute the data to all receivers. IP Multicast is designed with scalability so that a single transmission along a path can service hundreds or thousands of IP Multicast receivers.
The time is right for large-scale deployment of IP Multicast services on the Internet. Tens of millions of PCs have IP multicast software now that IGMP (Internet Group Multicast Protocol) is a standard feature of the Windows* operating system. IGMP is used on Internet host computers to manage multicast groups.
Most Internet router products feature a variety of multicast routing protocols that are applicable to different Internet environments. These router-based multicast implementations include DVMRP as described above, Multicast Open Shortest Path Routing (MOSPR), and Protocol Independent Multicast (PIM). MOSPR protocol is an IETF-proposed for routing multicast messages through the Internet or an intranet using a link-state database, as opposed to the distance-vector algorithm of DVMRP. PIM is Cisco Systems’ product that is designed to work across the autonomous systems that form today’s Internet. There are now products available for practically all Internet platforms that provide Internet Multicast services.
IP Multicast services is an enabling technology for broadcasting rich content such as video or audio to large quantities of receivers. By combining IP Multicast and scaleable video encoding (such as the ITU-T H.263 Recommendation) content providers should be able to reach data rates lower than 40Kbps on any particular network link. The possibility for a PC to send rich content simultaneously to a large community of users over a low-bandwidth connection, and with little load on the network opens new opportunity for network application and service providers. While such service is essential for group communications applications, we can expect that IP Multicast services will encourage a variety of novel applications for Internet PCs in the near future.
These emerging technologies have already gathered momentum. MCI, Intel, Sun, Microsoft, Bay Networks, Cisco, and several other application vendors already provide support for RSVP. In October 1996, sixteen leading Internet companies announced the formation of an industry group to promote and develop the usage of IP Multicast, including Intel, Microsoft, Netscape, Cisco and Sun Microsystems.
Application and content developers can inquiry about the availability of certain Intel implementations of RSVP, IP Multicast and RTP by contacting Intel (see link at the top of the page).
* Legal Information © 1998 Intel Corporation