Multicast

Henning Schulzrinne
Dept. of Computer Science
Columbia University
Fall 2003
Overview

 IP multicast service models

– any source, source-specific multicast, …
 Multicast protocol components
– address assignment
– local group management
– intra- and inter-domain routing
 Programming IP multicast applications
Multicast service models

 Basic idea: same data needs to reach multiple

receivers  avoid transmitting it once for each
receiver
– particularly useful if access link has bandwidth limitations
– can be implemented at link, network and application layer
– e.g., mailing list as example
 Variations: reach unknown destination by
membership (“foo server”) rather than address 
also anycast
*Cast

 Broadcast = all nodes on (small, local)

network
 Directed broadcast = copies to all hosts on
remote network
– DDOS  not supported any more (RFC 2644)
 Multicast = copies to >= 1 hosts (group)
 Anycast = packet to 1 of N hosts
Diversion: Anycast
 RFC 1546 (“Host Anycasting Service”)
– RFC 2373 (“IP Version 6 Addressing Architecture”)
 “locate a host which supports a particular service but, if several servers support
the service, does not particularly care which server is used.”
 Example uses:
– DNS root servers (F.root-servers.net = 192.5.5.241 ); see http://www.isc.org
 root servers are hard-configured in DNS resolvers
 272 million queries a day
– all access routers providing Internet service
 Anycast  deliver to single host
– special form of unicast routing
– deliver to nearest host (by routing metric)
 Multicast  deliver to >= 1 host (and maybe get answers from > 1 host)
Anycast routing

 Assign same address within subnet

– supernet is advertised either globally (“global nodes”) or
locally (“local nodes”)
– advertise whole prefix, not just single address  avoid
route filtering
 BGP automatically ensures routing to closest local or
global node
 Distributes (or localizes) denial-of-service traffic
 Does not scale well due to address usage (unless all
services within the same subnet)
Multicast applications

 audio-video distribution (1-to-many)

 audio-video conferences (all-to-all)
 distributed simulation (war gaming, multi-player
Doom, …)
 resource discovery (where’s the next time server?)
– instances of resource identified by multicast address
 file distribution (stock market quotes, new software
releases, OS patches, …)
 network news (Usenet)
Multicast trees
 spanning tree ≡ tree that connects all vertices
– vertices = hosts and routers
 shared tree = single tree for all sources S
– minimum cost spanning tree (MST)
 minimum-weight tree in a weighted graph which contains all of
the graph's vertices
 cost = hops, delay, transmission cost ($), …
– does not minimize length of S to individual destination
– all traffic concentrated on tree  reservation failure
 per-source tree
– build independently for each source
Multicast trees – Steiner trees

 “given a weighted graph in which a subset of

vertices are identified as terminals, find a minimum-
weight connected subgraph that includes all the
terminals”
 Differs from MST in that Steiner vertices must be
identified
 NP-complete problem (see traveling salesman)
– unstable: small additions to graph  large changes in traffic
flows
Finding MST via Prim’s algorithm

 centralized, finds MST for G = (V,E)

 U: set of vertices connected, start with one
 add lowest-cost edge (u,v) with u  U and v
in V – U
 tree T  T  (u,v)
 UUv
Connection-oriented multicast
 enumerate sources explicitly  source-based tree
 examples:
– ATM: explicitly add each end point to tree
– ST-II (IPv5): enumerate end points in setup message
– End nodes can also attach themselves to tree
 only connection-oriented  enumeration only in setup message
 source needs to know destinations
– resource discovery not possible
– dynamic groups difficult
 but: natural transition from 2-party to N-party
– same routing algorithm
Host group model

 Multicast service model

 S. Deering, 1991 (RFC 1112)
– senders need not be members
– groups may have any number of members
– there are no topological restrictions on group membership
– membership is dynamic and autonomous
– host groups may be dynamic or permanent
  receiver-driven model
– “subscriptions”
Local multicast
 Some local networks are by (original) nature multicast or
broadcast:
– Ethernet: original coax contention (CDMA), 802.11 wireless
 need to emulate in Ethernet switches
– token ring
– FDDI
– wireless links (BlueTooth, cellular), powerline networks
 Ethernet, token ring:
– broadcast: all-1 address
– multicast: 01.xx.xx.xx.xx.xx
– adapter hardware can filter dynamic list of addresses
 ATM: point-to-point links  ATM multicast server or replication
in switches
IP multicast: model & addresses
 host-group model
 network level: data packets remain same, only address changes
 need help from routers to replicate and route
 special IP addresses (class D): 224.0.0.0 through 239.255.255.255 (224/4)
– 28 bits  268 million groups
– in addition, scoping
 224.0.0.x: local network only
– 224.0.0.1: all hosts
– 224.0.0.2: all routers
 224.0.1.x: internetwork control block
 224.0.2.0-224.0.255.0: ad-hoc
 224.2.0.0-224.2.255.255: SDP/SAP block
 some pre-assigned by IANA
 map into Ethernet: 01.00.5E.00.00.00 + lower 23 bits
IP multicast scope
 Avoid accidental distribution to whole Internet
 IP TTL value: 0 = host, 1 = network
 Others to reach larger groups
– but “split horizon problem” (RFC 2907)
– pruning (see later) may fail: larger TTL later
 Administrative scoping (RFC 2365)
– 239.0.0.0 to 239.255.255.255
– RFC 1884 for IPv6 (16 scopes)
– link-local scope
– IPv4 local scope
– organization local scope
– global scope
 relative addresses (from top) for common applications within scope
IP multicast protocols

 tree construction protocol  PIM-SM, PIM-DM

 advertise reverse paths towards sources 
Multiprotocol Border Gateway Protocol (MBGP)
 disseminate information about sources  Multicast
Source Discovery Protocol (MSDP)
 hosts dynamically join and leave multicast groups 
Internet Group Management Protocol (IGMP)
– IGMPv2: specify host group
Multicast model problems
 Host group model now known as Any Source Multicast (ASM)
– variant: source-filtered multicast (SFM)
– hosts can request data for group G only for specific set of sources
– or exclude list of sources
  IGMPv3 for IPv4 and MLD (listener discovery) for IPv6
 host of problems have prevented large-scale deployment:
– attacks against multicast groups by unauthorized transmitters
– deployment complexity
– problems of allocating scarce global class-D IP addresses
– lack of inter-domain scalability
– single point-of-failure problems

K. Almeroth, S. Bhattacharyya, C. Diot, “Challenges of Integrating ASM and SSM

IP Multicast Protocol Architectures”
Source-Specific Multicast (SSM)

 receiving host explicitly specifies the address

of the source it wants to receive from
– in addition to multicast group
 support one-to-many multicast
 address range 232/8, ff2x:: and ff3x::
 IGMPv3: allow source specification
 remove complexity from network layer 
application layer (where needed)
SSM, cont’d.

 distribution tree for channel (S,G) rooted at S

– no shared tree infrastructure
 no need for MSDP
 only a single source can transmit
– avoid access control problem
– avoid forwarding unwanted data (cf. SFM)
– addresses local to each source  no global address
allocation needed
 for large groups, often single source
– or dominated by single source
Xcast
 “providing for many groups of small conferences (a small
number of widely dispersed people) with global topological
scope scales badly given the current multicast model” (IAB
workshop report)
 Large number of small groups:
– three-party calls
– small interactive conferences
– networked games
  explicitly enumerate addresses in IP header
 each router looks up all addresses
– group by interface
– remote addresses that don’t apply (why?)
Xcast

 Thus, sender-driven model

 Advantages:
– no session setup needed
– no address allocation
– known set of destinations: simplifies accounting,
access control
RPF – Reverse path forwarding

 Normal (unicast) routing:

look up destination address
in routing table
– forward to listed outgoing
interface
 RPF: look up source
address in IP routing table
– only forward if packet
arrived on that interface
– strictly correct only for
symmetric routes Cisco IP multicast technology overview
PIM-DM

 Uses unicast routing protocols (unlike

DVMRP)
 push model  send traffic everywhere
 non-receivers prune
 time out after 3 minutes
 only source trees
 good for networks where most subnets want
traffic
PIM-SM
 pull model
 join only (G,*)
 initially, shared tree =
rendezvous point (RP)
 router closest to receiver
registers with RP
 sources register with RP and
then initially send data via the
shared tree
 edge routers can force a source
tree by sending (S,G)
messages towards the source if
distance to source is smaller
than distance to RP Cisco IP multicast technology overview
 see draft-ietf-pim-v2-dm
Dense Mode PIM Example
Source Link
Data
Control

A B

C D F

E I

Receiver 1 Receiver 2

following slides by Salmani

Dense Mode PIM Example
Source
Initial Flood of Data
and Creation of State

A B

C D F

E I

Receiver 1 Receiver 2
Dense Mode PIM Example
Source
Prune to Non-RPF Neighbor

A B

Prune G

C D F

E I

Receiver 1 Receiver 2
Dense Mode PIM Example
Source
C and D Assert to Determine
Forwarder for the LAN, C Wins

A B

C D F
Asserts

E I

Receiver 1 Receiver 2
Dense Mode PIM Example
Source
I Gets Pruned
E’s Prune is Ignored
G’s Prune is Overridden
Prune
A B

C D F Join Override

Prune H

E I

Receiver 1 Receiver 2
Dense Mode PIM Example
Source
New Receiver, I Sends Graft

A B

C D F

Graft H

E I

Receiver 1 Receiver 2
Receiver 3
Dense Mode PIM Example
Source

A B

C D F

E I

Receiver 1 Receiver 2
Receiver 3
Sparse Mode PIM Example
Source Link
Data
Control

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
Receiver 1 Joins Group G
Source
C Creates (*, G) State, Sends
(*, G) Join to the RP

A B RP D
Join

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
RP Creates (*, G) State
Source

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
Source Sends Data
Source
A Sender Registers to the
RP

Register

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
RP de-encapsulates Registers
Source
Forwards Data Down the Shared Tree
Sends Joins Towards the Source

Join Join

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
RP Sends Register-Stop
Source
Once
Data Arrives Natively

Register-Stop

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
C Sends (S, G) Joins to Join
Source
the
Shortest Path (SPT) Tree

A B RP D

Join )S, G(

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
When C Receives Data Natively,
Source
It Sends Prunes Up the RP tree for
the Source. RP Deletes (S, G) OIF and
Sends Prune Towards the Source

Prune )S, G(

A B RP D
RP Bit Prune )S, G(

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
New Receiver 2 Joins
Source
E Creates State and Sends (*, G) Join

A B RP D

Join )G ,*(

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
C Adds Link Towards E to the OIF
Source
List of Both (*, G) and (S, G)
Data from Source Arrives at E

A B RP D

C E

Receiver 1 Receiver 2
Sparse Mode PIM Example
New Source Starts Sending
Source
D Sends Registers, RP Sends Joins
RP Forwards Data to Receivers
through Shared Tree

Register

A B D Source 2
RP

C E

Receiver 1 Receiver 2
MBGP (Multiprotocol BGP)

 RFC 2283 (Multiprotocol Extensions for

BGP-4)
 RPF check for AS
 path attributes MP_REACH_NLRI and
MP_UNREACH_NLRI  two sets of routing
information  non-congruent unicast and
multicast topologies
MSDP (Multicast source discovery
protocol)

 Scaling  different RPs for

each AS  several PIM-SM
domains
– each RP only knows local
sources and receivers
 RPs share source
information via MSDP
 TCP session mesh
 first message from new
source sent to other RPs via
Source Active (SA) MSDP
message
MSDP, cont’d.
 If receiving router has (*,G) state, it joins other RP and creates
(S,G) state
 Encapsulated data sent down “remote” RP shared tree
 Last-hop router may join shortest path to source directly
 MSDP is complex and effectively broadcasts to every RP in the
Internet
 DOS attack by sending out flood of source announcements
 Doesn’t scale for large number of sources  SA flood topology
& carry data
Multicast address allocation
 two different sessions may pick same class-D address and
interfere with each other
 solutions:
– dynamic allocation  SAP (later), but doesn’t fit all applications,
scaling problems
– explicit request  MALLOC
– static delegation  GLOP
 interim solution: GLOP (RFC 2770) divides IPv4 multicast
address space by AS

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 233 | 16 bits AS | local bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 multicast address allocation
 RFC 3306 (“Unicast-Prefix-based IPv6 Multicast Addresses”)
 Like GLOP, unicast prefix based

| 8 | 4 | 4 | 112 |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+

| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|0011|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
see RFC 3307:
length of permanent: e.g.,
network 0x40404040 for NTP
prefix
Multicast address allocation
 RFC 2908 (“Internet Multicast Address Allocation Architecture”)
 Instance of global identifier allocation problem:
– hierarchical blocks (IEEE EUI, DNS, IP addresses, phone
numbers, SSN, …)
 local mechanism left unspecified
– on-demand
 centralized server (e.g., DHCP within domain)
 distributed pools
– usually, combination of both
 Two qualifiers:
– scope (possibly global)
– lifetime (possibly indefinite)
Multicast address allocation

 core requirements:
– robustness: work even if remote parts of the
networks don’t
– timeliness: seconds
– low probability of clashes
– avoid fragmentation overhead
 unfortunately, can’t have all of them
– e.g., reliability  fragmentation to “warehouse”
addresses or collisions
Multicast address allocation

prefix MASC prefix

coordinator coordinator Layer 3
prefix or GLOP
coordinator

MAAS MAAS
Layer 2
intra-domain coordination
MADCAP HTTP Layer 1

domain (AS)
MADCAP

 Loosely based on DHCP

 Client sends unicast or multicast request to
server (one of a group)
– DISCOVER to find servers
– OFFER: lease time and multicast scope
– REQUEST address
 Client retransmits if no response
 Leases can be renewed and released
PGM (Pragmatic General Multicast)

 RFC 3208, PGM Reliable Transport Protocol

Specification
 ordered, duplicate-free multicast data from multiple
sources to multiple receivers
 either receives all data packets or can detect
unrecoverable losses
 sender retransmits after NAK
 routers suppress duplicate NAKs and route
retransmissions to branches in need
Multicast summary

 Relatively complete architecture

 Difficulty of network service enhancements
 Difficult to meet higher-layer requirements:
– Storage and time-shifting
– Access control and billing
– Heterogeneous networks
  application-layer techniques (CDNs)
Multicast readings

 Stephen A. Thomas, IPng and the TCP/IP

protocols, Wiley, 1996
 Christian Huitema, Routing in the Internet,
Prentice Hall, 1995
 J. Crowcroft, M. Handley, I. Wakeman,
Internetworking Multimedia, 2000.