Introduction to OSPF | OSPF Network Design Solutions

Table of Contents

OSPF also has the following characteristics:

• Open architecture

• Dynamically adjusts to changes in network topology

• Adjustable distance metrics

• Type of service (TOS) routing

• Support for hierarchical systems

• Load balancing

• Security features

• Supports three kinds of connections/networks

• Point to point

• Multiaccess networks with broadcasting

• Multiaccess networks without broadcasting

• Routing determined by computing a graph abstracting the topology of the network by using the shortest path algorithm

• Segmentation of the network through the use of Autonomous Systems and Areas for ease of management and traffic

• Multicasts rather than broadcasts

• Allows the use of virtual links

• Supports Variable Length Subnet Masking (VLSM) and Classless Interdomain Routing (CIDR)

The discussion of the RFCs will be somewhat brief and limited where the information will be repeated later in the text. If you require further information, refer to the following World Wide Web locations for the Internic and Cisco Systems:

   http://www.internic.net    http://www.cisco.comm

If you are not interested in the evolution of the RFCs and how they relate to each other, you can skip to the next section, “OSPF Functional Environment.”

RFC 1131: OSPF Specification

RFC 1131 is the very first RFC that introduced OSPF version 1 to the networking community. There is not a lot to gain by discussing this RFC because it has been rendered obsolete several times over. This chapter will discuss the newer RFCs in more detail later.

RFC 1245: OSPF Protocol Analysis

OSPF version 1 was published in RFC 1131 on October 1, 1989. Between that time and the release of this RFC in July of 1991, OSPF version 2 was developed but had not yet become a standard. The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG) required two reports in order for OSPF version 2 to advance to Draft Standard Status. This RFC and the next one (RFC 1246) summarize the key features of OSPF version 2. In addition, it analyzes how the protocol will perform and scale in the Internet.

The requirements of this RFC are briefly summarized in the following list. The remaining sections of the RFC document how OSPF version 2 satisfies these requirements.

• What are the key features and algorithms of the protocol?

• How much link bandwidth, router memory, and router CPU cycles does the protocol consume under normal conditions?

• For these metrics, how does the usage scale as the routing environment grows? This should include topologies at least an order of magnitude larger than the current environment.

• What are the limits of the protocol for these metrics (that is, when will the routing protocol break)?

• For which networking environments is the protocol well-suited, and for which is it not suitable?

These requirements are actually exceptional questions that help determine the operating specifications of the protocol within a production environment. To discuss them at this point would be premature; please consult the RFC if further information is required.

RFC 1246: Experience with the OSPF Protocol

This RFC is the second of two reports on the OSPF protocol version 2. These reports are required by the IAB/IESG for an Internet routing protocol to advance to Draft Standard.

The requirements of this RFC are briefly summarized in the following list. The remaining sections of the RFC document how OSPF version 2 satisfies these requirements.

• The specification for the routing protocol must be well-written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol.

• A Management Information Base (MIB) must be written for the protocol. The MIB must be in the standardization process, but does not need to be at the same level of standardization as the routing protocol.

• The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating routing messages and may include other forms of protection.

• Two or more interoperable implementations must exist. At least two must be written independently.

• There must be evidence that all features of the protocol have been tested, running between at least two implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection.

• There must be significant operational experience. This must include running in a moderate number routers configured in a moderately complex topology, and must be part of the operational Internet. All significant features of the protocol must be exercised. In the case of an Interior Gateway Protocol (IGP), both interior and exterior routes must be carried (unless another mechanism is provided for the exterior routes). In the case of an Exterior Gateway Protocol (EGP), it must carry the full complement of exterior routes.

The information presented in this RFC was compiled through a variety of sources. Because many of the goals and examples of the RFC require direct knowledge of the protocols operation, if you require further information, you should refer to the complete document.

Table of Contents