Packet Delivery - Learning Module

Loading content...

0/228

Multicast Delivery

Efficient One-to-Many Communication

Consider a video streaming scenario: a live sports event is watched by 10 million viewers simultaneously. How should the network deliver this content?

Unicast approach: The server sends 10 million individual copies—one to each viewer. This requires massive server bandwidth and creates enormous network load.

Broadcast approach: The server sends one copy that reaches everyone on the network. But most people aren't watching—they're interrupted anyway. And broadcast can't cross network boundaries.

Multicast approach: The server sends one copy. The network intelligently replicates it, but only to viewers who explicitly requested to receive the stream. Non-viewers are untouched. Network infrastructure handles efficient distribution.

Multicast delivery represents the elegant middle ground between unicast and broadcast: targeted one-to-many communication that scales efficiently while respecting the attention of uninterested hosts.

What You Will Learn

By the end of this page, you will understand: (1) The definition and advantages of multicast delivery, (2) How multicast addresses are structured in IPv4 and IPv6, (3) The group membership protocol (IGMP) and how hosts join/leave groups, (4) How routers forward multicast traffic, (5) Real-world applications that depend on multicast, and (6) The challenges of deploying multicast across the Internet.

Defining Multicast Delivery

Multicast delivery is the process of sending a single packet from one source to a specific group of interested receivers. The network infrastructure handles replication—the source sends only once, and intermediate routers copy the packet only where needed to reach group members.

The term 'multicast' combines 'multi' (many) with 'cast' (to send), indicating transmission to multiple (but not all) recipients. This stands in contrast to:

Unicast: One sender, one receiver
Broadcast: One sender, all receivers on a network
Multicast: One sender, a selected group of receivers

Multicast Delivery Characteristics
Characteristic	Description	Implication
Source Count	One or more senders	Sources don't need to know receivers
Destination Count	All group members	Only interested hosts receive traffic
Address Type	Class D / multicast address	224.0.0.0–239.255.255.255 (IPv4)
Group Membership	Dynamically managed	Hosts join/leave via IGMP (IPv4) or MLD (IPv6)
Replication	Network handles duplication	Sender bandwidth independent of receiver count
Routing	Specialized multicast routing	Builds distribution trees for efficient delivery

The Key Insight: Receiver-Driven

Unlike unicast (where senders must know and address each receiver), multicast is receiver-driven. Sources simply send to a group address. Receivers express interest by joining the group. The network connects interested receivers to available sources. This decoupling is powerful: a source can send without knowing how many (or which) hosts are listening.

The Conceptual Model

Multicast uses a publish-subscribe model:

Sources publish data to a multicast group address
Receivers subscribe to groups they're interested in
The network routes data from sources to subscribers
Reception is dynamic — hosts can join or leave anytime

This model abstracts receiver management away from applications. A video source doesn't track each viewer—it simply transmits to a group address, and the network handles delivery to whoever is subscribed.

Multicast Address Space

Multicast uses special address ranges reserved exclusively for group communication. These addresses don't identify individual hosts—they identify groups that hosts can choose to join.

IPv4 Multicast Addresses (Class D)

IPv4 reserves the Class D address range (224.0.0.0 to 239.255.255.255) for multicast. These addresses are identified by their first four bits being 1110.

IPv4 Multicast Address Structure
IPv4 Multicast Address Range: 224.0.0.0 – 239.255.255.255
 
Binary pattern:
  Class D prefix: 1110 (first 4 bits)
  
  1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
  ├──┤├────────────────────────────────┤
  Class D   28-bit Group ID
  identifier
  
Address range breakdown:
 
  224.0.0.0 – 224.0.0.255     Local Network Control
      ├── 224.0.0.1           All Hosts (on this segment)
      ├── 224.0.0.2           All Multicast Routers
      ├── 224.0.0.5           OSPF: All Routers
      ├── 224.0.0.6           OSPF: Designated Routers
      ├── 224.0.0.9           RIPv2 Routers
      └── 224.0.0.251         mDNS (Multicast DNS)
      
  224.0.1.0 – 224.0.1.255     Internetwork Control
      └── 224.0.1.1           NTP (Network Time Protocol)
      
  232.0.0.0 – 232.255.255.255 Source-Specific Multicast (SSM)
  
  233.0.0.0 – 233.255.255.255 GLOP Addresses (AS-based)
  
  239.0.0.0 – 239.255.255.255 Administratively Scoped
      └── Private/internal multicast (like RFC 1918 for unicast)

IPv6 Multicast Addresses

IPv6 was designed with multicast as a core feature (replacing broadcast entirely). IPv6 multicast addresses are identified by the prefix FF00::/8.

IPv6 Multicast Address Structure
Field	Bits	Description
Prefix	8	Always FF (binary 11111111)
Flags	4	Well-known (0) vs transient (1), etc.
Scope	4	1=node, 2=link, 5=site, 8=org, E=global
Group ID	112	Identifies the specific group

IPv6 Multicast Examples
IPv6 Multicast Address Format:
  FF02::1    = FF:02::0000:0000:0000:0001
                ││ │  └──────────────────────┘
                ││ │         Group ID
                ││ └── Scope: 2 = link-local
                │└──── Flags: 0 = well-known
                └───── Prefix: FF = multicast
 
Common IPv6 Multicast Addresses:
 
  Link-Local Scope (scope = 2):
    FF02::1   All nodes (replaces IPv4 broadcast)
    FF02::2   All routers
    FF02::5   OSPF: All routers
    FF02::6   OSPF: Designated routers
    FF02::9   RIPng routers
    FF02::FB  mDNS
    
  Solicited-Node (for Neighbor Discovery):
    FF02::1:FFxx:xxxx  (xx:xxxx from last 24 bits of target)
    
  Global Scope (scope = E):
    FF0E::XX  Globally routable multicast groups

Scope Control in IPv6

IPv6 multicast has built-in scope limiting. A link-local multicast (scope=2) will NEVER leave the local network segment. Site-local (scope=5) stays within an organization. This is enforced by the addressing itself—routers check the scope field and limit forwarding accordingly. IPv4 requires TTL-based scoping, which is less elegant.

Layer 2 Multicast Mapping

For multicast to function at the network layer, it must be supported at the data link layer. Ethernet provides multicast capability through special MAC addresses that map from IP multicast addresses.

IPv4 Multicast to Ethernet Mapping

Ethernet multicast addresses are identified by having the least significant bit of the first byte set to 1 (the 'I/G bit'). IPv4 multicast addresses are mapped to Ethernet using the IANA-assigned OUI prefix 01:00:5E:

IPv4 to Ethernet Multicast Mapping
IPv4 Multicast to Ethernet MAC Address Mapping
═══════════════════════════════════════════════
 
IEEE assigned OUI for IPv4 multicast: 01:00:5E
 
Mapping process:
  1. Start with 01:00:5E:0 (25 bits fixed)
  2. Map lower 23 bits of IPv4 multicast address
  3. Result: 48-bit Ethernet multicast address
 
Example: IPv4 multicast 239.192.100.50
 
  IPv4 address:  239.192.100.50
  Binary:        11101111.11000000.01100100.00110010
                 ────────────────────────────────────
                 Upper 5 bits    Lower 23 bits
                 (ignored)       (mapped)
                 
  Lower 23 bits: 1000000.01100100.00110010
                 └──────────────────────────┘
                        0x40:64:32
 
  Ethernet MAC:  01:00:5E:40:64:32
                 └─────────┘└──────────────┘
                 Fixed OUI  Lower 23 bits
 
IMPORTANT: This creates ambiguity!
  32 IP addresses map to each MAC address
  (5 bits are lost in the mapping)
  
  Example: Both 224.0.0.1 and 225.0.0.1 map to 01:00:5E:00:00:01
           Hosts must filter at IP layer

The 32:1 Ambiguity Problem

Because the mapping loses 5 bits, 32 different IP multicast groups map to the same Ethernet MAC address. This means hosts receive multicast traffic for 32 groups at the NIC level and must filter at the IP layer. While usually not a problem, in extreme multicast environments this can cause unnecessary CPU load.

IPv6 Multicast to Ethernet Mapping

IPv6 uses a more straightforward mapping with 4 bytes of the group ID preserved:

IPv6 to Ethernet Multicast Mapping
IPv6 Multicast to Ethernet MAC Address Mapping
═══════════════════════════════════════════════
 
Ethernet prefix for IPv6 multicast: 33:33
 
Mapping: 33:33:XX:XX:XX:XX
         └────┘└──────────────────────┘
         Fixed  Lower 32 bits of IPv6 multicast address
 
Example: FF02::1 (All Nodes)
  IPv6:  FF02:0000:0000:0000:0000:0000:0000:0001
  Lower 32 bits: 00:00:00:01
  Ethernet MAC:  33:33:00:00:00:01
 
Example: FF02::1:FFxx:xxxx (Solicited-Node for host ending in 01:02:03)
  IPv6:  FF02::1:FF01:0203
  Lower 32 bits: FF:01:02:03
  Ethernet MAC:  33:33:FF:01:02:03
 
Advantage over IPv4 mapping:
  - Preserves more bits (32 vs 23)
  - Less ambiguity (though still some overlap possible)

Group Membership: IGMP

How do hosts express interest in receiving multicast traffic? How do routers know which networks have interested receivers? The answer is IGMP (Internet Group Management Protocol)—the protocol that manages multicast group membership between hosts and their local routers.

IGMP Overview

IGMP operates between hosts and their first-hop router (the multicast router on their local network). It doesn't route multicast traffic—it simply informs the local router about group membership so the router knows whether to request multicast traffic from upstream.

IGMP Version Comparison
Feature	IGMPv1	IGMPv2	IGMPv3
RFC	RFC 1112	RFC 2236	RFC 3376
Explicit Leave	No (timeout only)	Yes (Leave Group message)	Yes
Group-Specific Query	No	Yes	Yes
Source Filtering	No	No	Yes (SSM support)
Query Interval	Fixed	Configurable	Configurable
Leave Latency	Up to 3 mins	Seconds	Seconds

IGMP Message Types (v2)
IGMP Operation Flow
════════════════════
 
1. MEMBERSHIP QUERY (Router → Hosts)
   ┌──────────────────────────────────────────────────┐
   │ Router periodically asks: "Who wants multicast?" │
   │ Destination: 224.0.0.1 (all hosts)              │
   │ Purpose: Discover active group memberships       │
   └──────────────────────────────────────────────────┘
 
2. MEMBERSHIP REPORT (Host → Router)
   ┌──────────────────────────────────────────────────┐
   │ Host responds: "I want group 239.1.2.3"         │
   │ Destination: The multicast group address         │
   │ Purpose: Announce/maintain group membership      │
   └──────────────────────────────────────────────────┘
 
3. LEAVE GROUP (Host → Router) [v2+]
   ┌──────────────────────────────────────────────────┐
   │ Host announces: "I'm leaving group 239.1.2.3"   │
   │ Destination: 224.0.0.2 (all multicast routers)  │
   │ Purpose: Expedite leave processing              │
   └──────────────────────────────────────────────────┘
 
Typical exchange:
 
  Time 0   Router ──[Query]──────► All Hosts (224.0.0.1)
  Time 1   Host A ──[Report 239.1.2.3]──► (239.1.2.3)
  Time 1   Host B ──[Report 239.1.2.3]──► (suppressed - already reported)
  ...
  Time 60  Router ──[Query]──────► All Hosts
  Time 61  Host A ──[Report 239.1.2.3]──► (maintains membership)
  Time 62  Host B ──[Leave 239.1.2.3]───► All Routers (224.0.0.2)
  Time 63  Router ──[Group-Specific Query 239.1.2.3]──► (239.1.2.3)
  Time 64  Host A ──[Report]──► (Host A still wants it)
  Time 65  Router maintains group on this interface

Report Suppression Mechanism

To reduce network traffic, IGMP includes a clever optimization: report suppression. When a host hears another host's Membership Report for the same group, it cancels its own pending report. This means only one report is sent per group per query, regardless of how many hosts are members.

The process:

Router sends Query
Each interested host sets a random timer (0 to Max Response Time)
When timer expires, host sends Report
Other hosts listening to that group hear the Report
Those hosts cancel their timers—no need to send duplicate reports

IPv6 Uses MLD Instead

IPv6 uses MLD (Multicast Listener Discovery) instead of IGMP. MLD is functionally identical to IGMP but is implemented as ICMPv6 messages rather than a separate protocol. MLDv1 corresponds to IGMPv2, and MLDv2 corresponds to IGMPv3 (with source filtering for SSM).

Multicast Routing Basics

While IGMP handles local group membership, multicast routing protocols handle the distribution of multicast traffic across networks. These protocols build distribution trees that efficiently deliver packets from sources to all interested receivers.

Distribution Tree Concepts

Unlike unicast routing (which finds a single path to one destination), multicast routing must build a tree structure that branches to reach all receivers efficiently.

Source-Based Trees

•Separate tree for each source
•Optimal path from source to receivers
•More state in routers (one entry per source)
•Notation: (S, G) tree
•Better for few sources, many receivers
•Used by DVMRP, MOSPF

Shared Trees

•Single tree shared by all sources
•Traffic flows through Rendezvous Point (RP)
•Less router state (one entry per group)
•Notation: (*, G) tree
•May have suboptimal paths
•Used by PIM-SM, CBT

Converting Mermaid diagram...

PIM (Protocol Independent Multicast)

The most widely deployed multicast routing protocol is PIM (Protocol Independent Multicast). It's called 'protocol independent' because it uses the existing unicast routing table (from any unicast protocol) to make reverse-path decisions.

PIM Modes:

PIM Dense Mode (PIM-DM): Assumes all networks want multicast. Floods traffic everywhere, then prunes branches with no receivers. Good for dense receiver populations.
PIM Sparse Mode (PIM-SM): Assumes most networks don't want multicast. Receivers explicitly join via shared tree, can switch to source tree for efficiency. Good for sparse receiver populations (most deployments).
PIM Source-Specific Multicast (PIM-SSM): Receivers specify both group AND source. Simplifies routing, eliminates need for RP. Used for applications with known sources (like IPTV).

Reverse Path Forwarding

Multicast routing uses Reverse Path Forwarding (RPF): a router only accepts multicast from an interface if that interface is on the shortest path BACK to the source. This prevents loops without needing TTL decrementation at each hop. If a packet arrives on the 'wrong' interface, it's dropped as a presumed duplicate.

Real-World Multicast Applications

Multicast enables applications that would be impractical with unicast alone. Let's examine where multicast provides significant value.

Multicast-Enabled Applications

•IPTV and Video Distribution — Cable and IPTV providers use multicast to deliver hundreds of TV channels to millions of subscribers. Each channel is a multicast group; your set-top box joins groups for channels you watch. One stream per channel regardless of viewers.
•Live Streaming (Enterprise) — Corporate live events (all-hands meetings, training) within an enterprise network use multicast to avoid overwhelming the source. 10,000 employees can watch one stream.
•Financial Data Feeds — Stock exchanges distribute market data via multicast. Every broker receives the same real-time feed simultaneously. Latency is equal for all participants—essential for fairness.
•Software Distribution — Large-scale OS or application updates deployed via multicast to thousands of workstations simultaneously. One transmission updates an entire campus.
•Routing Protocol Updates — OSPF, RIPv2, and other routing protocols use multicast to distribute updates to all routers. 224.0.0.5 (OSPF All Routers) avoids bothering non-routers.
•Service Discovery — mDNS (224.0.0.251), SSDP (239.255.255.250), and similar protocols use multicast for local service discovery. Printers, speakers, and IoT devices announce their presence.

Multicast Efficiency Example: Corporate Live Stream
Approach	Source Bandwidth	Network Load	Scalability
Unicast to 10,000 employees	10,000 × 5 Mbps = 50 Gbps	Heavy duplication	Limited by source capacity
Multicast to 10,000 employees	1 × 5 Mbps = 5 Mbps	Replicated at branches	Essentially unlimited
Savings Factor	10,000× less at source	Varies by topology	Dramatically better

Why Isn't Netflix Using Multicast?

You might wonder why streaming giants like Netflix use unicast CDNs instead of multicast. The reasons: (1) Internet-wide multicast isn't deployed — ISPs don't support multicast transit, (2) On-demand viewing — each viewer watches at different times/positions, requiring unique streams, (3) Adaptive bitrate — each viewer needs different quality based on their bandwidth. Multicast excels for live, synchronized content within controlled networks, not for on-demand Internet streaming.

Challenges and Limitations

Despite its efficiency advantages, multicast faces significant deployment challenges that have limited its adoption to specific environments.

Why Multicast Isn't Everywhere

Multicast Deployment Challenges

•ISP Support Lacking — Most Internet Service Providers don't enable multicast routing between networks. Multicast generally works only within a single administrative domain (enterprise, campus, ISP internal network).
•Complex State Management — Routers must maintain state for every active (S, G) or (*, G) entry. In large deployments, this can consume significant memory and processing resources.
•Difficult Troubleshooting — Multicast problems are harder to diagnose than unicast. Traffic flows through dynamic trees that change as receivers join/leave. Standard tools like ping and traceroute don't work the same way.
•Security Concerns — Any host can join any group—there's no built-in access control. Unauthorized receivers can capture sensitive multicast streams. Authentication is challenging.
•Reliability is Complex — Multicast is inherently unreliable (like UDP). Implementing reliable multicast requires application-layer protocols that handle NAKs and retransmissions for potentially thousands of receivers.
•Group Address Management — Who assigns multicast addresses? How do you ensure group addresses don't collide across organizations? This administrative overhead deters adoption.

Where Multicast Thrives vs. Struggles

Multicast Succeeds When

•Single administrative domain
•Controlled network infrastructure
•Live, synchronized content
•Large receiver populations
•Bandwidth is constrained
•Enterprise or service provider networks

Multicast Struggles When

•Crossing ISP boundaries
•On-demand/personalized content
•Reliability is critical
•Strong security required
•Dynamic source discovery needed
•Public Internet deployment

The Overlay Alternative

Given the difficulty of native multicast deployment, many applications use application-layer multicast or overlay networks. Systems like WebRTC mesh, BitTorrent, and CDN architectures create multicast-like efficiency using unicast connections. The network doesn't natively replicate—application nodes do. Less efficient than native multicast, but deployable over any IP network.

Summary: Multicast Delivery

We've explored multicast delivery comprehensively. Let's consolidate the essential knowledge:

Key Takeaways

•Multicast is one-to-group communication — Sources send once; the network replicates to interested receivers. Efficient for one-to-many scenarios.
•Class D addresses (224.0.0.0–239.255.255.255) — IPv4 reserves this range for multicast groups. IPv6 uses FF00::/8 with built-in scope.
•IGMP manages local membership — Hosts join/leave groups via IGMP; routers learn which groups have local interest. IPv6 uses MLD instead.
•Distribution trees route multicast — PIM and other protocols build source-based or shared trees to deliver packets efficiently across networks.
•Receiver-driven model — Sources don't need to know receivers. Receivers subscribe; the network connects them.
•Deployment challenges limit adoption — Inter-ISP multicast isn't deployed; security, reliability, and management are complex. Multicast thrives within enterprises, not across the public Internet.
•Real applications — IPTV, enterprise video, financial feeds, routing protocols, and service discovery all leverage multicast's efficiency.

What's next:

We've covered unicast (one-to-one), broadcast (one-to-all), and multicast (one-to-many). But there's one more delivery type that flips the model entirely: anycast—where multiple servers share the same address, and the network delivers to the nearest one. This mechanism powers global services like DNS root servers and CDNs.

Page Complete

You now understand multicast delivery—from addressing and group management to routing and real-world applications. This knowledge is essential for understanding scalable content delivery and network service architectures. Next, we'll explore anycast's unique approach to geographic load distribution.