Introduction to OSPF | OSPF Network Design Solutions

Table of Contents

By implementing this new standard, OSPF gained the ability to forward multicast packets from one IP network to another. A new link-state Advertisement (LSA) is used to determine the exact location of all the Autonomous System’s members. This RFC provides the information necessary to understand the operation of this new feature and its specific LSA, the group-membership-LSA. Also presented is how the link-state database operates to include the building, pruning, and caching of routes.

A potential area of concern was seen as a result of this new feature. When OSPF forwards multicasts between areas, incomplete routes are built; this may lead to routing inefficiency. To correct that problem, OSPF summary link advertisements or OSPF AS external link advertisements are used to approximate the neighbors needed for routing. The RFC provides a very good description of this issue and the resulting methodology needed to compensate.

Discussion is provided on the compatibility between network devices running MOSPF and non-multicast OSPF. To include some of the issues surrounding the networks operation if this topology will be in place.

Additional practical information on this subject can be found in RFC 1585, MOSPF: Analysis and Experience.

RFC 1585: MOSPF: Analysis and Experience

This RFC immediately followed the 100+ page RFC 1584 that fully detailed all relevant information regarding the ability of allowing OSPF to perform multicasting. This RFC is rather short and was written to fulfill the requirements imposed by the Internet Engineering Task Force (IETF) Internet Routing Protocol Standardization Criteria as detailed in RFC 1264.

A brief discussion surrounding the basic operation of the MOSPF and how it uses the Internet Group Management Protocol (IGMP) to monitor multicast group membership. This information is retrieved from the LAN and then forwarded out by the router by the OSPF flooding protocol through the use of the new group-membership-LSA. The specific benefits that result from this process and detailed operation is provided.

The six primary characteristics of the multicast datagram’s path are also provided as well as some of the more interesting miscellaneous features.

The RFC further details the testing the author conducted and how MOSPF was implemented during these tests. Further discussion is provided on the scaling characteristics of MOSPF and some of the known difficulties surrounding it.

Notes:
Please note that Cisco routers do not currently support MOSPF because of scaling issues. The reasons for this will be discussed in later chapters.

RFC 1586: Guidelines for Running OSPF over Frame Relay Networks

This RFC specifies a set of guidelines for implementing the Open Shortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over Frame Relay networks. The authors show the techniques that can be used to prevent the “fully meshed” connectivity that had been required by OSPF until the publication of this RFC. The benefits of following the guidelines detailed in this RFC allow for more straightforward and economic OSPF network designs. This RFC differs from many of the others in that it does not require changes to be made to the protocol itself but rather better ways to configure it.

The reason behind this RFC is that OSPF considers Frame Relay networks as non-broadcast multiple access (NBMA). OSPF does this because Frame Relay (FR) can support more than two connected routers but Frame Relay does not offer any broadcast capabilities. The following quote from the RFC addresses this issue.

OSPF characterizes FR networks as non-broadcast multiple access (NBMA) because they can support more than two attached routers, but do not have a broadcast capability [2]. Under the NBMA model, the physical FR interface on a router corresponds to a single OSPF interface through which the router is connected to one or more neighbors on the FR network; all the neighboring routers must also be directly connected to each other over the FR network. Hence OSPF implementations that use the NBMA model for FR do not work when the routers are partially interconnected. Further, the topological representation of a multiple access network has each attached router bi-directionally connected to the network vertex with a single link metric assigned to the edge directed into the vertex.

We see that the NBMA model becomes more restrictive as the number of routers connected to the network increases. First, the number of VCs required for full-mesh connectivity increases quadratically with the number of routers. Public FR services typically offer performance guarantees for each VC provisioned by the service. This means that real physical resources in the FR network are devoted to each VC, and for this the customer eventually pays. The expense for full-mesh connectivity thus grows quadratically with the number of interconnected routers. We need to build OSPF implementations that allow for partial connectivity over FR. Second, using a single link metric (per TOS) for the FR interface does not allow OSPF to weigh some VCs more heavily than others according to the performance characteristics of each connection. To make efficient use of the FR network resources, it should be possible to assign different link metrics to different VCs.”

These rather expensive limitations can result in reducing the value and cost effectiveness of Frame Relay as network size increases. The RFC proposes a set of solutions that do not greatly increase the complexity of OSPF’s configuration. A brief list of their recommendations is provided, though I recommend further reading in the actual RFC if more in depth information is required.

One of the recommendations is to expand the operation of an OSPF interface to allow the protocol to understand its function (point-to-point, broadcast, NBMA). In other words, allow OSPF to support both logical and physical interfaces.

The other recommendation proposed by the RFC is to use the NBMA model as OSPFs mode of operation for small homogenous networks.

Notes:
Cisco’s recommendations for how to use the NBMA model can be found at: http://www.cisco.com/warp/public/104/3.html#11.0. In a nutshell, they consider point-to-point a good option because of the reduced OSPF operations required (that is, there are no DR or neighbor statements).

Table of Contents