rfc1246.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   code. Consult Rob Coltun [rcoltun] for more details.

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 [e-mail]. (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:

o  Addition of the forwarding address to OSPF external LSAs. This
   eliminated the extra hops that were being taken in BARRNet when only
   routers BR5 and BR6 were exchanging EGP information with the NSS (see
   Figure 2). Without the forwarding address feature, that meant that
   NSFNet traffic handled by routers BR10, BR16 and BR28 was taking an
   extra hop to get to the NSS.

o  Addition of stub areas. This was an attempt to get OSPF running on
   some of the BARRNet routers that had insufficient memory to deal with
   all of BARRNet's external routes.



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