rfc2329.txt

RFC 的详细文档！

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

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]

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]

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]

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]

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.