With revenues from data-only services only showing modest growth, both DSL and cable modem developers must develop new service offerings. Clearly, the delivery of video services over their broadband links is one alternative. Through video, carriers can offer a bundled service that can deliver a higher return on their existing broadband pipes.
The problem carriers and MSOs face, however, is making video work in an IP-enabled world. While the Internet protocol (IP) delivers a host of benefits to the data network, it provides as many challenges on the video side. The best effort and bursty nature of an IP network is not a friendly environment for sending video streams that required high quality-of-service (QoS) requirements, to say the least.
Fortunately, designers can solve IP streaming problems by implementing multicasting data streams using the Internet Group Management Protocol (IGMP). Below, we'll take a detailed look at IGMP multicast can be used to more efficiently stream video over broadband links.
How IGMP Works
IGMP works by using the IP stack to its extreme. The network stack is made up of different layers. Each layer is aware only of the layer directly above or below it. IGMP uses layer 2 and 3 in a slightly different way from usual unicast or broadcast streams.
Streams of data running on a network are made up of packets. Each packet header contains information on the packet's origination address and information on the packet's destination address.
In unicast streams, like file transfer, the origination address is obvious. This address is the IP address, in the layer 3 or IP header, and the origination media access control (MAC) address in layer 2 or the datalink layer.
Broadcast packets offer the same format as unicast packets. However, in the case of broadcast packets, the destination address is a broadcast address. Thus, the destination address would be 192.168.34.255 for an IP network that has 192.168.34.0 as its network address.
Multicast streams running on an IP network using IGMP must also adhere to the same basic format provided for unicast and broadcast streams. The difference, however, occurs in the destination address. IGMP-enabled multicast streams offer a class D destination address, such as 220.127.116.11-18.104.22.168, that does not match up with a specific PC or host on the network. On the contrary, this destination address matches up with the nearest layer 3 device, usually a router, on the network.
Once the multicast packet has arrived at the router, the router must decide to send the packet further along on its journey, or to drop it altogether. Remember that the class D IP address stated as the destination address for this packet is not a "real" host, but rather a group that must first be assembled in the nearest router and then be sent to the streaming host. If this is the first packet to arrive, then the router will start "building the group". If other hosts do not ask the routers to receive data for this group then the packets will be dropped by the router.
Give me a D for Requests
Requests for multicast data streams also use class D addresses. If a host is looking for a multicast group it will send a join message to 22.214.171.124. This reserved address is actually a message targeted at "all routers on this subnet." (There are many reserved addresses. More information is available at http://www.iana.org/assignments/multicast-addresses) Once a host has requested to join a specific group, the routers along the way will flood the request out, away from the requester. The group will eventually be found and the stream will then be flooded back along the same path that the request was received.
When the host that has been receiving the multicast decides that it no longer wants the stream, it will also send a message to a specific multicast address and the steam will be stopped. In practice, the host that is receiving the stream will be "pruned" from the various trees in the various routers and other layer 3 devices and the stream will stop being forwarded to that particular host.
Why IGMP is Useful
IGMP is useful because the request to join a group does not have to reach the router nearest to the streaming host. If a host has requested to join a group on the streaming route, the router closest to the streaming router will duplicate the packets and flood them out of the additional port that has requested to join the multicast group. In this way, even though the same number of hosts and requests can view the stream, the requests do not have to get back to the source and thus bandwidth is conserved over the entire network since the stream is only duplicated where it must be and not at the source.
If a system could only unicast on the network and not multicast, then each request would have to return to the source and each host would have to gets its own stream from the source. While this might be convenient in that it lets viewers tune in whenever they want from start to finish, it is not efficient and does not conserve network resources.
Implementing IGMP Multicast
OK, above we laid out the differences between IGMP multicast and other streaming approaches. Now, let's see how its implemented.
In IP multicasting, everyone who wants to get the content can receive it while the network itself manages the groups of receivers and clients. To implement IGMP multicastng, the network must be multicast aware of when and where the stream is duplicated.
When using IGMP multicast, a transmitter sends a stream and additional messages to the router closest to it or to the router that is located on the same subnet. Upon receiving the information, the router creates a group destination address (GDA) that is defined by a particular class D IP Address. (Class D IP addresses range from 126.96.36.199 to 188.8.131.52).
The router then checks to see if there are any clients for this group. If there are no clients, the router drops each packet that it receives from the transmitter without sending them anywhere (Figure 1).
Click here for Figure 1
Figure 1: In IGMP multicast, the router will drop packets if clients are not available.
If however, a clienteven if located on a remote networkwants to receive the stream, several things happen:
- First the receiver sends a dedicated multicast IP address (to which all multicast-enabled routers listen) to all routers on its subnet, stating that it wishes to join a multicast group.
- If the router on the subnet recognized the group, it begins to release packets to the requesting receiver. If the router, however, does not recognize the IGMP group, it sends out messages and begins to search for the group.
- By communicating with other routers, the router to which the original request was made, is able to find the multicast group. Routers communicate with each other through "routing" protocols such as MOSPF and DVMRP that have been adapted for IGMP use.
- When the multicast group is found, the other router along the way acts as the "source" router, either releasing or duplicating the stream.
The big benefit to the IGMP scheme is conserved bandwidth, which is highlighted in (Figure 2). As this figure illustrates, the remote receiver in network A is receiving a stream from the first router after the source router. The source router, which is IGMP version 2-enabled, duplicates the stream at the point where the stream needs to be duplicated and not at the source router, thus conserving bandwidth.
Click here for Figure 2
Figure 2: Diagram of how IGMP conserves bandwidth when sending video streams.
The IGMP version is use today is version 2. The major difference between IGMP version 1 and version 2 is in how clients are dropped from multicast groups. Version 1 specified that routers would continue to release the stream to the receiver for a number of minutes, even after the receiver had ceased listening to the stream. In IGMP version 1, receivers couldn't tell routers when they wanted to stop receiving the stream.
Version 2 lets receivers send a message telling the router to stop releasing packets if there are no other receivers present. In this way version 2 enhances bandwidth conservation over version 1.
Reliability and Quality Count
At the end of the day consumers don't really care how they receive their TV content. What they demand is reliability, availability and quality. Through the use of the IGMP multicast scheme, design engineers can build broadband equipment that meets these three criteria.
About the Authors
Uzi Yahav is the director of product management at Optibase. He holds a B.Sc. degree in electrical engineering from Ben Gurion University and an MBA from the University of Haifa. Uzi can be reached at email@example.com.
Arthur Rabinovitz is the Pre sales and Technical Support Manager for the Broadband TV business unit of Optibase LTD. Prior to joining Optibase, he served as a technical support manager for Phonet. Arthur can be reached at firstname.lastname@example.org.