CSE679: Multicast and Multimedia r Basics r Addressing r Routing r Hierarchical multicast r QoS multicast

Multicast -motivation r Point-to-point delivery not efficient for events/transmissions of general interest r Examples m News multicast m IETF sessions/rock concerts r Many receivers may share the same path r Point-to-point delivery too expensive

Multicast motivation

Multicast issues r In point-to-point delivery, receiver address is known => routing is straightforward r In Multicast, many receivers r How to transmit data to all the receivers? r How to identify the group of receivers? m At the sender? m In the network?

Multicast issues r Identify multicast by a group/multicast address r The membership changes as the receivers join/leave the group r Routers/Network need to recognize the multicast address r Receivers need to receive on their own IP address and on the multicast address

Multicast addressing r A multicast sender uses the group address as the receiver’s address when sending packets r Network/routers keep track of actual receiving subnets/paths for this group address (not the actual receivers) r Receivers can reply to sender’s address or to group address

Multicast addressing r Part of IP address space reserved for multicast r Multicast routers recognize multicast addresses r Need to get a multicast address for a transmission before multicast can start r Protocols exist for obtaining multicast addresses and finding out a multicast address

Class D addresses r High order 4 bits = 1110, followed by a 28-bit multicast group ID r all systems on this subnet r all routers on this subnet r all DVMRP routers r all OSPF routers

IGMP r Internet Group Membership Protocol r Used to join a multicast group and to check on the current status of receivers on a subnet r IGMP -join message propagated up the routers until the multicast tree reached. r Routers periodically poll hosts on subnets to see if any active receivers remain r If no active receivers remain, routers propagate leave messages upstream to reduce unnecessary traffic r Frequent polling can increase overhead r Separate protocols for finding group membership address - sd

Multicast routing r For point-to-point delivery, a router looks up routing table and knows how to forward r For multicast, many receivers m may have to forward packets on multiple outgoing links m too hard to keep track of individual receivers at each router for each multicast group m remember just the links on which to be forwarded - change as receivers join/leave

Multicast routing r Need to recognize multicast addresses r The routing tables change as the receivers join/leave a multicast group r Every router keeps track of “downstream” links on which to forward a packet r Routing table and multicast address “expire” at the end of session

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

Multicast routing approaches r Flooding m send on all links to reach the receivers m not efficient r Spanning tree m efficient m could concentrate traffic on a few links

Spanning tree based routing r Spanning trees rooted at the sender r When a receiver wants to join a group, may have to broadcast on all upstream links to find a path to the sender m could cause a lot of overhead in sparse groups m need better solutions

Sparse Mode routing r Use a Core-based tree (CBT) r Use a rendezvous point or a core router r Direct all joins to RP which knows how to reach the sender m can avoid broadcasting multicast group information to all routers in the network m can result in non-optimal paths m would need to modify multicast tree over time

Reliable Multicast r In unicast, receiver ACKs give feedback ---Sender takes responsibility in transmitting data r In Multicast, many receivers -- too difficult for sender to keep track of every receiver’s status r ACK Implosion

Receiver-driven Multicast r Sender based schemes don’t scale well as number of receivers increase r Receiver based schemes scale better r Receivers can decide the level of reliability needed as well as the level of quality desired etc.

Send NAKs r Sender keeps no information of receivers’ status r Receivers send NAKs to reduce ACK implosion problem r How to send NAKs? m Unicast NAKs to sender m Multicast NAKs

Unicast NAKs to sender r Reduces overhead when packet losses are isolated and rare r Packet loss early in the tree will result in too many NAKs

Multicast NAKs r Others missing packets need not send NAKs r if every receiver, sends a NAK immediately after getting an out-of-sequence packet, too many NAKS at once! r Wait for a random time, send a NAK r If some one else sends a NAK, suppress your NAK r Getting random timers tricky business r Could cause burden on receivers if only one receiver doesn’t get the packet

Hierarchical Multicast r Organize multicast into a number of groups r One Designated Receiver (DR) takes responsibility for reliability r On packet loss, NAK propagated to DR r If DR has data, retransmits or re-multicasts with limited scope to the group r If DR doesn’t have data, sends NAK to sender

Hierarchical Multicast r More scalable than other multicast protocols r Specially useful when multicast over wide geographic boundaries, keep one DR in each country for example r DR nodes may need more power than other receivers r Need mechanisms to find out DR r Need mechanisms to delegate DR function to another node as primary DR node leaves multicast r RMTP: Reliable Multicast Transport Protocol - Bell Labs

Congestion control r Layered multicast r Arrange layers in an exponentially increasing data rates r TCP-friendly Multicast m In steady state, packet drop => congestion, drop a layer m If layers are doubling in data rates, dropped layer = reducing multicast rate by half => TCP friendly

QoS-Sensitive Multicast r The key issue is to construct a multicast tree with QoS constraints r 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 r Exact solutions to such multi-constrained optimization problems are prohibitively expensive r 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

Mbone r Multicast Backbone r Consists of all the multicast-enabled routers r If two multicast routers are not directly connected, uses tunneling over non-multicast routers r Allows gradual deployment

Conclusion r Multicast basics m Motivation and Issues m Addressing m Routing r Hierarchical multicast r QoS multicast