CSE679: Multicast and Multimedia

Basics Addressing Routing Hierarchical multicast QoS multicast

Multicast -motivation

Point-to-point delivery not efficient for events/transmissions of general interest

Examples News multicast IETF sessions/rock concerts

Many receivers may share the same path Point-to-point delivery too expensive

Multicast motivation

Multicast issues

In point-to-point delivery, receiver address is known => routing is straightforward

In Multicast, many receivers How to transmit data to all the receivers? How to identify the group of receivers?

At the sender? In the network?

Multicast issues

Identify multicast by a group/multicast address The membership changes as the receivers

join/leave the group Routers/Network need to recognize the

multicast address Receivers need to receive on their own IP

address and on the multicast address

Multicast addressing

A multicast sender uses the group address as the receiver’s address when sending packets

Network/routers keep track of actual receiving subnets/paths for this group address (not the actual receivers)

Receivers can reply to sender’s address or to group address

Multicast addressing

Part of IP address space reserved for multicast Multicast routers recognize multicast

addresses Need to get a multicast address for a

transmission before multicast can start Protocols exist for obtaining multicast

addresses and finding out a multicast address

Class D addresses

High order 4 bits = 1110, followed by a 28-bit multicast group ID. 224.0.0.0 - 239.255.255.255

224.0.0.1 - all systems on this subnet 224.0.0.2 - all routers on this subnet 224.0.0.4 - all DVMRP routers 224.0.0.5 - all OSPF routers

IGMP

Internet Group Membership Protocol Used to join a multicast group and to check on

the current status of receivers on a subnet IGMP -join message propagated up the routers

until the multicast tree reached. Routers periodically poll hosts on subnets to see

if any active receivers remain If no active receivers remain, routers propagate

leave messages upstream to reduce unnecessary traffic

Frequent polling can increase overhead Separate protocols for finding group membership

address - sd

Multicast routing

For point-to-point delivery, a router looks up routing table and knows how to forward

For multicast, many receivers may have to forward packets on multiple outgoing

links too hard to keep track of individual receivers at each

router for each multicast group remember just the links on which to be forwarded -

change as receivers join/leave

Multicast routing

Need to recognize multicast addresses The routing tables change as the receivers

join/leave a multicast group Every router keeps track of “downstream”

links on which to forward a packet Routing table and multicast address “expire”

at the end of session

Multicast Routing Protocols

DVMRP - Distance Vector Multicast MOSPF - Multicast Extensions to OSPF PIM - Protocol Independent Multicast

Multicast routing approaches

Flooding send on all links to reach the receivers not efficient

Spanning tree efficient could concentrate traffic on a few links

Spanning tree based routing

Spanning trees rooted at the sender When a receiver wants to join a group, may

have to broadcast on all upstream links to find a path to the sender could cause a lot of overhead in sparse groups need better solutions

Sparse Mode routing

Use a Core-based tree (CBT) Use a rendezvous point or a core router Direct all joins to RP which knows how to reach

the sender can avoid broadcasting multicast group information

to all routers in the network can result in non-optimal paths would need to modify multicast tree over time

Reliable Multicast

In unicast, receiver ACKs give feedback ---Sender takes responsibility in transmitting data

In Multicast, many receivers -- too difficult for sender to keep track of every receiver’s status

ACK Implosion

Receiver-driven Multicast

Sender based schemes don’t scale well as number of receivers increase

Receiver based schemes scale better Receivers can decide the level of reliability

needed as well as the level of quality desired etc.

Send NAKs

Sender keeps no information of receivers’ status

Receivers send NAKs to reduce ACK implosion problem

How to send NAKs? Unicast NAKs to sender Multicast NAKs

Unicast NAKs to sender

Reduces overhead when packet losses are isolated and rare

Packet loss early in the tree will result in too many NAKs

Multicast NAKs

Others missing packets need not send NAKs if every receiver, sends a NAK immediately

after getting an out-of-sequence packet, too many NAKS at once!

Wait for a random time, send a NAK If some one else sends a NAK, suppress your

NAK Getting random timers tricky business Could cause burden on receivers if only one

receiver doesn’t get the packet

Hierarchical Multicast

Organize multicast into a number of groups One Designated Receiver (DR) takes

responsibility for reliability On packet loss, NAK propagated to DR If DR has data, retransmits or re-multicasts

with limited scope to the group If DR doesn’t have data, sends NAK to sender

Hierarchical Multicast

More scalable than other multicast protocols Specially useful when multicast over wide

geographic boundaries, keep one DR in each country for example

DR nodes may need more power than other receivers

Need mechanisms to find out DR Need mechanisms to delegate DR function to

another node as primary DR node leaves multicast

RMTP: Reliable Multicast Transport Protocol - Bell Labs

Congestion control

Layered multicast Arrange layers in an exponentially increasing

data rates TCP-friendly Multicast

In steady state, packet drop => congestion, drop a layer

If layers are doubling in data rates, dropped layer = reducing multicast rate by half => TCP friendly

QoS-Sensitive Multicast

The key issue is to construct a multicast tree with QoS constraints

Goal is to build a tree of paths to destinations such that sum of link costs (e.g. consumed bandwidth) is minimum and QoS constraints (e.g. delay) are satisfied

Exact solutions to such multi-constrained optimization problems are prohibitively expensive

Need heuristics that provide fast solutions of high quality

An Example for Constructing A Tree

Application QoS requirements: end-to-end delay 13, jitter 7 example 1

example 2

10

10

10

2

10

6 6

10

Mbone

Multicast Backbone Consists of all the multicast-enabled routers If two multicast routers are not directly

connected, uses tunneling over non-multicast routers

Allows gradual deployment

Conclusion

Multicast basics Motivation and Issues Addressing Routing

Hierarchical multicast QoS multicast