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)