Introduction to OSPF | OSPF Network Design Solutions

Table of Contents

RFC 1793: Extending OSPF to Support Demand Circuits

The author of this RFC did an excellent job in summarizing its contents. A direct quote of selected sections taken from the RFC provides you with an excellent overview of this RFC and its contents. The following section comes directly from RFC 1371.

“This memo defines enhancements to the OSPF protocol that allow efficient operation over “demand circuits”. Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.

The periodic nature of OSPF routing traffic has until now required a demand circuit’s underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic.

Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open.

While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio.

The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point-to-MultiPoint Interface).

This memo provides functionality similar to that specified for RIP in [2], with the main difference being the way the two proposals handle oversubscription. However, because OSPF employs link-state routing technology as opposed to RIP’s Distance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different.”

RFC 1850: OSPF Version 2 Management Information Base

This RFC defines a portion of the Management Information Base (MIB) for managing the Open Shortest Path First routing protocol. It had been over four years and twelve additional RFCs detailing many features of OSPF to include a new version. This RFC was needed to handle the many new enhancements to the protocol and includes over 20 new features or changes. Some of these are rather minor like name changes or clarifications and the reader is referred to the RFC for specific details. A brief list is provided of the more important modifications.

• Support for status entries were added.

• Range of the link-state database MIB was extended to include the multicast (group-membership-LSA) and NSSA (NSSA-LSA).

• The OSPF external link-state database was added.

RFC 2178: OSPF Version 2

At over 211 pages, it is a document that explains the smallest internal workings of the OSPF protocol. Armed with this document, you would be able to program the code necessary for OSPF to operate on any type of network equipment it supports. The RFC will also be able to take you through every step of its operation to include those that are not apparent to the user.

RFC 2328: OSPF Version 2

This RFC is almost a book itself and having been recently released, it is the most current RFC concerning OSPF. It surpasses the previous OSPF RFC by weighing in at 244 pages, all about OSPF. The differences between this RFC and the previous are detailed in Appendix G of the document.

Any Chief Information Officer (CIO) who is considering an OSPF network should have this document available for their design engineers. This RFC is definitely written for a very advanced and specific target audience within the networking arena.

The differences between RFC 2178 and RFC 1583 are explained in Appendix G of the RFC. All differences are backward-compatible in nature. Implementations following this RFC and of those following RFC 1583 will be able to interoperate.

RFC Conclusions

This section discussed the specific evolution of the OSPF protocol by tracing its path through the RFCs. Each RFC was examined and briefly discussed to include whether or not it is still relevant in today’s networks. RFC 238 is the most current OSPF RFC, however, not every vendor’s implementation supports it, so check to be sure.

Now that you have a complete picture concerning the technical resources and documentation surrounding OSPF, you should familiarize yourself with the functional environment and hierarchy used by OSPF, as discussed in the next sections.

OSPF Functional Environment

This section describes the basic characteristics and features of the OSPF functional environment. The environment in which OSPF operates is defined by the features and characteristics of its operation and design. Simply put, the functional environment of OSPF is defined as the network architecture in which the protocol will function correctly.

RFC 1793 provides an example that concerns adding to OSPF the capability to operate in demand-based circuits. Until this RFC was published and implemented, OSPF did not properly function when dealing with such circuits like ISDN. Now that the protocol has been adjusted to operate properly when dealing with demand-based circuits, you can say that the functional environment of the protocol has expanded.

With that example in mind, turn your attention to the three network types that OSPF recognizes.

Table of Contents