rfc1246.txt

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

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


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


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

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

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

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

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

o  There must be significant operational experience. This must include
   running in a moderate number routers configured in a moderately
   complex topology, and must be part of the operational Internet. All
   significant features of the protocol must be exercised. In the case
   of an Interior Gateway Protocol (IGP), both interior and exterior
   routes must be carried (unless another mechanism is provided for the
   exterior routes). In the case of 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 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,
[e-mail], 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, [e-mail], 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:


o  11 define the above Group and Tables

o  10 define the Entry in a Table

o  7 are Counters

o  6 are Gauges

o  68 objects mandated by the OSPF Version 2 Specification

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


o  3com. This implementation was wholly developed by 3com. It has
   participated in all three rounds of interoperability testing. It is
   also the only implementation of OSPF's TOS routing..  The 3com
   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 OSPF
   MIB (see Section 3.0 for details), which it uses for monitoring and
   configuration. The ACC implementation consists of approximately
   24,000 lines of C code, including its OSPF MIB code. Consult Fred
   Baker [fbaker] for more details.

o  Proteon. This implementation was wholly developed by Proteon. It has
   participated in all three rounds of interoperability testing. It is
   also the only implementation that has a significant amount of field
   experience (see Section 6.0 for details). The Proteon implementation
   consists of approximately 9500 lines of C code, including comments
   but excluding user interface code.  Consult John Moy [jmoy] for more
   details.

o  Wellfleet. This implementation has participated in all three rounds
   of interoperability testing.  Consult Jonathan Hsu [jhsu] for more
   details.

o  University of Maryland. This implementation was developed wholly by
   Rob Coltun at the University of Maryland. It has formed the basis for
   a number of commercial OSPF implementations, and also participated in
   the latest round of interoperability testing. The University of
   Maryland implementation consists of approximately 10,000 lines of C