1 Group Communications: MOSPF and PIM Dr. Rocky K. C. Chang 19 March, 2002

2 Multicast extension to OSPF (MOSPF) MOSPF adds a new group-membership LSA (link state advertisement) to support IP multicast. Given that each MOSPF router has learnt where the members are, it can make forwarding decision based on both the source and destination addresses. –For example, host 2 sends a multicast packet to group B. RT3 will send a copy to N3 but not to RT6. Upon receiving a multicast packet, each MOSPF router could compute a pruned “shortest-path” spanning tree rooted at the source network. –After the computation, the router may or may not be on the tree. –For example, host 2 sends a multicast packet to group A.

3

4 Shortest-path tree rooted at RT3

5 Router support for intra-area multicasting Each MOSPF router is required to keep a local group database and a forwarding cache. A local group database which keep tracks of group membership on its directly attached networks (through IGMP). For example, RouterLocal Group Database RT1[Group B, N1] RT2[Group A, N2], [Group B, N2] RT3[Group B, N3] RT4None –In this example, RT3 is a designated router for N3, responsible for advertising the multicast membership for this network.

6 Forwarding cache A forwarding cache (only for routers on the multicast tree). For each (source network, destination group, type-of- service), the router maintains a list of outgoing interfaces and the number of hops to the destinations. Example: source network = N4 and destination = group A. RouterUpstream NodeDownstream interface (interface: hops) RT10RT6(N6:1) (N8:2) RT11N8(N9:1) RT3N4(N3:1) (RT6:3) RT6RT3(RT10:2) RT2N3(N2:1)

7 Forwarding cache The forwarding cache is computed based on the source network address, the network topology, and the group membership information. –Find the upstream node, and –the downstream nodes and number of hops. The forwarding cache will change when –the topology of the OSPF network changes, or –there is a change in the group-membership LSAs.

8 Computing shortest-path trees A MOSPF will compute the shortest-path tree for (s, G) upon receiving the first packet, i.e., data driven. Based on a link state database, every MOSPF router can independently compute shortest-path trees for any (s, G). –Need a modified shortest-path algorithm for the computation? –The shortest path is truly computed from the source to the networks with membership. –Contrary to DVMRP and PIM-DM, MOSPF is not based on RPF.

9 Joining a multicast group When a first member joins a group on a network by sending an IGMP report message, –A designated router updates its local group database. –It then floods a group-membership LSA about this new membership throughout the area. –Every MOSPF router, upon receiving this message, updates its local database. –An MOSPF router that is on the tree will eventually modify its forwarding entry to include this new network. –For example, each of the routers R1, R2, and R3 will originate a group membership LSA for group B.

10 Leaving a multicast group When the last member leaves a group on a network, –A designated router ages out the corresponding entry in its local group database. –It then floods a group-membership LSA throughout the area to delete this network from the group. –Every MOSPF router, upon receiving this message, updates its local database. –An MOSPF router that is on the tree will modify its forwarding entry to exclude this new network.

11 Comparison with DVMRP Unlike DVMRP and PIM-DM, the first packet from a (s, G) is not flooded to the entire network. –In other words, MOSPF uses an explicit join (through the group-membership LSAs). –But, all MOSPF routers in an area do need to store all the group-membership LSAs, whether or not any source is even sending to this group. Like DVMRP and PIM-DM, the creation of the forwarding table is “driven” by the first packet sent to the group.

12 Protocol Independent Multicast (PIM)-DM PIM is independent of particular unicast routing protocols. –It is based on the unicast routing tables, independent of how those tables are computed. PIM-DM also implements RPM, with a few important differences as compared with DVMRP: –PIM-DM is not hard-wired into a specific type of topology discovery protocol, such as RIP. –The trade-off is that more overhead may be incurred, because broadcast-and-prune occurs on some links that could be avoided if topology information is available. –PIM routers send periodic Hello message out of each interface and keep track of neighbors based on received Hello messages.

13 Leaf network detection The definition of leaf networks in PIM-DM is different from that used in DVMRP: –A network on a router interface is deemed a leaf if there are no other PIM neighbors on that network (do not receive Hello messages). –When there are two routers on a network, and each of them does not use the other as the next-hop router towards as source: In DVMRP, that network is a leaf to both routers. In PIM-DM, that network is not a leaf to both routers.

14 Multicasting on multi-access LAN If a router receives a multicast datagram on an outgoing interface to a multi-access LAN, the packet must be a duplicate. To elect a single forwarder for the LAN, the router sends out an Assert message addressed to all-PIM- routers group. –The message contains a metric or a set of metrics with preferences describing the path from the router to the source. –Those routers that have lost the election prune their interfaces. –The router that have won the election and there are members on the LAN, it sends an assert with its own metric on the LAN so that all other routers know the winner.

15 Pruning of branches When a prune message is sent onto an upstream LAN, it is a data-link multicast addressed to all-PIM-routers group. –The router to process the prune will be indicated by inclusion of its address in the message. After receiving the message, the expected router schedules to delete the interface from the set of outgoing interfaces by activating a timer. Before the timer expiration, if other routers on the LAN sends a PIM-Join message addressed to all-PIM- routers group, –the expected router will cancel the scheduled delete request (prune-override). Otherwise, the interface will be pruned.

16 Pruning of branches Similar to IGMP, each router that needs to send PIM- Join messages will start a random join message delay timer. –A router will cancel its timer if it hears a PIM-Join message. PIM messages required for dense mode: –Hello –Join/Prune (only Prune is used) –Assert –Graft (used only in PIM-DM) –Graft-Ack (used only in PIM-DM)

17 Protocol Independent Multicast (PIM)-SM PIM-SM distributes multicast packets through a shared tree, which is rooted at a pre-determined router called Rendezvous Point (RP). –Another well-known multicast routing protocol based on shared tree is Core Based Tree (CBT). PIM-SM is designed for a sparsely distributed group membership. PIM-SM allows also members to receive a source’s packet from a source-specific tree. –The shared tree is required to prune away those sources. PIM-SM uses soft-state refreshment mechanisms to achieve reliability.

18 Local hosts joining a group When receiving a first IGMP report message for a group G, the Designated Router (DR) creates a wildcard multicast route entry (*, G). –The DR looks up the associated RP for G (through bootstrap messages). –The RP’s address is included in periodic upstream Join/Prune messages. –The outgoing interface is set to the one receiving the IGMP report messages. –The incoming interface is set to the one used to send unicast packets to the RP.

19 Establishing the RP-rooted shared tree Triggered by the (*, G) state, the DR creates a Join/Prune message with the RP address in its join list. –The wildcard bit (WC-bit) is set to 1, indicating that the downstream receivers are expecting to receive packets from all sources via the shared tree. –The RP-tree bit (RPT-bit) is set to 1, indicating that this join is being sent up the shared, RP-tree. Each upstream router creates or updates its multicast route entry for (*,G) when it receives a Join/Prune with the RPT-bit and WC-bit set. –The interface on which the Join/Prune message arrived is added to the list of outgoing interfaces (oifs) for (*,G).

20 Establishing the RP-rooted shared tree

21 Hosts sending to a group The sender's DR initially encapsulates each data packet in a Register message and unicasts it to the RP for that group. –The RP decapsulates each Register message and forwards the enclosed data packet natively to downstream members on the shared RP-tree. If the data rate of the source warrants the use of a source-specific shortest path tree (SPT), –the RP may construct a new multicast route entry (S,G), and send periodic Join/Prune messages toward the source. The source's DR must stop encapsulating data packets in Registers when (and so long as) it receives Register-Stop messages from the RP.

22 Hosts sending to a group –The RP triggers Register-Stop messages in response to Registers, if the RP has no downstream receivers for the group (or for that particular source), or if the RP has already joined the (S,G) tree and is receiving the data packets natively. –Each source's DR maintains, per (S,G), a Register- Suppression-timer. The Register-Suppression-timer is started by the Register-Stop message; upon expiration, the source's DR resumes sending data packets to the RP, encapsulated in Register messages.

23 Hosts sending to a group

24 Switching from RP-tree to SP-tree A router with directly-connected members first joins the shared RP-tree. –The router can switch to a source's shortest path tree (SP- tree) after receiving packets from that source over the shared RP-tree. –Only the RP and routers with local members can initiate switching to the SP-tree; intermediate routers cannot. When a (S,G) entry is activated (and periodically so long as the state exists), a Join/Prune message is sent upstream towards the source, S, with S in the join list. –The outgoing interface list for (S, G) is copied from (*,G).

25 Switching from RP-tree to SP-tree Note that (S,G) state must be maintained in each last- hop router that is responsible for initiating and maintaining an SP-tree. –(S,G) state is kept alive by data packets arriving from that source. –A timer, Entry-timer, is set for the (S,G) entry. –This timer is restarted whenever data packets for (S,G) are forwarded out at least one oif, or Registers are sent. –When the Entry-timer expires, the state is deleted.

26 Switching from RP-tree to SP-tree The (S,G) entry is initialized with the SPT-bit cleared, indicating –that the shortest path tree branch from S has not yet been setup completely, and –the router can still accept packets from S that arrive on the (*,G) entry's indicated incoming interface (iif). When a router with a (S,G) entry and a cleared SPT- bit starts to receive packets from the new source S on the iif for the (S,G) entry, and that iif differs from the (*,G) entry's iif (a forked path), –the router sets the SPT-bit, and sends a Join/Prune message towards the RP, indicating that the router no longer wants to receive packets from S via the shared RP-tree.

27 Switching from RP-tree to SP-tree –The Join/Prune message sent towards the RP includes S in the prune list, with the RPT-bit set indicating that S's packets must not be forwarded down this branch of the shared tree. If the router receiving the Join/Prune message has (S,G) state, it deletes the arriving interface from the (S,G) oif list. If the router has only (*,G) state, it creates an entry with the RPT-bit flag set to 1 ((S,G)RPT-bit entry).

28 Switching from RP-tree to SP-tree

29 Maintenance of distribution tree In the steady state, each router sends periodic Join/Prune messages for each active PIM route entry. –The Join/Prune messages are sent to the neighbor indicated in the corresponding entry. –These messages are sent periodically to capture state, topology, and membership changes. A Join/Prune message is also sent on an event- triggered basis each time a new route entry is established for some new source. Join/Prune messages do not elicit any form of explicit acknowledgment; routers recover from lost packets using the periodic refresh mechanism.

30 Multicast data packet processing A router first performs a longest match on the source and group address in the data packet. –A (S,G) entry is matched first if one exists; a (*,G) entry is matched otherwise. –If neither matches, drop the packet (we do not consider the (*, *, RP) entry match). If a state is matched, the router compares the interface from which the packet is received and the incoming interface in the route entry. –If not matched, drop the packet. –Otherwise, the packet is forwarded to the set of outgoing interfaces.

31 Multicast data packet processing Some special actions are needed to deliver packets continuously while switching from the shared to shortest-path tree. When a (S,G) entry is matched, incoming packets are forwarded as follows: –If the SPT-bit is set, then: if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). if the incoming interface is different than a matching (S,G) iif, the packet is discarded. –If the SPT-bit is cleared, then: if the incoming interface is the same as a matching (S,G) iif, the packet is forwarded to the oif-list of (S,G). In addition, the SPT bit is set for that entry if the incoming interface differs from the incoming interface of the (*,G).

32 Multicast data packet processing if the incoming interface is different than a matching (S,G) iif, the incoming interface is tested against a matching (*,G) entry. If the iif is the same as one of those, the packet is forwarded to the oif-list of the matching entry. Otherwise the iif does not match any entry for G and the packet is discarded. Data packets never trigger prunes. However, data packets may trigger actions that in turn trigger prunes. –For example, when router B in figure 3 decides to switch to SP-tree at step 3, it creates a (S,G) entry with SPT-bit set to 0. –When data packets from S arrive at interface 2 of B, B sets the SPT-bit to 1 since the iif for (*,G) is different than that for (S,G). –This triggers the sending of prunes towards the RP.

33 Multicast data packet processing Operation over multi-access networks and the pruning method are the same as the PIM-DM.

34 Acknowledgements The notes are based on –J. Moy, “Multicast Extensions to OSPF,” RFC 1584, March –S. Deering, D. Estrin, D. Farinacci, V. Jacobson, A. Helmy, D. Meyer, L. Wei, “Protocol Independent Multicast Version 2 Dense Mode Specification,” Internet Draft draft-ietf-pim- v2-dm-03.txt, June –D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei, “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification,” RFC 2362, June 1998.