Hubbry Logo
MulticastMulticastMain
Open search
Multicast
Community hub
Multicast
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Multicast
Multicast
Multicast
View on Wikipedia
from Wikipedia
This article is about one-to-many communications in computer networks. For radio systems, see Point-to-multipoint communication. For broadcasting multiple programs using a single channel, see Multicast channel.
Routing schemes
Unicast

Broadcast

Multicast

Anycast

In computer networking, multicast is a type of group communication where data transmission is addressed to a group of destination computers simultaneously.[1] Multicast can be one-to-many or many-to-many distribution.[2][3] Multicast differs from physical layer point-to-multipoint communication.

Group communication may either be application layer multicast[1] or network-assisted multicast, where the latter makes it possible for the source to efficiently send to the group in a single transmission. Copies are automatically created in other network elements, such as routers, switches and cellular network base stations, but only to network segments that currently contain members of the group. Network assisted multicast may be implemented at the data link layer using one-to-many addressing and switching such as Ethernet multicast addressing, Asynchronous Transfer Mode (ATM), point-to-multipoint virtual circuits (P2MP)[4] or InfiniBand multicast. Network-assisted multicast may also be implemented at the Internet layer using IP multicast. In IP multicast the implementation of the multicast concept occurs at the IP routing level, where routers create optimal distribution paths for datagrams sent to a multicast destination address.

Multicast is often employed in Internet Protocol (IP) applications of streaming media, such as IPTV and multipoint videoconferencing.

Ethernet

[edit]

Ethernet frames with a value of 1 in the least-significant bit of the first octet of the destination address are treated as multicast frames and are flooded to all points on the network. This mechanism constitutes multicast at the data link layer. This mechanism is used by IP multicast to achieve one-to-many transmission for IP on Ethernet networks. Modern Ethernet controllers filter received packets to reduce CPU load, by looking up the hash of a multicast destination address in a table, initialized by software, which controls whether a multicast packet is dropped or fully received.

Ethernet multicast is available on all Ethernet networks. Multicasts span the broadcast domain of the network. Multiple Registration Protocol can be used to control Ethernet multicast delivery.

IP

[edit]
The relationship between the multicast group management protocol family and the multicast routing protocols family based on the network topology terms.

IP multicast is a technique for one-to-many communication over an IP network. The destination nodes send Internet Group Management Protocol membership report and leave group messages, for example in the case of IPTV when the user changes from one TV channel to another. IP multicast 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 take care of replicating the packet to reach multiple receivers only when necessary.

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. By adding loss detection and retransmission mechanisms, reliable multicast has been implemented on top of UDP or IP by various middleware products, e.g. those that implement the Real-Time Publish-Subscribe (RTPS) Protocol of the Object Management Group (OMG) Data Distribution Service (DDS) standard, as well as by special transport protocols such as Pragmatic General Multicast (PGM).

IP multicast is always available within the local subnet. Achieving IP multicast service over a wider area requires multicast routing. Many networks, including the Internet, do not support multicast routing. Multicast routing functionality is available in enterprise-grade network equipment but typically needs to be configured by a network administrator. The Internet Group Management Protocol is used to control IP multicast delivery.

Application layer

[edit]

Application layer multicast overlay services are not based on IP multicast or data link layer multicast. Instead, they use multiple unicast transmissions to simulate a multicast. These services are designed for application-level group communication. Internet Relay Chat (IRC) implements a single spanning tree across its overlay network for all conference groups.[5] The lesser-known PSYC technology uses custom multicast strategies per conference.[6] Some peer-to-peer technologies employ the multicast concept known as peercasting when distributing content to multiple recipients.

Explicit multi-unicast (Xcast) is another multicast strategy that includes addresses of all intended destinations within each packet. As such, given maximum transmission unit limitations, Xcast cannot be used for multicast groups with many destinations. The Xcast model generally assumes that stations participating in the communication are known ahead of time so that distribution trees can be generated and resources allocated by network elements in advance of actual data traffic.[7]

Wireless networks

[edit]

Wireless communications (with the exception of point-to-point radio links using directional antennas) are inherently broadcasting media. However, the communication service provided may be unicast, multicast, or broadcast, depending on if the data is addressed to an individual node, a specific group of nodes, or all nodes in the covered network, respectively.

Wireless networks use electromagnetic waves to transmit data through the air, enabling devices to connect and communicate without physical cables. These networks come in various types, including Wi-Fi, Bluetooth, cellular, and satellite networks, each serving different purposes.

Types of Wireless Communication

[edit]

Unicast: In a unicast wireless communication, data is transmitted from a single source to a single, specific receiver. This is typical in point-to-point communication, where a device sends data directly to another device. Examples include internet browsing or file downloads.

Multicast: In multicast communication, data is sent from one source to multiple specific receivers, often to a defined group within a network. This is efficient in scenarios like live streaming, where the data is only sent once but received by multiple devices interested in the same content.

Broadcast: Broadcast communication involves sending data from one source to all devices within the network's range. In this case, every device receives the same data, regardless of whether it is requested. Examples of broadcast communication include certain emergency alerts and some radio communications.

Security Considerations: Wireless networks are more vulnerable to security threats compared to wired networks, primarily because their signals can be intercepted more easily. Common security measures include encryption protocols such as WPA3 for Wi-Fi networks, firewalls, and the use of Virtual Private Networks (VPNs) to safeguard communication.

Advantages and Challenges: Wireless networks offer flexibility and mobility, allowing users to connect devices without being tethered to a physical connection. However, they can be affected by interference from physical obstacles, environmental factors, or even other wireless devices, leading to slower speeds or connection issues.[8]

Television

[edit]

In digital television, the concept of multicast service sometimes is used to refer to content protection by broadcast encryption, i.e. encrypted pay television content over a simplex broadcast channel only addressed to paying viewers. In this case, data is broadcast to all receivers but only addressed to a specific group.

The concept of interactive multicast, for example using IP multicast, may be used over TV broadcast networks to improve efficiency, offer more TV programs, or reduce the required spectrum. Interactive multicast implies that TV programs are sent only over transmitters where there are viewers and that only the most popular programs are transmitted. It relies on an additional interaction channel (a back-channel or return channel), where user equipment may send join and leave messages when the user changes TV channel. Interactive multicast has been suggested as an efficient transmission scheme in DVB-H and DVB-T2 terrestrial digital television systems,[9] A similar concept is switched broadcast over cable TV networks, where only the currently most popular content is delivered in the cable-TV network.[10] Scalable video multicast in an application of interactive multicast, where a subset of the viewers receive additional data for high-resolution video.

TV gateways converts satellite (DVB-S, DVB-S2), cable (DVB-C, DVB-C2) and terrestrial television (DVB-T, DVB-T2) to IP for distribution using unicast and multicast in home, hospitality and enterprise applications

Another similar concept is Cell-TV, and implies TV distribution over 3G cellular networks using the network-assisted multicasting offered by the Multimedia Broadcast Multicast Service (MBMS) service, or over 4G/LTE cellular networks with the eMBMS (enhanced MBMS) service.

See also

[edit]
Wikiversity has learning resources about Multicast

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Multicast

View on Grokipedia
from Grokipedia
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 from a source to a "host group"—a dynamic set of zero or more hosts identified by a single IP destination address—providing to all group members similar to unicast datagrams. This approach contrasts with , which targets individual hosts, and broadcast, which floods data to all devices on a network; multicast instead directs only to subscribed recipients, conserving bandwidth by avoiding redundant transmissions. IP multicast was pioneered by Steve Deering during the 1980s at as an extension to the (IP) to support efficient one-to-many and many-to-many communications. 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 (IGMP) for managing group memberships. 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. 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. IPv6 multicast embeds similar principles using addresses prefixed with ff00::/8, often derived from unicast prefixes for embedded-RP models. Multicast finds essential applications in bandwidth-intensive scenarios such as video conferencing, , distance learning, , 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 streams, though challenges like firewall traversal, , and inter-domain have historically limited widespread adoption beyond enterprise and research environments. Ongoing IETF efforts continue to address these issues, enhancing support for secure and reliable multicast in modern networks.

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 . Unlike , 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. 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 updates to numerous subscribers. Groups can be transient or permanent, with no limits on size or geographic distribution, supporting scalable, semantics. The origins of multicast trace back to the late 1980s, with foundational work by Steve Deering at , culminating in his 1991 Ph.D. dissertation, which proposed multicast extensions to the (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 . Conceptually, multicast distribution often employs a tree-based model, where the source acts as the , and branches extend to group members via intermediate routers, forming a that optimizes paths and avoids loops. This structure ensures data flows efficiently from the source through shared links to receivers, with of unused branches to further enhance resource use; for example, in a , routers calculate routes based on metrics like distance to minimize latency. Such models underpin multicast's , as the adapts dynamically to membership changes without source involvement.

Comparison to Unicast and Broadcast

Multicast differs from and broadcast in its targeted delivery mechanism for group communications, enabling a single to reach multiple selected recipients efficiently without duplicating transmissions for each one. In , 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 . Broadcast, by contrast, floods the data to all nodes in domain, leading to unnecessary congestion as uninterested devices process the , making it suitable only for small, fully interconnected environments like local area networks. Multicast addresses these limitations by a single stream to a defined group of interested receivers, replicating packets only at branching points in the , which scales well for medium-sized groups where not all nodes need the data. 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. For instance, with 20-40 receivers, multicast achieves 60-70% bandwidth savings over unicast, escalating to around 90% for groups exceeding 1,000 members. Against broadcast, multicast avoids wasteful delivery to non-subscribers, preventing network congestion in larger or segmented topologies where broadcast would overwhelm irrelevant nodes. 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. 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. 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. Broadcast suits simple LAN announcements, such as ARP requests or in small networks, where delivering to all devices is acceptable due to the limited scope. 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 scales as O(n) due to per-recipient streams, and broadcast as O(V) where V is the total number of nodes. 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.

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. When an with a multicast destination is received by a switch, the default forwarding behavior treats it similarly to a broadcast frame. Per bridging specifications, the switch floods the frame out of all ports except the incoming port, ensuring delivery to all potential recipients in the 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 frames. To optimize multicast delivery and mitigate flooding, Ethernet switches often implement , a Layer 2 feature that monitors (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. Despite these optimizations, Ethernet multicast has notable limitations. Without , 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 space restricts the number of unique IPv4 multicast groups that can be distinctly addressed at the 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 . The (PPP), primarily designed for communication over point-to-point links, offers limited multicast support through its Link Control Protocol (LCP) options and extensions for bridging. In scenarios such as (DSL) deployments, where PPP operates in point-to-multipoint configurations like PPP over (PPPoA), multicast traffic is often emulated via broadcast or filtered using the PPP Bridging Control Protocol (BCP), which negotiates multicast group addresses to prevent unnecessary flooding. This approach relies on protocols like GARP Multicast Registration Protocol (GMRP) integrated within BCP to register and filter multicast MAC addresses, ensuring efficient delivery in bridged PPP environments without native point-to-multipoint addressing. Token Ring networks, defined under IEEE 802.5, implement multicast through functional addressing, a mechanism that uses predefined bit patterns in the destination address field to target specific functions or groups across the ring topology. Unlike Ethernet's MAC multicast, Token Ring functional addresses are 48-bit identifiers where certain bits are set to represent group delivery, such as the all-stations functional address (C0-00-00-04-00-00) for broadcast-like multicast or specialized bits for services like ring parameter servers. This allows frames to circulate the ring and be copied by multiple stations matching the functional pattern, with adapters configured to receive specific groups via operations like DLC_ADD_FUNC_ADDR, supporting up to 17 functional address bits for efficient group communication in token-passing environments. multicast over Token Ring maps group addresses to these functional equivalents, ensuring seamless transmission without altering the underlying ring protocol. Asynchronous Transfer Mode () supports multicast at the through point-to-multipoint (VPCs), which enable a single sender to connect to multiple receivers via a shared identifier (VCI) for efficient switching and bandwidth conservation. In ATM Forum UNI 3.0/3.1 specifications, multicast is facilitated by root-initiated join protocols via mechanisms like the Resolution Server (MARS), where the network allocates VCIs to replicate cells at switches without full mesh connections. For integration, architectures like Resolution Server (MARS) use point-to-multipoint VPCs to form VC meshes or server-based trees, reducing connection overhead compared to point-to-point meshes while supporting for QoS-aware multicast flows. Inventory Management further optimizes VCI allocation in these multipoint setups, allowing dynamic scaling for group communications in ATM networks. In modern storage-oriented data link protocols like (FC), multicast is adapted for fabric services using dedicated group identifiers mapped to port world-wide names (WWNs) or domain IDs, supporting up to 256 multicast groups per Virtual (VSAN) alongside a . This enables efficient distribution of management frames, such as queries or zoning updates, across the FC fabric without disrupting storage traffic, with switches computing distribution trees via Fabric Shortest Path First (FSPF) for loop-free delivery. Alias servers maintain these multicast groups by registering node aliases, facilitating targeted delivery in switched FC topologies used for high-performance storage networks.

Network Layer

IP Multicast

operates at the 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 by a . This mechanism relies on special address ranges and protocols for group management, distinct from 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 . 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 or broadcast addresses. This range is exclusively reserved for multicast traffic and cannot be assigned as source addresses or routed as . 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 and not forwarded by routers, supporting protocols like OSPF and . The address 224.0.0.0 itself is reserved and must not be used. IPv6 multicast addresses begin with the prefix ff00::/8, where the initial eight bits are 11111111, providing a 128-bit 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 , derived from a or address by appending its low-order 24 bits to the prefix ff02:0:0:0:0:1:ff00::/104; this supports by allowing efficient address resolution without flooding the network. In IP multicast packet handling, the destination address in the is set to the multicast group address, enabling routers to identify and forward the packet to interested interfaces. The (TTL) field in the 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. 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. Multicast address allocation is managed by the (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 , 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.

Multicast Routing Protocols

Protocol Independent Multicast (PIM) is a widely adopted family of multicast protocols designed to distribute traffic efficiently across routers by leveraging the underlying information base or a separate multicast information base. PIM operates without assuming a specific protocol, making it versatile for various network environments. It supports the construction of distribution trees to forward packets from sources to receivers, minimizing duplication and bandwidth usage. 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. 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. 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 (RPF) checks. The RP is discovered through mechanisms like Bootstrap Routers (BSR) or static configuration, ensuring scalability in inter-domain scenarios. In contrast, PIM Dense Mode (PIM-DM) assumes multicast group members are densely populated, initially flooding traffic to all interfaces and relying on messages to suppress forwarding on branches without receivers, thus building source-based trees through a flood-and-prune cycle. PIM-DM uses the multicast routing information base (MRIB) derived from tables for RPF to prevent loops during flooding, with Graft messages allowing pruned branches to rejoin when new receivers appear. 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. Multicast OSPF (MOSPF) extends the OSPF 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. 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 and membership. Upon receiving a , a router calculates a pruned SPT rooted at the source using on the enhanced link-state database, caching the tree for subsequent packets and replicating data only at branch points to optimize paths. MOSPF supports inter-area via summary LSAs and wild-card receivers but is limited to single autonomous systems due to its reliance on full visibility. Core-Based Trees (CBT) version 2 employs a bidirectional shared architecture per multicast group, centered on a core router to minimize per-group state across the network and reduce overhead in large-scale deployments. 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. 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. CBT's shared design suits both intra- and inter-domain by limiting state to on-tree routers only, though it may introduce higher latency compared to source-based approaches. 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. MP-BGP carries multicast 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. It integrates with route reflectors to scale within ASes, supporting the distribution of multicast forwarding entries without requiring separate protocols for inter-domain exchanges. 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. 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. 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. These updates, revising earlier specifications, enhance adaptability to changes via triggered updates and override timers, ensuring faster tree maintenance in dynamic wide-area networks.

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 tunnels to replicate and forward packets among group members. This overlay abstraction allows applications to manage group membership, , and distribution independently of the underlying IP infrastructure. 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 is unavailable or restricted. This flexibility has enabled widespread use in systems and applications on the public , where rapid adoption without administrative intervention is essential. Additionally, ALM supports customizable features at the , such as tailored congestion control and reliability mechanisms, enhancing adaptability to diverse network conditions. Despite these benefits, ALM incurs notable limitations compared to native multicast solutions. The overlay structure introduces additional latency from extra forwarding , 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 utilization than network-layer multicast.

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 , 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. NICE (Nebulous Infrastructure for Conferencing Experiments) is a protocol designed for scalable ALM, organizing participating hosts into a tree-like structure with bounded 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 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 shortest path) in Internet-like topologies. 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 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. 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.

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. 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. 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. 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.

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 due to interference and 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. 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. In networks, multicast transmissions lack automatic repeat requests (ARQ) unlike , 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 (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 (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 New Radio (NR), 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. In low-power wireless sensor networks, directed provides a data-centric where interests (queries for specific ) are diffused throughout 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. This pull-based mechanism caches and propagates event along multiple paths, allowing adaptive rerouting around failures while minimizing global state maintenance.

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 fundamentals at the network layer. The transition from analog to digital multicast systems began in the , driven by the development of standards that allowed for more efficient spectrum use and higher-quality video delivery. This shift was marked by the formation of the Project in 1993, which standardized digital transmission for , cable, and terrestrial networks, incorporating multicast capabilities to support widespread adoption of digital TV services across and beyond. In systems, multicast IP is utilized for and cable distribution, encapsulating transport streams over UDP to deliver compressed video and audio to multiple endpoints with minimal duplication. 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 specifications, such as ETSI TS 102 034, define the transport of these -based services over IP-based networks, facilitating seamless integration of multicast in traditional infrastructures. For (IPTV), multicast enables efficient channel delivery in managed networks, with the (IGMP) handling group membership for channel zapping, allowing users to join or leave multicast streams rapidly during live viewing. Session management in IPTV systems often employs the (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. The 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. 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 . This protocol stack allows broadcasters to deliver multiple streams within a single channel, enhancing capacity for high-definition services. Overall, multicast in and television significantly reduces bandwidth requirements compared to 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. This efficiency has been crucial in scaling digital TV distribution since the , minimizing infrastructure costs while maintaining service quality for mass audiences.

Other Network Applications

In online gaming, particularly massively multiplayer online role-playing games (MMORPGs), 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. 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. Service discovery protocols leverage multicast for in home and local environments. (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 () on UDP port 5353, allowing automatic detection without a central DNS server. Similarly, the (SSDP) in (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. In stock trading, delivers real-time market data feeds efficiently to multiple subscribers, minimizing bandwidth usage for high-frequency updates. employs UDP/ protocols, such as , to distribute depth and trade information across dedicated multicast groups, enabling low-latency dissemination to traders and vendors. Videoconferencing utilizes multicast for multi-party sessions to scale media distribution. The (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. 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. Emerging applications in (VR) and (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 , through optimized power and channel allocation. Sidelink-aided multicast further enhances tiled 360° VR video delivery in shared scenarios by supporting multi-quality streams over links, adapting to user viewpoints and channel conditions for scalable group immersion.

References

  1. https://datatracker.ietf.org/doc/html/rfc1112
  2. https://ethw.org/Stephen_Deering
  3. https://datatracker.ietf.org/doc/html/rfc6308
  4. https://datatracker.ietf.org/doc/html/rfc2588
  5. https://www.ietf.org/archive/id/draft-ietf-pim-multicast-lessons-learned-03.html
  6. https://sites.cs.ucsb.edu/~almeroth/papers/033.pdf
  7. https://www.dpss.inesc-id.pt/~ler/docencia/prd0506/papers/stardust00survey.pdf
  8. https://www.sciencedirect.com/topics/computer-science/multicast-tree
  9. https://book.systemsapproach.org/scaling/multicast.html
  10. https://www.haivision.com/blog/all/broadcast-unicast-multicast-explained/
  11. http://web.cs.ucla.edu/classes/fall03/cs218/paper/12_4.pdf
  12. https://datatracker.ietf.org/doc/html/rfc4541
  13. https://www.rfc-editor.org/rfc/rfc3518.html
  14. https://datatracker.ietf.org/doc/html/rfc2470
  15. https://datatracker.ietf.org/doc/html/rfc2022
  16. https://datatracker.ietf.org/doc/html/rfc2149
  17. https://datatracker.ietf.org/doc/html/rfc2382
  18. http://www.cisco.com/en/US/docs/storage/san_switches/mds9000/sw/rel_2_x/san-os/configuration/guide/fspf.html
  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. https://www.iana.org/assignments/multicast-addresses
  21. https://datatracker.ietf.org/doc/html/rfc3376
  22. https://datatracker.ietf.org/doc/html/rfc3810
  23. https://datatracker.ietf.org/doc/html/rfc5771
  24. https://datatracker.ietf.org/doc/html/rfc2365
  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. https://datatracker.ietf.org/doc/html/rfc3973#section-4.2
  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. https://datatracker.ietf.org/doc/html/rfc1584#section-12.2
  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. https://datatracker.ietf.org/doc/html/rfc2189#section-7
  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. https://datatracker.ietf.org/doc/html/rfc8279
  44. https://datatracker.ietf.org/doc/html/rfc7761#section-4.6.4
  45. https://datatracker.ietf.org/doc/html/rfc7761#section-4.5.7
  46. http://www.eecs.ucf.edu/courses/cop6731/assigments/papers/P2PMulticast.pdf
  47. https://www.researchgate.net/publication/3454678_A_Survey_of_Application-Layer_Multicast_Protocols
  48. https://conferences.sigcomm.org/sigcomm/2002/papers/appmulti.pdf
  49. https://dl.acm.org/doi/10.1145/345063.339337
  50. https://datatracker.ietf.org/doc/html/rfc7019
  51. https://ieeexplore.ieee.org/document/1311844
  52. https://www.sciencedirect.com/science/article/pii/S092054891500046X
  53. https://www.rfc-editor.org/rfc/rfc9119.html
  54. https://www.cs.montana.edu/courses/spring2009/541/HW/HW1/Summer-Multicast.pdf
  55. https://people.cs.vt.edu/~irchen/6204/paper/Viswanath-TMC06.pdf
  56. https://onlinelibrary.wiley.com/doi/abs/10.1002/wcm.129
  57. https://link.springer.com/article/10.1023/A:1016631911947
  58. https://www.3gpp.org/technologies/broadcast-multicast1
  59. https://dl.acm.org/doi/10.1145/345910.345920
  60. https://dvb.org/wp-content/uploads/2019/12/History-of-the-DVB-Project.pdf
  61. https://www.itu.int/dms_pub/itu-r/opb/rep/r-rep-bt.2140-3-2011-pdf-e.pdf
  62. https://dvb.org/wp-content/uploads/2019/12/A086_DVB-MPEG2_over_IP_Oct2015.pdf
  63. https://www.researchgate.net/publication/224543774_Analysis_and_characterization_of_IPTV_user_behavior
  64. https://www.oipf.tv/web-spec/volume4a.html
  65. https://www.atsc.org/wp-content/uploads/2017/10/A300-2017-ATSC-3-System-Standard-1.pdf
  66. https://www.rfc-editor.org/rfc/rfc9223.html
  67. https://koovik.com/en/2018/09/21/iptv-broadcast-multicast-unicast-streaming/
  68. https://people.eecs.berkeley.edu/~sylvia/papers/frm-sigcomm06.pdf
  69. https://www.rfc-editor.org/rfc/rfc6762.html
  70. https://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
  71. https://www.nasdaqtrader.com/Trader.aspx?id=FeedIPS_Other
  72. https://datatracker.ietf.org/doc/html/rfc4353
  73. https://www.researchgate.net/publication/321107238_Design_and_realization_of_WebRTC_multicast_system_based_on_genetic_selection_and_consistent_hashing
  74. https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-020-01690-9
  75. https://ieeexplore.ieee.org/document/9514569
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.