Home Articles FAQs XREF Games Software Instant Books BBS About FOLDOC RFCs Feedback Sitemap

Request For Comments - RFC2329

You are here: irt.org | RFCs | RFC2329 [ previous next ]

NetworkWorkingGroup  J. Moy
Requestfor Comments: 2329     Ascend Communications, Inc.
Category: Informational      April 1998

      OSPF Standardization Report

Status of this Memo

    This memo provides information for the Internet community.It does
    notspecifyan Internet standard ofany kind.  Distributionof this
    memo is unlimited.

Copyright Notice

    Copyright (C) The Internet Society (1998).All Rights Reserved.


    This memo documentshow therequirements for advancing a routing
    protocol toFull Standard, set out in [Ref2], have been metfor

    Please sendcomments to ospf@gated.cornell.edu.

Table of Contents

    1     Introduction ........................................... 2
    2     Modifications since Draft Standardstatus .............. 3
    2.1     Point-to-MultiPoint interface .......................... 4
    2.2     Cryptographic Authentication ........................... 5
    3     Updated implementation anddeployment experience ....... 5
    4     Protocol Security ...................................... 7
     References............................................. 8
     Security Considerations ................................ 8
     Author's Address ....................................... 8
     Full Copyright Statement ............................... 9

Moy     Informational[Page 1]

RFC 2329      OSPF Standardization Report      April 1998

1.  Introduction

    OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
    protocol documentedin [Ref8]. OSPFis a link-staterouting
    protocol.  It is designed to be runinternal to a single Autonomous
    System.  Each OSPF router maintainsan identical database describing
    theAutonomous System's topology.  From this database, a routing
    table is calculatedby constructinga shortest-pathtree. OSPF
    features include the following:

    oOSPF responds quickly to topology changes, expending a minimum
of network bandwidth inthe process.

    oSupportfor CIDR addressing.

    oOSPF routing exchanges can be authenticated, providing routing

    oEqual-cost multipath.

    oAn arearoutingcapability is provided,enabling an Autonomous
system to be split intoa two level hierarchy to further reduce
the amount of routing protocol traffic.

    oOSPF allows import of external routing information intothe
Autonomous System, including a tagging feature that canbe
exploited to exchange extra informationat the AS boundary (see

    An analysisof OSPFtogether with amore detailed description of
    OSPF features was originally provided in [Ref6], asa part of
    promoting OSPF to Draft Standard status. The analysis of OSPF
    remains unchanged. Two additional major features have been developed
    forOSPF since the protocolachieved Draft Standardstatus:the
    Point-to-MultiPointinterface and Cryptographic Authentication.
    These features are described in Sections 2.1 and 2.2 respectively of
    this memo.

    TheOSPF MIB is documented in [Ref4]. It iscurrently at Draft
    Standard status.

Moy     Informational[Page 2]

RFC 2329      OSPF Standardization Report      April 1998

2.  Modifications sinceDraft Standard status

    OSPF becamea DraftStandard with the release of RFC 1583 [Ref3].
    Implementations of the new specification in[Ref8] are backward-
    compatible with RFC1583. The differences between the two documents
    aredescribed in the Appendix Gs of[Ref1] and [Ref8]. These
    differencesare listed briefly below. Two major features were also
    added, the Point-to-MultiPoint interface and Cryptographic
    Authentication, which are describedin separate sections.

    oConfiguration requirements for OSPF area address rangeshave
been relaxed toallow greater flexibility in area assignment.
See Section G.3of [Ref1] for details.

    oThe OSPF flooding algorithm wasmodified to a) improve database
convergence in networkswith low speed links b)resolvea
problemwhere unnecessary LSA retransmissions could occur as a
result of differing clock granularities, c) remove race
conditions between the floodingof MaxAge LSAs and the Database
Exchange process, d) clarify the use ofthe MinLSArrival
constant, and e) rate-limit theresponse to less recentLSAs
received via flooding.See Sections G.4 and G.5 of [Ref1] and
SectionG.1 of [Ref8] for details.

    oTo resolve the long-standing confusion regarding representation
of point-to-point linksin OSPF, the specification now
optionally allows advertisementof a stub link to a point-to-
point link's subnet, ala RIP. See Section G.6 of [Ref1].

    oSeveralproblems involving advertising the sameexternal route
from multiple areas were found and fixed, as described in
SectionG.7 of [Ref1] and Section G.2 of [Ref8].  Without the
fixes, persistent routing loopscould form in certain such
configurations.Note that one of the fixes was not backward-
compatible, in that mixing routers implementingthe fixes with
those implementing justRFC 1583 could cause loops not present
in an RFC 1583-only configuration. Thiscaused an
RFC1583Compatibility global configuration parameter to be added,
as described inSectionC.1 of [Ref1].

Moy     Informational[Page 3]

RFC 2329      OSPF Standardization Report      April 1998

    oIn order to deal with high delay links,retransmissionsof
initialDatabase Description packets nolonger reset anOSPF

    oIn order to detect linkMTU mismatches,which can causeproblems
both inIP forwarding and in the OSPF routing protocol itself,
MTU wasadded to OSPF'sDatabase Description packets.
Neighboring routers refuse to bring up an OSPF adjacency unless
they agree on their common link's MTU.

    oThe TOSroutingoption was deleted fromOSPF. However, for
backward compatibility the formats of OSPF's various LSAs remain
unchanged, maintaining the ability to specify TOS metrics in
router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-

    oOSPF's routing table lookup algorithm was changed to reflect
currentpractice. The "best match" routing table entry is now
always selectedto be the one providingthe most specific
(longest) match. See Section G.4 of [Ref8] for details.

    2.1.  Point-to-MultiPoint interface

The Point-to-MultiPointinterface was added as an alternative to
OSPF's NBMA interface when running OSPFover non-broadcast
subnets. Unlikethe NBMA interface, Point-to-MultiPointdoes not
requirefull mesh connectivity over thenon-broadcast subnet.
Point-to-MultiPoint is less efficient than NBMA, but iseasier
to configure (in fact, it can be self-configuring) and is more
robust than NBMA, tolerating all failures within the non-
broadcast subnet.  For more informationon the Point-to-
MultiPoint interface, see Section G.2 of [Ref1].

There are at least six independent implementations of the
Point-to-MultiPoint interface. Interoperabilityhas been
demonstrated between atleast two pairsof implementations:
between3com and Bay Networks, and between cisco and Cascade.

Moy     Informational[Page 4]

RFC 2329      OSPF Standardization Report      April 1998

    2.2.  CryptographicAuthentication

Non-trivial authentication was added toOSPF with the
development of the Cryptographic Authenticationtype. This
authentication type uses any keyed message digest algorithm,
with explicit instructions included forthe useof MD5.For more
information on OSPF authentication, seeSection4.

There are at least three independent implementations ofthe OSPF
Cryptographic authentication type. Interoperability hasbeen
demonstrated between the implementations from cisco andCascade.

3.  Updated implementation and deployment experience

    When OSPF was promoted to Draft Standard Status, a report was issued
    documentingcurrentimplementation and deployment experience (see
    [Ref6]). That report is nowquite dated. Inan attempt to get more
    current data, a questionnaire was sent to OSPF mailing listin
    January 1996. Twelve responses werereceived, from 11 router vendors
    and1 manufacturer of test equipment. Theseresponses represented 6
    independentimplementations. A tabulation of the results are
    presented below.

    Table 1 indicates the implementation, interoperability and
    deployment of the major OSPF functions. Thenumber in each column
    represents the number of responses in the affirmative.

Moy     Informational[Page 5]

RFC 2329      OSPF Standardization Report      April 1998

    Feature       mentedoperated   Deployed
    OSPF areas       1010   10
    Stub areas       1010   9
    Virtual links       109   8
    Equal-cost multipath       107   8
    NBMA support       98   7
    CIDR addressing       85   6
    OSPF MIB       85   5
    Cryptographic auth.       32   1
    Point-to-Multipointifc.   63   4

    Table 1: Implementation of OSPF features

    Table 2 indicates the size of the OSPF routing domains thatvendors
    have tested. For each size parameter, the number ofresponders and
    therange of responses (minimum, mode, meanand maximum) are listed.

       Parameter    ResponsesMin   Mode   Mean   Max
       Max routers in domain    730    240    460    1600
       Max routers in single area   720    240    380    1600
       Max areas in domain    71     10     16    60
       Max AS-external-LSAs    950    10K    10K    30K

       Table 2:OSPF domain sizes tested

    Table 3 indicates the size of the OSPF routing domains thatvendors
    have deployed in real networks. Foreach size parameter, the number
    of responders and the rangeof responses (minimum, mode, mean and
    maximum) are listed.

Moy     Informational[Page 6]

RFC 2329      OSPF Standardization Report      April 1998

       Parameter    ResponsesMin   Mode   Mean   Max
       Max routers in domain    820    350    510    1000
       Max routers in single area   820    100    160    350
       Max areas in domain    71     15     23    60
       Max AS-external-LSAs    650    1K     2K    5K

      Table 3: OSPF domain sizes deployed

    In an attempt to ascertain the extent to which OSPFis currently
    deployed, vendors were alsoasked in January 1998 to provide
    deployment estimates. Four vendors of OSPF routers responded, with a
    total estimate of 182,000 OSPF routers in service, organized into
    4300 separate OSPF routing domains.

4.  Protocol Security

    AllOSPF protocol exchangesare authenticated. OSPFsupports
    multiple types of authentication; the type of authentication in use
    canbe configured on a per network segment basis. One of OSPF's
    authentication types, namely the Cryptographic authentication
    option, is believedto be secure against passive attacks and provide
    significantprotection against active attacks. Whenusing the
    Cryptographic authentication option, each router appends a "message
    digest" to its transmitted OSPF packets. Receivers then usethe
    shared secret key and received digest to verify that each received
    OSPF packetis authentic.

    Thequalityof the securityprovided by theCryptographic
    authentication option depends completely onthe strength ofthe
    message digest algorithm (MD5 is currently the onlymessagedigest
    algorithm specified), the strength of the key beingused, and the
    correct implementation of the security mechanism inall
    communicating OSPF implementations. It also requires that all
    parties maintain the secrecy of theshared secret key.

    None of theOSPF authentication types provide confidentiality. Nor
    do they protect against traffic analysis. Key management isalso not
    addressed by the OSPF specification.

Moy     Informational[Page 7]

RFC 2329      OSPF Standardization Report      April 1998

    Formore information, see Sections 8.1, 8.2, and Appendix Dof


    [Ref1]  Moy, J., "OSPF Version 2", RFC 2178, July 1997.

    [Ref2]  Hinden, B.,"Internet Routing Protocol Standardization
    Criteria", RFC 1264, October 1991.

    [Ref3]  Moy, J., "OSPF Version 2", RFC 1583, March 1994.

    [Ref4]  Baker, F., and R. Coltun, "OSPF Version 2 Management
    InformationBase", RFC 1850, November 1995.

    [Ref5]  Moy, J., "OSPF Protocol Analysis", RFC 1245, August1991.

    [Ref6]  Moy, J., "Experience with the OSPF Protocol", RFC 1246,
    August 1991.

    [Ref7]  Varadhan, K., HaresS., andY. Rekhter, "BGP4/IDRP for IP--
    -OSPF Interaction",RFC 1745, December 1994.

    [Ref8]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

Security Considerations

    Security considerations areaddressed in Section 4 of this memo.

Author's Address

    John Moy
    Ascend Communications, Inc.
    1 Robbins Road
    Westford, MA 01886

    Phone: 978-952-1367
    Fax:   978-392-2075
    EMail: jmoy@casc.com

Moy     Informational[Page 8]

RFC 2329      OSPF Standardization Report      April 1998

    Full Copyright Statement

Copyright (C) The Internet Society (1998).  AllRights Reserved.

This document and translations of it may be copied and furnished
to others, and derivative worksthat comment onor otherwise
explainit or assist inits implementation may be prepared,
copied,published and distributed, in whole or in part,without
restriction of any kind, provided that the above copyright
notice and thisparagraph are included on all such copies and
derivative works.  However, this document itself may not be
modified in anyway, such as byremoving the copyright notice or
references to the Internet Society or other Internet
organizations, except as neededfor thepurposeof developing
Internet standards in which case the proceduresfor copyrights
definedin the InternetStandards process must be followed, or
as required to translate it into languages other than English.

The limited permissionsgrantedabove are perpetual andwill not
be revoked by the Internet Society or its successors orassigns.

This document and the information contained herein is provided

Moy     Informational[Page 9]

©2018 Martin Webb