RFC 1584 Multicast Extensions to OSPF March 1994 + | 3+---+ +--+ +--+ N12 N14 N1|--|RT1|\1 |Mb| |H4| \ N13 / _| +---+ \ +--+ /+--+ 8\ |8/8 | + \ _|__/ \|/ +--+ +--+ / \ 1+---+8 8+---+6 |Mb| |Mb| * N3 *---|RT4|------|RT5|--------+ +--+ /+--+ \____/ +---+ +---+ | + / | |7 | | 3+---+ / | | | N2|--|RT2|/1 |1 |6 | __| +---+ +---+8 6+---+ | | + |RT3|--------------|RT6| | +--+ +--+ +---+ +--+ +---+ | |Ma| |H3|_ |2 _|H2| Ia|7 | +--+ +--+ \ | / +--+ | | +---------+ | | N4 | | | | | | N11 | | +---------+ | | | \ | | N12 |3 +--+ | |6 2/ +---+ |Ma| | +---+/ |RT9| +--+ | |RT7|---N15 +---+ | +---+ 9 |1 + | |1 _|__ | Ib|5 __|_ +--+ / \ 1+----+2 | 3+----+1 / \--|Ma| * N9 *------|RT11|----|---|RT10|---* N6 * +--+ \____/ +----+ | +----+ \____/ | | | |1 + |1 +--+ 10+----+ N8 +---+ |H1|-----|RT12| |RT8| +--+SLIP +----+ +---+ +--+ |2 |4 _|H5| | | / +--+ +---------+ +--------+ N10 N7 Figure 1: A sample MOSPF configuration RFC 1584 Multicast Extensions to OSPF March 1994 should not be pruned from Group A's datagram shortest-path trees. The router lists itself in its group-membership-LSA for Group A if either 1) one or more of the router's attached stub networks contain Group A members or 2) the router itself is a member of Group A. The router lists a directly connected transit network in the group-membership- LSA for Group A if both 1) the router is Designated Router on the network and 2) the network contains one or more Group A members. Consider again the example pictured in Figure 1. If Router RT3 has been elected Designated Router for Network N3, then Table 1: lists the local group database for the routers RT1-RT4. In this case, each of the routers RT1, RT2 and RT3 will originate a group-membership-LSA for Group B. In addition, RT2 will also be originating a group-membership-LSA for Group A. RT1 and RT2's group-membership-LSAs will list solely the routers themselves (N1 and N2 are stub networks). RT3's group-membership-LSA will list the transit Network N3. Figure 2 displays the Autonomous System's link state database. A router/transit network is labelled with a multicast group if (and only if) it has been mentioned in a group-membership-LSA for the group When building the shortest-path tree for a particular multicast datagram, this labelling enables those branches without group members to be pruned from the tree. The process of building a multicast datagram's shortest path tree is discussed in Section 2.3.2. Note that none of the hosts in Figure 1 belonging to multicast groups A and B show up explicitly in the link state database (see Figure 2). In fact, looking at the link state database you cannot even determine which stub networks Router local group database _____________________________________ RT1 [Group B, N1] RT2 [Group A, N2], [Group B, N2] RT3 [Group B, N3] RT4 None Table 1: Sample local group databases Moy [Page 12] RFC 1584 Multicast Extensions to OSPF March 1994 **FROM** |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| ----- --------------------------------------------- RT1| | | | | | | | | | | | |0 | | | | RT2| | | | | | | | | | | | |0 | | | | RT3| | | | | |6 | | | | | | |0 | | | | RT4| | | | |8 | | | | | | | |0 | | | | RT5| | | |8 | |6 |6 | | | | | | | | | | RT6| | |8 | |7 | | | | |5 | | | | | | | RT7| | | | |6 | | | | | | | | |0 | | | * RT8| | | | | | | | | | | | | |0 | | | * RT9| | | | | | | | | | | | | | | |0 | T RT10| | | | | |7 | | | | | | | |0 |0 | | O RT11| | | | | | | | | | | | | | |0 |0 | * RT12| | | | | | | | | | | | | | | |0 | * N1|3 | | | | | | | | | | | | | | | | N2| |3 | | | | | | | | | | | | | | | N3|1 |1 |1 |1 | | | | | | | | | | | | | N4| | |2 | | | | | | | | | | | | | | N6| | | | | | |1 |1 | |1 | | | | | | | N7| | | | | | | |4 | | | | | | | | | N8| | | | | | | | | |3 |2 | | | | | | N9| | | | | | | | |1 | |1 |1 | | | | | N10| | | | | | | | | | | |2 | | | | | N11| | | | | | | | |3 | | | | | | | | N12| | | | |8 | |2 | | | | | | | | | | N13| | | | |8 | | | | | | | | | | | | N14| | | | |8 | | | | | | | | | | | | N15| | | | | | |9 | | | | | | | | | | H1| | | | | | | | | | | |10| | | | | Figure 2: The MOSPF database. Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. In addition, RT1, RT2 and N3 are labelled with multicast group A and RT1, N6 and RT9 are labelled with multicast group B. RFC 1584 Multicast Extensions to OSPF March 1994 o RT3 (N4, origin) / \ 1/ \8 / \ N3 (Mb) o o RT6 / \ 0/ \7 / \ RT2 (Ma,Mb) o o RT10 / \ 3/ \1 / \ N8 o o N6 (Ma) / 0/ / RT11 o / 1/ / N9 o / 0/ / RT9 (Ma) o Figure 3: Sample datagram's shortest-path tree, source N4, destination Group A The router's (call it Router RTX) position in the datagram's pruned shortest-path tree consists of 1) RTX's parent in the tree (this will be the forwarding cache entry's upstream node) and 2) the list of RTX's interfaces that lead to downstream routers/transit networks that have been labelled with the datagram's destination (these will be added to the forwarding cache entry as downstream interfaces). Note that after calculating the datagram's shortest path tree, a router may find that it is itself not on the tree. This would be indicated by a forwarding cache entry having no upstream node or an empty list of downstream interfaces. As an example of a router describing its position on the datagram's shortest-path tree, consider Router RT10 in Figure 3. Router RT10's upstream node for the datagram is Router RT6, and there are two downstream interfaces: one Moy [Page 17] RFC 1584 Multicast Extensions to OSPF March 1994 Router Upstream Downstream interfaces node (interface:hops) ___________________________________________ RT10 Router RT6 (N6:1), (N8:2) RT11 Net N8 (N9:1) RT3 Net N4 (N3:1), (RT6:3) RT6 Router RT3 (RT10:2) RT2 Net N3 (N2:1) Table 2: Sample forwarding cache entries, for source N4 and destination Group A. resources are in short supply. 3. Inter-area multicasting Up to this point this memo has discussed multicast forwarding when the entire Autonomous System is a single OSPF area. The logic for when the multicast datagram's source and its destination group members belong to the same OSPF area is the same. This section explains the behavior of the MOSPF protocol when the datagram's source and (at least some of) its destination group members belong to different OSPF areas. This situation is called inter-area multicast. Inter-area multicast brings up the following issues, which are resolved in succeeding sections: o Are the group-membership-LSAs specific to a single area? And if they are, how is group membership information conveyed from one area to the next? o How are the datagram shortest-path trees built in the inter-area case, since complete information concerning the topology of the datagram source's neighborhood is not available to routers in other areas? o In an area border router, multiple datagram shortest-path trees are built, one for each attached area. How are these separate datagram shortest-path trees combined into a single forwarding cache entry? It should be noted in the following that the basic protocol mechanisms in the inter-area case are the same as for the intra-area case. Forwarding of multicasts is still defined by the contents of Moy [Page 19] RFC 1584 Multicast Extensions to OSPF March 1994 .................................. . + . . | 3+---+ +--+ +--+ . N12 N14 . N1|--|RT1|\1 |Mb| |H4| . \ N13 / . _| +---+ \ +--+ /+--+ . 8\ |8/8 . | + \ _|__/ . \|/ . +--+ +--+ / \ 1+---+8. 8+---+6 . |Mb| |Mb| * N3 *---|RT4|------|RT5|--------+ . +--+ /+--+ \____/ +---+ . +---+ | . + / | . |7 | . | 3+---+ / | . | | . N2|--|RT2|/1 |1 . |6 | . __| +---+ +---+8 . 6+---+ | . | + |RT3|--------------|RT6| | . +--+ +--+ +---+ +--+. +---+ | . |Ma| |H3|_ |2 _|H2|. Ia|7 | . +--+ +--+ \ | / +--+. | | . +---------+ . | | .Area 1 N4 . | | .................................. | | ................................ | | . N11 . | | . +---------+ . | | . | \ . | | N12 . |3 +--+ . | |6 2/ . +---+ |Ma| . | +---+/ . |RT9| +--+ . | |RT7|---N15 . +---+ ....... | +---+ 9 . |1 .. + ...|..........|1........ . _|__ .. | Ib|5 __|_ +--+. . / \ 1+----+2.. | 3+----+1 / \--|Ma|. . * N9 *------|RT11|----|---|RT10|---* N6 * +--+. . \____/ +----+ .. | +----+ \____/ . . | !*******|*****! | . . |1 Virtual + Link |1 . . +--+ 10+----+ ..N8 +---+ . . |H1|-----|RT12| .. |RT8| . . +--+SLIP +----+ .. +---+ +--+. . |2 .. |4 _|H5|. . | .. | / +--+. . +---------+ .. +--------+ . . N10 Area 3..Area 2 N7 . ............................................................. Figure 4: A sample MOSPF area configuration Moy [Page 20] RFC 1584 Multicast Extensions to OSPF March 1994 Suppose an OSPF router has a local group database entry for [Group Y, Network X]. The router then originates a group- membership-LSA for Group Y into the area containing Network X. For example, in the area configuration pictured in Figure 4, Router RT1 originates a group-membership-LSA for Group B. This group-membership-LSA is flooded throughout Area 1, and no further. Likewise, assuming that Router RT3 has been elected Designated Router for Network N3, RT3 originates a group- membership-LSA into Area 1 listing the transit Network N3 as having group members. Note that in the link state database for Area 1 (Figure 6) both Router RT1 and Network N3 have accordingly been labelled with Group B. In OSPF, the area border routers forward routing information and data traffic between areas. In MOSPF. a subset of the area border routers, called the inter-area multicast forwarders, forward group membership information and multicast datagrams between areas. Whether a given OSPF area border router is also a MOSPF inter-area multicast forwarder is configuration dependent (see Section B.1). In Figure 4 we assume that all area border routers are also inter-area multicast forwarders. In order to convey group membership information between areas, inter-area multicast forwarders "summarize" their attached areas' group membership to the backbone. This is very similar functionality to the summary-link-LSAs that are generated in the base OSPF protocol. An inter-area multicast forwarder calculates which groups have members in its attached non- backbone areas. Then, for each of these groups, the inter-area multicast forwarder injects a group-membership-LSA into the backbone area. For example, in Figure 4 there are two groups having members in Area 1: Group A and Group B. For that reason, both of Area 1's inter-area multicast forwarders (Routers RT3 and RT4) inject group-membership-LSAs for these two groups into the backbone. As a result both of these routers are labelled membership +------------------+ datagrams + > > > >>| Backbone |< < < < + ^ +------------------+ ^ ^ / | \ ^ ^ / | \ ^ +----^-----+/ +----------+ \+----^-----+ | Area 1 | | Area 2 | | Area 3 | +----------+ +----------+ +----------+ Figure 5: Inter-area routing architecture RFC 1584 Multicast Extensions to OSPF March 1994 **FROM** |RT|RT|RT|RT|RT|RT| |1 |2 |3 |4 |5 |7 |N3| ----- ------------------- RT1| | | | | | |0 | RT2| | | | | | |0 | RT3| | | | | | |0 | * RT4| | | | | | |0 | * RT5| | |14|8 | | | | T RT7| | |20|14| | | | O N1|3 | | | | | | | * N2| |3 | | | | | | * N3|1 |1 |1 |1 | | | | N4| | |2 | | | | | Ia,Ib| | |15|22| | | | N6| | |16|15| | | | N7| | |20|19| | | | N8| | |18|18| | | | N9-N11,H1| | |19|16| | | | N12| | | | |8 |2 | | N13| | | | |8 | | | N14| | | | |8 | | | N15| | | | | |9 | | Figure 6: Area 1's MOSPF database. Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. In addition, RT1, RT2 and N3 are labelled with multicast group A, RT1 is labelled with multicast group B, and both RT3 and RT4 are labelled as wild-card multicast receivers. Moy [Page 23] RFC 1584 Multicast Extensions to OSPF March 1994 **FROM** |RT|RT|RT|RT|RT|RT|RT |3 |4 |5 |6 |7 |10|11| ------------------------ RT3| | | |6 | | | | RT4| | |8 | | | | | RT5| |8 | |6 |6 | | | RT6|8 | |7 | | |5 | | RT7| | |6 | | | | | * RT10| | | |7 | | |2 | * RT11| | | | | |3 | | T N1|4 |4 | | | | | | O N2|4 |4 | | | | | | * N3|1 |1 | | | | | | * N4|2 |3 | | | | | | Ia| | | | | |5 | | Ib| | | |7 | | | | N6| | | | |1 |1 |3 | N7| | | | |5 |5 |7 | N8| | | | |4 |3 |2 | N9-N11,H1| | | | | | |1 | N12| | |8 | |2 | | | N13| | |8 | | | | | N14| | |8 | | | | | N15| | | | |9 | | | Figure 7: The backbone's MOSPF database. Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. In addition, RT3 and RT4 are labelled with both multicast groups A and B, and RT7, RT10, and RT11 are labelled with multicast group A. OSPF area is not distributed to other OSPF areas (the flooding of router-LSAs, network-LSAs and group-membership-LSAs is restricted to a single OSPF area only), the building of complete datagram shortest-path trees is often impossible in the inter- area case. To compensate, approximations are made through the use of wild-card multicast receivers and OSPF summary-link-LSAs. When it first receives a datagram for a particular [source net, destination group] pair, a router calculates a separate datagram shortest-path tree for each of the router's attached areas. Each datagram shortest-path tree is built solely from LSAs belonging Moy [Page 24] RFC 1584 Multicast Extensions to OSPF March 1994 to the particular area's link state database. Suppose that a router is calculating a datagram shortest-path tree for Area A. It is useful then to separate out two cases. The first case, Case 1: The source of the datagram belongs to Area A has already been described in Section 2.3.2. However, in the presence of OSPF areas, during tree pruning care must be taken so that the branches leading to other areas remain, since it is unknown whether there are group members in these (remote) areas. For this reason, only those branches having no group members nor wild-card multicast receivers are pruned when producing the datagram shortest-path tree. As an example, suppose in Figure 4 that Host H2 sends a multicast datagram to destination Group A. Then the datagram's shortest-path tree for Area 1, built identically by all routers in Area 1 that receive the datagram, is shown in Figure 8. Note that both inter-area multicast forwarders (RT3 and RT4) are on the datagram's shortest-path tree, ensuring the delivery of the datagram to the backbone and from there to Areas 2 and 3. o Case 2: The source of the datagram belongs to an area other than Area A. In this case, when building the datagram shortest-path tree for Area A, the immediate neighborhood of the datagram's source is unknown. However, there are summary-link-LSAs in the Area A link state database indicating the cost of the paths between each of Area A's inter-area multicast forwarders and the datagram source. These summary links are used to approximate the neighborhood of the datagram's source; the tree begins with links directly connecting the source to each of the inter-area multicast forwarders. These links point in the reverse o RT3 (W, origin=N4) | 1| | N3 (Mb) o / \ 0/ \0 / \ RT2 (Ma,Mb) o o RT4 (W) Figure 8: Datagram's shortest-path tree, Area 1, source N4, destination Group A Moy [Page 25] RFC 1584 Multicast Extensions to OSPF March 1994 direction (towards instead of away from the datagram source) from the links considered in Case 1 above. All additional links added to the tree also point in the reverse direction. The final datagram shortest-path tree is then produced by, as before, pruning all branches having no group-members nor wild-card multicast receivers. As an example, suppose again that Host H2 in Figure 4 sends a multicast datagram to destination Group A. The datagram's shortest-path tree for the backbone is shown in Figure 9. The neighborhood around the source (Network N4) has been approximated by the summary links advertised by routers RT3 and RT4. Note that all links in Figure 9's datagram shortest-path tree have arrows pointing in the reverse direction, towards Network N4 instead of away from it. The reverse costs used for the entire tree in Case 2 are forced because summary-link-LSAs only specify the cost towards the datagram source. In the presence of asymmetric link costs, this may lead to less efficient routes when forwarding multicasts o N4 / \ 2/ \3 / \ RT3 (Ma,Mb) o o RT4 (Ma,Mb) / \ 6/ \8 / \ RT6 o o RT5 | | 5| |6 | | RT10 (Ma) o o RT7 (Ma) | 2| | RT11 (Ma) o Figure 9: Datagram shortest-path tree: Backbone, source N4, destination Group A. Note that reverse costs (i.e., toward origin) are used throughout. Moy [Page 29] RFC 1584 Multicast Extensions to OSPF March 1994 o N12 | 2| | o RT7 | 14| | o RT4 (W) | 0| | o N3 (Mb) /|\ / | \ 1/ | 1\ / 1| \ / | \ RT1 (Mb) o | o RT3 (W) o RT2 (Ma,Mb) Figure 10: Datagram shortest-path tree: Area 1, source N12, destination Group B. Note that reverse costs (i.e., toward origin) are used throughout. N12) as the upstream node for the datagram. This means that RT7 must receive the datagram from a router in another AS before injecting the datagram into the MOSPF system. 4.2. Stub area behavior AS external links are not imported into stub areas. Suppose that the source of a particular datagram lies outside of the Autonomous System, and that the datagram is forwarded into a stub area. In the stub area's datagram shortest-path tree the neighborhood of the datagram's source cannot be approximated by AS external links. Instead the neighborhood of the source is approximated by the default summary links (see Section 3.6 of [OSPF]) that are originated by the stub area's intra-area multicast forwarders. Except for this small change to the construction of a stub area's datagram shortest-path trees, all other MOSPF algorithms (e.g., merging with other areas' datagram shortest-path trees to