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
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 router-
requirements 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:
o Initially we configured the routers into three separate areas and a
physically disconnected backbone. The backbone was then reconnected
through configuration of several virtual links. These tests verified
the generation and processing of summary link advertisements, as well
as the operation of virtual links.
o We connected multiple routers to an X.25 packet switch, testing
OSPF's non-broadcast network capability. OSPF was successfully run
over the X.25 network, using routers that were both DR eligible and
DR ineligible. Some problems were encountered, but they all involved
running IP over X.25 (i.e., they were not X.25 specific).
o We also connected a 3com router, Proteon router, and Rob's SUN to an
ethernet, and then treated the ethernet as a non-broadcast network.
This allowed us to connect Rob's SUN into the rest of the routing
domain without installing the IP multicast modifications to the SUN
kernel. It also further tested the OSPF's non-broadcast network
capability.
o We then reconfigured the OSPF system so that all but three of the
routers were connected to a single ethernet. This tested the
Designated Router functionality (12 routers were synchronizing with
the DR). We then also tested the DR election algorithm, by
selectively restarting the DR, or sometimes both the DR and the
Backup DR. This also tested OSPF's Database Description process.
o In this configuration, we then imported 400 external routes from
BARRNet (one of the 3com routers ran both OSPF and EGP). Some
problems were encountered in implementations' buffer allocation
strategies, and problems were also found in the way implementations
avoid IP fragmentation. But overall, this system was fairly stable.
The following problems we found in the OSPF specification:
o The specification should say that the "Network mask" field should not
be verified in OSPF Hellos received over virtual links.
o The specification should say that on multi-access networks neighbors
are identified by their IP address, and on point-to-point networks
and virtual links by their OSPF Router ID. This eliminates confusion
when, for example, a router is restarted and comes up with the same
IP address but a different Router ID.
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:
o Designated Router election. With as many as thirteen routers attached
to a single LAN, the election of Backup Designated Router and
Designated router was verified by bringing routers up and down,
singly and in pairs.
o Adjacency bringup. The Database Description process was verified,
with databases having over 400 LSAs. Adjacency bringup was also
verified in times when flooding was taking place simultaneously.
o Reliable flooding. It was verified that OSPF's flooding algorithm
maintains database synchronization, both in the presence of loops in
the topology, and with large databases (over 400 LSAs).
o Flushing advertisements from routing domain. OSPF's procedure for
flushing old or unreachable LSAs from the routing domain was
verified, both in the presence of topology loops and with many LSAs
being flushed at once. This is also referred to as OSPF's MaxAge
procedure.
o OSPF routing hierarchy. The OSPF four level routing hierarchy:
intra-area, inter-area. type 1 externals and type 2 externals was
tested.
o Import of external routing information. The importing of external
routes has been tested, with as many as 400 imported at once. Also,
the varying options in external LSAs has been tested: type 1 or type
2 metrics and forwarding addresses.escribe all options. In addition,
test setups were utilized having AS boundary routers both internal to
non-backbone areas and also being simultaneously area border routers.
o Running protocol over various network types. In the test setups, OSPF
has been run over ethernet, point-to-point serial lines (both PPP and
proprietary), 802.5 token ring and X.25.
o Non-broadcast, multi-access networks. OSPF has been tested over X.25.
Some testing was also done treating ethernet as a non-broadcast
network. Two separate situations were tested: when all routers
attached to the non-broadcast network were DR-eligible, and when only
some of them were.
o Authentication. OSPF's authentication procedure was tested for the
two current authentication types.
o Equal-cost multipath. Much of the testing was done in configurations
with redundant paths, and equal-cost multipath was verified through
examination of implementations' routing tables.
o Variable-length subnet masks. It was verified that implementations
paid attention to the network mask field present in OSPF LSAs.
Testing was also performed on the following pieces of OSPF's Area
functionality:
o Extent of advertisements. It was verified that all advertisements
except external LSAs were flooded throughout a single area only.
o Inter-area routing. The generation and processing of summary link
LSAs was tested. Also tested were configurations having multiple area
border routers attaching to a single area.
o Virtual links.
The following OSPF options were also tested:
o TOS routing. The interplay between TOS-capable and non-TOS-capable
routers was tested, by configuring TOS-specific metrics in the only
implementation (3com) supporting TOS routing.
o Stub areas. OSPF's stub area functionality was verified.
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.
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.
8.2 Simulation results
The OSPF simulation has been run using the following topologies:
o The two sample topologies in the OSPF specification (Figure 2 and
Figure 6 in [2]). The first of these topologies shows an Autonomous
System without areas, the second the same AS with three areas and a
virtual link configured.
o The 19-node hub topology from [7].
o A large network of over 50 nodes, all attached to a single ethernet.
o A large network of over 50 nodes, containing both ethernets and
serial lines, pseudo randomly generated.
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", RFC1131, October 1989.
[2] Moy, J., "OSPF Version 2", RFC1247, July 1991.
[3] Coltun, R. and Baker, F., "OSPF Version 2 Management Information
Base", RFC1248, 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.
[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
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