The Internet, although lacking support for most of the features discussed on the previous sections, has been extensively used as a testbed for algorithms and protocols supporting multimedia multicasting. The network layer service uses IP (the Internet Protocol) which provides connectionless, datagram based, best effort delivery. Only unicast routing is provided using various algorithms, and no quality of service or resource reservation provisions are made. Reliability is provided if required at the transport layer using TCP (the Transmission Control Protocol), or it may be bypassed using UDP (the User Datagram Protocol). TCP provides error free byte streams and uses a windowing scheme for flow control and congestion control, with the window size adapting to the loss rate encountered, which is taken as an indication of congestion status[80]. It should be clear that these characteristics are not sufficient to support either real time continuous media or multicast, and some features, such as the congestion control scheme, may even get in the way. However, experimentation with multicast protocols and multimedia applications over the Internet has been extensive since the first audiocast of an Internet Engineering Task Force (IETF) meeting[81].
The initial work on IP multicast routing algorithms[38] and the definition of the host group model[32] initiated the current flurry of activity on the Internet, although some work has also been influenced by earlier research in broadcasting[43]. The extensions of the IP model to support multicasting are the provision of special (class D) multicast addresses and IGMP (the Internet Group Management Protocol). IGMP supports the host group model, with receivers explicitly joining the groups denoted by multicast addresses[82]. Multicast aware routers periodically multicast on a well known address membership queries on their LANs and gather replies from interested hosts in order to discover which groups have members present in their area.
Routing is performed by routers that learn the shortest paths to each group member using DVMRP (Distance Vector Multicast Routing Protocol) and simply aggregate these shortest paths into a tree. DVMRP is based on the Bellman-Ford algorithm, using the underlying unicast routing tables to find the shortest routes. Initially, it only performed truncated broadcast, i.e. it forwarded all packets everywhere, only dropping them if no group members were located in the lowest level leaf subnetworks[83]. Extended versions can prune unused parts of this tree thus conserving resources. Since only some machines have been extended to support multicast, the multicast aware routers that serve multicast aware subnetworks, directly exchange encapsulated packets among them. These are regular packets embedded in another packet that has the two multicast routers as source and destination. Thus, the encapsulated packets travel over virtual links, called tunnels, which are simple unicast routes that pass through non multicast capable routers without disturbing them. These multicast routers and the virtual links connecting them are called the MBone[60]. DVMRP and the tunnelling scheme suffer from inefficiencies and inflexibility, so an alternative routing protocol has been proposed: MOSPF (Multicast Open Shortest Path First). MOSPF uses Dijkstra's algorithm to create shortest path trees which do not require any pruning[37][84][85].
Since both DVMRP and MOSPF suffer from scalability problems, two new routing protocols have been proposed: CBT (Core Based Trees) builds a single tree for each group trying to conserve resources[47], based on predetermined fixed points. PIM (Protocol Independent Multicast) also supports single shared trees, but it allows shortest delay paths when receivers request them, and even traditional per source trees[48]. Both protocols were designed with an eye on scalability, interoperability with various underlying routing schemes and possible resource reservation protocols. Technically they are advances over DVMRP and MOSPF, especially PIM which tries to combine simple management with short delays, but they are more complex than their less flexible predecessors and thus more difficult to deploy in a large scale.
Two proposals for Internet resource reservations exist. ST-II (Stream Protocol II) is actually a new network layer protocol that supports both multicasting and resource negotiations based on a sender initiated approach[88], but it is more of a framework, with specific mechanisms expected to be provided externally. An implementation has been tested[87] and a new version designed[88]. A proposal closer to the ones presented here is RSVP (Resource ReSerVation Protocol) which acts as an overlay on routing protocols, supporting receiver initiated resource reservations over any available multicast routing scheme[17], essentially reversing the ST-II mechanism[89]. In addition, RSVP supports dynamic reservation modifications and network reconfigurations. Experimental implementations interoperating with other IP multicast extensions are currently tested.
Furthermore, a new transport protocol supporting continuous media has been developed: RTP (Real Time Protocol)[90] provides support for timing information, packet sequence numbers and option specification, without imposing any additional error control or sequencing mechanisms. An application can use this basic framework adapted to its requirements to add whatever mechanisms seem appropriate, such as error control based on loss detection using sequence numbers. A companion control protocol, RTCP (Real Time Control Protocol), can be used for gathering feedback from the receivers, again according to the application's needs. For example, an application can use RTP for transport and RTCP adapted for scalable feedback control, along with appropriate FEC and adaptation mechanisms[78].
Finally, another relevant protocol is SDP (Session Description Protocol)[91]. SDP provides a mechanism for applications to learn what streams are carried in the network, describing them in adequate detail so that anyone interested can launch the appropriate receiver applications. However, the need for session control protocols has not yet been adequately addressed in general, as it entails many application specific requirements that are difficult to generalise under one umbrella mechanism.