Fact-checked by Grok 2 weeks ago

Multicast

In computer networking, multicast is a group communication method where data transmission is addressed to a group of destination computers simultaneously. In IP networks, this is achieved by sending a single IP datagram from a source to a "host group"—a dynamic set of zero or more hosts identified by a single IP destination address—providing best-effort delivery to all group members similar to unicast datagrams.^[1] This approach contrasts with unicast, which targets individual hosts, and broadcast, which floods data to all devices on a network; multicast instead directs traffic only to subscribed recipients, conserving bandwidth by avoiding redundant transmissions.^[1] IP multicast was pioneered by Steve Deering during the 1980s at Stanford University as an extension to the Internet Protocol (IP) to support efficient one-to-many and many-to-many communications.^[2] It was formalized as an Internet standard in RFC 1112 in 1989, specifying host-level extensions such as new IP service interface operations (e.g., JoinHostGroup and LeaveHostGroup) and integration with the Internet Group Management Protocol (IGMP) for managing group memberships.^[1] Subsequent developments, including Protocol Independent Multicast (PIM) for inter-router forwarding, have built upon this foundation to enable scalable deployment across wide-area networks. Multicast addressing relies on dedicated ranges: for IPv4, Class D addresses from 224.0.0.0 to 239.255.255.255, which include globally scoped addresses (224.0.0.0/4 excluding reserved blocks), organization-local scopes (e.g., 239.192.0.0/14), and GLOP blocks (233.0.0.0/8) tied to Autonomous System numbers for private allocations.^[3] In operation, a sending host transmits packets with the multicast destination address and a time-to-live (TTL) value greater than 1 for network traversal; local delivery occurs via hardware multicast support (e.g., Ethernet MAC addresses starting with 01-00-5E), while routers use IGMP to learn group memberships from hosts and PIM to build distribution trees for forwarding.^[1] IPv6 multicast embeds similar principles using addresses prefixed with ff00::/8, often derived from unicast prefixes for embedded-RP models.^[3] Multicast finds essential applications in bandwidth-intensive scenarios such as video conferencing, live streaming, distance learning, software distribution, and real-time data feeds like stock quotes or news dissemination, where it reduces network load by delivering one stream to thousands of recipients. Its efficiency stems from eliminating the need for multiple unicast streams, though challenges like firewall traversal, security, and inter-domain routing have historically limited widespread adoption beyond enterprise and research environments.^[4] Ongoing IETF efforts continue to address these issues, enhancing support for secure and reliable multicast in modern networks.^[5]

Fundamentals

Definition and Principles

Multicast is a communication paradigm in computer networking that enables a single source to transmit a packet to multiple destination hosts simultaneously, forming a group identified by a shared multicast address. Unlike unicast, which targets individual recipients, or broadcast, which floods all nodes, multicast addresses the packet to a dynamic set of interested receivers, allowing efficient one-to-many or many-to-many data distribution. This method relies on network infrastructure to replicate the packet only as needed along the path to group members, minimizing unnecessary transmissions.^[1] The core principles of multicast revolve around group membership management, bandwidth efficiency, and dynamic participation. Hosts join or leave multicast groups through signaling mechanisms that inform the network of their interest, enabling routers to maintain accurate membership lists and forward traffic selectively. By avoiding packet duplication at the source—where the sender transmits once and the network handles replication—multicast conserves bandwidth and reduces load on the originator, particularly beneficial for applications like video streaming or stock updates to numerous subscribers. Groups can be transient or permanent, with no limits on size or geographic distribution, supporting scalable, best-effort delivery semantics.^[1]^[6] The origins of multicast trace back to the late 1980s, with foundational work by Steve Deering at Stanford University, culminating in his 1991 Ph.D. dissertation, which proposed multicast extensions to the Internet Protocol (IP). This led to the first standardization in 1989 through RFC 1112, defining host extensions for IP multicasting and establishing Class D addresses (ranging from 224.0.0.0 to 239.255.255.255) for group identification. Early experiments, such as the 1992 IETF audiocast across 20 sites via the Multicast Backbone (MBone), demonstrated practical deployment using tunneled protocols, paving the way for broader adoption in the 1990s.^[1]^[7]^[6] Conceptually, multicast distribution often employs a tree-based model, where the source acts as the root, and branches extend to group members via intermediate routers, forming a spanning tree that optimizes paths and avoids loops. This structure ensures data flows efficiently from the source through shared links to receivers, with pruning of unused branches to further enhance resource use; for example, in a shortest-path tree, routers calculate routes based on metrics like distance to minimize latency. Such models underpin multicast's scalability, as the tree adapts dynamically to membership changes without source involvement.^[8]^[9]

Comparison to Unicast and Broadcast

Multicast differs from unicast and broadcast in its targeted delivery mechanism for group communications, enabling a single data stream to reach multiple selected recipients efficiently without duplicating transmissions for each one.^[10] In unicast, the sender transmits individual copies of the data to each recipient separately, which consumes bandwidth proportional to the number of recipients and becomes inefficient for large groups due to repeated transmissions across the network.^[10] Broadcast, by contrast, floods the data to all nodes in the network domain, leading to unnecessary congestion as uninterested devices process the traffic, making it suitable only for small, fully interconnected environments like local area networks.^[10] Multicast addresses these limitations by routing a single stream to a defined group of interested receivers, replicating packets only at branching points in the network topology, which scales well for medium-sized groups where not all nodes need the data.^[10] The primary advantages of multicast lie in its resource efficiency compared to unicast and broadcast. It reduces server load and network bandwidth usage by 50-90% in group communication scenarios relative to unicast, depending on group size and network topology, as the sender transmits only once regardless of the number of recipients.^[11] For instance, with 20-40 receivers, multicast achieves 60-70% bandwidth savings over unicast, escalating to around 90% for groups exceeding 1,000 members.^[11] Against broadcast, multicast avoids wasteful delivery to non-subscribers, preventing network congestion in larger or segmented topologies where broadcast would overwhelm irrelevant nodes.^[10] However, multicast requires group management protocols to join/leave sessions, adding slight overhead absent in simpler unicast or broadcast setups, and it performs best in controlled networks rather than the open internet.^[10] Practical use cases illustrate when each method excels. Multicast is ideal for video streaming to multiple viewers, such as live IPTV distribution within an enterprise, where a single stream serves hundreds without proportional bandwidth escalation.^[10] Unicast proves superior for point-to-point file transfers or on-demand video delivery to individual users, like over-the-top (OTT) services, as it ensures reliable, tailored connections without group coordination.^[10] Broadcast suits simple LAN announcements, such as ARP requests or service discovery in small networks, where delivering to all devices is acceptable due to the limited scope.^[10] Quantitatively, multicast's efficiency in network utilization can be expressed through its asymptotic behavior: the bandwidth overhead remains O(1) per group on the shared path, independent of group size n, whereas unicast scales as O(n) due to per-recipient streams, and broadcast as O(V) where V is the total number of nodes.^[11] This contrast underscores multicast's scalability for group-oriented applications while highlighting unicast's precision for individualized needs and broadcast's simplicity in uniform scenarios.^[10]

Data Link Layer

Ethernet Multicast

In Ethernet networks, multicast communication at the data link layer relies on specific multicast MAC addresses to deliver frames to multiple recipients within a local segment. According to the IEEE 802.3 standard, multicast MAC addresses are identified by setting the least significant bit of the first octet to 1, distinguishing them from unicast addresses. For IPv4 multicast, these addresses use the fixed prefix 01-00-5E, followed by 23 bits derived from the IP multicast group address, as defined in RFC 1112. This mapping process takes the low-order 23 bits of the 32-bit IPv4 multicast address (from the range 224.0.0.0 to 239.255.255.255) and inserts them into the low-order 23 bits of the Ethernet MAC address, resulting in addresses ranging from 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF. For example, the IPv4 multicast group 224.0.0.1 maps to the MAC address 01-00-5E-00-00-01.^[1] When an Ethernet frame with a multicast destination MAC address is received by a switch, the default forwarding behavior treats it similarly to a broadcast frame. Per IEEE 802.1D bridging specifications, the switch floods the frame out of all ports except the incoming port, ensuring delivery to all potential recipients in the broadcast domain but potentially consuming unnecessary bandwidth on links without interested hosts. This flooding mechanism is inherent to transparent bridging in Ethernet switches, where multicast frames are not learned in the address table like unicast frames.^[12] To optimize multicast delivery and mitigate flooding, Ethernet switches often implement IGMP snooping, a Layer 2 feature that monitors Internet Group Management Protocol (IGMP) traffic to learn which ports have hosts joined to specific multicast groups. As outlined in RFC 4541, IGMP snooping switches maintain a multicast forwarding table based on IGMP membership reports from hosts, forwarding multicast frames only to ports associated with group members and to router ports that connect to upstream multicast sources. This pruning reduces bandwidth waste by excluding non-member ports from the traffic path, while still flooding certain link-local groups like 224.0.0.X to all ports due to their scope. IGMP snooping also handles group leave events via IGMP leave messages or timeouts to update the forwarding table dynamically.^[12] Despite these optimizations, Ethernet multicast has notable limitations. Without IGMP snooping, flooding can lead to multicast storms in large or looped networks, overwhelming switches and endpoints with excessive traffic. Additionally, the 23-bit mapping in the MAC address space restricts the number of unique IPv4 multicast groups that can be distinctly addressed at the data link layer to approximately 8 million (2^23), as the full 28-bit IPv4 multicast range cannot be preserved one-to-one, causing multiple IP groups to share the same MAC address.^[1]^[12]

Network Layer

IP Multicast

IP multicast operates at the network layer to enable efficient one-to-many or many-to-many communication by allowing a single packet to be sent to a group of interested hosts identified by a multicast address. This mechanism relies on special address ranges and protocols for group management, distinct from unicast addressing which targets individual hosts. In IP networks, multicast addresses are used as the destination in packet headers, with routers replicating packets only towards networks containing group members, thus optimizing bandwidth usage compared to broadcasting.^[1] For IPv4, multicast addresses fall within the Class D range from 224.0.0.0 to 239.255.255.255, where the first four bits are set to 1110 in binary to distinguish them from unicast or broadcast addresses. This range is exclusively reserved for multicast traffic and cannot be assigned as source addresses or routed as unicast. Within this space, certain subranges are reserved for specific scopes; for instance, 224.0.0.0/24 is designated for link-local multicast, limited to the local network segment and not forwarded by routers, supporting protocols like OSPF and RIP. The address 224.0.0.0 itself is reserved and must not be used.^[1]^[20]^[1] IPv6 multicast addresses begin with the prefix ff00::/8, where the initial eight bits are 11111111, providing a 128-bit address space analogous to IPv4's Class D but with enhanced scoping capabilities. These addresses include flags and scope fields to define permanence and dissemination range, such as link-local (ff02::/16) or site-local (ff05::/16). A key example is the solicited-node multicast address, derived from a unicast or anycast address by appending its low-order 24 bits to the prefix ff02:0:0:0:0:1:ff00::/104; this supports IPv6 Neighbor Discovery Protocol by allowing efficient address resolution without flooding the network. In IP multicast packet handling, the destination address in the IP header is set to the multicast group address, enabling routers to identify and forward the packet to interested interfaces. The Time to Live (TTL) field in the IP header serves as a scope control mechanism; for example, a TTL of 1 restricts packets to the local link, while higher values allow broader propagation, preventing indefinite looping in the network. Routers decrement the TTL on each hop, discarding packets that reach zero, which helps enforce administrative or geographic boundaries for multicast distribution.^[1]^[1] Host group management in IP multicast is facilitated by protocols that allow hosts to join or leave multicast groups, informing local routers of membership changes. For IPv4, the Internet Group Management Protocol version 3 (IGMPv3) enables hosts to report interest in specific groups and, crucially, supports source-specific joins where a host can request traffic only from particular sources (S,G) rather than all sources (*,G), reducing unwanted traffic and enhancing security. IGMPv3 operates via a query-response process: routers periodically send general queries to the all-hosts address (224.0.0.1) to poll for group memberships, with a configurable maximum response time; hosts respond with membership reports detailing their groups and sources, and suppression mechanisms prevent redundant reports from multiple hosts. For IPv6, Multicast Listener Discovery version 2 (MLDv2) performs an analogous function, using ICMPv6 messages to discover listeners on a link and support source-specific filtering, mirroring IGMPv3's capabilities for consistent behavior across IP versions.^[21]^[21]^[22] Multicast address allocation is managed by the Internet Assigned Numbers Authority (IANA) to ensure global uniqueness and prevent conflicts, with guidelines outlined for permanent, temporary, and scoped assignments. For example, the range 239.0.0.0/8 is reserved for administratively scoped or private multicast use within organizations, not routed across the public Internet, allowing internal applications like video conferencing to select addresses without IANA coordination. IANA maintains registries for both IPv4 and IPv6 multicast spaces, assigning addresses based on requests that demonstrate need, such as for standardized protocols.^[23]^[20]^[24]

Multicast Routing Protocols

Protocol Independent Multicast (PIM) is a widely adopted family of multicast routing protocols designed to distribute IP multicast traffic efficiently across routers by leveraging the underlying unicast routing information base or a separate multicast routing information base.^[25] PIM operates without assuming a specific unicast protocol, making it versatile for various network environments.^[26] It supports the construction of distribution trees to forward packets from sources to receivers, minimizing duplication and bandwidth usage.^[25] PIM Sparse Mode (PIM-SM) is optimized for wide-area networks where multicast receivers are sparsely distributed, building unidirectional shared trees rooted at a Rendezvous Point (RP) to coordinate initial traffic distribution.^[25] In PIM-SM, routers connected to receivers send (*,G) Join messages upstream toward the RP, forming the shared tree (RP-Tree) that allows sources to register and send data encapsulated in Register messages until the tree stabilizes.^[27] For efficiency, PIM-SM can switch to source-specific shortest-path trees (SPTs) using (S,G) Join messages when data rates exceed thresholds, reducing latency by routing directly from the source to receivers via reverse path forwarding (RPF) checks.^[28] The RP is discovered through mechanisms like Bootstrap Routers (BSR) or static configuration, ensuring scalability in inter-domain scenarios.^[29] In contrast, PIM Dense Mode (PIM-DM) assumes multicast group members are densely populated, initially flooding traffic to all interfaces and relying on Prune messages to suppress forwarding on branches without receivers, thus building source-based trees through a flood-and-prune cycle.^[26] PIM-DM uses the multicast routing information base (MRIB) derived from unicast tables for RPF to prevent loops during flooding, with Graft messages allowing pruned branches to rejoin when new receivers appear.^[30] State Refresh messages periodically propagate from sources to maintain prune states and avoid reflooding, making PIM-DM suitable for networks with high receiver density but less efficient in sparse environments due to initial overhead.^[31] Multicast OSPF (MOSPF) extends the OSPF link-state routing protocol for intra-domain multicast by incorporating group membership information into the link-state database, enabling routers to compute source-based shortest-path trees on demand.^[32] Designated routers originate group-membership Link State Advertisements (LSAs) that flood within an OSPF area, identifying networks with active receivers and allowing all MOSPF routers to maintain a consistent view of topology and membership.^[33] Upon receiving a multicast datagram, a router calculates a pruned SPT rooted at the source using Dijkstra's algorithm on the enhanced link-state database, caching the tree for subsequent packets and replicating data only at branch points to optimize paths.^[34] MOSPF supports inter-area routing via summary LSAs and wild-card receivers but is limited to single autonomous systems due to its reliance on full topology visibility.^[35] Core-Based Trees (CBT) version 2 employs a bidirectional shared tree architecture per multicast group, centered on a core router to minimize per-group state across the network and reduce overhead in large-scale deployments.^[36] Routers join the tree by sending JOIN_REQUEST messages toward the core, which are acknowledged and propagated to establish bidirectional paths allowing traffic to flow in both directions without source-specific states.^[37] Pruning occurs via QUIT_NOTIFICATION messages when downstream interfaces lack receivers, with ECHO_REQUEST/REPLY messages maintaining tree liveness every 60 seconds; cores are selected and advertised via a bootstrap mechanism for dynamic discovery.^[38] CBT's shared tree design suits both intra- and inter-domain routing by limiting state to on-tree routers only, though it may introduce higher latency compared to source-based approaches.^[39] Multiprotocol BGP (MP-BGP) facilitates inter-domain multicast routing by extending BGP-4 to exchange multicast-specific reachability information across autonomous systems, using address family identifiers (AFI) and subsequent address family identifiers (SAFI=2 for multicast) to distinguish multicast routes.^[40] MP-BGP carries multicast Network Layer Reachability Information (NLRI) via MP_REACH_NLRI and MP_UNREACH_NLRI attributes, enabling border routers to advertise and withdraw multicast destinations along with next-hop details for efficient propagation.^[41] It integrates with route reflectors to scale within ASes, supporting the distribution of multicast forwarding entries without requiring separate protocols for inter-domain exchanges.^[42] Bit Indexed Explicit Replication (BIER) is a stateless multicast forwarding architecture that encodes destination information in a bit string within the packet header, allowing ingress routers to explicitly specify replication paths to bit-forwarding routers (BFRs) without maintaining per-group forwarding state in intermediate nodes.^[43] BIER supports subdomains and sets for scalability, using existing unicast routing for BFR adjacency discovery, and is applicable in MPLS, IPv6, and Ethernet environments via specific encapsulations. It enables efficient one-to-many or many-to-many distribution for applications like video streaming, with ongoing IETF extensions for traffic engineering (BIER-TE) and integration with protocols like PIM and EVPN as of 2025.^[43] Modern enhancements to PIM-SM, as specified in RFC 7761, improve convergence and reliability through refined state machines for (*,G) and (S,G) joins/prunes, AssertCancel messages to expedite duplicate packet resolution, and PruneEcho mechanisms on shared LANs to prevent lost prunes.^[44] These updates, revising earlier specifications, enhance adaptability to routing changes via triggered updates and override timers, ensuring faster tree maintenance in dynamic wide-area networks.^[45]

Application Layer

Application-Level Multicast

Application-level multicast (ALM), also referred to as end system multicast, enables multicast communication by implementing the necessary functionality directly within end-user applications or overlay networks, rather than relying on network-layer support. In this approach, participating hosts form logical overlay topologies—typically trees or meshes—using unicast tunnels to replicate and forward data packets among group members. This overlay abstraction allows applications to manage group membership, routing, and data distribution independently of the underlying IP infrastructure.^[46] A primary advantage of ALM is its ease of deployment, as it requires no modifications to routers or core network elements, making it suitable for environments where native IP multicast is unavailable or restricted. This flexibility has enabled widespread use in peer-to-peer systems and applications on the public Internet, where rapid adoption without administrative intervention is essential. Additionally, ALM supports customizable features at the application layer, such as tailored congestion control and reliability mechanisms, enhancing adaptability to diverse network conditions.^[47]^[47] Despite these benefits, ALM incurs notable limitations compared to native multicast solutions. The overlay structure introduces additional latency from extra forwarding hops, resulting in end-to-end delays that can be 1.3 to 1.7 times higher for small groups and up to 2.2 to 2.8 times for larger groups of around 256 members. Bandwidth efficiency is also reduced, as the same physical link may carry multiple duplicate packets, leading to 30-50% higher resource utilization than network-layer multicast.^[46]^[46]

Protocols and Frameworks

Application-layer multicast (ALM) relies on specific protocols and frameworks to construct and manage overlay networks at the end hosts, enabling efficient group communication without native IP multicast support. These implementations focus on scalability, reliability, and ease of integration into applications. Key examples include tree-based and mesh-based protocols that build low-latency overlays through end-system coordination.^[48] NICE (Nebulous Infrastructure for Conferencing Experiments) is a hierarchical clustering protocol designed for scalable ALM, organizing participating hosts into a tree-like structure with bounded diameter to minimize latency. In NICE, hosts form clusters at multiple levels, where each cluster has a leader that connects to higher-level clusters, ensuring the overlay diameter grows logarithmically with the number of participants (O(log N) for N hosts). This approach supports low-bandwidth applications like conferencing by reducing control overhead and enabling efficient data dissemination through intra-cluster and inter-cluster forwarding. Developed as part of research at the University of Maryland, NICE has been evaluated to achieve near-optimal stretch (close to 1.1 times the unicast shortest path) in Internet-like topologies.^[48] End System Multicast (ESM) employs a peer-to-peer tree construction mechanism for ALM, where end hosts probe available bandwidth between pairs to build an efficient spanning tree for data distribution. The protocol uses a centralized coordinator initially to match senders and receivers based on latency measurements, then constructs the tree by selecting low-cost links while considering node degree constraints to balance load. ESM incorporates application-specific feedback, such as bandwidth estimation via packet train probes, to adapt the overlay to network conditions and minimize end-to-end delay. Originating from Carnegie Mellon University research, ESM demonstrates in simulations and deployments that it can support groups of up to 100 nodes with average path stretch under 1.5, making it suitable for streaming applications.^[49] IETF outputs from research groups like the Scalable Adaptive Multicast (SAM) provide foundational standards for ALM, including extensions for session management and error recovery in overlay networks as outlined in RFC 7019.^[50]

Wireless Multicast

Challenges in Wireless Environments

In wireless environments, the hidden and exposed terminal problems are particularly amplified in multicast scenarios due to the broadcast nature of transmissions and the shared medium. The hidden terminal problem occurs when multiple nodes, out of each other's sensing range but within the reception range of a common receiver, transmit simultaneously, leading to collisions at the receiver and significant packet loss. In multicast, this effect is exacerbated because a single collision can affect delivery to all group members simultaneously, unlike unicast where individual links can recover independently. Similarly, the exposed terminal problem arises when a node unnecessarily defers transmission due to sensing a nearby transmission that does not interfere with its intended receivers, reducing spatial reuse and overall channel efficiency in group communications.^[51]^[52] Reliability in wireless multicast is further challenged by the absence of acknowledgments in basic protocols like IEEE 802.11, where multicast frames do not elicit ACKs from receivers, preventing senders from detecting and retransmitting lost packets. This results in significantly higher packet loss rates compared to wired networks, primarily from interference, fading, and the lack of feedback, making reliable delivery to dynamic groups difficult without additional mechanisms.^[53] Energy inefficiency poses another key challenge, as mobile nodes in wireless multicast must often listen continuously or forward packets for the entire group, accelerating battery drain in battery-constrained devices. Unlike unicast, where transmissions are targeted, multicast requires nodes to process and relay group traffic even if not all members are active, leading to unnecessary power consumption on idle listening and redundant forwarding in dynamic topologies. This is particularly problematic in MANETs, where nodes rely solely on limited battery resources without infrastructure support for recharging.^[54] Scalability issues arise from frequent topology changes in MANETs, which disrupt multicast trees or meshes, requiring constant rebuilding and increasing control overhead. Tree-based multicast structures, while efficient for data forwarding, are fragile; node mobility can break links, partitioning the tree and causing temporary service interruptions or packet drops until repairs occur. In high-mobility scenarios, these disruptions can degrade performance significantly, limiting the protocol's ability to support large or dynamic groups without excessive reconfiguration costs.^[55]

Wireless-Specific Techniques

In mobile ad hoc networks (MANETs), the Multicast Ad-hoc On-Demand Distance Vector (MAODV) protocol extends the AODV unicast routing mechanism to support multicast by forming shared trees on demand through route discovery processes, where group members initiate join queries to establish paths to the multicast source, minimizing overhead in dynamic topologies. This on-demand approach allows nodes to join or leave multicast groups dynamically, with route maintenance via periodic advertisements and error notifications to handle mobility-induced link failures. Reliable multicast in wireless environments addresses packet loss due to interference and fading by employing feedback mechanisms that reduce acknowledgment overhead compared to per-packet unicast ACKs. Batch-mode protocols, such as the Batch Mode Multicast MAC (BMMM), aggregate acknowledgments from multiple receivers into a single feedback frame, enabling the sender to poll recipients sequentially and retransmit only lost packets, which improves efficiency in error-prone channels.^[56] Leader-based feedback selects a designated receiver as a representative to collect and forward NACKs on behalf of the group, further minimizing collisions in contention-based access while ensuring delivery reliability without excessive signaling.^[57] In IEEE 802.11 Wi-Fi networks, multicast transmissions lack automatic repeat requests (ARQ) unlike unicast, leading to adaptations like basic rate fallback, where frames are sent at the lowest supported data rate (e.g., 1 Mbps in legacy modes) to maximize reception probability across varying receiver distances and signal qualities. To enhance reliability, hybrid ARQ schemes integrate forward error correction (FEC) with selective retransmissions, allowing the access point to combine incremental redundancy from repeated packets for decoding, as proposed in extensions for multicast traffic over WLANs. For cellular wireless systems, the Multimedia Broadcast Multicast Service (MBMS) in LTE, evolved as enhanced MBMS (eMBMS) in Release 9 and beyond, enables efficient delivery of synchronized content to multiple users via dedicated multicast channels, reducing bandwidth usage for applications like live video streaming. In 5G New Radio (NR), 3GPP Release 16 introduces multicast and broadcast services (MBS) with support for both unicast and multicast bearers, allowing dynamic switching based on user density and incorporating sidelink multicast for device-to-device communications in scenarios like public safety. Subsequent enhancements in Releases 17 and 18 (as of 2025) improve MBS with better integration for sidelink and core network support for more efficient multicast delivery.^[58] In low-power wireless sensor networks, directed diffusion provides a data-centric multicast paradigm where interests (queries for specific data) are diffused throughout the network via gradients, enabling sources to reinforce paths toward sinks and support one-to-many dissemination without explicit addressing, which conserves energy in resource-constrained deployments.^[59] This pull-based mechanism caches and propagates event data along multiple paths, allowing adaptive rerouting around failures while minimizing global state maintenance.^[59]

Applications

Broadcasting and Television

Multicast plays a pivotal role in the distribution of television content, enabling efficient delivery of live and on-demand video streams to multiple receivers simultaneously, building on IP multicast fundamentals at the network layer. The transition from analog broadcasting to digital multicast systems began in the 1990s, driven by the development of standards that allowed for more efficient spectrum use and higher-quality video delivery.^[60] This shift was marked by the formation of the Digital Video Broadcasting (DVB) Project in 1993, which standardized digital transmission for satellite, cable, and terrestrial networks, incorporating multicast capabilities to support widespread adoption of digital TV services across Europe and beyond.^[61] In DVB systems, multicast IP is utilized for satellite and cable TV distribution, encapsulating MPEG-2 transport streams over UDP to deliver compressed video and audio to multiple endpoints with minimal duplication.^[62] This approach ensures synchronized playback across receivers while optimizing bandwidth in broadcast environments, where content is sent once and replicated at network points closer to viewers. The DVB specifications, such as ETSI TS 102 034, define the transport of these MPEG-2-based services over IP-based networks, facilitating seamless integration of multicast in traditional TV infrastructures. For Internet Protocol Television (IPTV), multicast enables efficient channel delivery in managed networks, with the Internet Group Management Protocol (IGMP) handling group membership for channel zapping, allowing users to join or leave multicast streams rapidly during live viewing.^[63] Session management in IPTV systems often employs the Real-Time Streaming Protocol (RTSP) to initiate and control streams, coordinating with IGMP to switch between multicast channels without interrupting service continuity. This combination supports fast channel changes, typically reducing zapping delays to under a second in optimized deployments.^[64] The ATSC 3.0 standard, approved in 2017, represents a next-generation advancement in IP-based television, incorporating multicast delivery through the ROUTE protocol for unidirectional transport of media objects over IP networks.^[65] ROUTE, specified in RFC 9223, enables efficient multicast of DASH-formatted content and signaling data, supporting features like 4K video, interactivity, and mobile reception in over-the-air broadcasting.^[66] This protocol stack allows broadcasters to deliver multiple streams within a single physical layer channel, enhancing capacity for high-definition services. Overall, multicast in broadcasting and television significantly reduces bandwidth requirements compared to unicast streaming, particularly for live events where thousands of viewers access the same content; for instance, delivering a 4 Mbps stream to 100 viewers via multicast uses only 4 Mbps total, versus 400 Mbps in unicast, achieving up to 99% savings in network resources.^[67] This efficiency has been crucial in scaling digital TV distribution since the 1990s, minimizing infrastructure costs while maintaining service quality for mass audiences.

Other Network Applications

In online gaming, particularly massively multiplayer online role-playing games (MMORPGs), IP multicast facilitates efficient distribution of player position updates to nearby participants, enabling group synchronization that reduces server bandwidth from O(n²) to O(n) and lowers latency by offloading propagation directly to players.^[68] This approach supports scalable multi-source scenarios, allowing updates to be sent once to a multicast group rather than individually to each recipient, which is critical for maintaining fluid movement in large virtual worlds.^[68] Service discovery protocols leverage multicast for zero-configuration networking in home and local environments. Multicast DNS (mDNS), defined in RFC 6762, enables devices to resolve hostnames and discover services by sending queries to the multicast address 224.0.0.251 (IPv4) or FF02::FB (IPv6) on UDP port 5353, allowing automatic detection without a central DNS server.^[69] Similarly, the Simple Service Discovery Protocol (SSDP) in Universal Plug and Play (UPnP) uses multicast to the address 239.255.255.250:1900 for devices to advertise availability via NOTIFY messages and for control points to search for services with M-SEARCH requests, supporting dynamic plug-and-play connectivity.^[70] In stock trading, IP multicast delivers real-time market data feeds efficiently to multiple subscribers, minimizing bandwidth usage for high-frequency updates. NASDAQ employs UDP/IP multicast protocols, such as ITCH, to distribute order book depth and trade information across dedicated multicast groups, enabling low-latency dissemination to traders and vendors.^[71] Videoconferencing utilizes multicast for multi-party sessions to scale media distribution. The Session Initiation Protocol (SIP), as outlined in RFC 4353, supports loosely coupled conferences through multicast media groups, where participants join shared addresses without centralized signaling, and distributed mixing models that redistribute streams via single-source multicast for efficient handling of diverse client capabilities.^[72] In WebRTC-based group calls, application-layer multicast techniques extend this by overlaying multicast trees on peer connections, often using selective forwarding units (SFUs) to simulate group synchronization for immersive multi-user audio and video.^[73] Emerging applications in virtual reality (VR) and augmented reality (AR) shared environments employ application-layer multicast to deliver immersive content efficiently. In 5G-enabled systems, device-to-device (D2D) multicast clusters allow VR users to share high-resolution content (e.g., 8K video) by reusing cellular uplink channels, achieving up to 50% higher system throughput and uplink delays under 10 ms to prevent motion sickness, through optimized power and channel allocation.^[74] Sidelink-aided multicast further enhances tiled 360° VR video delivery in shared scenarios by supporting multi-quality streams over wireless links, adapting to user viewpoints and channel conditions for scalable group immersion.^[75]

References

[1]
RFC 1112 - Host extensions for IP multicasting - IETF Datatracker
INTRODUCTION IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address.
[2]
Stephen Deering - Engineering and Technology History Wiki
Feb 26, 2016 · Dr. Deering's design for IP multicast was adopted by the Internet Engineering Task Force (IETF) as a Standard and is a component of all IP ...
[3]
RFC 6308: Overview of the Internet Multicast Addressing Architecture
### Summary of IP Multicast Addressing Architecture (RFC 6308)
[4]
RFC 2588 - IP Multicast and Firewalls - IETF Datatracker
1. Abstract Many organizations use a firewall computer that acts as a security gateway between the public Internet and their private, internal 'intranet'. · 2.
[5]
Multicast Lessons Learned from Decades of Deployment Experience
Mar 4, 2024 · This draft attempts to explain the current, and future, state of multicast affairs by reviewing the distractions, hype and innovation over the years.
[6]
[PDF] The evolution of multicast - CS@UCSB
in perspective, compare multicast to the World Wide Web and HyperText Transfer Protocol (HTTP). IP multicast was first introduced in Steve Deering's Ph.D.
[7]
[PDF] A Survey of the History of Internet Multicast
Jan 27, 1999 · IP multicast was first introduced in Steve Deering's Ph. D. dissertation in 1988 and tested on a wide scale during an “audiocast” at the 1992 ...Missing: ARPANET | Show results with:ARPANET
[8]
multicast tree - an overview | ScienceDirect Topics
A multicast tree refers to a structure used in data centers to efficiently deliver data to multiple recipients. It can be categorized as per-source tree or ...
[9]
4.3 Multicast - Computer Networks: A Systems Approach
The basic IP multicast model is a many-to-many model based on multicast groups, where each group has its own IP multicast address.Missing: authoritative | Show results with:authoritative
[10]
Unicast vs Multicast vs Broadcast: What's the Difference? - Haivision
May 21, 2025 · Unicast is one-to-one, multicast is one-to-many, and broadcast is one-to-all. Unicast is for on-demand, multicast for closed networks, and ...
[11]
[PDF] Modeling the Branching Characteristics and Efficiency Gains in ...
The shape of the curve implies that multicast outperforms unicast even with a few receivers; between 20 and 40 receivers, mul- ticast provides 60-70% increased ...
[12]
RFC 4541 - Considerations for Internet Group Management Protocol ...
This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches.<|control11|><|separator|>
[13]
RFC 3518: Point-to-Point Protocol (PPP) Bridging Control Protocol ...
To reduce unnecessary multicast flooding in the network, bridges exchange group MAC addresses using the GARP Multicast Registration Protocol. GMRP provides ...
[14]
RFC 2470 - Transmission of IPv6 Packets over Token Ring Networks
Address Mapping -- Multicast All IPv6 packets with multicast destination addresses are transmitted to Token Ring functional addresses. The following table ...
[15]
RFC 2022 - Support for Multicast over UNI 3.0/3.1 based ATM ...
... RFC 1112 style Level 2 IP multicast over the ATM Forum's UNI 3.0/3.1 point to multipoint connection service. Clusters of endpoints share a MARS and use it ...Missing: circuits | Show results with:circuits
[16]
RFC 2149 - Multicast Server Architectures for MARS-based ATM ...
... point to multipoint tree rooted on a Multicast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core ...
[17]
RFC 2382 - A Framework for Integrated Services and RSVP over ATM
... point-to- multipoint VC to a set of receivers. This moves the VC scaling issues noted previously for point-to-multipoint VCs to the multicast server.
[18]
Understanding Fibre Channel Services - TechDocs - Broadcom Inc.
Oct 16, 2024 · Alias server – The alias server keeps a group of nodes that are registered as one name to handle multicast groups. Broadcast server – The ...
[19]
https://techdocs.broadcom.com/us/en/fibre-channel-networking/fabric-os/fabric-os-administration/9-2-x/Understanding-Fibre-Channel-Services-AG.html
[20]
RFC 3376 - Internet Group Management Protocol, Version 3
1 The Need for State-Change Messages IGMPv3 specifies two types of Membership Reports: Current-State and State Change. · 2 Host Suppression In IGMPv1 and IGMPv2, ...
[21]
RFC 5771 - IANA Guidelines for IPv4 Multicast Address Assignments
This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses.Missing: Class | Show results with:Class
[22]
RFC 2365 - Administratively Scoped IP Multicast - IETF Datatracker
... [Page 3]. RFC 2365 Administratively Scoped IP Multicast July 1998 The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope ...
[23]
RFC 7761 - Protocol Independent Multicast - Sparse Mode (PIM-SM)
PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base.
[24]
RFC 3973 - Protocol Independent Multicast - Dense Mode (PIM-DM)
PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers.
[25]
https://datatracker.ietf.org/doc/html/rfc7761
[26]
https://datatracker.ietf.org/doc/html/rfc3973
[27]
https://datatracker.ietf.org/doc/html/rfc7761#section-4.5.4
[28]
https://datatracker.ietf.org/doc/html/rfc7761#section-4.5.5
[29]
https://datatracker.ietf.org/doc/html/rfc7761#section-4.7
[30]
RFC 1584 - Multicast Extensions to OSPF - IETF Datatracker
Multicast routing in MOSPF This section describes MOSPF's basic multicast routing algorithm. ... RFC 1584 Multicast Extensions to OSPF March 1994 (2) MOSPF ...
[31]
https://datatracker.ietf.org/doc/html/rfc3973#section-4.4
[32]
https://datatracker.ietf.org/doc/html/rfc1584
[33]
https://datatracker.ietf.org/doc/html/rfc1584#section-10
[34]
RFC 2189: Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --
### Summary of CBT Version 2: Core-Based Trees
[35]
https://datatracker.ietf.org/doc/html/rfc1584#section-3.2
[36]
https://datatracker.ietf.org/doc/html/rfc2189
[37]
https://datatracker.ietf.org/doc/html/rfc2189#section-5.2
[38]
RFC 4760 - Multiprotocol Extensions for BGP-4 - IETF Datatracker
This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (eg, IPv6, IPX, L3VPN, etc.).
[39]
https://datatracker.ietf.org/doc/html/rfc2189#section-1
[40]
https://datatracker.ietf.org/doc/html/rfc4760
[41]
https://datatracker.ietf.org/doc/html/rfc4760#section-3
[42]
https://datatracker.ietf.org/doc/html/rfc4760#section-7
[43]
[PDF] A Case for End System Multicast
In this section, we will study how we support an important, performance demanding class of applications - video conferencing - within the Narada frame- work.
[44]
(PDF) A Survey of Application-Layer Multicast Protocols
Aug 9, 2025 · This article surveys the literature over the period 1995-2005 on different application layer multicasting approaches. ResearchGate Logo.Missing: seminal | Show results with:seminal
[45]
[PDF] A Reliable Multicast Framework for Light-weight Sessions and ...
This paper describes. SRM. (Scalable. Reliable. Multicast), a reliable multicast framework for application level framing and light-weight sessions.
[46]
[PDF] Scalable Application Layer Multicast - Events - acm sigcomm
ABSTRACT. We describe a new scalable application-layer multicast protocol, specif- ically designed for low-bandwidth, data streaming applications with.Missing: seminal survey
[47]
A case for end system multicast (keynote address)
We call such a scheme End System Multicast. This shifting of multicast support from routers to end systems has the potential to address most problems associated ...
[48]
librecast - Codeberg
Librecast is a C multicast library which aims to make working with multicast easier. Librecast extends IPv6 multicast to provide a multicast communication layer ...<|control11|><|separator|>
[49]
[PDF] Multicast for the Web - W3C
Separate multicast-capable APIs per use-case: ○ WebRTC extension to support multicast RTP. ○ Segmented media delivery API (Maybe DVB's protocols ...
[50]
RFC 3208 - PGM Reliable Transport Protocol Specification
Abstract Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free ...Missing: paper | Show results with:paper<|control11|><|separator|>
[51]
RFC 7019 - Application-Layer Multicast Extensions - IETF Datatracker
This RFC represents the consensus of the Scalable Adaptive Multicast Research Group of the Internet Research Task Force (IRTF). Documents approved for ...
[52]
https://www.sciencedirect.com/science/article/pii/S092054891500046X
[53]
On the influence of the hidden and exposed terminal problems on ...
Hidden and exposed terminal problems are known to negatively impact wireless communications, degrading potential computing services on top.
[54]
RFC 9119: Multicast Considerations over IEEE 802 Wireless Media
1. Multicast Reliability. Multicast traffic is typically much less reliable than unicast traffic. · 2. Lower and Variable Data Rate. Multicast over wired differs ...
[55]
[PDF] Energy efficient multicast routing in ad hoc wireless networks
Energy efficiency is an important issue in ad hoc net- works, where mobile nodes are powered by batteries that may not be possible to be recharged or ...
[56]
[PDF] Exploring Mesh and Tree-Based Multicast Routing Protocols for ...
However, topology changes in MANETs can be very frequent, making conven- tional routing mechanisms both ineffective and expensive. When it became clear that ...
[57]
IEEE 802.11a Throughput Performance with Hidden Nodes
Aug 10, 2025 · It is shown that the presence of hidden nodes barely affects the network performance in low traffic conditions, but it causes 33% performance ...Missing: formula | Show results with:formula
[58]
Reliable MAC layer multicast in IEEE 802.11 wireless networks - Sun
Jun 25, 2003 · To redress the problems of reliability and efficiency, we propose a reliable Batch Mode Multicast MAC protocol (BMMM), which in most cases ...Missing: ACKs | Show results with:ACKs
[59]
Reliable Multicast in Multi-Access Wireless LANs | Wireless Networks
Our approach involves the election of one of the multicast group members (receivers) as a “leader” or representative for the purpose of sending feedback to the ...
[60]
Directed diffusion: a scalable and robust communication paradigm ...
In this paper, we explore the directed diffusion paradigm for such coordination. Directed diffusion is datacentric in that all communication is for named data.Missing: original | Show results with:original
[61]
[PDF] History of the DVB Project
During 1991, broadcasters and consumer equipment manufacturers discussed how to form a concerted pan-European platform to develop digital terrestrial TV.Missing: multicast | Show results with:multicast
[62]
[PDF] Transition from analogue to digital terrestrial broadcasting - ITU
The purpose of this Report is to help the Countries that are in the process of migrating from analogue to digital terrestrial broadcasting. The Report examines ...
[63]
[PDF] Transport of MPEG-2 TS Based DVB Services over IP Based Networks
ETSI TS 102 472: "Digital Video Broadcasting (DVB);IP Datacast over DVB-H: Content. Delivery Protocols". [66]. SMPTE specification 2022-1 (2007): "Forward ...
[64]
Analysis and characterization of IPTV user behavior - ResearchGate
IP multicast which is used for transferring Live TV content is based on the concept of a group. IGMP is used to manage the membership of multicast groups. Based ...
[65]
Release 2 Specification - Volume 4a, Examples of IPTV Protocol ...
This document provides non-normative examples of call flows that realize the functionality defined in Volume 4.
[66]
[PDF] A/300, "ATSC 3.0 System Standard"
Oct 19, 2017 · With higher capacity to deliver Ultra High-Definition services, robust reception on a wide range of devices, improved efficiency, IP transport, ...
[67]
RFC 9223: Real-Time Transport Object Delivery over Unidirectional ...
The ROUTE protocol is suitable for unicast, broadcast, and multicast ... (ATSC) 3.0 specifies the ROUTE protocol integrated with an ATSC 3.0 services layer.
[68]
IPTV Broadcast, Multicast and Unicast Data Streaming - koovik
Sep 21, 2018 · Each unicast client that connects to the server uses its own bandwidth. Example: 5 clients watching a 4Mbps program stream are using a total ...1. - Broadcast · 2. - Multicast · 3. - Unicast
[69]
[PDF] Revisiting IP Multicast - People @EECS
The multicast service model offered two key benefits: (1) the effi- cient use of bandwidth for multipoint communication and, (2) the indirection of a group ...
[70]
RFC 6762: Multicast DNS
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server.
[71]
[PDF] UPnP Device Architecture 1.1
Oct 15, 2008 · The remainder of this section explains the UPnP discovery protocol known as SSDP (Simple Service Discovery Protocol) in detail, enumerating ...<|separator|>
[72]
UDP/IP Addresses - NASDAQ Data Feeds
Nasdaq offers many of its direct data feed products in a UDP/IP protocol option. Please refer to Nasdaq Global Data Products - Direct Data Feeds page for ...Missing: distribution | Show results with:distribution
[73]
RFC 4353 - A Framework for Conferencing with the Session ...
SIP can support many models of multi-party communications. One, referred to as loosely coupled conferences, makes use of multicast media groups. In the ...
[74]
Design and realization of WebRTC multicast system based on ...
Aug 6, 2025 · WebRTC and FreeSWITCH are used to achieve the design of multicast system, which is a critical and supporting technique for Internet ...<|separator|>
[75]
Resource allocation for virtual reality content sharing based on 5G D2D multicast communication - EURASIP Journal on Wireless Communications and Networking
### Summary of Multicast for VR/AR Shared Environments (D2D)
[76]
Sidelink-Aided Multiquality Tiled 360° Virtual Reality Video Multicast
Insufficient relevant content. The provided URL (https://ieeexplore.ieee.org/document/9514569) points to a specific IEEE article, but the content snippet provided is incomplete and lacks details about the use of multicast in VR video delivery for shared environments. No full text or abstract is available in the input to summarize.