IP multicast

IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. It is often employed for streaming media applications on the Internet and private networks. The method is the IP-specific version of the general concept of multicast networking. It uses specially reserved multicast address blocks in IPv4 and IPv6. In IPv6, IP multicast addressing replaces broadcast addressing as implemented in IPv4.

History

IP multicast was first standardized in 1986.^[1] Its specifications have been revised to include group management^[2] and administratively scoped addresses.^[3]

Technical description

IP multicast is a technique for one-to-many and many-to-many real-time communication over an IP infrastructure in a network. It scales to a larger receiver population by not requiring prior knowledge of who or how many receivers there are. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. The nodes in the network (typically network switches and routers) take care of replicating the packet to reach multiple receivers such that messages are sent over each link of the network only once. The most common low-level protocol to use multicast addressing is User Datagram Protocol (UDP). By its nature, UDP is not reliable—messages may be lost or delivered out of order. Reliable multicast protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission on top of IP multicast.

Key concepts in IP multicast include an IP multicast group address,^[3] a multicast distribution tree and receiver driven tree creation.^[4]

An IP multicast group address is used by sources and the receivers to send and receive multicast messages. Sources use the group address as the IP destination address in their data packets. Receivers use this group address to inform the network that they are interested in receiving packets sent to that group. For example, if some content is associated with group 239.1.1.1, the source will send data packets destined to 239.1.1.1. Receivers for that content will inform the network that they are interested in receiving data packets sent to the group 239.1.1.1. The receiver joins 239.1.1.1. The protocol typically used by receivers to join a group is called the Internet Group Management Protocol (IGMP).

With routing protocols based on shared trees, once the receivers join a particular IP multicast group, a multicast distribution tree is constructed for that group. The protocol most widely used for this is Protocol Independent Multicast (PIM). It sets up multicast distribution trees such that data packets from senders to a multicast group reach all receivers which have joined the group. For example, all data packets sent to the group 239.1.1.1 are received by receivers who joined 239.1.1.1. There are variations of PIM implementations: Sparse Mode (SM), Dense Mode (DM), Source Specific Mode (SSM) and Bidirectional Mode (Bidir, or Sparse-Dense Mode, SDM). Of these, PIM-SM is the most widely deployed as of 2006^[update];^{[citation needed]} SSM and Bidir are simpler and scalable variations developed more recently and are gaining in popularity.^{[citation needed]}

IP multicast operation does not require an active source to know about the receivers of the group. The multicast tree construction is receiver driven and is initiated by network nodes which are close to the receivers. IP multicast scales to a large receiver population. The IP multicast model has been described by Internet architect Dave Clark as, "You put packets in at one end, and the network conspires to deliver them to anyone who asks."^{[citation needed]}

IP multicast creates state information per multicast distribution tree in the network. If a router is part of 1000 multicast trees, it has 1000 multicast routing and forwarding entries. On the other hand, a multicast router does not need to know how to reach all other multicast trees in the Internet. It only needs to know about multicast trees for which it has downstream receivers. This is key to scaling multicast-addressed services. It is very unlikely that core Internet routers would need to keep state for all multicast distribution trees,^{[citation needed]} they only need to keep state for trees with downstream membership. In contrast, a unicast router needs to know how to reach all other unicast addresses in the Internet, even if it does this using just a default route. For this reason, aggregation is key to scaling unicast routing. Also, there are core routers that carry routes in the hundreds of thousands because they contain the Internet routing table.

Addressing

See also: Multicast address

There are four forms of IP addressing, each with its own unique properties.

• Unicast: The most common concept of an IP address is in unicast addressing, available in both IPv4 and IPv6. It normally refers to a single sender or a single receiver, and can be used for both sending and receiving. Usually, a unicast address is associated with a single device or host, but it is not a one-to-one correspondence. Some individual PCs have several distinct unicast addresses, each for its own distinct purpose. Sending the same data to multiple unicast addresses requires the sender to send all the data many times over, once for each recipient.

• Broadcast: In IPv4 it is possible to send data to all possible destinations ("all-hosts broadcast"), which permits the sender to send the data only once, and all receivers receive a copy of it. In the IPv4 protocol, the address 255.255.255.255 is used for local broadcast. In addition, a directed (limited) broadcast can be made by combining the network prefix with a host suffix composed entirely of binary 1s. For example, the destination address used for a directed broadcast to devices on the 192.0.2.0/24 network is 192.0.2.255. IPv6 does not implement broadcast addressing and replaces it with multicast to the specially-defined all-nodes multicast address.

• Multicast: A multicast address is associated with a group of interested receivers. In IPv4, addresses 224.0.0.0 through 239.255.255.255 (the former Class D addresses) are designated as multicast addresses.^[3] IPv6 uses the address block with the prefix ff00::/8 for multicast applications. In either case, the sender sends a single datagram from its unicast address to the multicast group address and the intermediary routers take care of making copies and sending them to all receivers that have joined the corresponding multicast group.

• Anycast: Like broadcast and multicast, anycast is a one-to-many routing topology. However, the data stream is not transmitted to all receivers, just the one which the router decides is the "closest" in the network.^{[Note 1]} Anycast is useful for global load balancing and is commonly used in DNS communications.

Protocols and applications

IP multicast is widely deployed in enterprises, commercial stock exchanges, and multimedia content delivery networks. A common enterprise use of IP multicast is for IPTV applications such as distance learning and televised company meetings.^{[citation needed]}

Since multicast is a different transmission mode from unicast, only protocols designed for multicast can be sensibly used with multicast.

Most of the existing application protocols that use multicast run on top of the User Datagram Protocol (UDP). In many applications, the Real-time Transport Protocol (RTP) is used for framing of multimedia content over multicast; the Resource Reservation Protocol (RSVP) may be used for bandwidth reservation in a network supporting multicast distribution.

On the local network, multicast delivery is controlled by IGMP (on IPv4 network) and MLD (on IPv6 network); inside a routing domain, PIM or MOSPF are used; between routing domains, one uses inter-domain multicast routing protocols, such as MBGP.

A number of errors can happen if packets intended for unicast are accidentally sent to a multicast address; in particular, sending ICMP packets to a multicast address has been used in the context of DoS attacks as a way of achieving packet amplification.

IP multicast protocols

• Internet Group Management Protocol (IGMP)
• Protocol Independent Multicast (PIM)
• Distance Vector Multicast Routing Protocol (DVMRP)
• Multicast Open Shortest Path First (MOSPF)
• Multicast BGP (MBGP)
• Multicast Source Discovery Protocol (MSDP)
• Multicast Listener Discovery (MLD)
• GARP Multicast Registration Protocol (GMRP)
• Multicast DNS (mDNS)

Routing

Each host (and in fact each application on the host) that wants to be a receiving member of a multicast group (i.e. receive data corresponding to a particular multicast address) must use the Internet Group Management Protocol (IGMP) to join. Adjacent routers also use this protocol to communicate.

In unicast routing, each router examines the destination address of an incoming packet and looks up the destination in a table to determine which interface to use in order for that packet to get closer to its destination. The source address is irrelevant to the router.

However, in multicast routing, the source address (which is a simple unicast address) is used to determine data stream direction. The source of the multicast traffic is considered upstream. The router determines which downstream interfaces are destinations for this multicast group (the destination address), and sends the packet out through the appropriate interfaces. The term reverse path forwarding is used to describe this concept of routing packets away from the source, rather than towards the destination.

Layer 2 delivery

Unicast packets are delivered to a specific recipient on an Ethernet or IEEE 802.3 subnet by setting a specific layer 2 MAC address on the Ethernet packet address. Broadcast packets make use of a broadcast MAC address (FF:FF:FF:FF:FF:FF), which includes setting the broadcast/multicast bit in the address. The IANA owns the OUI MAC address 01:00:5e, therefore multicast packets are delivered by using the Ethernet MAC address range 01:00:5e:00:00:00 - 01:00:5e:7f:ff:ff. This is 23 bits of available address space. The first octet (01) includes the broadcast/multicast bit. The lower 23 bits of the 28-bit multicast IP address are mapped into the 23 bits of available Ethernet address space. This means that there is ambiguity in delivering packets. If two hosts on the same subnet each subscribe to a different multicast group whose address differs only in the first 5 bits, Ethernet packets for both multicast groups will be delivered to both hosts, requiring the network software in the hosts to discard the unrequired packets.

For IPv6 Multicast addresses, the Ethernet MAC is derived by the four low-order octets OR'ed with the MAC 33:33:00:00:00:00, so for example the IPv6 address FF02:DEAD:BEEF::1:3 would map to the Ethernet MAC address 33:33:00:01:00:03.^[5]

Switches that do not understand multicast addresses broadcast traffic sent to a multicast group to all the members of a LAN; in this case the system's network card (or operating system) has to filter the packets sent to multicast groups they are not subscribed to.

There are switches that listen to IGMP traffic and maintain a state table of which network systems are subscribed to a given multicast group. This table is then used to forward traffic destined to a given group only to a limited set of hosts (ports). This is done through the use of IGMP snooping.

Additionally, some switches with layer 3 capabilities can act as an IGMP querier.^[6] In networks where there is no router present to act as a multicast router a switch with IGMP snooping enabled can be used to generate the needed IGMP messages to get users to subscribe to multicast traffic.

Reliable multicast

Multicast, by its very nature, is not a connection-oriented mechanism, so protocols such as TCP, which allows for retransmission of missing packets, are not appropriate. For applications such as streaming audio and video, the occasional dropped packet is not a problem. But for distribution of critical data, a mechanism is required for requesting retransmission.

One such scheme, proposed by Cisco, is PGM (originally Pretty Good Multicasting, but changed for trademark reasons to Pragmatic General Multicast)^{[citation needed]}, documented in RFC 3208. In this scheme, multicast packets have sequence numbers and when a packet is missed a recipient can request that the packet be re-multicast with other members of the Multicast group ignoring the replacement data if not needed. An expanded version, PGM-CC, has attempted to make IP Multicasting more "TCP friendly" by stepping the entire group down to the bandwidth available by the worst receiver.

Two other schemes documented by the Internet Engineering Task Force (IETF) are NACK-Oriented Reliable Multicast (NORM), documented in RFC 3940 and RFC 5401, and File Delivery over Unidirectional Transport (FLUTE), documented in RFC 3926. Open-source, in addition to proprietary, implementations exist for these. Other such protocols exist, such as Scalable Reliable Multicast, and are defined by a variety of sources. Such protocols vary in the means of error detection, the mechanisms used in error recovery, the scalability of such recovery and the underlying ideas involved in what it means to be reliable. A list of reliable multicast protocols from the ACM SIGCOMM Multicast Workshop, August 27, 1996, documents a number of approaches to the problem.

Independent groups like the Internet Protocol Multicast Standards Initiative (IPMSI) have claimed that the lack of a truly scalable Secure Reliable IP Multicast protocol like the proposed Secure Multicast for Advanced Repeating of Television (SMART) have hampered the adoption of IP Multicast in inter-domain routing. The lack of a widely adopted system that has AES level security and scalable reliability have kept mass media transmissions of sporting events (like the Super Bowl) and/or breaking news events from being transmitted on the Public Internet.^{[citation needed]}

Reliable IP Multicasting protocols, such as PGM and SMART, are experimental; the only standards-track protocol is NORM (the standards-track revision of RFC 3941 is specified in RFC 5401, the standards-track revision of RFC 3940 is specified in RFC 5740).

Wireless (802.11) considerations

An 802.11 wireless network will handle multicast traffic differently, depending on the configuration of Delivery Traffic Indication Message (DTIM), and beacon interval settings. If no stations within the basic service set are in power save mode, multicast packets are sent immediately when they arrive. If there are one or more stations in power save mode, access points then only delivers multicast traffic after each DTIM interval, and transmit at one of the supported rates in the basic rate set. In most retail wireless access points/routers, this interval is 102.4 ms (DTIM=1 (beacon interval)) and the transmit rate is either 1 Mbps or 6 Mbps, depending on the operating band and protection mode. As a result, the DTIM and beacon interval settings should be adjusted for optimum performance when implementing multicast in wireless networks.^[7]

Implementations

Pay-TV operators and some educational institutions with significant on-campus student housing have deployed IP multicast to deliver one-way streaming media such as high-speed video to large groups of receivers. Additionally, there have been some uses of audio and video conferencing using multicast technologies. These are far less prevalent and are most often relegated to research and education institutions, which often have a greater degree of network capacity to handle the demands.^{[citation needed]} Some technical conferences and meetings are transmitted using IP multicast. Until recently^[when?] many of the sessions at the IETF meetings were delivered using multicast.^{[citation needed]}

Another use of multicast within campus and commercial networks is for file distribution, particularly to deliver operating system images and updates to remote hosts. The key advantage of multicast boot images over unicasting boot images is significantly lower network bandwidth usage.

IP multicast has also seen deployment within the financial sector for applications such as stock tickers and hoot-n-holler systems.^[8]

While IP multicast has seen some success in each of these areas, IP multicast is not widely deployed and is generally not available as a service for the average end user.^{[citation needed]} There are at least two primary factors for the lack of widespread deployment, both somewhat related to the other. On the one hand, forwarding multicast traffic, particularly for two-way communication, requires a great deal of protocol complexity.^{[citation needed]} On the other hand, there are a number of additional operational concerns in being able to run a multicast network successfully, largely stemming from the complexity of a widely-deployed implementation, not the least of which is the enabling of additional avenues of failure, particularly from denial-of-service attacks.^{[original research?]} Many of these issues are covered in further detail below.

RFC 3170 (IP Multicast Applications: Challenges & Solutions) provides an overview of deployment issues.

History and milestones

IP multicasting was first developed by Steve Deering while at Stanford University for which he received the IEEE Internet Award ^[9]

The MBONE was a long-running experimental approach to enabling multicast between sites through the use of tunnels. While the MBONE is no longer operational, there is renewed interest in tunneling multicast traffic once again in order to make the service available to a wide array of end users.^{[citation needed]}

Commercial deployment

Starting in 2005,^[10] the BBC has begun encouraging UK-based Internet service providers to adopt multicast-addressable services in their networks by providing BBC Radio at higher quality^[11] than is available via their unicast-addressed services. This has also been supported by a variety of commercial radio networks, including GCAP, EMAP, and Virgin Radio.^{[citation needed]}

The German public-service broadcasters ARD^[12] and ZDF and the Franco-German network Arte offer their TV program multicasted on several networks. Austrian Internet service provider Telekom Austria offers its Digital Subscriber Line (DSL) customers a TV set-top box that uses multicast addressing in receiving TV and radio broadcasts. In Germany, T-Home, a brand of Deutsche Telekom, offers a similar service.

IP multicast software

• Media Tools Repository - a collection of tools for the MBone
• VideoLAN - a free software multicasted video streaming application
• Xorp - a free software router with multicast (IGMP, PIM) support
• Smcroute - a simple tool to manipulate multicast routes on the Linux kernel
• SSM-ping - tool to test multicast connectivity
• Host implementation of IGMPv3 on FreeBSD
• IP multicast software from Xerox
• Java Reliable Multicast Service
• PIM implementation - an implementation of the PIM protocol, now obsolete
• qpimd - PIM Daemon for Quagga - PIM module for the Quagga Routing Suite
• GateD - UNIX implementation of routing protocols, including multicast
• PIM-DM code for GateD
• NORM - Nack-Oriented Reliable Multicast from the U.S. Naval Research Laboratory, with an open source C++ implementation
• ecmh (Easy Cast du Multi Hub) - IPv6 Multicast Daemon, allows IPv6 multicast to be used without the need for PIM.
• MRD6 - Ipv6 multicast routing daemon
• UFTP - Encrypted UDP based FTP with multicast
• GStreamer - a free software multimedia framework that supports multicast video streaming

See also

• Dense multicast
• Sparse multicast
• Source-specific multicast
• Core-based trees
• IGMP snooping
• Multicast address
• Multicast

Notes

1. ^ Anycast implementations typically operate using the shortest-path metric of BGP routing and not take into account congestion or other attributes of the path.

References

1. ^ RFC 998
2. ^ RFC 2236
3. ^ ^{a b c} RFC 3171
4. ^ RFC 1112
5. ^ RFC 2464
6. ^ eg. Cisco SLM 2008
7. ^ "802.11 Multicasting". http://www.wireless-nets.com/resources/tutorials/802.11_multicasting.html. Retrieved 2008-10-08. 
8. ^ Speakerbus, a IP Hoot-n-Holler Provider
9. ^ IEEE Internet Award recipients
10. ^ http://news.bbc.co.uk/sport1/hi/rugby_union/4290396.stm BBC
11. ^ BBC multicast services
12. ^ ARD IPTV

External links

• Multicast over TCP/IP HOWTO, describes Multicast in the Linux kernel, although some sections (specially multicast programs) is outdated and does not cover recent software.
• IETF Reliable Multicast Transport (rmt) Working Group
• IETF Multicast & Anycast Group Membership (magma) Working Group
• IETF Protocol Independent Multicast (pim) Working Group
• IETF Source-Specific Multicast (ssm) Working Group
• IETF Multicast Security (msec) Working Group
• Multicast IP details at sockets.com
• IP-Ethernet multicast tutorial.
• Good illustrative video about IP Multicast at Cisco.
• Overview of Reliable Multicast methods, ACM SIGCOMM Multicast Workshop, August 27, 1996
• A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing (the paper defining Scalable Reliable Multicast)
• "Frequently Asked Questions (FAQ) File for Multicasting". Multicast Tech. http://www.multicasttech.com/faq/. Retrieved 2010-11-18. 
• Multicast over TCP/IP HOWTO
• An Analysis of Multicast Methods