Network Working Group                                     J. Moy, Editor
Request for Comments: 1246                                     July 1991

                   Experience with the OSPF protocol

Status of this Memo

This memo provides information for the Internet community. It does not specify any Internet standard. Distribution of this memo is unlimited.

Abstract

This is the second of two reports on the OSPF protocol. These reports are required by the IAB/IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol).

OSPF is currently designated as a Proposed Standard. Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247. The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report.

This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. It also presents a summary of the OSPF Management Information Base (MIB), and a summary of OSPF authentication mechanism.

Please send comments to ospf@trantor.umd.edu.

1.0 Introduction

This document addresses, for OSPF V2, the requirements set forth by the IAB/IESG for an Internet routing protocol to advance to Draft Standard state. This requirements are briefly summarized below. The remaining sections of this report document how OSPF V2 satisfies these requirements:

[Moy] [Page 1]

RFC 1246 Experience with OSPF July 1991

This report is a compilation of information obtained from many people. The reader is referred to specific people when more information on a subject is available. People references are gathered into Section 10.0, in a format similar to that used in [4].

1.1 Acknowledgments

The OSPF protocol has been developed by the OSPF Working Group of the Internet Engineering Task Force. Many people have contributed to this report. They are listed in Section 10.0 of this report.

[Moy] [Page 2]

RFC 1246 Experience with OSPF July 1991

2.0 Documentation

Version 1 of the OSPF protocol is documented in RFC 1131 [1]. OSPF Version 2, which supersedes Version 1, has been documented in RFC 1247 [2]. The differences between OSPF Version 1 and Version 2 are relatively minor, and are listed in Appendix F of RFC 1247 [2]. All information presented in this report concerns OSPF V2 unless explicitly mentioned otherwise.

The OSPF protocol was developed by the OSPF Working Group of the Internet Engineering Task Force. This Working Group has a mailing list, ospf@trantor.umd.edu, where discussions of protocol features and operation are held. The OSPF Working Group also meets during the quarterly Internet Engineering Task Force conferences. Reports of these meeting are published in the IETF's Proceedings. In addition, two reports on the OSPF protocol have been presented to the IETF plenary (see "Everything You Ever Wanted to Know about OSPFIGP" in [5] and "OSPF Update" in [6]).

The OSPF protocol began undergoing field trials in Spring of 1990. A mailing list, ospf-tests@seka.cso.uiuc.edu, was formed to discuss how the field trials were proceeding. This mailing list is maintained by Ross Veach of the University of Illinois [rrv]. Archives of this list are also available. There has been quite a bit of discussion on the list concerning OSPF/RIP/EGP interaction.

A OSPF V2 Management Information Base has also been developed and published in [3]. For more information, see Section 3.0 of this report.

There is a free implementation of OSPF available from the University of Maryland. This implementation was written by Rob Coltun [rcoltun]. Contact Rob for details.

3.0 MIB

An OSPF Management Information Base has been published in RFC 1248 [3]. The MIB was written by Rob Coltun [rcoltun] and Fred Baker [fbaker]. The OSPF MIB appears on the mgmt subtree as SMI standard-mib 13.

The OSPF MIB was originally developed by Rob Coltun of the University of Maryland, under contract to Advanced Computer Communications. A subset of his proposal was implemented to facilitate their development, and represents operational experience of a sort.

The MIB consists of a general variables group and ten tables:

TABLE 1. OSPF MIB Organization

[Moy] [Page 3]

RFC 1246 Experience with OSPF July 1991

Group Name Description 

    ospfGeneralGroup     General Global Variables
    ospfAreaTable        Area Descriptions
    ospfStubAreaTable    Default Metrics, by Type of Service
    ospfLsdbTable        Link State Database
    ospfAreaRangeTable   Address Range Specifications
    ospfHostTable        Directly connected Hosts
    ospfIfTable          OSPF Interface Variables
    ospfIfMetricTable    Interface Metrics, by Type of Service
    ospfVirtIfTable      Virtual Links
    ospfNbrTable         (Non-virtual) OSPF Neighbors
    ospfVirtNbrTable     Virtual OSPF Neighbors

As MIBs go, the OSPF MIB is quite large; 105 objects. The following are some statistics describing the distribution of the MIB's variables:

Section D.2 of the OSPF V2 specification [2] lists a set of required statistics that an implementation must maintain. These statistics have been incorporated into the OSPF MIB. The MIB's thirteen Counters and Gauges enable evaluation of the OSPF protocol's performance in an operational environment. Most of the remainder of the MIB's variables parameterize the many features that OSPF provides the network administrator.

For more information on the MIB contact Fred Baker [fbaker].

4.0 Security architecture

In OSPF, all protocol packet exchanges are authenticated. The OSPF packet header (which is common to all OSPF packets) contains a 16-bit Authentication type field, and 64-bits of Authentication data. Each particular OSPF area must run a single authentication scheme, as indicated by the Authentication type field. However, authentication keys can be configured by the system administrator on a per-network basis.

[Moy] [Page 4]

RFC 1246 Experience with OSPF July 1991

When an OSPF packet is received from a network, the OSPF router first verifies that it indicates the correct Authentication type. The router then authenticates the packet, running a verification algorithm using the configured authentication key, the 64-bits of Authentication data and the rest of the OSPF packet data as input. The precise algorithm used is dictated by the Authentication type. Packets failing the authentication algorithm are dropped, and the authentication failure is noted in a MIB-accessible variable (see [3]).

There are currently few Authentication types in use. The current assignments are:

TABLE 2. Current OSPF Authentication types.

Type code Algorithm 

  0           No authentication performed.
  1           Simple (clear) password.
  2-255       Reserved for assignment by the IANA (iana@isi.edu)
  > 255       Available for local (per-AS) definition.

For more information on OSPF's authentication procedures, see Sections 8.1, 8.2, and Appendix E of [2].

5.0 Implementations

The are multiple, interoperable implementations of OSPF currently available. This section gives a brief overview of the five implementations that have participated in at least one round of interoperability testing. (For a detailed discussion of OSPF interoperability testing, see Section 7.0 of this report.) Other implementations do exist, but because of commercial realities (e.g., the product is not yet announced) they unfortunately cannot be listed here.

The five implementations that have participated in the OSPF interoperability testing are (listed in alphabetical order):

[Moy] [Page 5]

RFC 1246 Experience with OSPF July 1991

Note that, as required by the IAB/IESG for Draft Standard status, there are multiple interoperable independent implementations, namely those from 3com, Proteon and the University of Maryland.

6.0 Operational experience

This section discusses operational experience with the OSPF protocol. Version 1 of the OSPF protocol began to be deployed in the Internet in Spring of 1990. The results of this original deployment were reported to the mailing list ospf-tests@seka.cso.uiuc.edu. (Archives of this mailing list are available from Ross Veach [rrv].) No protocol bugs were found in this first deployment, although several additional features were found to be desirable. These new features were added to the protocol in OSPF Version 2.

The OSPF protocol is now deployed in a number of places in the Internet. In this section we focus on three highly visible systems, namely the NASA Sciences Internet, BARRNet and OARnet. The dimensions of these three OSPF systems is summarized in the following table:

[Moy] [Page 6]

RFC 1246 Experience with OSPF July 1991

TABLE 3. Three operational OSPF deployments 

         Name      Version 1 date   Version 2 date   # routers
         _____________________________________________________
         NSI       4/13/90          1/1/91           15
         BARRNet   4/90             11/90            14
         OARnet    10/15/90         not yet          13

All the above deployments are using the Proteon OSPF implementation. There is one other deployment worth mentioning in this context. 3com has started to deploy OSPF on their corporate network. They have 8 of their routers running OSPF (the 3com implementation), and are planning on cutting over the remaining routers (20 in all). Currently they have two operational routers running OSPF and RIP simultaneously. One converts OSPF data to RIP data, and the other RIP data to OSPF data. For more details, contact Dino Farinacci [dino].

6.1 NSI

The NASA Science Internet (NSI) is a multiprotocol network, currently supporting both DECnet and TCP/IP protocols. NSI's mission is to provide reliable high-speed communications to the NASA science community. The NASA Science Internet connects with other national networks including the National Science Foundation's NSFNET, the Department of Energy's ESnet and the Department of Defense's MILNET. NSI also has international connections to Japan, Australia, New Zealand, Chile and several European countries.

For more information on NSI, contact Jeffrey Burgan [jeff] or Milo Medin [medin].

6.1.1 NSI's OSPF system

NSI was one of the initial deployment sites for OSPF Version 1, having deployed the protocol in April 1990. NSI has been running OSPF V2 since 1/1/91. They currently have 15 routers in their OSPF system. This system is pictured in Figure 1. It consists of a nationwide collection of serial lines, with ethernets at hub sites. The numbers associated to interfaces/links in Figure1 are the associated OSPF costs. Note that certain links have been weighted so that they are less preferable than others.

Many of NSI's OSPF routers are speaking either RIP and/or EGP as well as OSPF. Routes from these other routing protocols are selectively imported

[Moy] [Page 7]

RFC 1246 Experience with OSPF July 1991

into their OSPF system as externals. The current number of imported externals is 496.

All NSI externals are imported as OSPF type 2 metrics. In addition, NSI uses the OSPF external route tag to manage the readvertisement of external routes. For example, a route learned at one edge of the NSI system via EGP can be tagged with the number of the AS from which it was learned. Then, as the OSPF external LSA describing this route is flooded through the OSPF system, this tagging information is distributed to all the other AS boundary routers. A router on the other edge of the NSI can then say that it wants to readvertise (via EGP) routes learned from one particular AS but not routes learned from another AS. This allows NSI to implement transit policies at the granularity of Autonomous Systems, instead of network numbers, which greatly reduces the network's configuration burden.

NSI has also experimented with OSPF stub areas, in order to support routers having a small amount of memory.

6.1.2 NSI - Deployment analysis

NSI ran a couple of experiments after OSPF's deployment to test OSPF's convergence time in the face of network failures, and to compare the level of routing traffic in OSPF with the level of routing traffic in RIP. These experiments were included in NSI status reports to the OSPF plenary.

The first experiment consisted of running a continuous ICMP ping, and then bringing down one of the links in the ping packet's path. They then timed how long it took OSPF to find an alternate path, by noticing when the pings resumed. The result of this experiment is contained in Milo Medin's "NASA Sciences Internet Report" in [8]. It shows that the interrupted ping resumed in three seconds.

The second experiment consisted in analyzing the amount of routing protocol traffic that flow over an NSI link. One of the NSI links was installed, but did not have any active users yet. For this reason, all traffic that flowed over the link was routing protocol traffic. The link was instrumented to continuously measure the amount of bandwidth consumed, first in the case where RIP was running, and then in the case of where OSPF was running. The result is shown graphically in Jeffrey Burgan's "NASA Sciences Internet" report in [9]. It shows that OSPF consumes many times less network bandwidth than RIP.

[Moy] [Page 8]

RFC 1246 Experience with OSPF July 1991

6.2 BARRNet

BARRNet is the NSFNet regional network in Northern California. At the present time, it serves approximately 80 member sites in an area stretching from Sacramento in the north-east to Monterey in the in the south-west. Sites are connected to the network at speeds from 9.6Kbps to full T1 using Proteon and cisco routers as well as a Xylogics terminal server. The membership is composed of a mix of university, government, and commercial organizations. BARRNet has interconnections to the NSFNet (peering with both T1 and T3 backbones at Stanford University), ESNet (peering at LLNL, with additional multi-homed sites at LBL, SLAC, and NASA Ames), and DDN national networks (peering at the FIX network at NASA Ames), and to the statewide networks of the University of California (peering at U.C. Berkeley) and the California State University system (peering at San Francisco State and Sacramento State).

Topologically, the network consists of fourteen OSPF-speaking Proteon routers, which as a "core", with six of these redundantly connected into a ring. All "core" sites are interconnected via full T1 circuits. Other member sites attach as "stub" connections to the "core" sites. The bulk of these are connected in a "star" configuration at Stanford University, with lesser numbers at other "core" sites.

Contact Vince Fuller [vaf] for more information on BARRNet.

6.2.1 BARRNet's OSPF system

BARRNet was also one of the initial deployment sites for OSPF Version 1, having deployed the protocol in April 1990. BARRNet has been running OSPF V2 since November 1990. They currently have 14 routers in their OSPF system. The BARRNet OSPF system is pictured in Figure 2. It consists of a collection of T1 serial lines, with ethernets at hub sites.

Most of BARRNet's OSPF routers are speaking either RIP and/or EGP as well as OSPF. Routes from these other routing protocols are selectively imported into their OSPF system as externals. A large number of external routes are imported; the current number is1816. The bulk of these are the T1 NSFNet routes, followed by several hundred NSN routes, around 60-80 BARRNet routes from the non-OSPF system, and several dozen from ESNet.

All external routes are imported into the BARRNet system as external type 1 metrics. In addition, BARRnet, like NSI, uses the OSPF's external route tagging feature to help manage the readvertisement of external routes via EGP.

[Moy] [Page 9]

RFC 1246 Experience with OSPF July 1991

BARRnet is also using four stub OSPF areas in order to collapse subnet information. These stub areas all consist of a single LAN. They do not contain any OSPF routers in their interiors.

6.2.2 BARRNet - Deployment analysis

Initial deployment of OSPF Version 1 in BARRNet pointed to the need for two new protocol features that were added to OSPF V2, namely:

6.3 OARnet

OARnet, the Ohio Academic Resources Network, is the regional network for the state of Ohio. It serves the entire higher education community, providing Ohio schools access to colleagues worldwide. The Ohio Supercomputer Center and the NSF Supercomputer Centers are reached through OARnet. Libraries, databases, national and international laboratories and research centers are accessible to faculty, helping make Ohio schools competitive.

OARnet was established in 1987 to provide state-wide access to the CRAY at the Ohio Supercomputer Center in Columbus, Ohio. Since then it has evolved into a network supporting all aspects of higher education within Ohio. A primary goal of OARnet is to facilitate collaborative projects and sharing of resources between institutions, including those outside the state. OARnet connections are available to Ohio academic institutions and corporations engaged in research, product development, or instruction. Colleges, universities, and industries currently use OARnet connections to communicate within the state and with colleagues around the country.

OARnet uses the Internet (TCP/IP) and DECNET protocols. OARnet participants using TP/IP protocols are connected to the worldwide Internet, which includes all the major networks open to non-classified research. OARnet is also connected to NSFNet, the national research and

[Moy] [Page 10]

RFC 1246 Experience with OSPF July 1991

education network sponsored by the National Science Foundation. It has gateways to BITNET, CSNET, CICNet (a network connecting the Big Ten universities), and the NASA Science Internet.

For more information on OARnet, contact Kannan Varadhan [kannan].

6.3.1 OARnet's OSPF system

OARnet has been running OSPF Version 1 since October 15, 1990. They currently have 14 routers in their OSPF system. The OARnet OSPF system is pictured in Figure 3.

There are 29 sites connected directly to the OARnet backbone. All 13 of OARnet's OSPF routers act as ASBRs. There are 40 OSPF internal routes on OARnet's network, and they import about 120 routes from RIP. OARnet runs EGP on the DMZnet at Columbus, which connects them to CICNet. The router connecting OARnet to DMZnet (OAR1 in Figure 3) runs EGP on the DMZnet side, and OSPF and RIP on the OARnet backbone. No EGP routes are imported into the OSPF system. The OAR1 router is configured to generate a default when EGP routes are available. The OAR1 router is the keystone for routing on OARnet's network, in that it acts as an intermediary for all of OARnet's RIP centric routers.

OARnet uses the Event Logging System on its Proteon routers to generate traps for "interesting" events related to routing. They have these traps sent to an SNMP management station, where the logs are collected for later perusal.

6.3.2 OARnet - Deployment analysis

OARnet is monitoring their OSPF system via collection of traps on their SNMP management station. The following is a report on their observations. It has been edited slightly to conform better with the other text and maps presented in this report. For more information, contact Kannan Varadhan [kannan]:

3 of our 10 DS1 circuits are on digital microwave, and these tend to flap occasionally. Our observations indicate that the routers bring up links, and adjacencies, on average, in about 2 seconds. Routes fallback to alternate backup paths instantly. Whole blocks of routes cut over the instant the adjacencies are formed.

In contrast to this, our RIP routes would take about 3-6 minutes to cutover, and, on occasion, would not cut back to the preferred paths. This was our prime motivation in switching to OSPF.

[Moy] [Page 11]

RFC 1246 Experience with OSPF July 1991

We attempted to duplicate Milo Medin's ping test to dramatically illustrate the performance of RIP over OSPF. To do this, we selected a host on the farthest point from our workstation, and ran a continuous ping to it. We would then bring down a primary DS1 circuit, and watch the time it took to switch to the fallback route. Following this, we would bring the circuit back up, and study the time it took to re-sync to the new path. With RIP, we were unable to fully complete the experiment, because the farthest point was exactly equal to the new (and preferred) primary path, and therefore, RIP would never choose it on it's own, until the path it was currently using failed. With OSPF, it took about 2 seconds to synchronize over a new, much slower 56kb path, and less than a second when the DS1 circuit came back up.

Here are some more observations of the OARnet OSPF system's behavior:

The Akron router restarts, and has to re-sync with all the lines. This restart is confirmed when one looks at the traps from gwCSP1. Traps from gwASP1 still do not get through to us, because traps are

[Moy] [Page 12]

RFC 1246 Experience with OSPF July 1991

sent via UDP, and gwASP1's routing tables are not fully configured yet.

Events 1 and 2 are route changes routing traffic via Cleveland, across 2 DS1 circuits and a 56kb line.

When the DS1 circuit to UAkron came up, routes instantly cut over to use this as a better least cost path. This is shown in events 3, 4 and 5.

In a few seconds, the line to Columbus is the next one up. This is event 6. Event 8 relates to this cutover, and is the best path yet. When the DS1 circuit to Kent is up, the link is used instantly.

We are able to make such a definitive conclusion of these traps on the basis of the topological information that we have about the network and the means used to monitor them. 

           REPORT DATE: 02/26/91   ROUTER: gwcsp1
           09:55:06: SPF.15: State Change, ifc 131.187.22.6,
                      new state <Point-To-Point>, event 1
           09:55:06: GW.xxx: Link Up Trap: 09:55:07: SPF.37:
                     new route to Net 131.187.22.5, type SPF cost 1
           09:55:07: SPF.21: State Change, nbr 131.187.22.5,
                     new state <Init>, event 1
           09:55:09: SPF.37: new route to Net 131.187.27.5,
                     type SPF cost 22
           09:55:11: SPF.21: State Change, nbr 131.187.22.5,
                     new state <ExStart>, event 14
           09:55:11: SPF.21: State Change, nbr 131.187.22.5,
                     new state <2-Way>, event 3
           09:55:12: SPF.21: State Change, nbr 131.187.22.5,
                     new state <Exchange>, event 5

[Moy]                                                          [Page 13]

RFC 1246                  Experience with OSPF                 July 1991

           09:55:12: SPF.21: State Change, nbr 131.187.22.5,
                     new state <Full>, event 9
           09:55:12: SPF.21: State Change, nbr 131.187.22.5,
                     new state <Loading>, event 6

Below, is another trace of the same router restart sequence, where the router is proceeding to bring up other DS1 circuits. Bringing up the first adjacency took about 5 seconds. Subsequent adjacencies take the router less than a second as seen below. 

           REPORT DATE: 02/26/91   ROUTER: gwasp1
           09:55:20: SPF.15: State Change, ifc 131.187.27.5,
                     new state <Point-To-Point>, event 1
           09:55:20: GW.xxx: Link Up Trap: 09:55:20: SPF.21:
                     State Change, nbr 131.187.27.6, new state <Init>, event 1
           09:55:20: SPF.21: State Change, nbr 131.187.27.6,
                     new state <ExStart>, event 14
           09:55:20: SPF.21: State Change, nbr 131.187.27.6,
                     new state <Exchange>, event 5
           09:55:20: SPF.21: State Change, nbr 131.187.27.6,
                     new state <Full>, event 9
           09:55:21: SPF.21: State Change, nbr 131.187.27.6,
                     new state <Loading>, event 6
           09:55:24: SPF.21: State Change, nbr 131.187.51.6,
                     new state <Init>, event 1
           09:55:24: SPF.21: State Change, nbr 131.187.21.5,
                     new state <Init>, event 1
           09:55:25: SPF.37: new route to Net 131.187.21.6, type SPF cost 13
           09:55:25: SPF.37: new route to Net 131.187.51.5, type SPF cost 22
           09:55:28: SPF.21: State Change, nbr 131.187.21.5,
                     new state <ExStart>, event 14
           09:55:28: SPF.21: State Change, nbr 131.187.21.5,
                     new state <2-Way>, event 3
           09:55:28: SPF.21: State Change, nbr 131.187.21.5,
                     new state <Exchange>, event 5
           09:55:28: SPF.21: State Change, nbr 131.187.21.5,
                     new state <Full>, event 9
           09:55:28: SPF.21: State Change, nbr 131.187.21.5,
                     new state <Loading>, event 6
           09:55:29: SPF.37: new route to Net 131.187.51.6, type SPF cost 1
           09:55:29: SPF.37: new route to Net 131.187.21.5, type SPF cost 1
           09:55:29: SPF.21: State Change, nbr 131.187.51.6,
                     new state <Exchange>, event 5
           09:55:29: SPF.21: State Change, nbr 131.187.51.6,
                     new state <ExStart>, event 14
           09:55:29: SPF.21: State Change, nbr 131.187.51.6,
                     new state <2-Way>, event 3
           09:55:29: SPF.21: State Change, nbr 131.187.51.6,

[Moy]                                                          [Page 14]

RFC 1246                  Experience with OSPF                 July 1991

                     new state <Full>, event 9
           09:55:29: SPF.21: State Change, nbr 131.187.51.6,
                     new state <Loading>, event 6

A transient fault on a DS1 circuit, causes the line to flap. All routers quickly reroute around the flap, and the router itself takes about 2 seconds to bring up the adjacency once more. 

           REPORT DATE: 02/26/91   ROUTER: gwasp1
           14:33:43: GW.xxx: Link Up Trap:
           14:34:19: SPF.15: State Change, ifc 131.187.22.5,
                     new state <Down>, event 7
           14:34:19: GW.xxx: Link Failure Trap:
           14:34:19: SPF.47: Net 131.187.22.6 now unreachable
           14:34:36: SPF.15: State Change, ifc 131.187.22.5,
                     new state <Point-To-Point>, event 1
           14:34:36: GW.xxx: Link Up Trap:
           14:34:37: SPF.37: new route to Net 131.187.22.6, type SPF cost 1
           14:34:45: SPF.21: State Change, nbr 131.187.22.6,
                     new state <2-Way>, event 3
           14:34:45: SPF.21: State Change, nbr 131.187.22.6,
                     new state <Init>, event 1
           14:34:46: SPF.21: State Change, nbr 131.187.22.6,
                     new state <ExStart>, event 14
           14:34:46: SPF.21: State Change, nbr 131.187.22.6,
                     new state <Exchange>, event 5
           14:34:47: SPF.21: State Change, nbr 131.187.22.6,
                     new state <Full>, event 9
           14:34:47: SPF.21: State Change, nbr 131.187.22.6,
                     new state <Loading>, event 6

           {nisca danw 51}
           ping 131.187.25.6 PING 131.187.25.6 (131.187.25.6):

[Moy]                                                          [Page 15]

RFC 1246                  Experience with OSPF                 July 1991

           56 data bytes 64 bytes from 131.187.25.6:
           icmp seq=0 ttl(255-ttl)=54(201). time=20 ms
                   [...]
           icmp seq=10 ttl(255-ttl)=54(201). time=20 ms
                    ||             T1 down
           icmp seq=14 ttl(255-ttl)=54(201). time=180 ms
           icmp seq=15 ttl(255-ttl)=54(201). time=60 ms
                   [...]
           icmp seq=38 ttl(255-ttl)=8(247). time=1300 ms
           icmp seq=39 ttl(255-ttl)=54(201). time=820 ms
                    ||             Tl Up
           icmp seq=40 ttl(255-ttl)=54(201). time=20 ms
           icmp seq=41 ttl(255-ttl)=54(201). time=20 ms
           131.187.25.6 PING Statistics
           51 packets transmitted, 48 packets received, 5% packet loss
           round-trip (ms) min/avg/max = 20/277/1300

6.4 Features exercised during operational deployment

In operational environments, all basic mechanisms of the OSPF protocol have been exercised. These mechanisms include:

[Moy] [Page 16]

RFC 1246 Experience with OSPF July 1991

6.5 Limitations of operational deployments

The following things have not been tested in an operational environment:

6.6 Conclusions

All basic features of the OSPF protocol have been exercised. Very large OSPF link state databases (e.g., BARRNet's OSPF system) have been deployed, providing a thorough test of OSPF's database synchronization mechanisms. No OSPF protocol problems have been found in operational deployments.

Most of the hassles in operation deployments has to do with the OSPF/RIP interchange. Many of these issues have been ironed out on the ospf-tests mailing list (see Section 2.0). However, the interaction between OSPF, RIP, and EGP continues to be an active area of research.

7.0 Interoperability Testing

There have been three separate OSPF V2 interoperability testing sessions. Five separate implementations have participated in at least one session: implementations from the companies 3com, ACC, Proteon and Wellfleet, and the publicly available implementation from the University of Maryland.

[Moy] [Page 17]

RFC 1246 Experience with OSPF July 1991

Each of the testing sessions is described in a succeeding section. For each session, the participants are identified, and the testing topologies are described along with the particular protocol features that were exercised. Any protocol problems that were encountered during the testing are also described. In addition, for the second and third rounds testing reports were sent to the ospf mailing lists. These reports are reproduced in this document.

There is quite a bit of commonality in the features that have been tested from session to session. There are several reasons for this commonality. First, in each testing session an attempt has been made to increase the size of the OSPF system under test. For example, the number of external routes imported has doubled each session. Secondly, the interoperability sessions have been debugging sessions as well as protocol sessions. Many things tested in the third round were to verify that implementations had successfully fixed problems found in earlier sessions. A brief overview of the testing session is presented in the following table:

TABLE 4. OSPF interoperability testing at a glance.

Site Week Routers Externals Implementations 

Proteon   9/25/90    6         20-30       3com, Proteon, Wellfleet
SURAnet   12/17/90   10        96          3com, ACC, Proteon, Wellfleet
3com      2/4/91     16        400         3com, ACC, Proteon, Wellfleet, UMD

For more information on the interoperability testing, the following people can be contacted: Fred Baker [fbaker], Rob Coltun [rcoltun], Dino Farinacci [dino], Jonathan Hsu [jhsu], John Moy [jmoy], and William Streilein [bstreile].

7.1 Testing methodology

In the interoperability tests, the routers have been interconnected using ethernet, serial lines (PPP and proprietary), X.25 and 802.5 token ring. Monitoring of the routers has been done through connecting terminals (either directly or via telnet) to the router consoles. Each implementation has a different user interface, which makes monitoring somewhat difficult. As explained earlier in this document, there is now an OSPF MIB, which in the future will enable a common monitoring interface to all implementations.

In general, each implementation has an error logging capability, and this is often how problems are discovered. LAN protocol analyzers are

[Moy] [Page 18]

RFC 1246 Experience with OSPF July 1991

also used to capture OSPF protocol packet exchanges that are causing problems. These packet traces are available for analysis either during of after the testing sessions.

Verification of routing was done through visual inspection of implementations' routing table and link state databases (via the console interface), and through network debugging tools such as "ping" and "traceroute".

7.2 First round (Proteon, 9/25/90 - 9/29/90)

The first round of OSPF protocol testing took place at Proteon Inc.'s Westborough facility, the week of September 25, 1990. Three implementations participated, from the vendors 3com, Proteon and Wellfleet.

There were two 3com routers, two Wellfleet routers and two Proteon routers available for testing. These routers were interconnected with ethernets and serial lines. External routes were imported from the Proteon company internet. In addition, during off hours we were able to connect the routers under test to the Proteon company internet, forming one fairly large OSPF system.

The testing at Proteon proceeded as follows:

[Moy] [Page 19]

RFC 1246 Experience with OSPF July 1991

represent an OSPF default route.

Unfortunately, incomplete records were kept of this testing, so that no maps of the testing configurations can be reproduced for this document.

7.2.1 Problems found in the First round testing

A couple of OSPF protocol/specification problems were uncovered in the first round of testing. First, it was noticed that there was a window in the Database Description process where concurrently flooded MaxAge advertisements could prevent database synchronization from completing. This required a change in the specification's handling of MaxAge LSAs.

Secondly, it was found that the OSPF specification did not specify how the Network Mask field should be set in external LSAs that were advertising the DefaultDestination. This was a minor problem, but caused difficulties because of assumptions made in one implementation on how the mask should be set.

7.3 Second round (SURAnet, 12/17/90 - 12/21/90)

The second round of OSPF protocol testing took place at SURAnet's College Park facility, the week of December 12, 1990. Four implementations participated, from the vendors 3com, ACC, Proteon and Wellfleet.

There were two 3com routers, two ACC routers, two Wellfleet routers and four Proteon routers available for testing. These routers were interconnected with ethernets, serial lines and token rings. External routes were imported from SURAnet by one of the Proteon routers.

The testing at SURAnet proceeded as follows. Initially nine routers were configured as a single backbone area, with six of the routers connected to a single ethernet. This is pictured in Figure 4. In this configuration, the Designated Router transition and database synchronization process were tested. Ninety-six external routes were imported from SURAnet to stress the flooding algorithm. By restarting the router that was importing the routes, the flushing of advertisements from the routing domain was tested. Additionally, variable-length subnets and OSPF's optional TOS routing capability were tested in this configuration.

Next the routers were configured into four separate OSPF areas, with each area directly connected to the OSPF backbone (which was a single ethernet). There were no virtual links in this configuration. Inter-

[Moy] [Page 20]

RFC 1246 Experience with OSPF July 1991

area routing was tested, including having AS boundary routers internal to a non-backbone area. Also tested was the case where a single router was both an area border router and an AS boundary router.

For more details of the testing, see the "Official report of the Second Round Testing" listed below.

7.3.1 Official report of the Second round testing

The following report was sent to the ospf, ospf-tests, and routerrequirements mailing lists after the second round of interoperability tests:

The second round of OSPF multi-vendor testing was done in College Park, Maryland the week of 12/17/90. The facilities were provided by SURAnet. Four major router vendors were present, Advanced Computer Communications (ACC), Proteon, 3Com, and Wellfleet. A press conference and presentation was provided for 3 different data communication magazine representatives.

Each vendor provided at least 2 routers. Each vendor had a device connected to a common Ethernet. This Ethernet was configured as the OSPF backbone area. The rest of the routers were attached to the various backbone routers via Ethernet, Token Ring, proprietary serial line, PPP serial line, and X.25 type media. The following test scenarios were performed and completed in the following order:

[Moy] [Page 21]

RFC 1246 Experience with OSPF July 1991

state advertisements. It was observed how the other vendor implementations reacted to it. Some problems were found.

Each vendor agreed that this sort of testing was extremely valuable and that it should occur again. 3Com has offered for the third round of testing to occur in Santa Clara sometime in February. 3Com will encourage other OSPF implementations to join in the testing. Items that will be tested are:

[Moy] [Page 22]

RFC 1246 Experience with OSPF July 1991

Furthermore, we hope that in future rounds of testing an OSPF MIB would allow us to also use a network management station to gather test data.

In summary, the stability of implementations were better this time more so than the first round of testing. No problems with the protocol design were encountered. The exchange of ideas and the cooperation among implementors that occurred during this test effort, continues the spirit that OSPF is truly an open protocol.

7.3.2 Problems found in the Second round testing

No problems were found in the OSPF protocol during the second round of testing.

7.4 Third round (3com, 2/4/91 - 2/8/91)

The third round of OSPF protocol testing took place at 3com's Santa Clara facility, the week of February 4, 1991. Five implementations participated, from the vendors 3com, ACC, Proteon and Wellfleet and the publicly available University of Maryland implementation (running on a SUN workstation).

There were five 3com routers, four ACC routers, three Wellfleet routers, three Proteon routers and the UMD Sun workstation available for testing (giving a total of 16 routers available). These routers were interconnected with ethernets, serial lines and X.25. External routes were imported from BARRNet by one of the 3com routers.

The initial testing configuration is shown in Figure 5. Three areas were configured, along with a non-contiguous backbone. The backbone was then joined by configuring two virtual links. In this configuration the following OSPF functionality was tested: inter-area routing and virtual links.

The system was then reconfigured so that twelve of the routers were connected to a single ethernet. This configuration is pictured in Figure 6. By bringing routers up and down, this configuration tested Designated Router election, database synchronization and reliable flooding. To see how this functionality, and also the implementations, scale, 400

[Moy] [Page 23]

RFC 1246 Experience with OSPF July 1991

external routes were imported from BARRNet.

7.4.1 Official report of the Third round testing

The following report was sent to the ospf, ospf-tests, and routerrequirements mailing lists after the third round of interoperability tests:

The third round of OSPF interoperability testing was held at 3com Corporation in Santa Clara the week of February 4-8. Four router vendors came to the testing: 3com, ACC, Proteon and Wellfleet. In addition, Rob Coltun brought the University of Maryland implementation, which was run on a Sun Workstation.

Testing was performed over ethernet, point-to-point networks (using PPP) and X.25. In all we had 16 routers available: five 3com routers, four ACC routers, three Proteon routers, three Wellfleet routers and Rob's SUN. We also were able to import external routes from BARRNet.

Specific tests performed included the following:

[Moy] [Page 24]

RFC 1246 Experience with OSPF July 1991

The following problems we found in the OSPF specification:

Thanks to 3com for providing the testing facility, cables. terminals, X.25 switch. etc. Also thanks to Vince Fuller of BARRNet for helping us import the BARRNet routes.

7.4.2 Problems found in the Third round testing

A couple of specification/protocol problems were found in the third round of interoperability testing. First, it was noticed that the specification did not specify the setting of the Network Mask field in Hellos sent over virtual links. This caused some initial difficulty in bringing up virtual links between routers belonging to different vendors. Secondly, it was noticed that the specification was not strict enough in defining how OSPF neighbors are identified on multi-access networks. This caused difficulties in one implementation when another vendor's router was restarted with the same IP address but a different OSPF Router ID. This is discussed more fully in the above "Official Report of the Third Round Testing".

7.5 Overall: Features tested

All significant protocol features and mechanisms have been tested in the three rounds of interoperability testing. In particular, the following basic pieces of the protocol have been tested:

[Moy] [Page 25]

RFC 1246 Experience with OSPF July 1991

singly and in pairs.

[Moy] [Page 26]

RFC 1246 Experience with OSPF July 1991

Testing was also performed on the following pieces of OSPF's Area functionality:

The following OSPF options were also tested:

7.6 Testing conclusions

The interoperability testing has proven to be very valuable. Many bugs were found (and fixed) in the implementations. Some protocol problems were found (and fixed), and gray areas of the specification were cleared up. Implementations have also been "bullet-proofed" in order to deal with the unexpected behavior of other implementations. All participants in the testing now understand the maxim "be conservative in what you generate, and liberal in what you accept" (if they didn't already).

7.7 Future work

The one thing that has gone mostly untested at the interoperability sessions is the interaction between OSPF and other routing protocols (such as RIP and EGP). Each interoperability session generally had a router running multiple routing protocols in order to import external routing information into the OSPF system. However, simultaneously running multiple routing protocols between different vendors' routers has not been tested.

Each vendor has developed a slightly different architecture for the exchange of routing information between differing routing protocols. As the OSPF field testing has also shown, this exchange of routing information is an area of ongoing work and a candidate for future standardization.

[Moy] [Page 27]

RFC 1246 Experience with OSPF July 1991

8.0 Simulation

The OSPF protocol has been simulated by the Distributed Systems Research Group at the University of Maryland Baltimore County (UMBC). The two principal investigators for the OSPF simulation project are Dr. Deepinder P. Sidhu of UMBC and Rob Coltun. They have been aided by three graduate students: S. Abdallah, T. Fu and R. Nair. This section attempts to summarize their simulation setup and results. For more information, contact the Distributed Systems Research Group at the following address: 

        Dr. Deepinder P. Sidhu
        Department of Computer Science
        University of Maryland Baltimore County
        Baltimore, MD 21228
        email: sidhu@umbc3.umbc.edu

A demo was given of their OSPF simulation at the March 4-8, 1991 IETF in St. Louis. Details of the demo should be available in the IETF proceedings.

8.1 Simulator setup

The Distributed System Research Group uses a significantly enhanced version of the MIT network simulator. The simulator is event driven, and contains support for both point-to-point networks and ethernet links. It can simulate characteristics of both packet switches and hosts, and can simulate internet behavior under various types of data traffic load (e.g., Poisson, normal, exponential and uniform distributions). This latter ability could be used, for example, to simulate how a routing protocol works in a congested internet. Specific network topologies can be input into the simulator, or pseudo-random network topologies can be generated. Packet loss rates can also be simulated.

To simulate OSPF, Rob Coltun's OSPF implementation was incorporated into the simulator, essentially unchanged.

The output of the simulator can be displayed in a graphical manner (it uses X windows). Any variable in the implementation under test can be monitored. In addition, statistical reports can later be produced from logging files produced during the simulation runs.

[Moy] [Page 28]

RFC 1246 Experience with OSPF July 1991

8.2 Simulation results

The OSPF simulation has been run using the following topologies:

In these topologies, the correctness of the OSPF database synchronization was verified. This was done through examination of the nodes' OSPF link state databases and the nodes' routing tables. The implementation of multiple OSPF areas was also tested. Also, database convergence time was analyzed as a function of the network components' link speeds.

Also, some formal analysis of the OSPF protocol was undertaken. The neighbor and interface state machines were analyzed. In addition, the Designated Router election algorithm was verified for certain sets of initial conditions.

9.0 Reference Documents

The following documents have been referenced by this report:

[1] Moy, J., "The OSPF Specification", RFC 1131, October 1989.

[2] Moy, J., "OSPF Version 2", RFC 1247, July 1991.

[3] Coltun, R. and Baker, F., "OSPF Version 2 Management Information

Base", RFC 1248, July 1991.

[4] Reynolds, J. and Postel, J., "Assigned Numbers', RFC1060, March

1990.

[5] Corporation for National Research Initiatives, "Proceedings of the

Thirteenth Internet Engineering Task Force", Cocoa Beach, Florida, April 11-14, 1989.

[Moy] [Page 29]

RFC 1246 Experience with OSPF July 1991

[6] Corporation for National Research Initiatives, "Proceedings of the

Sixteenth Internet Engineering Task Force", Florida State University, February 6-9, 1990.

[7] Gardner, M., et al., "Type-of-service routing: modeling and

simulation," Report 6364, BBN Communications Corporation, January 1987.

[8] Corporation for National Research Initiatives, "Proceedings of the

Seventeenth Internet Engineering Task Force", Pittsburgh Supercomputing Center, May 1-4, 1990.

[9] Corporation for National Research Initiatives, "Proceedings of the

Eighteenth Internet Engineering Task Force", University of British Columbia, July 30-August 3, 1990.

10.0 People

The following people have contributed information to this report and can be contacted for further information:

TABLE 5. People references in this report

Tag Name Affiliation email 

bstreile   William Streilein   Wellfleet           bstreile@wellfleet.com
dino       Dino Farinacci      3com                dino@buckeye.esd.3com.com
fbaker     Fred Baker          ACC                 fbaker@acc.com
jeff       Jeffrey Burgan      Sterling Software   jeff@nsipo.nasa.gov
jhsu       Jonathan Hsu        Wellfleet           jhsu@wellfleet.com
jmoy       John Moy            Proteon             jmoy@proteon.com
kannan     Kannan Varadhan     OARnet              kannan@oar.net
medin      Milo Medin          Sterling Software   medin@nsipo.nasa.gov
rcoltun    Rob Coltun          U. of Maryland      rcoltun@umd5.umd.edu
rrv        Ross Veach          U. of Illinois      rrv@seka.cso.uiuc.edu
vaf        Vince Fuller        BARRNet             vaf@valinor.stanford.edu

[Moy]                                                          [Page 30]

RFC 1246                  Experience with OSPF                 July 1991

Security Considerations

The OSPF protocol's security architecture is described in Section 4.0.

Author's Address

John Moy
Proteon Inc.
2 Technology Drive
Westborough, MA 01581

Phone: (508) 898-2800
Email: jmoy@proteon.com

[Moy] [Page 31]