Multicast OSPF OSPF Open Shortest Path First Link State Protocol Use Dijkstra s algorithm (SPF) Calculate shortest path from the router to every possible destination Areas Limit the information volume Inter-area routing Link State Database Flooded to all routers in area Contains router identity router s neighbours link costs to neighbours external destinations Enhancement to OSPF Link State Advertisement List of groups known at each router Router gets those using IGMP Each router knows all multicast groups in area And where they are in use Where members are located When packet for multicast destination arrives If group exists Calculate SPF tree from source address to each member of multicast group Cache Results Source Address Group Address Incoming Interface Outgoing Links Min TTL to group member We have a network Contains members of a multicast group A packet arrives at a router address to this multicast group from some local source
Router calculates SPF tree from source address to all members of the group Caches result Forwards packet to downstream links One of those packets arrives at next router It calculates the same SPF tree From source address To all members of group Packet also goes to other router Calculated by first as downstream It also calculates the SPF tree from source address of packet to all members of group Note: It is the same tree Uses same algorithm on same data
Same process repeats everywhere packet arrives The same SPF tree is calculated Differences from DVMRP No Flooding Packets only arrive where needed group member exists on path to a group member No RPF Packets sent shortest paths to destinations no shortest paths from recipients needed Much state All routers need every group & where each one exists Limits practical area size Much calculation Every new (S,G) pair Source & group (destination) Must recalculate SPF tree Flush cache If link state database alters If group membership changes Inter-area All OSPF areas connect to backbone area Normal OSPF rule Exchanges destinations among areas All Group membership information flooded into backbone area As well as local area Nothing from backbone area sent back into other areas Groups may have members outside area Data not made available (too much) Must forward all multicast outside to backbone backbone knows all groups and their locations forwards to correct destination areas Wildcard receiver in each area member of all groups forwards to backbone
Inter-area Have backbone area and connected areas (2 here) Local area has a wildcard receiver a member of every multicast group identity flooded through area Inter-area When sender starts sending packets Routers in area calculate SPF tree from sender to all members wildcard router is a member Packets will eventually arrive at the wildcard router Inter-area Wildcard router forwards multicast to backbone always currently has no knowledge of what groups exist outside Backbone calculates tree to local members (in backbone) other areas with members
Inter-area When packet arrives in other area forwarded to members in that area PIM Note No knowledge of sender address Cannot calculate true SPF tree but can approximate Protocol Independent Multicast Protocol -> routing protocol The unicast routing protocol Used only for RPF check except for Multicast should not care which protocol routes need not even match reality but should be reasonable Advantage No duplication of routing less overhead traffic less routing calculations less data to maintain Disadvantage Multicast topology == unicast topology everything must understand multicast PIM Dense & Sparse Two models of multicast usage Many receivers they exist almost everywhere Few receivers only rarely will a net contain a member For first flood & prune works very well flood is little overhead traffic is needed everywhere almost no pruning gets done little state to maintain DVMRP (and similar) works well For second flood & prune is poor much traffic transmitted never needed much pruning is done lots of state to maintain
PIM Dense Mode Dense -> high concentration of group members good chance that most links have one or more everything very closely packed Use flood & prune Use any unicast routing protocol PIM Sparse Mode Sparse -> low concentration of group members low chance that links have members members hard to find Flood and prune much pruning state Avoid this PIM Sparse Mode Worse than it appears Each sender is a new tree Yellow lines show RPF tree to all members Depends upon unicast routing
PIM Sparse Mode For each different sender A totally different tree PIM Sparse Mode State depends upon product number of senders, number of groups Too much state in large net Limit state Select one sender per group Rendezvous Point Defines distribution tree One tree per group PIM Sparse Mode All senders send to RP from router near sender via tunnel
PIM Sparse Mode PIM-Sparse uses Rendezvous Points RP exists for each group Created when group created First IGMP Join request Selected via hash function so RP s are distributed not all near frequent sender Trade off traffic for state more traffic, less state Sometimes good sometimes not Allow source specific tree for high volume senders More state less extra traffic Core Based Trees Proposal not really used anywhere Dynamic Rendezvous points Know group members & senders Selected to be more optimal Explicit ACK protocol Less traffic overall No periodic refresh