4.4 Multicast routing with MOSPF

Multicast OSPF (MOSPF) is an extension of the OSPFv2 unicast routing protocol and only works in internetworks that run OSPF (refer to [18] for details). MOSPF is not a separate routing protocol; it operates by including multicast information in a new type of OSPF link-state advertisement, the group membership LSA, which enables each MOSPF router to learn which multicast groups are active on a per interface basis. The multicast extensions in MOSPF have been implemented to reuse the existing OSPF topology database to compute source-rooted shortest-path multicast delivery trees. Although group membership reports are flooded throughout the OSPF routing domain, MOSPF operates as a sparse-mode multicast routing protocol, since it relies on users joining a group before multicast data are forwarded to an interface. MOSPF builds a multicast distribution tree for each source-group pair and computes a tree for active sources sending to the group. The tree state is cached and must be recomputed when a link-state change occurs or when the cache times out.

4.4.1 Message formats

MOSPF routers advertise their ability to forward multicasts using standard OSPF hello messages by setting the MC bit in the options field. The example hello packet in Figure 4.8 shows both the E and MC bits set in a standard advertisement, indicating that the router can support both unicast and multicast forwarding.

 File:OSPF07.SCP  Type:XYP1820_SCP Mode:ooooooo Records:14 ================================================================== Frame  : 68        Len   : 78        Error  : None T Elapsed: 01:02:26:385   T Delta : 00:00:00:270 -----------------------------[mac]-------------------------------- Dest Mac : 01005e000005   Sourc Mac: Xyplex1208e5   Type   : IP -------------------------------[ip]------------------------------- IP Ver  : 4        IP HLen : 20 Bytes TOS   : 0x00       Pkt Len : 64        Seg ID  : 0x003a Flags  : FRAG:X.LAST   Frag Ptr : 0   (8 Octet) TTL   : 1 (Low) PID   : OSPF ( 89)    Checksum : 0xf4f1 (Good) Dest IP : 224.0.0.5    Source IP: 156.48.8.4 -------------------------------[ospf]----------------------------- OSPF Ver : 2        Type   : HELLO      Length  : 44 Router ID: 156.48.121.10  Area  ID: 0.0.0.0     Checksum : 0xe963 AU Type : 00        AU Key  : {    } -------------------------------[hello]---------------------------- Hello Msk: 255.255.255.0  Hello Int: 10        Hello Pri: 1 Options : MC.E (06)    Dead Int : 40 DR    : 0.0.0.0     BDR   : 0.0.0.0 ===============================[data:0]===========================

Figure 4.8: OSPF hello message example.

4.4.2 Operation

MOSPF forwards a multicast datagram along the shortest path tree, as per unicast datagrams; however, there are some differences in operation, as follows:

MOSPF is responsible for forwarding only multicast datagrams; OSPF is still required to forward unicast datagrams using shortest-path dynamic routing.
Unlike unicast datagrams, multicast datagrams are forwarded on the basis of both the datagram source unicast address and destination multicast address.
Since there are many potential Spanning Trees, each router will calculate a pruned shortest-path tree on demand for each multicast datagram. Shortest-path trees are built when the first datagram is received and then cached for subsequent use by datagrams with the same source and destination addresses (i.e., they are not recalculated for every datagram in a flow). Pruning occurs because some subnetworks may not require multicast groups to be forwarded to them.
All routers generate an identical pruned Spanning Tree for a given datagram (unlike unicast operation, where each router generates its own Spanning Tree). There is, therefore, a single path between a datagram's source and its destination group members. Unlike unicast datagrams there is no facility for equal-cost multipath support (optional with OSPF).
When multicast receivers are located on different interfaces, MOSPF will replicate the source multicast and forward it to all relevant interfaces.
Network Layer multicasts are mapped onto Data Link Layer multicast, as described previously. MOSPF can be used over NBMA networks, in which case multicasts will be forwarded to neighbors as unicasts, which avoids replication issues and allows selective forwarding.

The OSPF link-state database provides a complete description of the AS's topology. By using the new group membership LSA the location of all multicast group members can be retrieved from the database. The forwarding path for a multicast datagram can be calculated on the fly by building a shortest-path tree rooted at the datagram source address. All branches not containing multicast members are pruned from the tree.

The information cached is actually made up of two sets of data: the group membership information associated with hosts on a particular interface, and a datagram's shortest path tree built on demand for each source/destination multicast datagram. Note that group membership information is typically retrieved via IGMP (although it can be specified statically on some routers). MOSPF is purely concerned with the distribution trees and router-to-router communications. As with DVMRP, an MOSPF router only needs to know if one host requires multicast service on an interface to include that interface in the distribution tree. Note that IGMP is run only on designated routers in broadcast LANs for maximum efficiency. All other MOSPF routers on that subnet will ignore IGMP information.

MOSPF routers communicate multicast group status information throughout an AS so that other routers can forward relevant multicasts accordingly. This communication is achieved via the group membership LSA. From Chapter 3 you may recall that an OSPF router link advertisement is flooded into each of a router's attached areas, describing the status on cost of each interface into an area. This LSA is modified slightly for MOSPF by the use of a new bit field, the W bit in the Router Type field. This bit indicates that a router is a wildcard multicast receiver, and all multicast datagrams exiting the area should be forwarded to it. This is important, since group membership LSAs are local to an area and never flooded outside that area. Within a group membership LSA, each multicast group that has one or more members is advertised. These LSAs are typically generated by Designated Routers (DRs). Area Border Routers (ABRs) will issue these LSAs into the backbone area.

4.4.3 Design issues

MOSPF is protocol dependent; it works only in OSPF-based networks. Just as in the base OSPF protocol, datagrams (multicast or unicast) are routed as is; they are not further encapsulated or decapsulated as they transit the AS. We discussed in Chapter 3 how OSPF enables an AS to be split into areas and how routers in different areas have only partial knowledge of the AS topology. Clearly, therefore, when forwarding multicasts between areas, the shortest path trees calculated for each datagram may be suboptimal, since the multicast source's neighborhood is approximated by OSPF summary link advertisements or by OSPF AS external link advertisements. More importantly, MOSPF has significant scaling problems in that the Dijkstra algorithm must be run for every multicast (s, g) pair.

Unlike OSPF, MOSPF does not support shared delivery trees. Routers running MOSPF can be intermixed with nonmulticast OSPF routers, and both types of routers can interoperate when forwarding unicast IP data traffic. Unlike DVMRP, however, MOSPF does not support tunneling and, therefore, can be used only in contiguous multicast router networks. MOSPF works well in environments that have relatively few source-group pairs active at any given time. MOSPF is not appropriate for large internetworks with many active senders and receivers. As with OSPF, MOSPF may suffer in environments with a high proportion of unstable links, unless additional damping mechanisms are employed.