Multicast routing

1
Multicast routing

• Multicast Routing
• Prof. A. Sahoo
• KReSIT, IIT Bombay

2
Topics

• Multicasting for group communication
• Mechanisms
• Wide area multicasting
• Multicast IP address
• Reverse path forwarding (RPF), multicast shortest
  path tree, joining, pruning, cost of joining and
  pruning, Integration with Unicast protocol
• MOSPF ( Multicast extension of OSPF)
• MDVRP ( Multicast extension of distance vector)
• Core based tree (CBT)
• Protocol Independent Multicast ( PIM)
• Overlay Multicast network for Internet ( MBONE)
• Multicasting in Local Area Network
• Multicast address in 802 address space
• Internet Group Management Protocol ( IGMP)

3
Multicasting ( Group Communication)

• Multiparty application
• Distance education
• Video/voice conferencing
• Resource discovery
• All of these application require source send data
  to multiple receiver or multicast capability of
  sender.
• Different mode of packet communication in a
  network
• Broadcast,
• Unicast
• Multicast
• Anycast
• Multicast group

4
Multicast group

• Associates a set of senders and receivers with
  each other
• but they are independent of each other
• group created either when a sender starts sending
  from a group
• or a receiver expresses interest in receiving
• even if no one else is there!
• Sender does not need to know receivers
  identities
• Multicast group address serves as a rendezvous
  point between potential senders and receiver of
  that group
• Can view as receivers waiting at the rendezvous
  point for some sender to send them information ,
  and the network takes care of distributing every
  packet that arrives at the rendezvous point to
  every registered receiver.

5
Addressing

• Multicast group in the Internet has its own Class
  D address
• looks like a host address, but isnt
• Class D address in IP address space are used as
  multicast destination address
• 224.0.0.0 to 239.255.255.255, 28 bits can be
  used, over 250 million groups possible
• Multicast address can appear only as destination
  address, never as source address
• When send to a multicast address, the packet
  reaches to all host who are currently belonging
  to that group
• Senders send to the address
• Receivers anywhere in the world request packets
  from that address
• Magic is in associating the two dynamic
  directory service
• Four problems
• which groups are currently active
• how to express interest in joining a group
• discovering the set of receivers in a group
• delivering data to members of a group

6
Multicast flavors

• Unicast point to point
• Multicast
• point to multipoint
• multipoint to multipoint
• Can simulate point to multipoint by a set of
  point to point unicasts
• Can simulate multipoint to multipoint by a set of
  point to multipoint multicasts
• The difference is efficiency
• Ideally we need to send a packet only once over
  a link that is one the way of one or more
  receiver for a certain group

7
Example

• Suppose A wants to talk to B, G, H, I, B to A, G,
  H, I
• With unicast, 4 messages sent from each source
• links AC, BC carry a packet in triplicate
• With point to multipoint multicast, 1 message
  sent from each source
• but requires establishment of two separate
  multicast groups
• With multipoint to multipoint multicast, 1
  message sent from each source,
• single multicast group

8
Shortest path tree

• Ideally, want to send exactly one multicast
  packet per link
• forms a multicast tree rooted at sender
• Optimal multicast tree provides shortest path
  from sender to every receiver
• shortest-path tree rooted at sender

9
Issues in wide-area multicast

• Difficult because
• sources may join and leave dynamically
• need to dynamically update shortest-path tree
• leaves of tree are often members of broadcast LAN
• would like to exploit LAN broadcast capability
• would like a receiver to join or leave without
  explicitly notifying sender
• otherwise it will not scale

10
Multicast in a broadcast LAN

• After reaching edge router D ( refer last slide),
  how should the packet reach all multicast
  reveiver in the broadcast LAN?
• Wide area multicast can exploit a LANs broadcast
  capability
• E.g. Ethernet will multicast all packets with
  multicast bit set on destination address ( see
  next slide)
• Two problems
• what multicast MAC address corresponds to a given
  Class D IP address?
• does the LAN contain any members for a given
  group (why do we need to know this?)
• How to inform the network that there are receiver
  for group x in this LAN

11
Multicasting in Ethernet LAN

• Instead of sending multiple link layer packets to
  each host, or to avoid broadcasting, link/mac
  level multicast address should be used.
• In Ethernet, a portion of 6 byte Ethernet address
  is used to identify multicast groups in local LAN
• The lowest bit of most significant byte is set to
  1 to designate multicast address at Ethernet MAC
  address space
• 802 hosts can configure their host adaptor cards
  to listen to MAC layer multicast packets (
  usually 16 or 32 in number)

12
Class D to MAC translation

• Multiple Class D addresses map to the same MAC
  address
• Well-known translation algorithm gt no need for a
  translation table

23 bits copied from IP address
5E
01
00
IEEE 802 MAC Address
Reserved bit
Multicast bit
Class D IP address
1110 Class D indication
Ignored
13
Internet Group Management Protocol

• Detects if a LAN has any members for a particular
  group
• If no members, then we can prune (cut-off) the
  parent router from the shortest path tree for
  that group by updating upstream parent
• Two type of IGMP message
• Router periodically broadcasts a query message
• Hosts reply with the list of groups they are
  interested in
• To suppress traffic
• reply after random timeout
• broadcast reply
• if someone else has expressed interest in a
  group, drop out
• To receive multicast packets
• translate from class D to MAC and configure
  adapter

14
Simplest solution

• Flood packets from a source to entire network
• If a router has not seen a packet before, forward
  it to all interfaces except the incoming one
• Pros
• simple
• always works!
• Cons
• routers receive duplicate packets
• detecting that a packet is a duplicate requires
  storage, which can be expensive for long
  multicast sessions

15
A clever solution

• Reverse path forwarding (RFP)
• Rule
• forward packet from S to all interfaces if and
  only if packet arrives on the interface that
  corresponds to the shortest path to S
• no need to remember past packets
• C need not forward packet received from D

16
Cleverer

• Dont send a packet downstream if you are not on
  the shortest path from the downstream router to
  the source
• C need not forward packet from A to E
• Potential confusion if downstream router has a
  choice of shortest paths to source (see figure on
  previous slide)

17
Pruning

• RPF does not completely eliminate unnecessary
  transmissions
• B and C get packets even though they do not need
  it
• Pruning gt router tells parent in tree to stop
  forwarding
• Can be associated either with a multicast group
  or with a source and group
• trades selectivity for router memory

18
Rejoining

• What if host on Cs LAN wants to receive messages
  from A after a previous prune by C?
• IGMP lets C know of hosts interest
• C can send a join(group, A) message to B, which
  propagates it to A
• or, periodically flood a message C refrains from
  pruning.
• The later is called Flood and Prune approach to
  multicast tree management.
• Flood and Prune was used in first implementation
  of multicast in Internet

19
Contd

• Cost of pruning and joining
• Prunes can be associated with a multicast group
  or a particular multicast group source
• In first case
• Routers need to store only one prune indication
  per output interface per group
• Receivers the prunes message from one source
  cannot receive message from other source in the
  same group
• In second case
• Routers need to store prune indication per source
  per group for each interface.
• Second case is much costly with regard to storage
  space.

20
Internet Multicast Protocol

• MOSPF DVMRP
• What modification is required in link state
  routing and distance vector routing to support
  multicasting
• What if not all routers but only a subset of
  routers in Internet supports multicasting
  mechanism
• Multicast version of OSPF
• In link state each router monitors its directly
  connected links and broadcasts to all other
  routers whenever a change in link state occurs
• The extension requires to support multicasting is
  following
• - The link state part also contains all multicast
  groups for which the link has member(s)
• -with this information each router can compute
  the shortest path multicast tree for each source
  of each group
• Since router has to store this tree for each
  source for each group, overhead is high, hence
  not scalable

21
Internet Multicast Protocol

• MOSPF DVMRP
• What modification is required in link state
  routing and distance vector routing to support
  multicasting
• What if not all routers but only a subset of
  routers in Internet supports multicasting
  mechanism

22
DVMRP

• DVMRP ( Distance vector multicast routing
  protocol)
• Very similar to RIP
• distance vector
• hop count metric
• reverse-path forwarding (to decide where to
  forward a packet)
• Used in conjunction with
• flood-and-prune (to determine memberships)
• prunes store per-source and per-group information
• Each router stores prune information for reverse
  path multicasting I.e. selective forwarding. (
  per source, per group for each interface)
• explicit join messages to reduce join latency
  (but no source info, so still need flooding)

23
MOSPF

• MOSPF (Multicast OSPF)
• Multicast extension to OSPF
• Routers flood group membership information with
  LSPs (LSP extended)
• Each router independently computes shortest-path
  tree that only includes multicast-capable routers
• no need to flood and prune
• Group joining and leaving information gets
  updated in all router through Link State Update
• Complex
• interactions with external and summary records
• need storage per group per link
• need to compute shortest path tree per source and
  group
• Since router has to store this tree for each
  source for each group, overhead is high, hence
  not scalable

24
Core based tree Multicasting

• DVMRP and MOSPF were source based multicast tree
• Each source uses different source specific
  shortest path tree for data forwarding
• Cost of group formation with these schemes
  join/prune information store per source per group
  per interface in each router.
• Both suffer from scaling problems.Building trees
  installs state in the routers. It is easy to
  observe that both does not scale well when a
  relatively small proportion (sparse mode) of
  routers wants to receive packet from a particular
  group. CBT and PIM( see next slides) are
  primarily for sparse mode situation.

25
Core based tree Multicasting

• Core based Tree
• Key idea with core-based tree
• coordinate multicast with a core router
• host sends a join request to core router
• routers along path mark incoming interface for
  forwarding.

26
Example

• Pros
• routers not part of a group are not involved in
  pruning
• explicit join/leave makes membership changes
  faster
• router needs to store only one record per group
• Cons
• all multicast traffic traverses core, which is a
  bottleneck
• traffic travels on non-optimal paths

27
Protocol independent multicast (PIM)

• Tries to bring together best aspects of CBT and
  DVMRP
• Choose different strategies depending on whether
  multicast tree is dense or sparse
• In dense mode the receivers are densely situated
  and most f the routes need to participate in the
  multicast forwarding
• flood and prune good for dense groups
• only need a few prunes
• CBT needs explicit join per source/group
• In sparse mode receivers are sparsely situated,
  Flood and prune is a wastage. Too many prune
  message. Join and prune is better
• CBT good for sparse groups
• Dense mode PIM DVMRP
• Sparse mode PIM is similar to CBT
• but receivers can switch from CBT to a
  shortest-path tree

28
Protocol independent multicast (PIM)

• PIM uses a notion of central node (rendezvous
  point) RP for each group, which maintains
  multicast shortest path tree for each group
• We assume in a domain of routers each router
  knows the unicast IP address for RP of a
  particular group
• In PIM sparse there are two type of trees
  shared tree for a group and source specific
  tree
• Typically shared tree is built first and then
  source specific tree if required

29
Protocol independent multicast (PIM)

• R4 send a join message ( , G) to RP of G.
  denotes all senders.
• All routers in path make an entry in multicast
  forwarding table for (, G) on the incoming link
  R2-R4
• Then R2 selects a link for forwarding the join
  request to RP, ( here R2-RP). This will be only
  acceptable incoming interface for incoming
  packets sent to this group.
• This completes the a branch of the shared tree
  installation at RP and in all routers required to
  reach receiver R4
• Joining request from R5 for group G needs only to
  go up to router router R2, this is another branch
  of shared tree for receiver R5

30
Protocol independent multicast (PIM)

• Problem cost of encapsulation and
  de-encapsulation
• When R1 wants to send to packet to group G, R1
  tunnels it through unicast IP packet to RP, RP
  then forwards the packet with the help of shared
  tree for group G rooted in it
• Approach for long lived session RP sends a join
  message to R1 which installs state in R3, Then R1
  can send native multicast packets
• This join message from RP is sender specific
  (S,G) ( the previous join message from R4 and R5
  were not) and installs sender specific state in
  R3
• So, source specific tree till RP and then
  not-source specific tree from RP upto receivers

31
Protocol independent multicast (PIM)

• Further Optimization
• Clearly the route from R1 to R4 is is not the
  shortest one.
• So entire shared tree can be replaced by source
  specific tree for long sessions
• R4 can send a join request of the form to R1,
  which takes the shortest path installing state (
  S, G) in all intermediate routers. Thus bypassing
  RP completely for sender S
• But the shared tree for (,G) remains at RP for
  all receivers to handle the situation for any new
  sender in the group.
• This is called protocol independent as it works
  any unicast routing mechanism in the internet

32
More on core

• Renamed a rendezvous point
• because it no longer carries all the traffic like
  a CBT core
• Rendezvous points periodically send I am alive
  messages downstream
• Leaf routers set timer on receipt
• If timer goes off, send a join request to
  alternative rendezvous point
• Problems
• how to decide whether to use dense or sparse
  mode?
• how to determine best rendezvous point?

33
Factors evaluating multicast protocol

• Scalability
• What is the amount of state required in routers?
  Or how dies the amount of state change with the
  number of nodes leaving or joining the group
• Reliance on underlying unicast protocol
• To what extent in relies on information available
  by underlying unicast protocol?
• MOSPF, PIM
• Un-needed traffic received
• Router chould not receive traffic if it does not
  have a member for the particular group
• Traffic Concentration
• Group shared tree tend to use specific links
  while source based trees distribute traffic
• Optimality of forwarding path
• Minimum cost multicast tree finding is hard (
  Solving Steiner Tree), center based tree is not
  optimal

34
Some References

• Research Directions
• Congestion/Rate control in multicast tree,
  session maintenance, error control. Security is
  a major issue
• Inter AS Multicast protocol ( IDMR Work group of
  IETF)
• References
• S.E. Deering and D.R. Cheriton, Multicast Routing
  in Datagram Internetworks and Extended LANs, ACM
  Trans. On Comp. Sys., Vol 8, No 2, May 1990, pp
  85-110.
• S.E. Deering, et.al., An Architecture for
  Wide-Area Multicast Routing, Proc. SIGCOMM 94,
  London, England, August 1994.
• V. Johnson and M. Johnson, Introduction to IP
  Multicast Routing, http//www.ipmulticast.com/comm
  unity/whitepapers/introrouting.html.
• S. Deering, D. Estrin, D. Farinacci, V. Jacobson,
  C. Liu, and L. Wei, Protocol Independent
  Multicasting
• Scalable Multicast Key Distribution (1994)   Tony
  Ballardie
• Scalable Secure Group Communication over
  IP  Multicast Suman Banerjee, Bobby Bhattacharjee
  
• L wei, D. Estreen, A comparison of multicast
  trees and algorithms Technical report USC.

35
Some References

• Multicasting Tools
• SDR, VIC and RAT for Sun, Linux and Windows
  multicasting. Quicktime will be the Macintosh
  application for viewing multicast sessions.
• Products
• Apple's QuickTime Conferencing software.
• ICAST Express Media, video, audio and text
  clients and servers, beta version available on
  request.
• Merit Network's mrouted, multicast router daemon
  (server).
• Microsoft's NetShow-- Windows video/audio client
  and server. Multicast-capable.
• Precept's IP/TV -- Windows client for receiving
  video/audio/slide broadcasts.
• Van Jacobson's popular multimedia multicasting
  tools for a Unix X Window server video (VIC),
  and audio (VAT).

36
Multicast Overlay

• Reverse path forwarding requires a router to know
  shortest path to a source
• known from routing table
• Doesnt work if some routers do not support
  multicast
• virtual links between multicast-capable routers
• shortest path to A from E is not C, but F

37
Overlay (contd.)

• Two problems
• how to build virtual links
• how to construct routing table for a network with
  virtual links
• TUNNELS
• Why do we need them
• Consider packet sent from A to F via
  multicast-incapable D
• If packets destination is Class D, D drops it
• If destination is Fs address, F doesnt get to
  know multicast address!
• So, put packet destination as F, but carry
  multicast address internally
• Encapsulate IP in IP gt set protocol type to
  IP-in-IP
• DVMRP is capable of making virtual links.

38
Reference for MBONE

• Michael R. Macedonia and Donald P. Brutzman.
  MBONE provides audio and video across the
  Internet. IEEE Computer, vol. 2Z(no. 4)30-36,
  April 1994. available at 44
• Hans Eriksson. MBONE The multicast backbone.
  Communications of the ACM, vol. 37(no. 8), August
  1994. available at
• Stephen Casner and Stephen Deering. First IETF
  Internet audiocast. ACM Sigcomm Computer
  Communication Review, vol. 22(no. 23)92-97, July
  1992. available at ftp//venera.isi.edu/pub/ietf-a
  udiocast.article.ps.
• Stephen Casner. Are you on the MBone? IEEE
  Multimedia, vol. 1(no. 2)76-79, 1994. available
  at
• Mark Handley and Van Jacobson. SDP Session
  description protocol, 1996. Internet draft,
  currently available at http//ds.internic.net/inte
  rnet-drafts/draft-ietf-mmusic-sdp-
• Mark Handley. SAP Session announcement protocol,
  1996. Internet draft,
• M. Handley, H. Schulzrinne, and E. Schooler. SIP
  Session invitation protocol, 1996. Internet draft.