Transcript EE689 Lecture 12

EE689 Lecture 12
• Review of last lecture
• Multicast basics
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 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 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 28bit 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
Multicasting
• The end routers use physical layer
multicasting to multicast packets to multiple
receivers on the same subnet
• IP-multicast group ID copied into the
MAC-layer multicast address
• All receivers of this group listen to this
multicast address to receive packets
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
IGMP
• 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
IGMP version 3
• Allows sender-specific reports when
multiple senders are in a multicast group
• Can exclude certain senders and allow
certain senders - allows better bandwidth
management in multi-sender multicasts.
Mbone
• Multicast Backbone
• Consists of all the multicast-enabled routers
• If two multicast routers are not directly
connected, uses tunneling over nonmulticast routers
• Allows gradual deployment
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
• Many possible approaches
• Flooding
– send on all links to reach the receivers
– not efficient
• Spanning tree
– efficient
– could concentrate traffic on a few links
Routing
• Spanning trees rooted at the sender
• Sender sends out a broadcast over the entire
network - all routers get at least one packet
• When receivers want to join, routers employ
Reverse Path Multicasting
• Use Pruning to limit the multicast
transmission.
Routing
• DVMRP - Distance Vector Multicast
• MOSPF - Multicast Extensions to OSPF
• PIM - Protocol Independent Multicast
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