Network Working Group J. Moy, Editor Request for Comments: 1246 July 1991 Experience with the OSPF protocol Status of this Memo This memo provides information for the Internet community. It does not specify any Internet standard. Distribution of this memo is unlimited. Abstract This is the second of two reports on the OSPF protocol. These reports are required by the IAB/IESG in order for an Internet routing protocol to advance to Draft Standard Status. OSPF is a TCP/IP routing protocol, designed to be used internal to an Autonomous System (in other words, OSPF is an Interior Gateway Protocol). OSPF is currently designated as a Proposed Standard. Version 1 of the OSPF protocol was published in RFC 1131. Since then OSPF version 2 has been developed. Version 2 has been documented in RFC 1247. The changes between version 1 and version 2 of the OSPF protocol are explained in Appendix F of RFC 1247. It is OSPF Version 2 that is the subject of this report. This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. It also presents a summary of the OSPF Management Information Base (MIB), and a summary of OSPF authentication mechanism. Please send comments to ospf@trantor.umd.edu. 1.0 Introduction This document addresses, for OSPF V2, the requirements set forth by the IAB/IESG for an Internet routing protocol to advance to Draft Standard state. This requirements are briefly summarized below. The remaining sections of this report document how OSPF V2 satisfies these requirements: [Moy] [Page 1] RFC 1246 Experience with OSPF July 1991 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, ospf@trantor.umd.edu, where discussions of protocol features and operation are held. The OSPF Working Group also meets during the quarterly Internet Engineering Task Force conferences. Reports of these meeting are published in the IETF's Proceedings. In addition, two reports on the OSPF protocol have been presented to the IETF plenary (see "Everything You Ever Wanted to Know about OSPFIGP" in [5] and "OSPF Update" in [6]). The OSPF protocol began undergoing field trials in Spring of 1990. A mailing list, ospf-tests@seka.cso.uiuc.edu, was formed to discuss how the field trials were proceeding. This mailing list is maintained by Ross Veach of the University of Illinois [rrv]. Archives of this list are also available. There has been quite a bit of discussion on the list concerning OSPF/RIP/EGP interaction. A OSPF V2 Management Information Base has also been developed and published in [3]. For more information, see Section 3.0 of this report. There is a free implementation of OSPF available from the University of Maryland. This implementation was written by Rob Coltun [rcoltun]. Contact Rob for details. 3.0 MIB An OSPF Management Information Base has been published in RFC 1248 [3]. The MIB was written by Rob Coltun [rcoltun] and Fred Baker [fbaker]. The OSPF MIB appears on the mgmt subtree as SMI standard-mib 13. The OSPF MIB was originally developed by Rob Coltun of the University of Maryland, under contract to Advanced Computer Communications. A subset of his proposal was implemented to facilitate their development, and represents operational experience of a sort. The MIB consists of a general variables group and ten tables: TABLE 1. OSPF MIB Organization [Moy] [Page 3] RFC 1246 Experience with OSPF July 1991 Group Name Description ________________________________________________________________ ospfGeneralGroup General Global Variables ospfAreaTable Area Descriptions ospfStubAreaTable Default Metrics, by Type of Service ospfLsdbTable Link State Database ospfAreaRangeTable Address Range Specifications ospfHostTable Directly connected Hosts ospfIfTable OSPF Interface Variables ospfIfMetricTable Interface Metrics, by Type of Service ospfVirtIfTable Virtual Links ospfNbrTable (Non-virtual) OSPF Neighbors ospfVirtNbrTable Virtual OSPF Neighbors As MIBs go, the OSPF MIB is quite large; 105 objects. The following are some statistics describing the distribution of the MIB's variables: 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 (iana@isi.edu) > 255 Available for local (per-AS) definition. For more information on OSPF's authentication procedures, see Sections 8.1, 8.2, and Appendix E of [2]. 5.0 Implementations The are multiple, interoperable implementations of OSPF currently available. This section gives a brief overview of the five implementations that have participated in at least one round of interoperability testing. (For a detailed discussion of OSPF interoperability testing, see Section 7.0 of this report.) Other implementations do exist, but because of commercial realities (e.g., the product is not yet announced) they unfortunately cannot be listed here. The five implementations that have participated in the OSPF interoperability testing are (listed in alphabetical order): 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 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 ospf-tests@seka.cso.uiuc.edu. (Archives of this mailing list are available from Ross Veach [rrv].) No protocol bugs were found in this first deployment, although several additional features were found to be desirable. These new features were added to the protocol in OSPF Version 2. The OSPF protocol is now deployed in a number of places in the Internet. In this section we focus on three highly visible systems, namely the NASA Sciences Internet, BARRNet and OARnet. The dimensions of these three OSPF systems is summarized in the following table: [Moy] [Page 6] RFC 1246 Experience with OSPF July 1991 TABLE 3. Three operational OSPF deployments Name Version 1 date Version 2 date # routers _____________________________________________________ NSI 4/13/90 1/1/91 15 BARRNet 4/90 11/90 14 OARnet 10/15/90 not yet 13 All the above deployments are using the Proteon OSPF implementation. There is one other deployment worth mentioning in this context. 3com has started to deploy OSPF on their corporate network. They have 8 of their routers running OSPF (the 3com implementation), and are planning on cutting over the remaining routers (20 in all). Currently they have two operational routers running OSPF and RIP simultaneously. One converts OSPF data to RIP data, and the other RIP data to OSPF data. For more details, contact Dino Farinacci [dino]. 6.1 NSI The NASA Science Internet (NSI) is a multiprotocol network, currently supporting both DECnet and TCP/IP protocols. NSI's mission is to provide reliable high-speed communications to the NASA science community. The NASA Science Internet connects with other national networks including the National Science Foundation's NSFNET, the Department of Energy's ESnet and the Department of Defense's MILNET. NSI also has international connections to Japan, Australia, New Zealand, Chile and several European countries. For more information on NSI, contact Jeffrey Burgan [jeff] or Milo Medin [medin]. 6.1.1 NSI's OSPF system NSI was one of the initial deployment sites for OSPF Version 1, having deployed the protocol in April 1990. NSI has been running OSPF V2 since 1/1/91. They currently have 15 routers in their OSPF system. This system is pictured in Figure 1. It consists of a nationwide collection of serial lines, with ethernets at hub sites. The numbers associated to interfaces/links in Figure1 are the associated OSPF costs. Note that certain links have been weighted so that they are less preferable than others. Many of NSI's OSPF routers are speaking either RIP and/or EGP as well as OSPF. Routes from these other routing protocols are selectively imported [Moy] [Page 7] RFC 1246 Experience with OSPF July 1991 into their OSPF system as externals. The current number of imported externals is 496. All NSI externals are imported as OSPF type 2 metrics. In addition, NSI uses the OSPF external route tag to manage the readvertisement of external routes. For example, a route learned at one edge of the NSI system via EGP can be tagged with the number of the AS from which it was learned. Then, as the OSPF external LSA describing this route is flooded through the OSPF system, this tagging information is distributed to all the other AS boundary routers. A router on the other ed