path: root/doc/rfc/rfc2329.txt

Network	Working	Group						  J. Moy
Request	for 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
    not	specify	an Internet standard of	any kind.  Distribution	of this
    memo is unlimited.

Copyright Notice

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

Abstract

    This memo documents	how the	requirements for advancing a routing
    protocol to	Full Standard, set out in [Ref2], have been met	for
    OSPFv2.

    Please send	comments to ospf@gated.cornell.edu.

Table of Contents

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













Moy			     Informational			[Page 1]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


1.  Introduction

    OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
    protocol documented	in [Ref8]. OSPF	is a link-state	routing
    protocol.  It is designed to be run	internal to a single Autonomous
    System.  Each OSPF router maintains	an identical database describing
    the	Autonomous System's topology.  From this database, a routing
    table is calculated	by constructing	a shortest-path	tree. OSPF
    features include the following:

    o	OSPF responds quickly to topology changes, expending a minimum
	of network bandwidth in	the process.

    o	Support	for CIDR addressing.

    o	OSPF routing exchanges can be authenticated, providing routing
	security.

    o	Equal-cost multipath.

    o	An area	routing	capability is provided,	enabling an Autonomous
	system to be split into	a two level hierarchy to further reduce
	the amount of routing protocol traffic.

    o	OSPF allows import of external routing information into	the
	Autonomous System, including a tagging feature that can	be
	exploited to exchange extra information	at the AS boundary (see
	[Ref7]).

    An analysis	of OSPF	together with a	more detailed description of
    OSPF features was originally provided in [Ref6], as	a part of
    promoting OSPF to Draft Standard status. The analysis of OSPF
    remains unchanged. Two additional major features have been developed
    for	OSPF since the protocol	achieved Draft Standard	status:	the
    Point-to-MultiPoint	interface and Cryptographic Authentication.
    These features are described in Sections 2.1 and 2.2 respectively of
    this memo.

    The	OSPF MIB is documented in [Ref4]. It is	currently at Draft
    Standard status.












Moy			     Informational			[Page 2]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


2.  Modifications since	Draft Standard status

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

    o	Configuration requirements for OSPF area address ranges	have
	been relaxed to	allow greater flexibility in area assignment.
	See Section G.3	of [Ref1] for details.

    o	The OSPF flooding algorithm was	modified to a) improve database
	convergence in networks	with low speed links b)	resolve	a
	problem	where unnecessary LSA retransmissions could occur as a
	result of differing clock granularities, c) remove race
	conditions between the flooding	of MaxAge LSAs and the Database
	Exchange process, d) clarify the use of	the MinLSArrival
	constant, and e) rate-limit the	response to less recent	LSAs
	received via flooding.	See Sections G.4 and G.5 of [Ref1] and
	Section	G.1 of [Ref8] for details.

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

    o	Several	problems involving advertising the same	external route
	from multiple areas were found and fixed, as described in
	Section	G.7 of [Ref1] and Section G.2 of [Ref8].  Without the
	fixes, persistent routing loops	could form in certain such
	configurations.	Note that one of the fixes was not backward-
	compatible, in that mixing routers implementing	the fixes with
	those implementing just	RFC 1583 could cause loops not present
	in an RFC 1583-only configuration. This	caused an
	RFC1583Compatibility global configuration parameter to be added,
	as described in	Section	C.1 of [Ref1].













Moy			     Informational			[Page 3]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


    o	In order to deal with high delay links,	retransmissions	of
	initial	Database Description packets no	longer reset an	OSPF
	adjacency.

    o	In order to detect link	MTU mismatches,	which can cause	problems
	both in	IP forwarding and in the OSPF routing protocol itself,
	MTU was	added to OSPF's	Database Description packets.
	Neighboring routers refuse to bring up an OSPF adjacency unless
	they agree on their common link's MTU.

    o	The TOS	routing	option was deleted from	OSPF. 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-
	LSAs.

    o	OSPF's routing table lookup algorithm was changed to reflect
	current	practice. The "best match" routing table entry is now
	always selected	to be the one providing	the most specific
	(longest) match. See Section G.4 of [Ref8] for details.

    2.1.  Point-to-MultiPoint interface

	The Point-to-MultiPoint	interface was added as an alternative to
	OSPF's NBMA interface when running OSPF	over non-broadcast
	subnets. Unlike	the NBMA interface, Point-to-MultiPoint	does not
	require	full mesh connectivity over the	non-broadcast subnet.
	Point-to-MultiPoint is less efficient than NBMA, but is	easier
	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 information	on the Point-to-
	MultiPoint interface, see Section G.2 of [Ref1].

	There are at least six independent implementations of the
	Point-to-MultiPoint interface. Interoperability	has been
	demonstrated between at	least two pairs	of implementations:
	between	3com and Bay Networks, and between cisco and Cascade.















Moy			     Informational			[Page 4]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


    2.2.  Cryptographic	Authentication

	Non-trivial authentication was added to	OSPF with the
	development of the Cryptographic Authentication	type. This
	authentication type uses any keyed message digest algorithm,
	with explicit instructions included for	the use	of MD5.	For more
	information on OSPF authentication, see	Section	4.

	There are at least three independent implementations of	the OSPF
	Cryptographic authentication type. Interoperability has	been
	demonstrated between the implementations from cisco and	Cascade.

3.  Updated implementation and deployment experience

    When OSPF was promoted to Draft Standard Status, a report was issued
    documenting	current	implementation and deployment experience (see
    [Ref6]). That report is now	quite dated. In	an attempt to get more
    current data, a questionnaire was sent to OSPF mailing list	in
    January 1996. Twelve responses were	received, from 11 router vendors
    and	1 manufacturer of test equipment. These	responses represented 6
    independent	implementations. A tabulation of the results are
    presented below.

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


























Moy			     Informational			[Page 5]
^L
RFC 2329	      OSPF Standardization Report	      April 1998



				       Imple-	Inter-
	    Feature		       mented	operated   Deployed
	    _______________________________________________________
	    OSPF areas		       10	10	   10
	    Stub areas		       10	10	   9
	    Virtual links	       10	9	   8
	    Equal-cost multipath       10	7	   8
	    NBMA support	       9	8	   7
	    CIDR addressing	       8	5	   6
	    OSPF MIB		       8	5	   5
	    Cryptographic auth.	       3	2	   1
	    Point-to-Multipoint	ifc.   6	3	   4


		    Table 1: Implementation of OSPF features


    Table 2 indicates the size of the OSPF routing domains that	vendors
    have tested. For each size parameter, the number of	responders and
    the	range of responses (minimum, mode, mean	and maximum) are listed.


       Parameter		    Responses	Min   Mode   Mean   Max
       _________________________________________________________________
       Max routers in domain	    7		30    240    460    1600
       Max routers in single area   7		20    240    380    1600
       Max areas in domain	    7		1     10     16	    60
       Max AS-external-LSAs	    9		50    10K    10K    30K


		       Table 2:	OSPF domain sizes tested


    Table 3 indicates the size of the OSPF routing domains that	vendors
    have deployed in real networks. For	each size parameter, the number
    of responders and the range	of responses (minimum, mode, mean and
    maximum) are listed.














Moy			     Informational			[Page 6]
^L
RFC 2329	      OSPF Standardization Report	      April 1998



       Parameter		    Responses	Min   Mode   Mean   Max
       _________________________________________________________________
       Max routers in domain	    8		20    350    510    1000
       Max routers in single area   8		20    100    160    350
       Max areas in domain	    7		1     15     23	    60
       Max AS-external-LSAs	    6		50    1K     2K	    5K


		      Table 3: OSPF domain sizes deployed


    In an attempt to ascertain the extent to which OSPF	is currently
    deployed, vendors were also	asked 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

    All	OSPF protocol exchanges	are authenticated. OSPF	supports
    multiple types of authentication; the type of authentication in use
    can	be configured on a per network segment basis. One of OSPF's
    authentication types, namely the Cryptographic authentication
    option, is believed	to be secure against passive attacks and provide
    significant	protection against active attacks. When	using the
    Cryptographic authentication option, each router appends a "message
    digest" to its transmitted OSPF packets. Receivers then use	the
    shared secret key and received digest to verify that each received
    OSPF packet	is authentic.

    The	quality	of the security	provided by the	Cryptographic
    authentication option depends completely on	the strength of	the
    message digest algorithm (MD5 is currently the only	message	digest
    algorithm specified), the strength of the key being	used, and the
    correct implementation of the security mechanism in	all
    communicating OSPF implementations.	 It also requires that all
    parties maintain the secrecy of the	shared secret key.

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










Moy			     Informational			[Page 7]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


    For	more information, see Sections 8.1, 8.2, and Appendix D	of
    [Ref1].

References

    [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
	    Information	Base", RFC 1850, November 1995.

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

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

    [Ref7]  Varadhan, K., Hares	S., and	Y. 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 are	addressed 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]
^L
RFC 2329	      OSPF Standardization Report	      April 1998


    Full Copyright Statement

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

	This document and translations of it may be copied and furnished
	to others, and derivative works	that comment on	or otherwise
	explain	it or assist in	its 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 this	paragraph are included on all such copies and
	derivative works.  However, this document itself may not be
	modified in any	way, such as by	removing the copyright notice or
	references to the Internet Society or other Internet
	organizations, except as needed	for the	purpose	of developing
	Internet standards in which case the procedures	for copyrights
	defined	in the Internet	Standards process must be followed, or
	as required to translate it into languages other than English.

	The limited permissions	granted	above are perpetual and	will not
	be revoked by the Internet Society or its successors or	assigns.

	This document and the information contained herein is provided
	on an "AS IS" basis and	THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT	THE USE
	OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY	RIGHTS OR ANY
	IMPLIED	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
	PARTICULAR PURPOSE.
























Moy			     Informational			[Page 9]
^L