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 (wheres 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 Prims 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, contd.
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 dont 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
see draft-ietf-pim-v2-dm
Cisco IP multicast technology overview
Dense Mode PIM Example
Source
Receiver 2 Receiver 1
D F
I
B
C
A
E
G
H
Link
Data
Control
following slides by Salmani
Dense Mode PIM Example
Initial Flood of Data
and Creation of State
Source
Receiver 2 Receiver 1
D F
I
B
C
A
E
G
H
Dense Mode PIM Example
Prune to Non-RPF Neighbor
Source
Prune
Receiver 2 Receiver 1
D F
I
B
C
A
E
G
H
Dense Mode PIM Example
C and D Assert to Determine
Forwarder for the LAN, C Wins
Source
Asserts
Receiver 2 Receiver 1
D F
I
B
C
A
E
G
H
Dense Mode PIM Example
I Gets Pruned
Es Prune is Ignored
Gs Prune is Overridden
Source
Prune
Receiver 2 Receiver 1
Join Override
Prune
D F
I
B
C
A
E
G
H
Dense Mode PIM Example
Source
Graft
Receiver 2
Receiver 3
Receiver 1
New Receiver, I Sends Graft
D F
I
B
C
A
E
G
H
Dense Mode PIM Example
Source
Receiver 2
Receiver 3
Receiver 1
D F
I
B
C
A
E
G
H
Sparse Mode PIM Example
Receiver 1
B
E
A D
Source
C
Receiver 2
RP
Link
Data
Control
Sparse Mode PIM Example
Receiver 1
B
E
A D
Source
Receiver 1 Joins Group G
C Creates (*, G) State, Sends
(*, G) Join to the RP
C
Receiver 2
RP
Join
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
RP Creates (*, G) State
C
Receiver 2
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
Source Sends Data
A Sender Registers to the
RP
C
Receiver 2
Register
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
RP de-encapsulates Registers
Forwards Data Down the Shared Tree
Sends Joins Towards the Source
C
Receiver 2
Join Join
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
RP Sends Register-Stop
Once
Data Arrives Natively
C
Receiver 2
Register-Stop
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
C Sends (S, G) Joins to Join
the
Shortest Path (SPT) Tree
C
Receiver 2
(S, G) Join
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
When C Receives Data Natively,
It Sends Prunes Up the RP tree for
the Source. RP Deletes (S, G) OIF and
Sends Prune Towards the Source
C
Receiver 2
(S, G) RP Bit Prune
(S, G) Prune
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
New Receiver 2 Joins
E Creates State and Sends (*, G) Join
C
Receiver 2
(*, G) Join
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
C Adds Link Towards E to the OIF
List of Both (*, G) and (S, G)
Data from Source Arrives at E
C
Receiver 2
Sparse Mode PIM Example
Receiver 1
B
E
A
RP
D
Source
New Source Starts Sending
D Sends Registers, RP Sends Joins
RP Forwards Data to Receivers
through Shared Tree
C
Receiver 2
Source 2
Register
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, contd.
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
Doesnt 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 doesnt 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:
permanent: e.g.,
0x40404040 for NTP
length of
network
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 dont
timeliness: seconds
low probability of clashes
avoid fragmentation overhead
unfortunately, cant have all of them
e.g., reliability fragmentation to warehouse
addresses or collisions

Multicast address allocation
MAAS MAAS
MADCAP HTTP
prefix
coordinator
Layer 2
intra-domain coordination
Layer 1
or GLOP
prefix
coordinator
prefix
coordinator
Layer 3
domain (AS)
MASC
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.