Download Multicast unicast: one sender, one receiver broadcast: one sender

Multicast
unicast: one sender, one receiver
broadcast: one sender, all nodes receive
multicast: one sender, multiple receivers
main issues are
1. how to support one send operation transmitting to many receivers — instead of many send operations
2. dealing with failures (what if one receiver gets error?)
3. QoS issues: voice, video, sources of multicast data
4. setup & teardown: how to coordinate multiple receivers,
how to allow more than one sender?
multicast trees
a natural solution to the first issue: root of tree sends
message(s) only along attached tree branches, and messages are replicated at junctures as needed so that each
leaf gets a copy
1
multicast trees
source
multicast
switches
sink #3
sink #1
sink #2
source only needs to send one message: switches take care of
replicating message as needed to get to all leaves (sinks) of tree
recall that within LAN, multicast can be supported by
broadcast techniques (in Ethernet using IP, there is a
multicast UDP option)
2
the collection of sinks is called the multicast group
1. how does group get formed? how does a node join or leave
the multicast group?
IGMP: Internet Group Management Protocol (often
use out-of-band requests)
2. what addresses do messages (datagrams) have for multicast?
(Class D; permanent and on-demand)
3. what determines tree shape?
4. what is multicast routing algorithm?
3
the link-state approach
shortest-path multicast tree
fact: the collection of least-cost paths from the source to each
sink is a tree
from a list the group members and source and a graph of the
network (link costs), the “least-cost path tree” can be constructed
using the link-state routing algorithm, each router gets a
graph of the network via LSPs
routers can then compute the least-cost path tree for each
multicast group
only routers in a group’s least-cost path tree are involved in
multicast send operations
problems with this approach
1. not scalable — different multicast trees for different groups
require much memory in routers
2. many routers need to know group membership
3. trees are not optimal when new nodes join group
4
the distance-vector approach
uses learning strategy like LAN bridges
1. starting point: distance vectors are available
2. first step: use flooding, but eliminate loops back to source
(ignore packets not coming from least-cost path to source
address; also choose only one router connected to source’s
LAN)
does implement least-cost multicast path routes, provided costs are the same in each direction on every
link (cost is just “one hop” per link in the Internet)
3. second step: prune back routers not in paths to sinks —
“downstream” routers not connected to group members send
messages “upstream” to get pruned from multicast tree
how it works: each router (except source) learns who
is “parent” router in least-cost path tree for a particular group — then prunes links not to parent or
children in the tree for that group
problems with this approach
1. flooding means many extra messages
2. not well suited to “sparse” groups spread over Internet
basic design choice: should group members find the source, or
should source seek out members?
5
MBone
the Internet’s Multicast Backbone
A virtual internet implemented on top of the real Internet
selected routers use IP tunnels for multicast messages
other routers just handle TCP connections implied by tunnels
routing over virtual internet can use DVMRP
(Distance Vector Multicast Routing Protocol)
actually just a “testbed” for multicast that has grown into
production use
IGMP used to manage groups (routers periodically poll to
drop inactive members)
6
the PIM approach to routing
share trees among many sources
one problem of earlier approaches: each source gets its own
routers need more memory to support
least-cost path tree
multicast
in some applications, every group member is occasionally a source (video conferencing)
PIM has two tree options: source-specific and shared
each group’s tree has a rendezvous point (RP)
using “join” and “prune” messages, tree changes shape as
membership changes
– router sends join message to RP
– unlike usual datagram forwarding, each router inspects
and remembers join messages passing through it (so it
can build tree from joiner to RP)
– as tree is built, some joins don’t need to be forwarded to
RP
– source-specific trees dynamically built using shared tree
the shared tree is also called core-based tree
7
PIM dense versus sparse modes
group density determines approach
extremes in multicast:
many (almost all) routers have group members
is like broadcast
multicast
in this case, distance-vector or link-state is good
very few routers have group members
like unicast
multicast is more
in this case, core-based tree is better
two modes of PIM: dense mode and sparse mode
dense mode uses “graft” messages to undo some pruning and
uses a modified DVMRP for routing
8