One minor inconvenience in writing about the worlds of video and data communications is the large amount of overlap between terminologies. Network means something completely different to a television broadcaster than it does to a datacomm engineer. Similarly, the terms multicasting and SAP that we will be discussing in this article have nothing to do with broadcasting multiple content streams on a DTV channel or the second audio program contained in broadcast programs. In this column, we’ll be discussing the terms multicasting and SAP as they apply in a datacomm environment.
Multicasting is a powerful tool for IP networking—it allows a single source to deliver programming to multiple destinations simultaneously. When this technology is used, the bulk of the work needed to generate multiple copies of the signal is performed inside the network, not in the sending or receiving devices. It is also more bandwidth efficient in the aggregate. Multicasting is one of the key techniques employed by many IPTV systems for distributing broadcast television programming.
(click thumbnail)Fig. 1: In unicasting, a video stream is sent to one recipient as a series of packets with a single IP destination address.
‘MULTIPLE UNICAST’
To understand multicasting, it is helpful to compare it to the process of unicasting. In unicasting, a video stream is sent to one recipient as a series of packets with a single IP destination address. Each packet in the stream flows over the entire path from the source to the destination over the IP network, as shown in Fig. 1.
In unicasting, if multiple recipients want the same video, the source must originate a separate unicast stream for each recipient. This is sometimes known as a “multiple unicast” and is often used on public networks such as the Internet. The network connection from the source must have enough bandwidth to accommodate all the copies of the streams that are to be delivered.
In multicasting, a single video stream originating from a source is delivered simultaneously to multiple destinations as shown in Fig. 2. The burden of creating streams for each user shifts from the video source to the network. Inside the network, a specialized protocol called IGMP (Internet Group Management Protocol) allows the network to recognize packets that are being multicast and sends them to multiple destinations. This is accomplished by giving the multicast packets special IP addresses that are reserved for multicasting. There is also a special protocol called SAP (Session Announcement Protocol) that informs user applications about the currently available multicasts on a particular network.
(click thumbnail)Fig. 2: In multicasting, a single video stream originating from a source is delivered simultaneously to multiple destinations.
It is important to note that IP multicasts operate in one direction only, just like an over-the-air broadcast. There is no built-in mechanism that funnels program requests or other information from endpoints and sends it back to the source. (Although there is a simple mechanism for gathering network performance statistics like counts of lost packets.) This means that any form of user interactivity between the endpoints and the video source must be handled by some other mechanism.
One advantage of multicasting is that it gives user applications the ability to control when they join and leave a multicast. This control is accomplished inside the network; the multicast source does not need to take any special actions when a user is added or removed from the multicast. In contrast, the router nearest the user is heavily involved in this process. In a moment, we’ll look at how this works.
JOINING AND LEAVING A MULTICAST
Before we begin talking about how users join and leave a multicast, let’s talk about why they need to do so. In a multicast, all users receive the same video stream at the same time. (Remember that only one stream is coming out of the multicast source.) So, when users want to watch a multicast program, they must join in at whatever point the program happens to be in. This is exactly analogous to broadcast television, through which users can watch only what is coming from the broadcaster’s antenna at any given time. Similarly, if a multicast program is already flowing through a network, users have the option of joining or leaving that multicast, but they cannot start it or stop it. In some implementations, multicast programs are sent in a continuous loop so that users who miss the beginning of a program can just keep watching to see what they missed.
When a router receives a request from a user application to join a multicast, it must do several things. First, the router must determine whether it is already processing the multicast for another user. If it is, then the router simply needs to make a copy of the multicast stream and send it to the requesting device. If it is not, the router must request the stream from a device that is closer to the multicast source. As soon as it begins to receive the stream, the router can send the stream to the user. Note that in this scenario, requests are made from router to router; this technique can be repeated as many times as necessary to find a complete route from the user’s location to the multicast source.
The key point to observe in this process is that each router must know whether or not it is already receiving the multicast stream before it requests a copy from elsewhere in the network. If it is already receiving the stream, it must make a copy for the new user. Only if it is not receiving the stream is it allowed to request it from another router closer to the source. This is the beauty of multicasting—only one copy of the multicast stream needs to be sent to each router on the network, and then only to the routers that have users (or other downstream routers) that are actually using the stream. This means that the bandwidth between routers is used very efficiently. In Fig. 2, this is illustrated by the stream replication occurring in Routers 2 and 4. A router that may be a gateway to a complex network hosting hundreds of users needs to receive only one copy of the multicast stream. Compare this to what would happen in a unicast environment: A gateway router supporting hundreds of users would need to have enough capacity to handle a full video stream for each user who wanted to watch.
So far, we have talked only about joining a multicast, but the process of leaving is also very important to maintain overall system efficiency. When a user application no longer wants to receive data from a multicast, it must send a leave message into the network. The router must stop sending the stream to the user device so that the device’s bandwidth can be freed up for other uses. Likewise, when a router no longer has any users (or other routers) that are requesting the stream, it must inform the network to stop sending the stream. In Fig. 2, if User 2 stopped receiving the stream, then Router 5 would no longer need to transport the stream, and Router 4 would no longer need to replicate the stream to two outputs. The leave process is important; without the ability for users to leave a multicast and have the network connections torn down, a multicast-enabled network could easily become choked with streams that nobody is watching.
TUNING IN
Multicast sources are responsible for periodically announcing the availability of their data stream to the network user community. This is accomplished by means of SAP packets that are distributed from the source. SAP packets contain information about the multicast streams that are available on a network, along with information that user applications need in order to connect to the multicast.
User devices for receiving multicasts listen for these announcements and gather information about the multicast programs that are available for the user to select. In concept, SAP is similar to the TV guide service that is broadcast on many cable television systems. Each of the programs that are currently playing is listed, along with the channel number for that program. Design of this software, which is often implemented in interactive program guides or media players, can be very important to the overall success of the multicasting system. Once the user has made a selection, the application can issue a request to join the multicast.
Note that the public Internet is not multicast enabled, so the technologies described in this column are available primarily on private networks, such as IPTV delivery systems. Interestingly, the Internet2 project that links a number of universities is multicast enabled.
CATEGORIES
