IP multicast is a method of sending Internet Protocol (IP) datagrams to a group of interested receivers in a single transmission. It is the IP-specific form of multicast and is used for streaming media and other network applications. It uses specially reserved multicast address blocks in IPv4 and IPv6.
IP multicast is described in RFC1112. IP multicast was first standardized in 1986.[1] Its specifications have been augmented in RFC4604 to include group management and in RFC5771 to include administratively scoped addresses.
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 requiring neither prior knowledge of a receiver's identity nor prior knowledge of the number of receivers. 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 transport layer 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,[2] a multicast distribution tree and receiver-driven tree creation.[3]
An IP multicast group address is used by sources and 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 joins239.1.1.1. The protocol typically used by receivers to join a group is called the Internet Group Management Protocol (IGMP).[4]
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. There are variations of PIM implementations: Sparse Mode (SM), Dense Mode (DM), source-specific multicast (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 that 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."[5]
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. 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.
Routing
Each host that wants to be a receiving member of a multicast group (i.e. receive data corresponding to a particular multicast address) must use 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.
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.
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.
The following are some common delivery and routing protocols used for multicast distribution:
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 the broadcast MAC address FF:FF:FF:FF:FF:FF.
IPv4 multicast packets are delivered using the Ethernet MAC address range 01:00:5E:00:00:00 through 01:00:5E:7F:FF:FF (with an OUI owned by the IANA). This range has 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.[6]
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.[7] If a switch does not understand multicast addresses then it will flood that traffic 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 process of listening to the IGMP traffic is called IGMP snooping.
Additionally, some switches with layer 3 capabilities can act as an IGMP querier. In networks where there is no router present to act as a multicast router, a switch with IGMP snooping querier enabled can be used to generate the needed IGMP messages to get users to subscribe to multicast traffic.
Wireless considerations
802.11 wireless networking uses the same range of MAC addresses as wired Ethernet to map IP multicast addresses. However, an 802.11 wireless network handles 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 deliver multicast traffic after each DTIM interval and transmit at one of the supported rates in the basic rate set. In most wireless access points, default configuration for this interval is either 102.4ms[citation needed] (Beacon interval = 100ms, DTIM = 1) or 204.8ms[citation needed] (Beacon interval = 100ms, DTIM = 2) and the transmit rate is either 1 Mbit/s or 6 Mbit/s[citation needed], depending on the operating band and protection mode. The DTIM and beacon interval settings can be adjusted to improve multicast performance in wireless networks.[8]
Unlike Ethernet, most traffic in 802.11 is sent reliably using ACKs and NACKs so that radio interference doesn't cause unbearably high packet loss. However, multicast packets are sent once and are not acknowledged, so they are subject to much higher loss rates. There are various methods for coping with this, such as choosing to unicast multicast data repeatedly to each client, or requesting ACKs from each client.[9] Some methods require only modification on the access point, and are supported in some enterprise-class devices, while other improvements would require modifications to clients, and therefore have not seen widespread adoption.
Secure multicast
IP multicast is an internet communication method where a single data packet can be transmitted from a sender and replicated to a set of receivers. The replication techniques are somewhat dependent upon the media used to transmit the data. Transmission of multicast on an inherent broadcast media such as Ethernet or a satellite link automatically allows the data packet to be received by all the receivers directly attached to the media. In contrast, transmission of multicast on media that is point-to-point or point-to-multipoint requires the packet to be replicated for each link. The replication process should occur in an optimal manner where a distribution tree is built within the network. The packet can be replicated at each of the branches in the tree. This mitigates the requirement for the sender to replicate the packet once for each recipient.
The use of IPsec as a communication link requires a point-to-point connection establishment. Usually, the security is required from sender to receiver which implies the sender must replicate the packet on each of the secure connections - one for each receiver. As the number of receivers grows, the sender must scale by replicating the packet to each of the receivers. The processing load placed on the sender can be high which limits the scalability of the sender. A new method was required to securely transmit multicast and this was referred to as Secure Multicast or Multicast Security.
The Internet Engineering Task Force (IETF) created a new Internet Protocol (IP) to securely transmit multicast traffic across a packet network. The protocol definition was developed in the Multicast Security Workgroup and led to several Request for Comments (RFC) that are now used as standards for securing IP multicast traffic. The protocol allowed a sender to encrypt the multicast packet and forward it into the packet network on the optimal distribution tree. The packet may be replicated at the optimal locations in the network and delivered to all the receivers. The receivers are capable of decrypting the packet and forwarding the packet in the secure network environment. The sender of a multicast packet does not know the potential receivers; therefore, the creation of pair-wise encryption keys (one for each receiver) is impossible. The sender must encrypt packets using a shared key that all the legitimate receivers use to decrypt the packets. The security of the system is based on the ability to control the distribution of the keys only to those legitimate receivers. For this, the IETF created the Group Domain of Interpretation (GDOI) protocol defined in RFC 6407. The protocol allows the sender and receiver to join a key server where policies and keys are encrypted and distributed to the members of the secure multicast group. The key server can authenticate and authorize senders and receivers into a specific group where the shared key is used to encrypt and decrypt traffic between members of the group.
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: the standards-track protocol NACK-Oriented Reliable Multicast (NORM), documented in RFC 5740 and RFC 5401, and the protocol File Delivery over Unidirectional Transport (FLUTE), documented in RFC 6726. 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).
Multicast-based protocols
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. Multicast DNS (mDNS) can be used to resolve domain or host names without a dedicated DNS server by using multicast.
Deployment
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 live television distribution and televised company meetings.[citation needed]
In the hospitality industry IP multicast has become common for IPTV distribution in hotels, and in the retail sector IP multicast is now widely used for TV distribution and video advertising applications.
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.
The large state requirements in routers make applications using a large number of trees unable to work while using IP multicast. Take presence information as an example where each person needs to keep at least one tree of its subscribers, if not several. No mechanism has yet been demonstrated that would allow the IP multicast model to scale to millions of senders and millions of multicast groups and, thus, it is not yet possible to make fully general multicast applications practical.[citation needed]
RFC 3170 (IP Multicast Applications: Challenges & Solutions) provides an overview of deployment issues.
History
Development
IP multicasting was first developed by Steve Deering while at Stanford University for which he received the IEEE Internet Award.[10]
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.
CastGate
CastGate was an attempt from the ETRO-TELE research group at the Vrije Universiteit Brussel to adopt IP multicast on the Internet.[11]
Although multicast would have allowed an Internet user to receive rich media and other content without placing a high burden on the net, it was still unavailable to most Internet users. The CastGate project tried to fix this by allowing end users to connect through an automatically configured IP tunnel over networks that did not natively support IP multicast. The idea was that if more users had multicast capability, more content providers would see the benefit of streaming content over multicast. The hope was if enough content providers and users used this service, then more Internet service providers would enable IP multicast natively to their customers.[11]
CastGate supplied a software client for both Microsoft Windows and Linux to connect to the CastGate tunnel network. It also supplied tools to add tunnel servers and tools to receive Session Announcement Protocol announcements from the multicast network with video and audio streams.[12]
The project maintained a web site through 2007.[12]
Commercial deployment
Starting in 2005,[13] the BBC began encouraging UK-based Internet service providers to adopt multicast-addressable services in their networks by providing BBC Radio at higher quality[14] than is available via their unicast-addressed services. This has also been supported by a variety of commercial radio networks, including BBC, GCap Media, EMAP and Virgin Radio.[15]
The German public-service broadcasters ARD[16] 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.
NORM, NRL, archived from the original on 2008-10-07, retrieved 2008-03-26 – Nack-Oriented Reliable Multicast from the U.S. Naval Research Laboratory, with an open source C++ implementation
ecmh (Easy Cast du Multi Hub), Unfix – IPv6 Multicast Daemon, allows IPv6 multicast to be used without the need for PIM
An Internet Protocol address is a numerical label such as 192.0.2.1 that is assigned to a device connected to a computer network that uses the Internet Protocol for communication. IP addresses serve two main functions: network interface identification, and location addressing.
Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.
The Internet Protocol (IP) is the network layer communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet.
In computer networking, multicast is a type of group communication where data transmission is addressed to a group of destination computers simultaneously. Multicast can be one-to-many or many-to-many distribution. Multicast differs from physical layer point-to-multipoint communication.
A multicast address is a logical identifier for a group of hosts in a computer network that are available to process datagrams or frames intended to be multicast for a designated network service. Multicast addressing can be used in the link layer, such as Ethernet multicast, and at the internet layer for Internet Protocol Version 4 (IPv4) or Version 6 (IPv6) multicast.
The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IPv4 networks to establish multicast group memberships. IGMP is an integral part of IP multicast and allows the network to direct multicast transmissions only to hosts that have requested them.
Anycast is a network addressing and routing methodology in which a single IP address is shared by devices in multiple locations. Routers direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast routing is widely used by content delivery networks such as web and name servers, to bring their content closer to end users.
A broadcast address is a network address used to transmit to all devices connected to a multiple-access communications network. A message sent to a broadcast address may be received by all network-attached hosts.
The Resource Reservation Protocol (RSVP) is a transport layer protocol designed to reserve resources across a network using the integrated services model. RSVP operates over an IPv4 or IPv6 and provides receiver-initiated setup of resource reservations for multicast or unicast data flows. It does not transport application data but is similar to a control protocol, like Internet Control Message Protocol (ICMP) or Internet Group Management Protocol (IGMP). RSVP is described in RFC 2205.
Protocol-Independent Multicast (PIM) is a family of multicast routing protocols for Internet Protocol (IP) networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the Internet. It is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead uses routing information supplied by other routing protocols. PIM is not dependent on a specific unicast routing protocol; it can make use of any unicast routing protocol in use on the network. PIM does not build its own routing tables. PIM uses the unicast routing table for reverse-path forwarding.
Multicast DNS (mDNS) is a computer networking protocol that resolves hostnames to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as unicast Domain Name System (DNS). It was designed to work as either a stand-alone protocol or compatible with standard DNS servers. It uses IP multicast User Datagram Protocol (UDP) packets and is implemented by the Apple Bonjour and open-source Avahi software packages, included in most Linux distributions. Although the Windows 10 implementation was limited to discovering networked printers, subsequent releases resolved hostnames as well. mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration networking technique specified separately in RFC 6763.
Reverse-path forwarding (RPF) is a technique used in modern routers for the purposes of ensuring loop-free forwarding of multicast packets in multicast routing and to help prevent IP address spoofing in unicast routing.
In computer networking, telecommunication and information theory, broadcasting is a method of transferring a message to all recipients simultaneously. Broadcasting can be performed as a high-level operation in a program, for example, broadcasting in Message Passing Interface, or it may be a low-level networking operation, for example broadcasting on Ethernet.
The internet layer is a group of internetworking methods, protocols, and specifications in the Internet protocol suite that are used to transport network packets from the originating host across network boundaries; if necessary, to the destination host specified by an IP address. The internet layer derives its name from its function facilitating internetworking, which is the concept of connecting multiple networks with each other through gateways.
IGMP snooping is the process of listening to Internet Group Management Protocol (IGMP) network traffic to control delivery of IP multicasts. Network switches with IGMP snooping listen in on the IGMP conversation between hosts and routers and maintain a map of which links need which IP multicast transmission. Multicasts may be filtered from the links which do not need them, conserving bandwidth on those links.
In packet switching networks, traffic flow, packet flow or network flow is a sequence of packets from a source computer to a destination, which may be another host, a multicast group, or a broadcast domain. RFC 2722 defines traffic flow as "an artificial logical equivalent to a call or connection." RFC 3697 defines traffic flow as "a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection." Flow is also defined in RFC 3917 as "a set of IP packets passing an observation point in the network during a certain time interval." Packet flow temporal efficiency can be affected by one-way delay (OWD) that is described as a combination of the following components:
An Internet Protocol version 6 address is a numeric label that is used to identify and locate a network interface of a computer or a network node participating in a computer network using IPv6. IP addresses are included in the packet header to indicate the source and the destination of each packet. The IP address of the destination is used to make decisions about routing IP packets to other networks.
An IPv6 packet is the smallest message entity exchanged using Internet Protocol version 6 (IPv6). Packets consist of control information for addressing and routing and a payload of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level transport layer protocol, but may be data for an internet layer or link layer instead.
NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.
Multicast routing is one of the routing protocols in IP networking.
↑ Taylor, Ian J. (2009). From P2P and grids to services on the web: evolving distributed communities. Harrison, Andrew B., Taylor, Ian J., 1968- (2nd.ed.). London: Springer. ISBN9781848001220. OCLC314174970.
↑ "Radio", Multicast, UK: The BBC Research & Development, retrieved 19 April 2012
↑ IPTV, DE: ARD, archived from the original on 2015-03-18, retrieved 2015-05-17.
External links
Multicast over TCP/IP (Howto), The Linux documentation project, Mar 1998. Describes Multicast in the Linux kernel, although some sections (specially multicast programs) is outdated and does not cover recent software.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
