As per Relevance of the word external, we have this rfc below:
Network Working Group J. Moy,
Request for Comments: 1246 July 1991
Experience with the OSPF
Status of this
This memo provides information for the Internet community. It does
specify any Internet standard. Distribution of this memo is unlimited
This is the second of two reports on the OSPF protocol. These
are required by the IAB/IESG in order for an Internet routing
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
OSPF protocol was published in RFC 1131. Since then OSPF version 2
been developed. Version 2 has been documented in RFC 1247. The
between version 1 and version 2 of the OSPF protocol are explained
Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of
report
This report documents experience with OSPF V2. This includes reports
interoperability testing, field experience, simulations and the
state of OSPF implementations. It also presents a summary of the
Management Information Base (MIB), and a summary of OSPF
mechanism
Please send comments to ospf@trantor.umd.edu
1.0
This document addresses, for OSPF V2, the requirements set forth by
IAB/IESG for an Internet routing protocol to advance to Draft
state. This requirements are briefly summarized below. The
sections of this report document how OSPF V2 satisfies
requirements
[Moy] [Page 1]
RFC 1246 Experience with OSPF July 1991
o The specification for the routing protocol must be well written
that independent, interoperable implementations can be
solely based on the specification. For example, it should be
to develop an interoperable implementation without consulting
original developers of the routing protocol
o A Management Information Base (MIB) must be written for the protocol
The MIB must be in the standardization process, but does not need
be at the same level of standardization as the routing protocol
o The security architecture of the protocol must be set
explicitly. The security architecture must include mechanisms
authenticating routing messages and may include other forms
protection
o Two or more interoperable implementations must exist. At least
must be written independently
o There must be evidence that all features of the protocol have
tested, running between at least two implementations. This
include that all of the security features have been demonstrated
operate, and that the mechanisms defined in the protocol
provide the intended protection
o There must be significant operational experience. This must
running in a moderate number routers configured in a
complex topology, and must be part of the operational Internet.
significant features of the protocol must be exercised. In the
of an Interior Gateway Protocol (IGP), both interior and
routes must be carried (unless another mechanism is provided for
exterior routes). In the case of a Exterior Gateway Protocol (EGP),
it must carry the full complement of exterior routes
This report is a compilation of information obtained from many people
The reader is referred to specific people when more information on
subject is available. People references are gathered into Section 10.0,
in a format similar to that used in [4].
1.1
The OSPF protocol has been developed by the OSPF Working Group of
Internet Engineering Task Force. Many people have contributed to
report. They are listed in Section 10.0 of this report
[Moy] [Page 2]
RFC 1246 Experience with OSPF July 1991
2.0
Version 1 of the OSPF protocol is documented in RFC 1131 [1].
Version 2, which supersedes Version 1, has been documented in RFC 1247
[2]. The differences between OSPF Version 1 and Version 2 are
minor, and are listed in Appendix F of RFC 1247 [2]. All
presented in this report concerns OSPF V2 unless explicitly
otherwise
The OSPF protocol was developed by the OSPF Working Group of
Internet Engineering Task Force. This Working Group has a mailing list
ospf@trantor.umd.edu, where discussions of protocol features
operation are held. The OSPF Working Group also meets during
quarterly Internet Engineering Task Force conferences. Reports of
meeting are published in the IETF's Proceedings. In addition,
reports on the OSPF protocol have been presented to the IETF
(see "Everything You Ever Wanted to Know about OSPFIGP" in [5] and "
Update" in [6]).
The OSPF protocol began undergoing field trials in Spring of 1990.
mailing list, ospf-tests@seka.cso.uiuc.edu, was formed to discuss
the field trials were proceeding. This mailing list is maintained
Ross Veach of the University of Illinois [rrv]. Archives of this
are also available. There has been quite a bit of discussion on the
concerning OSPF/RIP/EGP interaction
A OSPF V2 Management Information Base has also been developed
published in [3]. For more information, see Section 3.0 of this report
There is a free implementation of OSPF available from the University
Maryland. This implementation was written by Rob Coltun [rcoltun].
Contact Rob for details
3.0
An OSPF Management Information Base has been published in RFC 1248 [3].
The MIB was written by Rob Coltun [rcoltun] and Fred Baker [fbaker].
OSPF MIB appears on the mgmt subtree as SMI standard-mib 13.
The OSPF MIB was originally developed by Rob Coltun of the University
Maryland, under contract to Advanced Computer Communications. A
of his proposal was implemented to facilitate their development,
represents operational experience of a sort
The MIB consists of a general variables group and ten tables
TABLE 1. OSPF MIB
[Moy] [Page 3]
RFC 1246 Experience with OSPF July 1991
Group Name
________________________________________________________________
ospfGeneralGroup General Global
ospfAreaTable Area
ospfStubAreaTable Default Metrics, by Type of
ospfLsdbTable Link State
ospfAreaRangeTable Address Range
ospfHostTable Directly connected
ospfIfTable OSPF Interface
ospfIfMetricTable Interface Metrics, by Type of
ospfVirtIfTable Virtual
ospfNbrTable (Non-virtual) OSPF
ospfVirtNbrTable Virtual OSPF
As MIBs go, the OSPF MIB is quite large; 105 objects. The following
some statistics describing the distribution of the MIB's variables
o 11 define the above Group and
o 10 define the Entry in a
o 7 are
o 6 are
o 68 objects mandated by the OSPF Version 2
Section D.2 of the OSPF V2 specification [2] lists a set of
statistics that an implementation must maintain. These statistics
been incorporated into the OSPF MIB. The MIB's thirteen Counters
Gauges enable evaluation of the OSPF protocol's performance in
operational environment. Most of the remainder of the MIB's
parameterize the many features that OSPF provides the
administrator
For more information on the MIB contact Fred Baker [fbaker].
4.0 Security
In OSPF, all protocol packet exchanges are authenticated. The
packet header (which is common to all OSPF packets) contains a 16-
Authentication type field, and 64-bits of Authentication data.
particular OSPF area must run a single authentication scheme,
indicated by the Authentication type field. However, authentication
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
verifies that it indicates the correct Authentication type. The
then authenticates the packet, running a verification algorithm
the configured authentication key, the 64-bits of Authentication
and the rest of the OSPF packet data as input. The precise
used is dictated by the Authentication type. Packets failing
authentication algorithm are dropped, and the authentication failure
noted in a MIB-accessible variable (see [3]).
There are currently few Authentication types in use. The
assignments are
TABLE 2. Current OSPF Authentication types
Type code
____________________________________________________________________
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
8.1, 8.2, and Appendix E of [2].
5.0
The are multiple, interoperable implementations of OSPF
available. This section gives a brief overview of the
implementations that have participated in at least one round
interoperability testing. (For a detailed discussion of
interoperability testing, see Section 7.0 of this report.)
implementations do exist, but because of commercial realities (e.g.,
product is not yet announced) they unfortunately cannot be listed here
The five implementations that have participated in the
interoperability testing are (listed in alphabetical order):
o 3com. This implementation was wholly developed by 3com. It
participated in all three rounds of interoperability testing. It
also the only implementation of OSPF's TOS routing.. The 3
implementation consists of approximately 9000 lines of C code
including comments but excluding user interface and MIB code
Consult Dino Farinacci [dino] for more details
[Moy] [Page 5]
RFC 1246 Experience with OSPF July 1991
o ACC. This implementation is based on the University of Maryland code
It participated in the last two rounds of interoperability testing
It also contains the only implementation of (a precursor to) the
MIB (see Section 3.0 for details), which it uses for monitoring
configuration. The ACC implementation consists of
24,000 lines of C code, including its OSPF MIB code. Consult
Baker [fbaker] for more details
o Proteon. This implementation was wholly developed by Proteon. It
participated in all three rounds of interoperability testing. It
also the only implementation that has a significant amount of
experience (see Section 6.0 for details). The Proteon
consists of approximately 9500 lines of C code, including
but excluding user interface code. Consult John Moy [jmoy] for
details
o Wellfleet. This implementation has participated in all three
of interoperability testing. Consult Jonathan Hsu [jhsu] for
details
o University of Maryland. This implementation was developed wholly
Rob Coltun at the University of Maryland. It has formed the basis
a number of commercial OSPF implementations, and also participated
the latest round of interoperability testing. The University
Maryland implementation consists of approximately 10,000 lines of
code. Consult Rob Coltun [rcoltun] for more details
Note that, as required by the IAB/IESG for Draft Standard status,
are multiple interoperable independent implementations, namely
from 3com, Proteon and the University of Maryland
6.0 Operational
This section discusses operational experience with the OSPF protocol
Version 1 of the OSPF protocol began to be deployed in the Internet
Spring of 1990. The results of this original deployment were reported
the mailing list ospf-tests@seka.cso.uiuc.edu. (Archives of this
list are available from Ross Veach [rrv].) No protocol bugs were
in this first deployment, although several additional features
found to be desirable. These new features were added to the protocol
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
NASA Sciences Internet, BARRNet and OARnet. The dimensions of
three OSPF systems is summarized in the following table
[Moy] [Page 6]
RFC 1246 Experience with OSPF July 1991
TABLE 3. Three operational OSPF
Name Version 1 date Version 2 date #
_____________________________________________________
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
started to deploy OSPF on their corporate network. They have 8 of
routers running OSPF (the 3com implementation), and are planning
cutting over the remaining routers (20 in all). Currently they have
operational routers running OSPF and RIP simultaneously. One
OSPF data to RIP data, and the other RIP data to OSPF data. For
details, contact Dino Farinacci [dino].
6.1
The NASA Science Internet (NSI) is a multiprotocol network,
supporting both DECnet and TCP/IP protocols. NSI's mission is to
reliable high-speed communications to the NASA science community.
NASA Science Internet connects with other national networks
the National Science Foundation's NSFNET, the Department of Energy'
ESnet and the Department of Defense's MILNET. NSI also
international connections to Japan, Australia, New Zealand, Chile
several European countries
For more information on NSI, contact Jeffrey Burgan [jeff] or Milo
[medin].
6.1.1 NSI's OSPF
NSI was one of the initial deployment sites for OSPF Version 1,
deployed the protocol in April 1990. NSI has been running OSPF V2
1/1/91. They currently have 15 routers in their OSPF system.
system is pictured in Figure 1. It consists of a nationwide
of serial lines, with ethernets at hub sites. The numbers associated
interfaces/links in Figure1 are the associated OSPF costs. Note
certain links have been weighted so that they are less preferable
others
Many of NSI's OSPF routers are speaking either RIP and/or EGP as well
OSPF. Routes from these other routing protocols are selectively
[Moy] [Page 7]
RFC 1246 Experience with OSPF July 1991
into their OSPF system as externals. The current number of
externals is 496.
All NSI externals are imported as OSPF type 2 metrics. In addition,
uses the OSPF external route tag to manage the readvertisement
external routes. For example, a route learned at one edge of the
system via EGP can be tagged with the number of the AS from which it
learned. Then, as the OSPF external LSA describing this route is
through the OSPF system, this tagging information is distributed to
the other AS boundary routers. A router on the other edge of the NSI
then say that it wants to readvertise (via EGP) routes learned from
particular AS but not routes learned from another AS. This allows NSI
implement transit policies at the granularity of Autonomous Systems
instead of network numbers, which greatly reduces the network'
configuration burden
NSI has also experimented with OSPF stub areas, in order to
routers having a small amount of memory
6.1.2 NSI - Deployment
NSI ran a couple of experiments after OSPF's deployment to test OSPF'
convergence time in the face of network failures, and to compare
level of routing traffic in OSPF with the level of routing traffic
RIP. These experiments were included in NSI status reports to the
plenary
The first experiment consisted of running a continuous ICMP ping,
then bringing down one of the links in the ping packet's path. They
timed how long it took OSPF to find an alternate path, by noticing
the pings resumed. The result of this experiment is contained in
Medin's "NASA Sciences Internet Report" in [8]. It shows that
interrupted ping resumed in three seconds
The second experiment consisted in analyzing the amount of
protocol traffic that flow over an NSI link. One of the NSI links
installed, but did not have any active users yet. For this reason,
traffic that flowed over the link was routing protocol traffic. The
was instrumented to continuously measure the amount of
consumed, first in the case where RIP was running, and then in the
of where OSPF was running. The result is shown graphically in
Burgan's "NASA Sciences Internet" report in [9]. It shows that
consumes many times less network bandwidth than RIP
[Moy] [Page 8]
RFC 1246 Experience with OSPF July 1991
6.2
BARRNet is the NSFNet regional network in Northern California. At
present time, it serves approximately 80 member sites in an
stretching from Sacramento in the north-east to Monterey in the in
south-west. Sites are connected to the network at speeds from 9.6Kbps
full T1 using Proteon and cisco routers as well as a Xylogics
server. The membership is composed of a mix of university, government
and commercial organizations. BARRNet has interconnections to the
(peering with both T1 and T3 backbones at Stanford University),
(peering at LLNL, with additional multi-homed sites at LBL, SLAC,
NASA Ames), and DDN national networks (peering at the FIX network
NASA Ames), and to the statewide networks of the University
California (peering at U.C. Berkeley) and the California
University system (peering at San Francisco State and Sacramento State).
Topologically, the network consists of fourteen OSPF-speaking
routers, which as a "core", with six of these redundantly connected
a ring. All "core" sites are interconnected via full T1 circuits.
member sites attach as "stub" connections to the "core" sites. The
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
BARRNet was also one of the initial deployment sites for OSPF Version 1,
having deployed the protocol in April 1990. BARRNet has been
OSPF V2 since November 1990. They currently have 14 routers in
OSPF system. The BARRNet OSPF system is pictured in Figure 2.
consists of a collection of T1 serial lines, with ethernets at
sites
Most of BARRNet's OSPF routers are speaking either RIP and/or EGP
well as OSPF. Routes from these other routing protocols are
imported into their OSPF system as externals. A large number of
routes are imported; the current number is1816. The bulk of these
the T1 NSFNet routes, followed by several hundred NSN routes,
60-80 BARRNet routes from the non-OSPF system, and several dozen
ESNet
All external routes are imported into the BARRNet system as
type 1 metrics. In addition, BARRnet, like NSI, uses the OSPF's
route tagging feature to help manage the readvertisement of
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
information. These stub areas all consist of a single LAN. They do
contain any OSPF routers in their interiors
6.2.2 BARRNet - Deployment
Initial deployment of OSPF Version 1 in BARRNet pointed to the need
two new protocol features that were added to OSPF V2, namely
o Addition of the forwarding address to OSPF external LSAs.
eliminated the extra hops that were being taken in BARRNet when
routers BR5 and BR6 were exchanging EGP information with the NSS (
Figure 2). Without the forwarding address feature, that meant
NSFNet traffic handled by routers BR10, BR16 and BR28 was taking
extra hop to get to the NSS
o Addition of stub areas. This was an attempt to get OSPF running
some of the BARRNet routers that had insufficient memory to deal
all of BARRNet's external routes
6.3
OARnet, the Ohio Academic Resources Network, is the regional network
the state of Ohio. It serves the entire higher education community
providing Ohio schools access to colleagues worldwide. The
Supercomputer Center and the NSF Supercomputer Centers are
through OARnet. Libraries, databases, national and
laboratories and research centers are accessible to faculty,
make Ohio schools competitive
OARnet was established in 1987 to provide state-wide access to the
at the Ohio Supercomputer Center in Columbus, Ohio. Since then it
evolved into a network supporting all aspects of higher education
Ohio. A primary goal of OARnet is to facilitate collaborative
and sharing of resources between institutions, including those
the state. OARnet connections are available to Ohio
institutions and corporations engaged in research, product development
or instruction. Colleges, universities, and industries currently
OARnet connections to communicate within the state and with
around the country
OARnet uses the Internet (TCP/IP) and DECNET protocols.
participants using TP/IP protocols are connected to the
Internet, which includes all the major networks open to non-
research. OARnet is also connected to NSFNet, the national research
[Moy] [Page 10]
RFC 1246 Experience with OSPF July 1991
education network sponsored by the National Science Foundation. It
gateways to BITNET, CSNET, CICNet (a network connecting the Big
universities), and the NASA Science Internet
For more information on OARnet, contact Kannan Varadhan [kannan].
6.3.1 OARnet's OSPF
OARnet has been running OSPF Version 1 since October 15, 1990.
currently have 14 routers in their OSPF system. The OARnet OSPF
is pictured in Figure 3.
There are 29 sites connected directly to the OARnet backbone. All 13
OARnet's OSPF routers act as ASBRs. There are 40 OSPF internal routes
OARnet's network, and they import about 120 routes from RIP.
runs EGP on the DMZnet at Columbus, which connects them to CICNet.
router connecting OARnet to DMZnet (OAR1 in Figure 3) runs EGP on
DMZnet side, and OSPF and RIP on the OARnet backbone. No EGP routes
imported into the OSPF system. The OAR1 router is configured to
a default when EGP routes are available. The OAR1 router is the
for routing on OARnet's network, in that it acts as an intermediary
all of OARnet's RIP centric routers
OARnet uses the Event Logging System on its Proteon routers to
traps for "interesting" events related to routing. They have these
sent to an SNMP management station, where the logs are collected
later perusal
6.3.2 OARnet - Deployment
OARnet is monitoring their OSPF system via collection of traps on
SNMP management station. The following is a report on
observations. It has been edited slightly to conform better with
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
flap occasionally. Our observations indicate that the routers bring
links, and adjacencies, on average, in about 2 seconds. Routes
to alternate backup paths instantly. Whole blocks of routes cut over
instant the adjacencies are formed
In contrast to this, our RIP routes would take about 3-6 minutes
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
illustrate the performance of RIP over OSPF. To do this, we selected
host on the farthest point from our workstation, and ran a
ping to it. We would then bring down a primary DS1 circuit, and
the time it took to switch to the fallback route. Following this,
would bring the circuit back up, and study the time it took to re-
to the new path. With RIP, we were unable to fully complete
experiment, because the farthest point was exactly equal to the new (
preferred) primary path, and therefore, RIP would never choose it
it's own, until the path it was currently using failed. With OSPF,
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
o 131.187.36.0 is the 56kb line to Kent State University. Kent also
a DS1 circuit leading into ASP, the Akron Pop. Likewise, UAkron.
has a similar configuration. A roundabout backup path exists
traffic heads up to Cleveland over a couple of DS1 circuits, and
down a 56kb backup path used by another school in the Cleveland area
Some statistical information
1. 09:55:17: SPF.37: new route to Net 131.187.36.5,
type SPF cost 32
2. 09:55:18: SPF.37: new route to Net 131.187.36.6,
type SPF cost 22
3. 09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state , event 9
4. 09:55:21: SPF.37: new route to Net 131.187.36.5,
type SPF cost 31
5. 09:55:22: SPF.37: new route to Net 131.187.36.6,
type SPF cost 21
6. 09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state , event 9
7. 09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state , event 9
8. 09:55:31: SPF.37: new route to Net 131.187.36.5,
type SPF cost 22
9. 09:55:33: SPF.37: new route to Net 131.187.36.5,
type SPF cost 11
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
[Moy] [Page 12]
RFC 1246 Experience with OSPF July 1991
sent via UDP, and gwASP1's routing tables are not fully
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
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
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
the basis of the topological information that we have about
network and the means used to monitor them
o To illustrate the time required to fully synchronize a database,
piece together a few adjacency forming traces...
Please bear in mind that these time stamps are the time stamps on
management station, and are not to be taken as the absolute truth
Things we haven't taken into account are transit times
messages, ordering of events (SNMP traps are sent using UDP),
loss of event reports (recall that an entire synchronization
of gwASP1 on the ASP-CSP link is missing), etc
The trace below corresponds to the Akron router, gwASP1 bring up
link in the previous section. This is as observed on the other end
the line, gwCSP1.
REPORT DATE: 02/26/91 ROUTER: gwcsp
09:55:06: SPF.15: State Change, ifc 131.187.22.6,
new state , 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 , 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 , 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 , event 9
09:55:12: SPF.21: State Change, nbr 131.187.22.5,
new state , event 6
Below, is another trace of the same router restart sequence,
the router is proceeding to bring up other DS1 circuits. Bringing
the first adjacency took about 5 seconds. Subsequent adjacencies
the router less than a second as seen below
REPORT DATE: 02/26/91 ROUTER: gwasp
09:55:20: SPF.15: State Change, ifc 131.187.27.5,
new state , event 1
09:55:20: GW.xxx: Link Up Trap: 09:55:20: SPF.21:
State Change, nbr 131.187.27.6, new state , event 1
09:55:20: SPF.21: State Change, nbr 131.187.27.6,
new state , 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 , event 9
09:55:21: SPF.21: State Change, nbr 131.187.27.6,
new state , event 6
09:55:24: SPF.21: State Change, nbr 131.187.51.6,
new state , event 1
09:55:24: SPF.21: State Change, nbr 131.187.21.5,
new state , 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 , 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 , event 9
09:55:28: SPF.21: State Change, nbr 131.187.21.5,
new state , 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 , 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 , event 9
09:55:29: SPF.21: State Change, nbr 131.187.51.6,
new state , event 6
A transient fault on a DS1 circuit, causes the line to flap.
routers quickly reroute around the flap, and the router itself
about 2 seconds to bring up the adjacency once more
REPORT DATE: 02/26/91 ROUTER: gwasp
14:33:43: GW.xxx: Link Up Trap
14:34:19: SPF.15: State Change, ifc 131.187.22.5,
new state , event 7
14:34:19: GW.xxx: Link Failure Trap
14:34:19: SPF.47: Net 131.187.22.6 now
14:34:36: SPF.15: State Change, ifc 131.187.22.5,
new state , 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 , event 1
14:34:46: SPF.21: State Change, nbr 131.187.22.6,
new state , 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 , event 9
14:34:47: SPF.21: State Change, nbr 131.187.22.6,
new state , event 6
o On the amount of time it takes for a router to restart, and
fully synchronized. Taking the logs in the previous instance,
notice that the CSP-ASP link comes up at 9:55:06. The last link
observed to be up at 9:55:29, which is less than a minute
o On the RIP equivalent of the tests, it took us 3 minutes to
to the slower speed fallback route, and we lost countless
packets. The routes never cutover to the higher speed paths
available, and we waited well over 30 minutes watching this
wondering why. Unfortu- nately, at this point, we seem to have
the RIP statistics
On the OSPF version, we have...
{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
[...]
icmp seq=10 ttl(255-ttl)=54(201). time=20
|| T1
icmp seq=14 ttl(255-ttl)=54(201). time=180
icmp seq=15 ttl(255-ttl)=54(201). time=60
[...]
icmp seq=38 ttl(255-ttl)=8(247). time=1300
icmp seq=39 ttl(255-ttl)=54(201). time=820
|| Tl
icmp seq=40 ttl(255-ttl)=54(201). time=20
icmp seq=41 ttl(255-ttl)=54(201). time=20
131.187.25.6 PING
51 packets transmitted, 48 packets received, 5% packet
round-trip (ms) min/avg/max = 20/277/1300
6.4 Features exercised during operational
In operational environments, all basic mechanisms of the OSPF
have been exercised. These mechanisms include
o Designated Router election. There have been operational
have as many as 8 OSPF routers attached to a single
network
o Database synchronization. This includes OSPF's adjacency bringup
reliable flooding procedures. Large operational OSPF link
databases (e.g., BARRNet) have provided a thorough test of
mechanisms
o Flushing advertisements. The procedure for flushing old
unreachable advertisements (the MaxAge procedure) has been
operationally. It is interesting to note that flushing
advertisements does occur more during interoperability
(because of the constant restart- ing of routers) that it
operationally. For example, in a week of BARRNet statistics, 9650
advertisements were flushed, while 688,278 new advertisements
flooded
o Import of external routes. All options of external LSAs have
tested operationally: type 1 metrics, type 2 metrics,
addresses and the external route tag
o Authentication. The OSPF authentication procedure has been
operationally
[Moy] [Page 16]
RFC 1246 Experience with OSPF July 1991
o Equal-cost multipath. Operational deployments have
topologies with equal-cost, redundant paths
o Stub areas. These have been deployed both in BARRNet and NSI
6.5 Limitations of operational
The following things have not been tested in an operational environment
o Multi-vendor deployments. So far all deployments have used a
implementation. However, extensive interoperability testing of
has been done (see Section 7.0 of this report).
o Regular OSPF areas. These have however been tested in all
rounds of the OSPF interoperability testing
o Virtual links. These have however been tested in OSPF'
interoperability testing
o Non-broadcast networks. However, OSPF interoperability testing
been performed over X.25 networks
o TOS routing. However, this has been tested in OSPF's
testing
6.6
All basic features of the OSPF protocol have been exercised. Very
OSPF link state databases (e.g., BARRNet's OSPF system) have
deployed, providing a thorough test of OSPF's database
mechanisms. No OSPF protocol problems have been found in
deployments
Most of the hassles in operation deployments has to do with the OSPF/
interchange. Many of these issues have been ironed out on the ospf-
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
There have been three separate OSPF V2 interoperability
sessions. Five separate implementations have participated in at
one session: implementations from the companies 3com, ACC, Proteon
Wellfleet, and the publicly available implementation from the
of Maryland
[Moy] [Page 17]
RFC 1246 Experience with OSPF July 1991
Each of the testing sessions is described in a succeeding section.
each session, the participants are identified, and the
topologies are described along with the particular protocol
that were exercised. Any protocol problems that were encountered
the testing are also described. In addition, for the second and
rounds testing reports were sent to the ospf mailing lists.
reports are reproduced in this document
There is quite a bit of commonality in the features that have
tested from session to session. There are several reasons for
commonality. First, in each testing session an attempt has been made
increase the size of the OSPF system under test. For example, the
of external routes imported has doubled each session. Secondly,
interoperability sessions have been debugging sessions as well
protocol sessions. Many things tested in the third round were to ver
ify that implementations had successfully fixed problems found
earlier sessions. A brief overview of the testing session is
in the following table
TABLE 4. OSPF interoperability testing at a glance
Site Week Routers Externals
_____________________________________________________________________________
Proteon 9/25/90 6 20-30 3com, Proteon,
SURAnet 12/17/90 10 96 3com, ACC, Proteon,
3com 2/4/91 16 400 3com, ACC, Proteon, Wellfleet,
For more information on the interoperability testing, the
people can be contacted: Fred Baker [fbaker], Rob Coltun [rcoltun],
Farinacci [dino], Jonathan Hsu [jhsu], John Moy [jmoy], and
Streilein [bstreile].
7.1 Testing
In the interoperability tests, the routers have been
using ethernet, serial lines (PPP and proprietary), X.25 and 802.5
ring. Monitoring of the routers has been done through
terminals (either directly or via telnet) to the router consoles.
implementation has a different user interface, which makes
somewhat difficult. As explained earlier in this document, there is
an OSPF MIB, which in the future will enable a common
interface to all implementations
In general, each implementation has an error logging capability,
this is often how problems are discovered. LAN protocol analyzers
[Moy] [Page 18]
RFC 1246 Experience with OSPF July 1991
also used to capture OSPF protocol packet exchanges that are
problems. These packet traces are available for analysis either
of after the testing sessions
Verification of routing was done through visual inspection
implementations' routing table and link state databases (via the
interface), and through network debugging tools such as "ping"
"traceroute".
7.2 First round (Proteon, 9/25/90 - 9/29/90)
The first round of OSPF protocol testing took place at Proteon Inc.'
Westborough facility, the week of September 25, 1990.
implementations participated, from the vendors 3com, Proteon
Wellfleet
There were two 3com routers, two Wellfleet routers and two
routers available for testing. These routers were interconnected
ethernets and serial lines. External routes were imported from
Proteon company internet. In addition, during off hours we were able
connect the routers under test to the Proteon company internet,
one fairly large OSPF system
The testing at Proteon proceeded as follows
o All routers were connected to a single ethernet. Then, as
were taken up and down, the Designated Router election algorithm
the Database Description process were tested. Also OSPF's
flooding algorithm was tested in this configuration
o Twenty to thirty external routes were imported into the OSPF
by a Proteon router (which was simultaneously running RIP). It
then verified that these external routes were installed into
router's routing tables
o One of the 3com routers was configured to originate an OSPF
route. This tested OSPF default route processing, and also tested
behavior of the system when multiple routers were importing
routes
o The OSPF system was split into areas. Both regular OSPF areas (non
stub) and stub areas were tested
o The six routers under test were connected to the Proteon
internet (which was also running OSPF), forming an OSPF system
eighteen routers. This configuration was shortlived, due to
disagreement between the 3com and Proteon routers concerning how
[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
maps of the testing configurations can be reproduced for this document
7.2.1 Problems found in the First round
A couple of OSPF protocol/specification problems were uncovered in
first round of testing. First, it was noticed that there was a
in the Database Description process where concurrently flooded
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
the Network Mask field should be set in external LSAs that
advertising the DefaultDestination. This was a minor problem, but
difficulties because of assumptions made in one implementation on
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'
College Park facility, the week of December 12, 1990.
implementations participated, from the vendors 3com, ACC, Proteon
Wellfleet
There were two 3com routers, two ACC routers, two Wellfleet routers
four Proteon routers available for testing. These routers
interconnected with ethernets, serial lines and token rings.
routes were imported from SURAnet by one of the Proteon routers
The testing at SURAnet proceeded as follows. Initially nine routers
configured as a single backbone area, with six of the routers
to a single ethernet. This is pictured in Figure 4. In
configuration, the Designated Router transition and
synchronization process were tested. Ninety-six external routes
imported from SURAnet to stress the flooding algorithm. By
the router that was importing the routes, the flushing of
from the routing domain was tested. Additionally, variable-
subnets and OSPF's optional TOS routing capability were tested in
configuration
Next the routers were configured into four separate OSPF areas,
each area directly connected to the OSPF backbone (which was a
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
to a non-backbone area. Also tested was the case where a single
was both an area border router and an AS boundary router
For more details of the testing, see the "Official report of the
Round Testing" listed below
7.3.1 Official report of the Second round
The following report was sent to the ospf, ospf-tests, and router
requirements mailing lists after the second round of
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
(ACC), Proteon, 3Com, and Wellfleet. A press conference and
was provided for 3 different data communication
representatives
Each vendor provided at least 2 routers. Each vendor had a
connected to a common Ethernet. This Ethernet was configured as the
backbone area. The rest of the routers were attached to the
backbone routers via Ethernet, Token Ring, proprietary serial line,
serial line, and X.25 type media. The following test scenarios
performed and completed in the following order
o Intra-area routing. All routers were configured to reside in
backbone area. Designated Router election was performed
number of times so each vendor could be designated router for
period of time. Packet data was captured on a Sniffer for
observation
o Variable Length Subnet Masks. Some of the serial lines in
configuration were configured to be on the same IP network but
different subnet masks. It was observed that all routers
routes for the different length subnets
o Import SURAnet routes. The Proteon router was listening for
routes generated by the SURAnet routers. These routes were
into our OSPF test system. 96 external link state advertisements
generated as a result. Many scaling type implementation
surfaced for each vendor during this exercise
o Type of Service generation. While the test setup was still
as a single area, the 3Com router generated Type of Service
[Moy] [Page 21]
RFC 1246 Experience with OSPF July 1991
state advertisements. It was observed how the other
implementations reacted to it. Some problems were found
o Inter-area routing. Multiple areas were configured. Common non
backbone areas were shared by Proteon and Wellfleet and by ACC
3Com. It was observed that the correct Intra-area and Inter-
routes appeared in each router's routing table. At this point in
test setup, the Proteon router regenerated the 96 SURAnet routes
the configuration. It was observed that the routes were learned
propagated over area boundaries. Some problems occur at this point
More emphasis on this scenario will occur at the next round
testing
o OSPF over X.25. A point-to-point link was connected between
Proteon router and the 3Com router. The X.25 packet level
configured to run over the link. OSPF was enabled over the link
verify that multi-vendor OSPF over X.25 was performed. Both of
routers were in the same area
o MaxAge advertisements. Link state advertisements were flushed
the routing domain using the MaxAge procedure. We verified that
routers removed the advertisements from their databases, after
were properly acknowledged by the flooding procedure. Some
were found in this test, although not nearly as many as in the
round of testing
Each vendor agreed that this sort of testing was extremely valuable
that it should occur again. 3Com has offered for the third round
testing to occur in Santa Clara sometime in February. 3Com
encourage other OSPF implementations to join in the testing. Items
will be tested are
o Intra-area routing with loops (as well as equal-cost multipath).
o Inter-area testing including Stub and Transit area support, with
Intra-area and Inter-area loops
o Virtual link testing in the looped Inter-area configuration
o RIP/OSPF route interchange including testing forwarding
capability in external link state advertisements
o EGP/OSPF router interchange including the use of the route tag
in external link state advertisements
o More than two routers connected to an X.25 network. We would like
test OSPF's non-broadcast multi-access capabilities by attaching
than two vendor's routers to an X.25 packet switch
[Moy] [Page 22]
RFC 1246 Experience with OSPF July 1991
o Several vendors running OSPF and RIP simultaneously. This
further test the OSPF/RIP interactions
o Test processing of links with cost LSInfinity. These links should
treated as unreachable
Furthermore, we hope that in future rounds of testing an OSPF MIB
allow us to also use a network management station to gather test data
In summary, the stability of implementations were better this time
so than the first round of testing. No problems with the protocol
were encountered. The exchange of ideas and the cooperation
implementors that occurred during this test effort, continues the
that OSPF is truly an open protocol
7.3.2 Problems found in the Second round
No problems were found in the OSPF protocol during the second round
testing
7.4 Third round (3com, 2/4/91 - 2/8/91)
The third round of OSPF protocol testing took place at 3com's
Clara facility, the week of February 4, 1991. Five
participated, from the vendors 3com, ACC, Proteon and Wellfleet and
publicly available University of Maryland implementation (running on
SUN workstation).
There were five 3com routers, four ACC routers, three Wellfleet routers
three Proteon routers and the UMD Sun workstation available for
(giving a total of 16 routers available). These routers
interconnected with ethernets, serial lines and X.25. External
were imported from BARRNet by one of the 3com routers
The initial testing configuration is shown in Figure 5. Three areas
configured, along with a non-contiguous backbone. The backbone was
joined by configuring two virtual links. In this configuration
following OSPF functionality was tested: inter-area routing and
links
The system was then reconfigured so that twelve of the routers
connected to a single ethernet. This configuration is pictured in
6. By bringing routers up and down, this configuration tested
Router election, database synchronization and reliable flooding. To
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
The following report was sent to the ospf, ospf-tests, and router
requirements mailing lists after the third round of
tests
The third round of OSPF interoperability testing was held at 3
Corporation in Santa Clara the week of February 4-8. Four router
came to the testing: 3com, ACC, Proteon and Wellfleet. In addition,
Coltun brought the University of Maryland implementation, which was
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,
ACC routers, three Proteon routers, three Wellfleet routers and Rob'
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
physically disconnected backbone. The backbone was then
through configuration of several virtual links. These tests
the generation and processing of summary link advertisements, as
as the operation of virtual links
o We connected multiple routers to an X.25 packet switch,
OSPF's non-broadcast network capability. OSPF was successfully
over the X.25 network, using routers that were both DR eligible
DR ineligible. Some problems were encountered, but they all
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
ethernet, and then treated the ethernet as a non-broadcast network
This allowed us to connect Rob's SUN into the rest of the
domain without installing the IP multicast modifications to the
kernel. It also further tested the OSPF's non-broadcast
capability
o We then reconfigured the OSPF system so that all but three of
routers were connected to a single ethernet. This tested
Designated Router functionality (12 routers were synchronizing
the DR). We then also tested the DR election algorithm,
selectively restarting the DR, or sometimes both the DR and
Backup DR. This also tested OSPF's Database Description process
[Moy] [Page 24]
RFC 1246 Experience with OSPF July 1991
o In this configuration, we then imported 400 external routes
BARRNet (one of the 3com routers ran both OSPF and EGP).
problems were encountered in implementations' buffer
strategies, and problems were also found in the way
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
be verified in OSPF Hellos received over virtual links
o The specification should say that on multi-access networks
are identified by their IP address, and on point-to-point
and virtual links by their OSPF Router ID. This eliminates
when, for example, a router is restarted and comes up with the
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
import the BARRNet routes
7.4.2 Problems found in the Third round
A couple of specification/protocol problems were found in the
round of interoperability testing. First, it was noticed that
specification did not specify the setting of the Network Mask field
Hellos sent over virtual links. This caused some initial difficulty
bringing up virtual links between routers belonging to
vendors. Secondly, it was noticed that the specification was not
enough in defining how OSPF neighbors are identified on multi-
networks. This caused difficulties in one implementation when
vendor's router was restarted with the same IP address but a
OSPF Router ID. This is discussed more fully in the above "
Report of the Third Round Testing".
7.5 Overall: Features
All significant protocol features and mechanisms have been tested in
three rounds of interoperability testing. In particular, the
basic pieces of the protocol have been tested
o Designated Router election. With as many as thirteen routers
to a single LAN, the election of Backup Designated Router
Designated router was verified by bringing routers up and down
[Moy] [Page 25]
RFC 1246 Experience with OSPF July 1991
singly and in pairs
o Adjacency bringup. The Database Description process was verified
with databases having over 400 LSAs. Adjacency bringup was
verified in times when flooding was taking place simultaneously
o Reliable flooding. It was verified that OSPF's flooding
maintains database synchronization, both in the presence of loops
the topology, and with large databases (over 400 LSAs).
o Flushing advertisements from routing domain. OSPF's procedure
flushing old or unreachable LSAs from the routing domain
verified, both in the presence of topology loops and with many
being flushed at once. This is also referred to as OSPF's
procedure
o OSPF routing hierarchy. The OSPF four level routing hierarchy
intra-area, inter-area. type 1 externals and type 2 externals
tested
o Import of external routing information. The importing of
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
2 metrics and forwarding addresses.escribe all options. In addition
test setups were utilized having AS boundary routers both internal
non-backbone areas and also being simultaneously area border routers
o Running protocol over various network types. In the test setups,
has been run over ethernet, point-to-point serial lines (both PPP
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-
network. Two separate situations were tested: when all
attached to the non-broadcast network were DR-eligible, and when
some of them were
o Authentication. OSPF's authentication procedure was tested for
two current authentication types
o Equal-cost multipath. Much of the testing was done in
with redundant paths, and equal-cost multipath was verified
examination of implementations' routing tables
o Variable-length subnet masks. It was verified that
paid attention to the network mask field present in OSPF LSAs
[Moy] [Page 26]
RFC 1246 Experience with OSPF July 1991
Testing was also performed on the following pieces of OSPF's
functionality
o Extent of advertisements. It was verified that all
except external LSAs were flooded throughout a single area only
o Inter-area routing. The generation and processing of summary
LSAs was tested. Also tested were configurations having multiple
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-
routers was tested, by configuring TOS-specific metrics in the
implementation (3com) supporting TOS routing
o Stub areas. OSPF's stub area functionality was verified
7.6 Testing
The interoperability testing has proven to be very valuable. Many
were found (and fixed) in the implementations. Some protocol
were found (and fixed), and gray areas of the specification were
up. Implementations have also been "bullet-proofed" in order to
with the unexpected behavior of other implementations. All
in the testing now understand the maxim "be conservative in what
generate, and liberal in what you accept" (if they didn't already).
7.7 Future
The one thing that has gone mostly untested at the
sessions is the interaction between OSPF and other routing
(such as RIP and EGP). Each interoperability session generally had
router running multiple routing protocols in order to import
routing information into the OSPF system. However,
running multiple routing protocols between different vendors'
has not been tested
Each vendor has developed a slightly different architecture for
exchange of routing information between differing routing protocols.
the OSPF field testing has also shown, this exchange of
information is an area of ongoing work and a candidate for
standardization
[Moy] [Page 27]
RFC 1246 Experience with OSPF July 1991
8.0
The OSPF protocol has been simulated by the Distributed Systems
Group at the University of Maryland Baltimore County (UMBC). The
principal investigators for the OSPF simulation project are Dr
Deepinder P. Sidhu of UMBC and Rob Coltun. They have been aided by
graduate students: S. Abdallah, T. Fu and R. Nair. This
attempts to summarize their simulation setup and results. For
information, contact the Distributed Systems Research Group at
following address
Dr. Deepinder P.
Department of Computer
University of Maryland Baltimore
Baltimore, MD 21228
email: sidhu@umbc3.umbc.
A demo was given of their OSPF simulation at the March 4-8, 1991 IETF
St. Louis. Details of the demo should be available in the
proceedings
8.1 Simulator
The Distributed System Research Group uses a significantly
version of the MIT network simulator. The simulator is event driven,
contains support for both point-to-point networks and ethernet links.
can simulate characteristics of both packet switches and hosts, and
simulate internet behavior under various types of data traffic
(e.g., Poisson, normal, exponential and uniform distributions).
latter ability could be used, for example, to simulate how a
protocol works in a congested internet. Specific network topologies
be input into the simulator, or pseudo-random network topologies can
generated. Packet loss rates can also be simulated
To simulate OSPF, Rob Coltun's OSPF implementation was incorporated
the simulator, essentially unchanged
The output of the simulator can be displayed in a graphical manner (
uses X windows). Any variable in the implementation under test can
monitored. In addition, statistical reports can later be produced
logging files produced during the simulation runs
[Moy] [Page 28]
RFC 1246 Experience with OSPF July 1991
8.2 Simulation
The OSPF simulation has been run using the following topologies
o The two sample topologies in the OSPF specification (Figure 2
Figure 6 in [2]). The first of these topologies shows an
System without areas, the second the same AS with three areas and
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
serial lines, pseudo randomly generated
In these topologies, the correctness of the OSPF
synchronization was verified. This was done through examination of
nodes' OSPF link state databases and the nodes' routing tables.
implementation of multiple OSPF areas was also tested. Also,
convergence time was analyzed as a function of the network components
link speeds
Also, some formal analysis of the OSPF protocol was undertaken.
neighbor and interface state machines were analyzed. In addition,
Designated Router election algorithm was verified for certain sets
initial conditions
9.0 Reference
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
Base", RFC 1248, July 1991.
[4] Reynolds, J. and Postel, J., "Assigned Numbers', RFC1060,
1990.
[5] Corporation for National Research Initiatives, "Proceedings of
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
Sixteenth Internet Engineering Task Force", Florida
University, February 6-9, 1990.
[7] Gardner, M., et al., "Type-of-service routing: modeling
simulation," Report 6364, BBN Communications Corporation,
1987.
[8] Corporation for National Research Initiatives, "Proceedings of
Seventeenth Internet Engineering Task Force",
Supercomputing Center, May 1-4, 1990.
[9] Corporation for National Research Initiatives, "Proceedings of
Eighteenth Internet Engineering Task Force", University of
Columbia, July 30-August 3, 1990.
10.0
The following people have contributed information to this report and
be contacted for further information
TABLE 5. People references in this
Tag Name Affiliation
__________________________________________________________________________________
bstreile William Streilein Wellfleet bstreile@wellfleet.
dino Dino Farinacci 3com dino@buckeye.esd.3com.
fbaker Fred Baker ACC fbaker@acc.
jeff Jeffrey Burgan Sterling Software jeff@nsipo.nasa.
jhsu 