MOSPF Basics
Member 224.2.2.1
Member 224.8.2 3
Figure 5-33 The Local Group Database Records Attached Groups and the Subnets on Which the Group Members Reside
Member 224.2.2.1
Member 224.8.2 3
Member 224 8 2 3
Local Group database
Group Network
2242 2 1 192 168 1 0
Member 224 8 2 3
Local Group database
Group Network
2242 2 1 192 168 1 0
The DR then originates a Group Membership LSA for each attached group The LSA specifies the group address and the originating router ID and lists all the router's attached networks on which members of the group reside In some cases, the router itself may run multicast applications that make it a group member The LSA includes a Type field in which the router can indicate that it is advertising itself as a group member
The LSA is then flooded throughout the originating router's area The Group Membership (type 6) LSA is similar to a Network (type 2) LSA in two regards
• Like a Network LSA, only a designated router originates a Group Membership LSA
• Like a Network LSA, a Group Membership LSA only has area-wide scope That is, the LSA is not flooded outside of the originating router's area
The objective of the LSA flooding is to ensure that all MOSPF routers in an area have a copy of all Group Membership LSAs originated in the area As with unicast OSPF, all MOSPF routers in an area must have identical link-state databases The only difference between an OSPF link-state database and an MOSPF database in a given area is the inclusion of the type 6 LSAs
With synchronized databases, every MOSPF router in an area can calculate the same shortest path tree The tree is rooted at the source network and has branches extending to every network containing a group member However, the tree is not calculated immediately Instead, it is calculated "on-demand," when the first multicast packet for the group arrives This makes sense, because although the synchronized routers know where all destinations are, they may not yet know where the source is
The SPF calculation knows where all routers with attached group members are based on the Group Membership LSAs And it knows where the source is located based on the source and destination addresses of the first arriving packet for the group The regular unicast Router and Network LSAs whose MC bits are set are then used to calculate the least-cost paths from the source to each destination
The great advantage of the Group Membership LSA-based explicit joins, coupled with the on-demand SPF calculation, is that routers already know the location of the destination networks before the calculation is performed So unlike flood-and-prune protocols such as DVMRP, packets are never forwarded to all parts of the routing domain You might say that the MOSPF tree comes "prepruned "
Based on the results of the SPF calculation, entries are made into each router's multicast forwarding table The shortest-path tree is loop-free, and every router knows which interface is the upstream interface and which interfaces are downstream interfaces Therefore, no RPF check is required, as it is with DVMRP The forwarding table entry for a particular (S, G) pair indicates what upstream neighbor a matching packet should be received from and what downstream neighbors the packet must be forwarded to The local group database also is used to make entries into the forwarding table for locally attached networks containing group members
Keep in mind a few caveats about MOSPF First, although unicast OSPF supports equal-cost multipath, MOSPF does not The MOSPF shortest-path tree describes a single path between the source and all networks containing group members
Second, if OSPF and MOSPF routers coexist on the same multiaccess network, care must be taken to ensure that the MOSPF router is elected the DR If an OSPF router becomes the DR, no Group Membership LSAs are originated for any group members on the network, and consequently no multicast packets for the ¿roup are forwarded to the network
Finally, an MOSPF router must clear its entire forwarding table and recalculate its shortest-path trees if the topology within the MOSPF domain changes Therefore, it is important that the domain be as stable as possible
Inter-Area MOSPF
The preceding section described how MOSPF behaves when the source and all group members are within the same area Emphasis was placed on the fact that a Group Membership LSA is not flooded outside of its originating area So what happens when group members are in one or more areas different from the source?
You know from Chapter 9 of Volume I that inter-area OSPF communications is managed by Area Border Routers (ABRs) ABRs are members of the backbone area and one or more nonbackbone areas They learn all the destinations within each attached area via Router and Network LSAs, just as any other router in the area does ABRs then create Network Summary (type 3) LSAs, which advertise the destinations in one attached area into the ABR's other attached areas Like type 1 and type 2 LSAs, type 3 LSAs are never flooded outside of the area in which they are originated When an ABR receives a Network Summary LSA across the backbone area from another ABR, it creates its own Network Summary LSA to advertise that information into its attached nonbackbone areas Figure 5-34 illustrates conceptually how ABRs use types 1, 2, and 3 LSAs
Figure 5-34 Unicast OSPF ABRs Use Network Summary LSAs to Advertise Destinations Learned from One Attached Area into Other Attached Areas
Area 0
Area 0
|
Summary LSAs Originator: RT1 Destination A Destination B |
Summary LSAs Originator: RT2 Destination E Destination F |
|||
|
) |
Router/ Network LSAs Various Area 0 Originators Destination C Destination D |
X |
k |
|
Router/ Network LSAs Various Area 1 Originators
Destination A Destination B
Summary LSAs Originator: RT1
Destination C Destination D Destination E Destination F
Summary LSAs Originator: RT2
Destination A Destination B Destination C Destination D
Router/ Network LSAs Various Area 2 Originators
Destination E Destination F
Area 1
Area 2
MOSPF ABRs are perversely called inter-area multicast forwarders There are both similarities and differences with the way unicast ABRs operate An inter-area multicast forwarder knows what groups have members in each of its attached nonbackbone areas based on the Group Membership LSAs it has received in those areas For each known group, the forwarder creates a new Group Membership LSA and floods the LSA into the backbone, as illustrated in Figure 5-35 So far, this behavior is very similar to the way an ABR uses type 3 LSAs to summarize information learned from type 1 and type 2 LSAs into the backbone
Figure 5-35 Inter-Area Multicast Forwarders Use Group Membership LSAs to Advertise the Presence of Group Members in Their Nonbackbone Areas to the Backbone Area
Figure 5-35 Inter-Area Multicast Forwarders Use Group Membership LSAs to Advertise the Presence of Group Members in Their Nonbackbone Areas to the Backbone Area
Here the similarity to unicast ABRs ends Unlike the way in which type 3 LSAs are used, an inter-area multicast forwarder does not send type 6 LSAs into a nonbackbone area to advertise the presence of groups outside the area In Figure 5-35, for example, RT1 receives the type 6 LSA originated by RT2, advertising group C, but it does not create a type 6 LSA to advertise group C into area 1
The result is that an SPF tree is calculated in the backbone for each group, and the tree's branches extend to the inter-area multicast forwarder of each area containing group members The nonbackbone areas have no knowledge of group members outside of their own area
If the source for group C in Figure 5-35 is located in area 1, however, how do its packets reach members in areas 2 and 3? The answer is a wildcard multicast receiver These devices advertise themselves by setting the W bit in the rtype field of their Router LSAs Within an area, multicast traffic is always forwarded to all wildcard multicast receivers In nonbackbone areas, an inter-area multicast forwarder (a multicast ABR) is always a wildcard multicast receiver
When the source for group C in Figure 5-35 originates a group C packet, the packet is forwarded to RT1, the wildcard multicast receiver for area 1 RT1 also is a member of the backbone area, and so has calculated a shortest-path tree to all inter-area multicast forwarders whose attached areas contain members of group C Seeing that RT2 is advertising group C members, the packet is forwarded to that router across the backbone RT2, as a member of areas 2 and 3, has calculated separate SPF trees for group C in each area and forwards copies of the packet to the group C destinations
NOTE If there were any group C members in area 1, a copy of the packet would, of course, be forwarded over the local SPF tree to those members in addition to being forwarded to RT1
Note that wildcard multicast receivers are unnecessary in the backbone area for intradomain traffic For every group in the MOSPF domain, an SPF tree is calculated in area 0 The branches of the tree lead either to group members located in that area or to inter-area multicast forwarders attached to other areas So if a source is located in the backbone area, its packets can be forwarded along the correct tree
Continue reading here: InterAs Mospf
Was this article helpful?