Transcript ch4 extra slides on multicast

Chapter 4: Network Layer
 4. 1 Introduction
 4.2 Virtual circuit and
datagram networks
 4.3 What’s inside a
router
 4.4 IP: Internet
Protocol




Datagram format
IPv4 addressing
ICMP
IPv6
 4.5 Routing algorithms
 Link state
 Distance Vector
 Hierarchical routing
 4.6 Routing in the
Internet



RIP
OSPF
BGP
 4.7 Broadcast and
multicast routing
Network Layer
4-1
Broadcast Routing
 deliver packets from source to all other nodes
 source duplication is inefficient:
duplicate
duplicate
creation/transmission
R1
R1
duplicate
R2
R2
R3
R4
source
duplication
R3
R4
in-network
duplication
 source duplication: how does source
determine recipient addresses?
Network Layer
4-2
In-network duplication
 flooding: when node receives brdcst pckt,
sends copy to all neighbors

Problems: cycles & broadcast storm
 controlled flooding: node only brdcsts pkt
if it hasn’t brdcst same packet before
Node keeps track of pckt ids already brdcsted
 Or reverse path forwarding (RPF): only forward
pckt if it arrived on shortest path between
node and source

 spanning tree
 No redundant packets received by any node
Network Layer
4-3
Internet Multicast Service Model
128.59.16.12
128.119.40.186
multicast
group
226.17.30.197
128.34.108.63
128.34.108.60
multicast group concept: use of indirection
 hosts addresses IP datagram to multicast group
 routers forward multicast datagrams to hosts that
have “joined” that multicast group
Network Layer
4-4
Multicast groups
 class D Internet addresses reserved for multicast:
 host group semantics:
o anyone can “join” (receive) multicast group
o anyone can send to multicast group
o no network-layer identification to hosts of members
o host does not know other group members.
o routers keep track group members: more accurately, edge
multicast router only detects presence of group members
attached to each of its interfaces.
 needed: infrastructure to deliver mcast-addressed datagrams to
all hosts that have joined that multicast group
Network Layer
4-5
Joining a mcast group: two-step process
 local: host informs local mcast router of desire to join
group: IGMP (Internet Group Management Protocol)
 wide area: local router interacts with other routers to
receive mcast datagram flow
 many protocols (e.g., DVMRP, MOSPF, PIM)
IGMP
IGMP
wide-area
multicast
routing
IGMP
Network Layer
4-6
IGMP: Internet Group Management
Protocol
 host: sends IGMP report when application joins
mcast group
 IP_ADD_MEMBERSHIP socket option
 host need not explicitly “unjoin” group when
leaving
 router: sends IGMP query at regular intervals
 host belonging to a mcast group must reply to
query
query
report
Network Layer
4-7
IGMP
IGMP version 1
 router: Host Membership
Query msg broadcast on
LAN to all hosts
 host: Host Membership
Report msg to indicate
group membership


randomized delay before
responding
implicit leave via no reply
to Query
IGMP v2: additions
include
 group-specific Query
 Leave Group msg



last host replying to Query
can send explicit Leave
Group msg
router performs groupspecific query to see if any
hosts left in group
RFC 2236
IGMP v3: under development
Soft State: a state is
removed via timeout if it is
not explicitly refreshed.
as Internet draft
Network Layer
4-8
Spanning Tree
 First construct a spanning tree
 Nodes forward copies only along spanning
tree
A
B
c
F
A
E
B
c
D
F
G
(a) Broadcast initiated at A
E
D
G
(b) Broadcast initiated at D
Network Layer
4-9
Spanning Tree: Creation
 Center node
 Each node sends unicast join message to center
node

Message forwarded until it arrives at a node already
belonging to spanning tree
A
A
3
B
c
4
E
F
1
2
B
c
D
F
5
E
D
G
G
(a) Stepwise construction
of spanning tree
(b) Constructed spanning
tree
Network Layer 4-10
Multicast Routing: Problem Statement
 Goal: find a tree (or trees) connecting
routers having local mcast group members



tree: not all paths between routers used
source-based: different tree from each sender to rcvrs
shared-tree: same tree used by all group members
Shared tree
Source-based trees
Approaches for building mcast trees
Approaches:
 source-based tree: one tree per source
shortest path trees
 reverse path forwarding

 group-shared tree: group uses one tree
 minimal spanning (Steiner)
 center-based trees
…we first look at basic approaches, then specific
protocols adopting these approaches
Shortest Path Tree
 mcast forwarding tree: tree of shortest
path routes from source to all receivers

Dijkstra’s algorithm
S: source
LEGEND
R1
1
2
R4
R2
3
R3
router with attached
group member
5
4
R6
router with no attached
group member
R5
6
R7
i
link used for forwarding,
i indicates order link
added by algorithm
Reverse Path Forwarding
 rely on router’s knowledge of unicast
shortest path from it to sender
 each router has simple forwarding behavior:
if (mcast datagram received on incoming link
on shortest path back to center)
then flood datagram onto all outgoing links
else ignore datagram
Reverse Path Forwarding: example
S: source
LEGEND
R1
R4
router with attached
group member
R2
R5
R3
R6
R7
router with no attached
group member
datagram will be
forwarded
datagram will not be
forwarded
• result is a source-specific reverse SPT
– may be a bad choice with asymmetric links
Problem
 Flooding can cause a given packet to be sent multiple
times over the same link
S
x
y
a
duplicate packet
z
b
 Solution: Reverse Path Broadcasting
Network Layer 4-16
Reverse Path Broadcasting (RPB)
 Basic idea: forward a packet from S only on child
links for S
 Child link of router R for source S: link that has R
as parent on the shortest path from the link to S
S
5
x
forward only
to child link
child link of x
for S
6
y
a
z
b
Network Layer 4-17
Problem
 This is still a broadcast algorithm – the
traffic goes everywhere
 Reverse Path Multicasting: Reverse Path
Broadcasting + pruning
Network Layer 4-18
Reverse Path Forwarding: pruning
 forwarding tree contains subtrees with no mcast
group members
 no need to forward datagrams down subtree
 “prune” msgs sent upstream by router with no
downstream group members
LEGEND
S: source
R1
router with attached
group member
R4
R2
P
R5
R3
R6
P
R7
P
router with no attached
group member
prune message
links with multicast
forwarding
Basic RPM Idea
 Prune (Source,Group) at leaf if no members
 Send Non-Membership Report (NMR) up tree
 If all children of router R prune (S,G)
 Propagate prune for (S,G) to parent R
 On timeout:
 Prune dropped
 Flow is reinstated
 Down stream routers re-prune
 Note: again a soft-state approach
Network Layer 4-20
Details
 How to pick prune timers?
 Too long  large join time
 Too short  high control overhead
 What do you do when a member of a group (re)joins?
 Issue prune-cancellation message (grafts)
 Both NMR and graft messages are positively
acknowledged (why?)

A router may continue to receive multicast packets covered
by an outstanding NMR sent previously (why?). These packets
will be dropped.
Network Layer 4-21
Shared-Tree: Steiner Tree
 Steiner Tree: minimum cost tree
connecting all routers with attached group
members
 problem is NP-complete
 excellent heuristics exists
 not used in practice:
computational complexity
 information about entire network needed
 monolithic: rerun whenever a router needs to
join/leave

Shared-Tree: Steiner Tree
 Steiner Tree: minimum cost tree
connecting all routers with attached group
members
 problem is NP-complete
 excellent heuristics exists
 not used in practice:
computational complexity
 information about entire network needed
 monolithic: rerun whenever a router needs to
join/leave

Center-based trees
 single delivery tree shared by all
 one router identified as “center” of tree
 to join:
edge router sends unicast join-msg addressed
to center router
 join-msg “processed” by intermediate routers
and forwarded towards center
 join-msg either hits existing tree branch for
this center, or arrives at center
 path taken by join-msg becomes new branch of
tree for this router

Center-based trees: an example
Suppose R6 chosen as center:
LEGEND
R1
3
R2
router with attached
group member
R4
2
R5
R3
1
R6
R7
1
router with no attached
group member
path order in which join
messages generated
Internet Multicasting Routing: DVMRP
 DVMRP: distance vector multicast routing
protocol, RFC1075
 flood and prune: reverse path forwarding,
source-based tree
RPF tree based on DVMRP’s own routing tables
constructed by communicating DVMRP routers
 no assumptions about underlying unicast
 initial datagram to mcast group flooded
everywhere via RPF
 routers not wanting group: send upstream prune
msgs

DVMRP: continued…
 soft state: DVMRP router periodically (1 min.)
“forgets” branches are pruned:
mcast data again flows down unpruned branch
 downstream router: reprune or else continue to
receive data

 routers can quickly regraft to tree

following IGMP join at leaf
 odds and ends
 commonly implemented in commercial routers
 Mbone routing done using DVMRP
Tunneling
Q: How to connect “islands” of multicast
routers in a “sea” of unicast routers?
physical topology
logical topology
 mcast datagram encapsulated inside “normal” (non-multicast-
addressed) datagram
 normal IP datagram sent thru “tunnel” via regular IP unicast
to receiving mcast router
 receiving mcast router unencapsulates to get mcast datagram
PIM: Protocol Independent Multicast
 not dependent on any specific underlying unicast
routing algorithm (works with all)
 two different multicast distribution scenarios :
Dense:
Sparse:
 group members
 # networks with group
densely packed, in
“close” proximity.
 bandwidth more
plentiful
members small wrt #
interconnected networks
 group members “widely
dispersed”
 bandwidth not plentiful
Consequences of Sparse-Dense Dichotomy:
Dense
 group membership by
Sparse:
 no membership until
routers assumed until
routers explicitly join
routers explicitly prune  receiver- driven
 data-driven construction
construction of mcast
on mcast tree (e.g., RPF)
tree (e.g., center-based)
 bandwidth and non bandwidth and non-groupgroup-router processing
router processing
profligate
conservative
PIM- Dense Mode
flood-and-prune RPF, similar to DVMRP but
 underlying unicast protocol provides RPF info
for incoming datagram
 less complicated (less efficient) downstream
flood than DVMRP reduces reliance on
underlying routing algorithm
 has protocol mechanism for router to detect it
is a leaf-node router
PIM - Sparse Mode
 center-based approach
 router sends join msg
to rendezvous point
(RP)

router can switch to
source-specific tree
increased performance:
less concentration,
shorter paths
R4
join
intermediate routers
update state and
forward join
 after joining via RP,

R1
R2
R3
join
R5
join
R6
all data multicast
from rendezvous
point
R7
rendezvous
point
PIM - Sparse Mode
sender(s):
 unicast data to RP,
which distributes down
RP-rooted tree
 RP can extend mcast
tree upstream to
source
 RP can send stop msg
if no attached
receivers

“no one is listening!”
R1
R4
join
R2
R3
join
R5
join
R6
all data multicast
from rendezvous
point
R7
rendezvous
point
Chapter 4: summary
 4. 1 Introduction
 4.2 Virtual circuit and
datagram networks
 4.3 What’s inside a
router
 4.4 IP: Internet
Protocol




Datagram format
IPv4 addressing
ICMP
IPv6
 4.5 Routing algorithms
 Link state
 Distance Vector
 Hierarchical routing
 4.6 Routing in the
Internet



RIP
OSPF
BGP
 4.7 Broadcast and
multicast routing
Network Layer 4-34