Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Multicast

•Download as PPT, PDF•
•
Sagar Surve
Sagar Surve

1. The document discusses IP multicast routing protocols including DVMRP and PIM. It describes how multicast routing differs from unicast routing in establishing distribution trees from sources to receivers. 2. Key aspects covered include IGMP for hosts to join multicast groups, source trees versus shared trees, dense and sparse mode protocols, and data distribution policies using ACK and NACK approaches. 3. DVMRP is introduced as an early multicast routing protocol that uses distance vector exchange and reverse path forwarding to construct source trees and prune branches without receivers.

1 of 38
Multicast Outline Multicast Introduction and Motivation RIP-based and Protocol Independent Multicast Routing
One to many communication • Application level one to • IP multicast many communication • multiple unicasts R R S S R R R R CS 640 2
Why Multicast • When sending same data to multiple receivers – better bandwidth utilization – less host/router processing – quicker participation • Application – Video/Audio broadcast (One sender) – Video conferencing (Many senders) – Real time news distribution – Interactive gaming CS 640 3
IP multicast service model • Invented by Steve Deering (PhD. 1991) – It’s a different way of routing datagrams • RFC1112 : Host Extensions for IP Multicasting - 1989 • Senders transmit IP datagrams to a "host group" • “Host group” identified by a class D IP address • Members of host group could be present anywhere in the Internet • Members join and leave the group and indicate this to the routers • Senders and receivers are distinct: i.e., a sender need not be a member • Routers listen to all multicast addresses and use multicast routing protocols to manage groups CS 640 4
IP multicast group address • Things are a little tricky in multicast since receivers can be anywhere • Class D address space – high-order three 3bits are set – 224.0.0.0 ~ 239.255.255.255 • Allocation is essentially random – any class D can be used – Nothing prevents an app from sending to any multicast address – Customers end hosts and ISPs are the ones who suffer • Some well-known address have been designated – RFC1700 – 224.0.0.0 ~ 224.0.0.25 • Standard are evolving CS 640 5
Getting Packets to End Hosts • We haven’t treated general methods for this yet but the problem is having both a unicast and multicast IP • Packets from remote sources will only be forwarded by IP routers onto a local network only if they know there is at least one recipient for that group on that network • Internet Group Management Protocol (IGMP, RFC2236) – Used by end hosts to signal that they want to join a specific multicast group – Used by routers to discover what groups have have interested member hosts on each network to which they are attached. – Implemented directly over IP CS 640 6
IGMP – Joining a group Example : R joins to Group 224.2.0.1 IGMP Membership-Report • R sends IGMP Membership-Report R to 224.2.0.1 Network A • DR receives it. DR will start forwarding packets for 224.2.0.1 to Network A DR Network B Data to 224.2.0.1 • DR periodically sends IGMP Membership-Query to 224.0.0.1 (ALL-SYSTEMS.MCAST.NET) R: Receiver DR: Designated Router • R answers IGMP Membership- Report to 224.2.0.1 CS 640 7
IGMP – Leaving a group IGMP Leave-Group Example : R leaves from a Group 224.2.0.1 R • R sends IGMP Leave-Group to 224.0.0.2 Network A (ALL-ROUTERS.MCAST.NET) • DR receives it. DR • DR stops forwarding packets for Network B Data to 224.2.0.1 224.2.0.1 to Network A if no more 224.2.0.1 group members on Network R: Receiver DR: Designated Router A. CS 640 8
Challenges in the multicast model • How can a sender restrict who can receive? – need authentication, authorization – encryption of data – key distribution – still an active area of research CS 640 9
IP multicast routing • Purpose: share Group information among routers, to implement better routing for data distribution • Distribution tree structure – Source tree vs shared tree • Data distribution policy – Opt in (ACK) type vs opt out (NACK) type • Routing protocols are used in conjunction with IGMP CS 640 10
Source distribution tree Source S Notation: (S, G) S = Source G = Group A B D F C E R R Receiver 1 Receiver 2 CS 640 11
Shared distribution tree Source S1 Notation: (*, G) * = all sources G = Group Shared Root A B D F S2 C E R R Receiver 1 Receiver 2 CS 640 12
Source tree characteristics • Source tree – More memory O (G x S ) in routers – optimal path from source to receiver, minimizes delay • good for – small number of senders, many receivers such as Radio broadcasting application CS 640 13
Shared tree characteristics • Shared tree – Less memory O (G) in routers – Sub-optimal path from source to receiver, may introduce extra delay (source to root) – May have duplicate data transfer (possible duplication of a path from source to root and a path from root to receivers) • good for – Environments where most of the shared tree is the same as the source tree – Many senders with low bandwidth (e.g. shared whiteboard) CS 640 14
Data distribution policy • Opt out (NACK) type – Start with “broadcasting” then prune brunches with no receivers, to create a distribution tree – Lots of wasted traffic when there are only a few receivers and they are spread over wide area • Opt in (ACK) type – Forward only to the hosts which explicitly joined to the group – Latency of join propagation CS 640 15
Protocol types • Dense mode protocols – assumes dense group membership – Source distribution tree and NACK type – DVMRP (Distance Vector Multicast Routing Protocol) – PIM-DM (Protocol Independent Multicast, Dense Mode) – Example: Company-wide announcement • Sparse mode protocol – assumes sparse group membership – Shared distribution tree and ACK type – PIM-SM (Protocol Independent Multicast, Sparse Mode) – Examples: Futurama or a Shuttle Launch CS 640 16
DVMRP exchange distance vectors • Each router maintains a ‘multicast routing table’ by exchanging distance vector information among routers – First multicast routing protocol ever deployed in the Internet • Similar to RIP – Constructs a source tree for each group using reverse path forwarding • Tree provides a shortest path between source and each receiver • There is a “designated forwarder” in each subnet – Multiple routers on the same LAN select designated forwarder by lower metric or lower IP address (discover when exchanging metric info.) • Once tree is created, it is used to forward messages from source to receivers • If all routers in the network do not support DVMRP then unicast tunnels are used to connect multicast enabled networks CS 640 17
DVMRP broadcast & prune • Flood multicast packets based on RPF (Reverse path forwarding) rule to all routers. • Leaf routers check and sends prune message to upstream router when no group member is on their network • Upstream router prune the interface with no dependent downstream router. • Graft message to create a new branch for late participants • Restart forwarding after prune lifetime (standard : 720 minutes) • draft-ietf-idmr-dvmrp-v3-09.txt (September 1999) CS 640 18
RPF(reverse path forwarding) • Simple algorithm developed to avoid duplicate packets on multi- access links • RPF algorithm takes advantage of the IP routing table to compute a multicast tree for each source. • RPF check – When a multicast packet is received, note its source (S) and interface (I) – If I belongs to the shortest path from S, forward to all interfaces except I – If test in step 2 is false, drop the packet • Packet is never forwarded back out the RPF interface! CS 640 19
DVMRP (1) form a source tree by exchanging metric source tree S Source DF R1 Receiver 1 CS 640 20
DVMRP (2) broadcast source tree S Source datagram DF R1 Receiver 1 CS 640 21
DVMRP (3) prune source tree S Source datagram IGMP DVMRP-Prune DF R1 Receiver 1 CS 640 22
DVMRP (4) X and Y pruned source tree S Source datagram DF X Y R1 Receiver 1 CS 640 23
DVMRP (4) New member source tree S Source datagram IGMP DVMRP-Graft DF X Y R1 R2 Receiver 1 Receiver 2 CS 640 24
DVMRP (4) New branch source tree S Source datagram IGMP DVMRP-Graft DF X Y R1 R2 Receiver 1 Receiver 2 CS 640 25
Protocol Independent Multicast • PIM : Protocol Independent Multicast – Independent of particular unicast routing protocol • Just assumes one exists – Pros: simple, less overhead • Does not require computation of specific routing tables – Cons: may cause more broadcast-and-prunes (in dense mode) – Most popular multicast routing protocol today • Main difference with DVMRP – independence from underlying unicast routing mechanism • PIM supports both dense (DM) and sparse (SM) mode operation – You can locally use either or both modes CS 640 26
PIM DM overview(1) • Assumes that you have lots of folks who want to be part of a group • Based on broadcast and prune – Ideal for dense group • Source tree created on demand based on RPF rule • If the source goes inactive, the tree is torn down • Easy “plug-and-play” configuration • Branches that don’t want data are pruned CS 640 27
PIM DM overview(2) • Grafts used to join existing source tree • Asserts used to determine the forwarder for multi- access LAN • Non-RPF point-2-point links are pruned as a consequence of initial flooding CS 640 28
PIM DM Forwarding • PIM DM interfaces are placed on an “downstream” list for a multicast group if: – PIM neighbor is heard on interface – Host on this interface has just joined the group – Interface has been manually configured to join group • Packets are flooded out all interfaces in “downstream” list – If a PIM neighbor is present, DM assumes EVERYONE wants to receive the group so it gets flooded to that link CS 640 29
PIM Assert Mechanism • Routers receive packet on an interface in their “downstream” list – Only one router should continue sending to avoid duplicate packets. • Routers sends “PIM assert” messages – Compare distance and metric values – Router with best route to source wins – If metric & distance equal, highest IP addr wins – Losing router stops sending (prunes interface) CS 640 30
PIM DM State Maintenace • State is maintained by the “flood and prune” behavior of Dense Mode. – Received Multicast packets reset(S,G) entry “expiration” timers. – When (S,G) entry “expiration” timers count down to zero, the entry is deleted. • Interface prune state times out causing periodic reflooding and pruning – could be as little as 210 seconds CS 640 31
PIM-DM(1) Initial flood of data S Source A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 32
PIM-DM(2) prune non-RPF p2p link S Source IGMP PIM-Prune A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 33
PIM-DM(3) C and D Assert to Determine Forwarder for the LAN, C Wins S Source IGMP PIM-Assert with its own IP address A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 34
PIM-DM(4) I, E, G send Prune H send Join to override G’s Prune S Source IGMP PIM-Prune IGMP PIM-Join A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 35
PIM-DM(5) I Gets Pruned E’s Prune is Ignored (since R1 is a receiver) G’s Prune is Overridden (due to new receiver R2) S Source A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 36
PIM-DM(6) New Receiver, I send Graft S Source IGMP PIM-Graft A B G C D F H E I R1 R2 Receiver 1 R3 Receiver 2 CS 640 37 Receiver 3
PIM-DM(6) new branch S Source IGMP PIM-Graft A B G C D F H E I R1 R2 Receiver 1 R3 Receiver 2 CS 640 38 Receiver 3

More Related Content

Multicast

  • 1. Multicast Outline Multicast Introduction and Motivation RIP-based and Protocol Independent Multicast Routing
  • 2. One to many communication • Application level one to • IP multicast many communication • multiple unicasts R R S S R R R R CS 640 2
  • 3. Why Multicast • When sending same data to multiple receivers – better bandwidth utilization – less host/router processing – quicker participation • Application – Video/Audio broadcast (One sender) – Video conferencing (Many senders) – Real time news distribution – Interactive gaming CS 640 3
  • 4. IP multicast service model • Invented by Steve Deering (PhD. 1991) – It’s a different way of routing datagrams • RFC1112 : Host Extensions for IP Multicasting - 1989 • Senders transmit IP datagrams to a "host group" • “Host group” identified by a class D IP address • Members of host group could be present anywhere in the Internet • Members join and leave the group and indicate this to the routers • Senders and receivers are distinct: i.e., a sender need not be a member • Routers listen to all multicast addresses and use multicast routing protocols to manage groups CS 640 4
  • 5. IP multicast group address • Things are a little tricky in multicast since receivers can be anywhere • Class D address space – high-order three 3bits are set – 224.0.0.0 ~ 239.255.255.255 • Allocation is essentially random – any class D can be used – Nothing prevents an app from sending to any multicast address – Customers end hosts and ISPs are the ones who suffer • Some well-known address have been designated – RFC1700 – 224.0.0.0 ~ 224.0.0.25 • Standard are evolving CS 640 5
  • 6. Getting Packets to End Hosts • We haven’t treated general methods for this yet but the problem is having both a unicast and multicast IP • Packets from remote sources will only be forwarded by IP routers onto a local network only if they know there is at least one recipient for that group on that network • Internet Group Management Protocol (IGMP, RFC2236) – Used by end hosts to signal that they want to join a specific multicast group – Used by routers to discover what groups have have interested member hosts on each network to which they are attached. – Implemented directly over IP CS 640 6
  • 7. IGMP – Joining a group Example : R joins to Group 224.2.0.1 IGMP Membership-Report • R sends IGMP Membership-Report R to 224.2.0.1 Network A • DR receives it. DR will start forwarding packets for 224.2.0.1 to Network A DR Network B Data to 224.2.0.1 • DR periodically sends IGMP Membership-Query to 224.0.0.1 (ALL-SYSTEMS.MCAST.NET) R: Receiver DR: Designated Router • R answers IGMP Membership- Report to 224.2.0.1 CS 640 7
  • 8. IGMP – Leaving a group IGMP Leave-Group Example : R leaves from a Group 224.2.0.1 R • R sends IGMP Leave-Group to 224.0.0.2 Network A (ALL-ROUTERS.MCAST.NET) • DR receives it. DR • DR stops forwarding packets for Network B Data to 224.2.0.1 224.2.0.1 to Network A if no more 224.2.0.1 group members on Network R: Receiver DR: Designated Router A. CS 640 8
  • 9. Challenges in the multicast model • How can a sender restrict who can receive? – need authentication, authorization – encryption of data – key distribution – still an active area of research CS 640 9
  • 10. IP multicast routing • Purpose: share Group information among routers, to implement better routing for data distribution • Distribution tree structure – Source tree vs shared tree • Data distribution policy – Opt in (ACK) type vs opt out (NACK) type • Routing protocols are used in conjunction with IGMP CS 640 10
  • 11. Source distribution tree Source S Notation: (S, G) S = Source G = Group A B D F C E R R Receiver 1 Receiver 2 CS 640 11
  • 12. Shared distribution tree Source S1 Notation: (*, G) * = all sources G = Group Shared Root A B D F S2 C E R R Receiver 1 Receiver 2 CS 640 12
  • 13. Source tree characteristics • Source tree – More memory O (G x S ) in routers – optimal path from source to receiver, minimizes delay • good for – small number of senders, many receivers such as Radio broadcasting application CS 640 13
  • 14. Shared tree characteristics • Shared tree – Less memory O (G) in routers – Sub-optimal path from source to receiver, may introduce extra delay (source to root) – May have duplicate data transfer (possible duplication of a path from source to root and a path from root to receivers) • good for – Environments where most of the shared tree is the same as the source tree – Many senders with low bandwidth (e.g. shared whiteboard) CS 640 14
  • 15. Data distribution policy • Opt out (NACK) type – Start with “broadcasting” then prune brunches with no receivers, to create a distribution tree – Lots of wasted traffic when there are only a few receivers and they are spread over wide area • Opt in (ACK) type – Forward only to the hosts which explicitly joined to the group – Latency of join propagation CS 640 15
  • 16. Protocol types • Dense mode protocols – assumes dense group membership – Source distribution tree and NACK type – DVMRP (Distance Vector Multicast Routing Protocol) – PIM-DM (Protocol Independent Multicast, Dense Mode) – Example: Company-wide announcement • Sparse mode protocol – assumes sparse group membership – Shared distribution tree and ACK type – PIM-SM (Protocol Independent Multicast, Sparse Mode) – Examples: Futurama or a Shuttle Launch CS 640 16
  • 17. DVMRP exchange distance vectors • Each router maintains a ‘multicast routing table’ by exchanging distance vector information among routers – First multicast routing protocol ever deployed in the Internet • Similar to RIP – Constructs a source tree for each group using reverse path forwarding • Tree provides a shortest path between source and each receiver • There is a “designated forwarder” in each subnet – Multiple routers on the same LAN select designated forwarder by lower metric or lower IP address (discover when exchanging metric info.) • Once tree is created, it is used to forward messages from source to receivers • If all routers in the network do not support DVMRP then unicast tunnels are used to connect multicast enabled networks CS 640 17
  • 18. DVMRP broadcast & prune • Flood multicast packets based on RPF (Reverse path forwarding) rule to all routers. • Leaf routers check and sends prune message to upstream router when no group member is on their network • Upstream router prune the interface with no dependent downstream router. • Graft message to create a new branch for late participants • Restart forwarding after prune lifetime (standard : 720 minutes) • draft-ietf-idmr-dvmrp-v3-09.txt (September 1999) CS 640 18
  • 19. RPF(reverse path forwarding) • Simple algorithm developed to avoid duplicate packets on multi- access links • RPF algorithm takes advantage of the IP routing table to compute a multicast tree for each source. • RPF check – When a multicast packet is received, note its source (S) and interface (I) – If I belongs to the shortest path from S, forward to all interfaces except I – If test in step 2 is false, drop the packet • Packet is never forwarded back out the RPF interface! CS 640 19
  • 20. DVMRP (1) form a source tree by exchanging metric source tree S Source DF R1 Receiver 1 CS 640 20
  • 21. DVMRP (2) broadcast source tree S Source datagram DF R1 Receiver 1 CS 640 21
  • 22. DVMRP (3) prune source tree S Source datagram IGMP DVMRP-Prune DF R1 Receiver 1 CS 640 22
  • 23. DVMRP (4) X and Y pruned source tree S Source datagram DF X Y R1 Receiver 1 CS 640 23
  • 24. DVMRP (4) New member source tree S Source datagram IGMP DVMRP-Graft DF X Y R1 R2 Receiver 1 Receiver 2 CS 640 24
  • 25. DVMRP (4) New branch source tree S Source datagram IGMP DVMRP-Graft DF X Y R1 R2 Receiver 1 Receiver 2 CS 640 25
  • 26. Protocol Independent Multicast • PIM : Protocol Independent Multicast – Independent of particular unicast routing protocol • Just assumes one exists – Pros: simple, less overhead • Does not require computation of specific routing tables – Cons: may cause more broadcast-and-prunes (in dense mode) – Most popular multicast routing protocol today • Main difference with DVMRP – independence from underlying unicast routing mechanism • PIM supports both dense (DM) and sparse (SM) mode operation – You can locally use either or both modes CS 640 26
  • 27. PIM DM overview(1) • Assumes that you have lots of folks who want to be part of a group • Based on broadcast and prune – Ideal for dense group • Source tree created on demand based on RPF rule • If the source goes inactive, the tree is torn down • Easy “plug-and-play” configuration • Branches that don’t want data are pruned CS 640 27
  • 28. PIM DM overview(2) • Grafts used to join existing source tree • Asserts used to determine the forwarder for multi- access LAN • Non-RPF point-2-point links are pruned as a consequence of initial flooding CS 640 28
  • 29. PIM DM Forwarding • PIM DM interfaces are placed on an “downstream” list for a multicast group if: – PIM neighbor is heard on interface – Host on this interface has just joined the group – Interface has been manually configured to join group • Packets are flooded out all interfaces in “downstream” list – If a PIM neighbor is present, DM assumes EVERYONE wants to receive the group so it gets flooded to that link CS 640 29
  • 30. PIM Assert Mechanism • Routers receive packet on an interface in their “downstream” list – Only one router should continue sending to avoid duplicate packets. • Routers sends “PIM assert” messages – Compare distance and metric values – Router with best route to source wins – If metric & distance equal, highest IP addr wins – Losing router stops sending (prunes interface) CS 640 30
  • 31. PIM DM State Maintenace • State is maintained by the “flood and prune” behavior of Dense Mode. – Received Multicast packets reset(S,G) entry “expiration” timers. – When (S,G) entry “expiration” timers count down to zero, the entry is deleted. • Interface prune state times out causing periodic reflooding and pruning – could be as little as 210 seconds CS 640 31
  • 32. PIM-DM(1) Initial flood of data S Source A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 32
  • 33. PIM-DM(2) prune non-RPF p2p link S Source IGMP PIM-Prune A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 33
  • 34. PIM-DM(3) C and D Assert to Determine Forwarder for the LAN, C Wins S Source IGMP PIM-Assert with its own IP address A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 34
  • 35. PIM-DM(4) I, E, G send Prune H send Join to override G’s Prune S Source IGMP PIM-Prune IGMP PIM-Join A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 35
  • 36. PIM-DM(5) I Gets Pruned E’s Prune is Ignored (since R1 is a receiver) G’s Prune is Overridden (due to new receiver R2) S Source A B G C D F H E I R1 R2 Receiver 1 Receiver 2 CS 640 36
  • 37. PIM-DM(6) New Receiver, I send Graft S Source IGMP PIM-Graft A B G C D F H E I R1 R2 Receiver 1 R3 Receiver 2 CS 640 37 Receiver 3
  • 38. PIM-DM(6) new branch S Source IGMP PIM-Graft A B G C D F H E I R1 R2 Receiver 1 R3 Receiver 2 CS 640 38 Receiver 3