Network Protocols:
Design and Analysis
Polly Huang EE NTU
http://cc.ee.ntu.edu.tw/~phuang phuang@cc.ee.ntu.edu.tw
Why Study Multicast?
• want to send info to a group of people
– allows you to send one packet and let the network make copies to everyone
• supports anonymous addressing
– don’t have to keep track of individual users
– don’t worry about changes in group membership – but:
• may not get particular users
• all users may not need all info sent to the group
Multicast Goals
• Efficient data distribution
– send only one copy of pkt over each link, not n
• Anonymous group addressing
– ex. to get a phone number, you call the operator —any operator, not just Lilly
Unicast vs. Multicast
Src Src
compare amount of ban dwidth consumed
Unicast vs. Multicast
Src Src
Unicast vs. Multicast
Src Src
Unicast vs. Multicast
Src Src
Unicast vs. Multicast
Src Src
in this case, multicast requ ires about half as many pk t-hops compared to unicas t
Applications of multicast
• multiplayer games
– use proxy servers/app-level “multicast” – or just use centralized server
• distributed applications:
– ex. query distributed/replicated database (user-to-application) – inside an distributed application
• teleconference • broadcasting
• sensor networks or other physically distributed applications
Multicast:
Anonymous Addressing
• Applications:
– broadcast (don’t care about users), some distrib uted apps
• Special case: anycast
– find me the nearest receiver in the multicast gro up
Multicast:
Bandwidth Reduction
• applications– broadcast and teleconference
• but some caveats
– reliability? how do we do failure/loss recover in multicast
– different users with different start times? broadcast works best if e veryone’s syncrhonization (option: just start people in the middle, or do caching, multiple versions of stream [ex. using layered/partia l encoding]…)
Common Problems in Multicast
• scalability
– number of sources – number of receivers
– geographic/network distance (sparse vs. dense groups)
• message implosion
Common Techniques in Mcast
• soft state
– rather than reliable send and ACK, send periodically
• response after randomized delay
– delay may be biased to favor certain hosts repsonding
• suppression of duplicate responses
– listen to others responses: if they say the same as you, y ou don’t need to respond
Components of the
IP Multicast Architecture
hosts routers service model host-to-router protocol (IGMP)multicast routing protocols (various)
mcast addr allocation
IP Multicast Service Model
• Defined in RFC-1112 [Deering89a] • mcast groups identified by IP addr
• sending: anyone can send to mcast grp – don’t need to be a member
• receiving: hosts join and leave groups via IGMP
• network builds multicast distribution tree to send da ta
– responsibility of designated router on same LAN as host (and other rtrs in the network)
Class D IP addresses:
in “dotted decimal” notation: 224.0.0.0 — 239.255.255.255
two administrative categories:
– “well-known” multicast addresses (ex: 224.0.0.1 is “all hosts”, .2 is “all rtrs”)
IP Multicast Addresses
Address Allocation
• Outside the scope of this class, but… • Initially, random allocation
– odds of collision are low
– but are they? The Birthday Paradox says collisions will happen
• Later: more careful schemes
– ex. see “The MASC/BGMP Architecture for Multicast Routing”, SIGCOMM ’98
IP Multicast Service — Sending
• uses normal IP-Send operation, with an IP multic ast address specified as the destination
• must provide sending application a way to:
– specify outgoing network interface, if >1 available – specify IP time-to-live (TTL) on outgoing packet
– enable/disable loopback if the sending host is a memb er of the destination group on the outgoing interface
IP Multicast Service —
Receiving
• two new operations:
Join-IP-Multicast-Group ( group-address, inter face )
Leave-IP-Multicast-Group ( group-address, inter face )
• packets arrive like normal IP pkts
Why not do things at the app?
• get higher latencies/bandwidth usage
– because can’t use link-level multicast – don’t have network topology
Multicast Scope Control:
(1) TTL Expanding-Ring Search
to reach or find a nearby subset of a group
s
1
2
Multicast Scope Control:
(2) Admin TTL Boundaries
to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons
TTL threshold set on
Multicast Scope Control:
(3) Admin-Scoped Addresses
address boundary set on
the rest of the Internet
– “send with my company/country/continent/etc.” – uses address range 239.0.0.0/8
The MBone
• MBone = Multicast Backbone
• a set of routers on the Internet that can exc
hange multicast packets
– some use native multicast
– others tunnel multicast between themselves
Components of the MBone
square/circle: thick square/circle: solid line: dashed line: host/router MBone router physical link tunnel R R R H R H• a method for sending multicast packets through mu lticast-ignorant routers
• IP multicast packet is encapsulated in a unicast pac ket addressed to far end of tunnel:
• like Moble IP tunnels, but manually configured
MBone Tunnels
IP header, dest = unicast IP header, dest = multicast transport header and data…Components of the
IP Multicast Architecture
hosts routers service model host-to-router protocol (IGMP)multicast routing protocols (various)
Internet Group Management
Protocol(IGMP)
• the protocol by which hosts report their
multicast group memberships to
neighboring routers
• v1: RFC-1112; v2: RFC-2236
• operates over broadcast LANs and
point-to-point links
Relevant Protocol Layers
Within a Host
IP Service Interface
Link-Layer Service Interface
Upper-Layer Protocol Modules
IP Module
IP to link-layer address
Link-Layer
Transmission/Reception
transmission:
• IP multicast uses link-layer multicast, if pos sible
• ex: Ethernet:
reception:
• hosts link layers often filter multicast addrs • routers listen to all mcast
LAN multicast address
0000000100000000010111100
1110 28 bits 23 bits
IP multicast address group bit
IGMP Goal
• determine what IP mcast groups have receivers pr esent on the LAN
– just care about some vs. no receivers, not how many
• approach:
– designate one router as IGMP “querier” – it asks all hosts
– get at least one response per active group
How IGMP Works
• querier sends a Membership Query message to all-hosts (224.0.0.1), TTL=1
• hosts reply after random delay (0-10s) for each G
• reply goes to whole group G (and routers), suppressing ot
Q G G G routers: hosts: 1 6 4
IGMP Implications
• typically only one response (per G) is requ
ired
• routers query every 60-90 seconds
– implication: leave latency is 30-45s – IGMPv2 adds explicit leave msgs
• to reduce join latency, a host sends one or
two unsolicited responses immediately aft
er joining a new G
Components of the
IP Multicast Architecture
hosts routers service model host-to-router protocol (IGMP)multicast routing protocols (various)
The Mcast Routing Problem:
How do you connect sources and sinks?
The Mcast Routing Problem:
How do you connect sources and sinks?
Mcast Routing Startup
• senders flood everyone
– “flood and prune”, DVMRP, PIM-DM
• receivers flood everyone
– MOSPF
• define a rendezvous point, senders and
receivers send towards rendezvous
How many trees per group?
• shared tree
– all senders use the same tree
– may not be optimal latency, but within 2x
• source-specific tree (or shortest path tree,
SPF)
– one tree per sender
A Shared Tree
Source-Specific Trees
Source1 R3
Source2 can find a shorter path to R1 by following a
source-Who can send?
• Anyone (Deering’s service model)
– model used by most multicast apps
• Single-source
– only one person can send (others must make the ir own group)
Multicast Status
• MBone exists
– moderately widely used in research – but not always stable
• multi-domain routing is hard—everyone has to talk, and often p eople don’t talk about experimental services :-(
• Some commercial use (apps)
– but very little ISP support
• concerned about how to charge, and potential over-use
• Multicast widely used on LANs