Download - CMPE 252A: Computer Networks Set 11:
1
CMPE 252A: Computer Networks
Set 11:
Algorithms and Protocols for IP Multicasting
2
Multicasting Uses:
Multimedia “broadcast”: IP radio, webcasts Teleconferencing: multiparty videoconferencing
with (Mbone, CUSeeMe) Database replication Distributed computing: immediate updates to all
members Real-time workgroups: multimedia collaboration System management: concerted file updates to
group of hosts Stock ticker: low-bandwidth quotes to millions of
hosts (cf. Pointcast) Single LAN segment:
straightforward (IEEE 802 includes provision for MAC-layer multicast addresses)
3
Multicasting Purpose: Support one-to-many and many-to-many
communication needed for many applications across LANs and WANs.
Problem: To minimize the communication and processing overhead entailed in disseminating the same data packets to a group of receivers.
Goal: Identify the receiver set in a convenient way and distribute packets to the set efficiently.
Approach: Disseminate packets over a tree spanning all the
intended receivers. Identify the receivers with a group identifier or
the set of receiver identifiers.
4
Multipoint Dissemination Broadcasting packet to each
network Takes 13 copies of packet; 13
interfaces Multiple Unicasts
Send packet only to networks that have hosts in group
11 packets Multicasting
Determine least cost path to each network that has host in group
Gives spanning tree configuration containing networks with group members
Transmit single packet along spanning tree
Routers replicate packets at branch points of spanning tree
8 packets required
5
IP Multicast Architecture Based on Steve Deering’s original proposal
(SIGCOMM 88 Proceedings; his PhD thesis) The architecture expands LAN multicasting to the
Internet. It consists of three basic components:
Group addressing based on globally unique identifiers (IP multicast addresses)
Separation of senders and receivers with anonymous receiver affiliation
A tree-based routing and group structure Advantages: Efficiency of packet forwarding and
simplicity Disadvantages: Scalability, difficult to adapt to group
dynamics, limited services
6
IP Multicast Addresses used: 224.0.0.0 through
239.255.255.255 (the former Class D addresses in IPv4)
Abstraction: multicast address associated with
multicast group host joins / leaves group and
receives address dynamically sender host sends packets to
multicast group (one or more destinations) not individuals!
routers deliver to all hosts that joined group address
To avoid unnecessary duplication of packets, routers must route packets using source and destination addresses, and an efficient routing structure must be built!
7
IP Internet Multicasting
R
RR
R G
GG
R
R
R R
RR
RR
R R
8
Internet Group Management Protocol (IGMP)
RFC 1112 - used by hosts and routers to exchange multicast group membership information over LAN
Multicast routers use IGMP in conjunction with a multicast routing protocol, to support IP multicasting across the Internet.
Takes advantage of broadcast nature of LAN to updates - IGMP v1 - 3
Two kinds of packets: query / response
9
Constructing The Multicast Routing Structure
If routers know the topology of the network, they can compute a multicast routing tree locally.
If routers maintain only distance or path information to destinations, multicast routing tree must be computed in a distributed manner.
Internet multicast routing protocols are based on reverse path forwarding.
10
Link-State Multicast Goal: route packets to all hosts that joined multicast
group address Each host on a LAN periodically announces the groups to which
it belongs (IGMP). Each router uses link-state flooding to distribute
cost of links to neighbors multicast addresses it wants to receive (hosts joined group)
Each router computes regular unicast routing (Dijkstra's algorithm to compute shortest-
path spanning tree for each source/group pair) spanning tree for M nodes joining to each active multicast address Augment link-state update messages to include set of groups that
have members on a particular LAN. Each router caches tree for currently active source/group pairs. Possible algorithm:
find node with smallest host address among M use Dijkstra to build tree, rooted at that host reaching all M nodes
11
Limitations of Link-State Multicasting
Routers need to maintain too much state for each multicast group.
Routers need to send many more link-state updates.
Routers need to compute a multicast routing tree for each source of a group in the worst case, in order to decide when to forward packets.
12
Multicast Extensions to Open Shortest Path First (MOSPF)
RFC-1583: OSPFv2 - Interior Gateway Protocol (IGP) specifically designed to distribute unicast topology information among routers belonging to a single Autonomous System
RFC-1584: MOSPF routers maintain a current image of the network topology through the unicast OSPF link-state routing protocol Extends OSPF by providing the ability to route multicast
IP traffic Extension is backward compatible so that routers
running MOSPF will interoperate with non-multicast OSPF routers when forwarding unicast IP data traffic.
13
Distributed Approaches for Building Multicast Trees
Approaches: Source-based tree: One tree per source
shortest path trees reverse path forwarding
Group-shared tree: Entire group uses one tree Minimal spanning (Steiner) Center-based trees
14
Shortest Path Tree Multicast forwarding tree: tree of shortest
path routes from source to all receivers Dijkstra’s algorithm
R1
R2
R3
R4
R5
R6 R7
21
6
3 4
5
i
router with attachedgroup member
router with no attachedgroup member
link used for forwarding,i indicates order linkadded by algorithm
LEGENDS: source
15
Reverse Path Forwarding
if (mcast datagram received on incoming link on shortest path back to “center”)
then flood datagram onto all outgoing links else ignore datagram
Rely on router’s knowledge of unicast shortest path from it to sender
Each router has simple forwarding behavior:
16
Reverse Path Forwarding: Example
• result is a source-specific reverse shortest path tree– may be a bad choice with asymmetric links
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
datagram will be forwarded
LEGENDS: source
datagram will not be forwarded
17
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
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
prune message
LEGENDS: source
links with multicastforwarding
P
P
P
18
Distance-Vector Multicast Routing Protocol (DVMRP)
Implemented by the mrouted program. Specified in RFC-1075. Implemented version differs in packet
format, different tunnel format, additional packet types.
Maintains routing knowledge via a distance-vector routing protocol: Much like RIP, described in RFC-1058 Routers maintain hop count to all possible
multicast sources.
19
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
20
DVMRP: continued… soft state: DVMRP router periodically (1 min.)
“forgets” branches are pruned: mcast data again flows down un-pruned branch downstream router: re-prune or else continue to
receive data routers can quickly regraft to tree
following IGMP join at leaf odds and ends
Mbone routing was done using DVMRP Replaced by PIM
21
TunnelingHow do we connect “islands” of multicast
routers in a “sea” of unicast routers?
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
physical topology logical topology
22
Problems with Basic Approach Flooding the Internet to establish a multicast
routing tree is not an option! This is the key reason why multicasting (based on
DVMRP) cannot be deployed on a large scale. The problem stems from the lack of addressing
information in an IP multicast address! Where is a multicast group on the Internet?
The solution to this problem is to use special nodes as the “address” of a group
23
Shared-Tree: Steiner Tree
Steiner Tree: minimum cost tree connecting all routers with attached group members
Problem is NP-complete Good heuristics exist Not used in practice:
Computational complexity Information about entire network needed Monolithic: rerun whenever a router needs to
join/leave
24
Core-Based Trees Single delivery tree shared by all One router identified as “core” of tree To join:
Edge router sends unicast join-msg addressed to center router
join-msg “processed” by intermediate routers and forwarded towards core
join-msg either hits existing tree branch for this core, or arrives at core
path taken by join-msg becomes new branch of tree for this router
25
Example of Core-Based Trees
Suppose R6 chosen as center (core):
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
path order in which join messages generated
LEGEND
21
3
1
26
Core-Based Tree (CBT) Ballardi, Crowcroft, and Francis proposed CBT to
solve the problems found with Deering’s original scheme (DVMRP) based on RPF [Proc. ACM SIGCOMM 93]
The basic idea consists of using a router, called the core, as the de facto address for a multicast group.
In addition, a single shared multicast routing tree is used for the entire group, rather than one tree per source per group.
The links in the tree are bidirectional, meaning that multicast packets can flow between two neighbor members of the tree in either direction.
27
Core-Based Trees (CBT)
CBT is receiver-initiated, in that a router needs to send a JOIN request towards the core of the group to become a group member.
JOIN request is forwarded along the shortest path to the core.
Any router in the multicast tree receiving the JOIN replies with an ACK that makes the router join the group.
The ACK propagates back along the same path followed by the JOIN.
28
Limitations of CBT Using a single core is a vulnerability, CBT does not
work correctly with multiple cores, and CBT can have temporary loops.
Location of core is critical to performance Paths over multicast tree can be much longer than
the shortest paths.
A
B
29
PIM: Protocol Independent Multicast
Not dependent on any specific underlying unicast routing algorithm (works with all)
Multiple multicast modes: Sparse, dense, bidirectional, source-specific.
Dense: group members densely
packed, in “close” proximity.
bandwidth more plentiful
Sparse: # networks with group members
small wrt # interconnected networks
group members “widely dispersed”
bandwidth not plentiful
30
Consequences of Sparse-Dense Dichotomy:
Dense group membership by
routers assumed until routers explicitly prune
data-driven construction on mcast tree (e.g., RPF)
bandwidth and non-group-router processing profligate
Sparse: no membership until
routers explicitly join receiver- driven
construction of mcast tree (e.g., center-based)
bandwidth and non-group-router processing conservative
31
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
32
PIM - Sparse Mode Center (core)-based
approach router sends join msg to
rendezvous point (RP) intermediate routers
update state and forward join
after joining via RP, router can switch to source-specific tree
increased performance: less concentration, shorter paths
R1
R2
R3
R4
R5
R6R7
join
join
join
all data multicastfrom rendezvouspoint
rendezvouspoint
33
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
R2
R3
R4
R5
R6R7
join
join
join
all data multicastfrom rendezvouspoint
rendezvouspoint
34
IP Multicast Addressing Issues There are plenty of IPv4 and IPv6 addresses for
globally unique multicast addresses, if done carefully The problem is how to assign these addresses
permanently or temporarily to multicast groups.
Using globally unique multicast addresses requires Internet-wide coordination/rules in the assignment of identifiers to groups.
Evolving solution: GLOP addressing Unicast-prefix-based IPv4 mcast addresses Administratively scoped IPv4 mcast addresses
How do we map IP to MAC multicast addresses? Check: http://en.wikipedia.org/wiki/Multicast_address
35
IP Multicast Addresses 28 bits for identifying groups ~ 250
million groups can exist at the same time
Two kinds of supported addresses: Permanent, e.g.,
224.0.0.1 all systems on LAN 224.0.0.2 all routers on LAN
Temporary - must be created before they can be addressed (join and leave)