ARMWARE RFC Archive <- STD Index (1..100)

STD 54

(also RFC 2328)

Obsoletes RFC 2178
Updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Network	Working	Group						  J. Moy
Request	for Comments: 2328		     Ascend Communications, Inc.
STD: 54							      April 1998
Obsoletes: 2178
Category: Standards Track

			     OSPF Version 2

Status of this Memo

    This document specifies an Internet	standards track	protocol for the
    Internet community,	and requests discussion	and suggestions	for
    improvements.  Please refer	to the current edition of the "Internet
    Official Protocol Standards" (STD 1) for the standardization state
    and	status of this protocol.  Distribution of this memo is
    unlimited.

Copyright Notice

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

Abstract

    This memo documents	version	2 of the OSPF protocol.	 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 recalculates routes quickly in	the face of topological	changes,
    utilizing a	minimum	of routing protocol traffic.  OSPF provides
    support for	equal-cost multipath.  An area routing capability is
    provided, enabling an additional level of routing protection and a
    reduction in routing protocol traffic.  In addition, all OSPF
    routing protocol exchanges are authenticated.

    The	differences between this memo and RFC 2178 are explained in
    Appendix G.	All differences	are backward-compatible	in nature.

Moy			    Standards Track			[Page 1]



RFC 2328		     OSPF Version 2		      April 1998

    Implementations of this memo and of	RFCs 2178, 1583, and 1247 will
    interoperate.

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

Table of Contents

    1	     Introduction ........................................... 6
    1.1	     Protocol Overview ...................................... 6
    1.2	     Definitions of commonly used terms	..................... 8
    1.3	     Brief history of link-state routing technology ........ 11
    1.4	     Organization of this document ......................... 12
    1.5	     Acknowledgments ....................................... 12
    2	     The link-state database: organization and calculations  13
    2.1	     Representation of routers and networks ................ 13
    2.1.1    Representation of non-broadcast networks .............. 15
    2.1.2    An	example	link-state database ........................ 18
    2.2	     The shortest-path tree ................................ 21
    2.3	     Use of external routing information ................... 23
    2.4	     Equal-cost	multipath .................................. 26
    3	     Splitting the AS into Areas ........................... 26
    3.1	     The backbone of the Autonomous System ................. 27
    3.2	     Inter-area	routing	.................................... 27
    3.3	     Classification of routers ............................. 28
    3.4	     A sample area configuration ........................... 29
    3.5	     IP	subnetting support ................................. 35
    3.6	     Supporting	stub areas ................................. 37
    3.7	     Partitions	of areas ................................... 38
    4	     Functional	Summary	.................................... 40
    4.1	     Inter-area	routing	.................................... 41
    4.2	     AS	external routes	.................................... 41
    4.3	     Routing protocol packets .............................. 42
    4.4	     Basic implementation requirements ..................... 43
    4.5	     Optional OSPF capabilities	............................ 46
    5	     Protocol data structures .............................. 47
    6	     The Area Data Structure ............................... 49
    7	     Bringing Up Adjacencies ............................... 52
    7.1	     The Hello Protocol	.................................... 52
    7.2	     The Synchronization of Databases ...................... 53
    7.3	     The Designated Router ................................. 54
    7.4	     The Backup	Designated Router .......................... 56
    7.5	     The graph of adjacencies .............................. 56

Moy			    Standards Track			[Page 2]



RFC 2328		     OSPF Version 2		      April 1998

    8	     Protocol Packet Processing	............................ 58
    8.1	     Sending protocol packets .............................. 58
    8.2	     Receiving protocol	packets	............................ 61
    9	     The Interface Data	Structure .......................... 63
    9.1	     Interface states ...................................... 67
    9.2	     Events causing interface state changes ................ 70
    9.3	     The Interface state machine ........................... 72
    9.4	     Electing the Designated Router ........................ 75
    9.5	     Sending Hello packets ................................. 77
    9.5.1    Sending Hello packets on NBMA networks ................ 79
    10	     The Neighbor Data Structure ........................... 80
    10.1     Neighbor states ....................................... 83
    10.2     Events causing neighbor state changes ................. 87
    10.3     The Neighbor state	machine	............................ 89
    10.4     Whether to	become adjacent	............................ 95
    10.5     Receiving Hello Packets ............................... 96
    10.6     Receiving Database	Description Packets ................ 99
    10.7     Receiving Link State Request Packets ................. 102
    10.8     Sending Database Description Packets ................. 103
    10.9     Sending Link State	Request	Packets	................... 104
    10.10    An	Example	........................................... 105
    11	     The Routing Table Structure .......................... 107
    11.1     Routing table lookup ................................. 111
    11.2     Sample routing table, without areas .................. 111
    11.3     Sample routing table, with	areas ..................... 112
    12	     Link State	Advertisements (LSAs) ..................... 115
    12.1     The LSA Header ....................................... 116
    12.1.1   LS	age ............................................... 116
    12.1.2   Options .............................................. 117
    12.1.3   LS	type .............................................. 117
    12.1.4   Link State	ID ........................................ 117
    12.1.5   Advertising Router	................................... 119
    12.1.6   LS	sequence number	................................... 120
    12.1.7   LS	checksum .......................................... 121
    12.2     The link state database .............................. 121
    12.3     Representation of TOS ................................ 122
    12.4     Originating LSAs ..................................... 123
    12.4.1   Router-LSAs .......................................... 126
    12.4.1.1 Describing	point-to-point interfaces ................. 130
    12.4.1.2 Describing	broadcast and NBMA interfaces ............. 130
    12.4.1.3 Describing	virtual	links ............................. 131
    12.4.1.4 Describing	Point-to-MultiPoint interfaces ............ 131

Moy			    Standards Track			[Page 3]



RFC 2328		     OSPF Version 2		      April 1998

    12.4.1.5 Examples of router-LSAs .............................. 132
    12.4.2   Network-LSAs ......................................... 133
    12.4.2.1 Examples of network-LSAs ............................. 134
    12.4.3   Summary-LSAs ......................................... 135
    12.4.3.1 Originating summary-LSAs into stub	areas ............. 137
    12.4.3.2 Examples of summary-LSAs ............................. 138
    12.4.4   AS-external-LSAs ..................................... 139
    12.4.4.1 Examples of AS-external-LSAs ......................... 140
    13	     The Flooding Procedure ............................... 143
    13.1     Determining which LSA is newer ....................... 146
    13.2     Installing	LSAs in	the database ...................... 147
    13.3     Next step in the flooding procedure .................. 148
    13.4     Receiving self-originated LSAs ....................... 151
    13.5     Sending Link State	Acknowledgment packets ............ 152
    13.6     Retransmitting LSAs .................................. 154
    13.7     Receiving link state acknowledgments ................. 155
    14	     Aging The Link State Database ........................ 156
    14.1     Premature aging of	LSAs .............................. 157
    15	     Virtual Links ........................................ 158
    16	     Calculation of the	routing	table ..................... 160
    16.1     Calculating the shortest-path tree	for an area ....... 161
    16.1.1   The next hop calculation ............................. 167
    16.2     Calculating the inter-area	routes .................... 178
    16.3     Examining transit areas' summary-LSAs ................ 170
    16.4     Calculating AS external routes ....................... 173
    16.4.1   External path preferences ............................ 175
    16.5     Incremental updates -- summary-LSAs .................. 175
    16.6     Incremental updates -- AS-external-LSAs .............. 177
    16.7     Events generated as a result of routing table changes  177
    16.8     Equal-cost	multipath ................................. 178
	     Footnotes ............................................ 179
	     References	........................................... 183
    A	     OSPF data formats .................................... 185
    A.1	     Encapsulation of OSPF packets ........................ 185
    A.2	     The Options field .................................... 187
    A.3	     OSPF Packet Formats .................................. 189
    A.3.1    The OSPF packet header ............................... 190
    A.3.2    The Hello packet ..................................... 193
    A.3.3    The Database Description packet ...................... 195
    A.3.4    The Link State Request packet ........................ 197
    A.3.5    The Link State Update packet ......................... 199
    A.3.6    The Link State Acknowledgment packet ................. 201

Moy			    Standards Track			[Page 4]



RFC 2328		     OSPF Version 2		      April 1998

    A.4	     LSA formats .......................................... 203
    A.4.1    The LSA header ....................................... 204
    A.4.2    Router-LSAs .......................................... 206
    A.4.3    Network-LSAs ......................................... 210
    A.4.4    Summary-LSAs ......................................... 212
    A.4.5    AS-external-LSAs ..................................... 214
    B	     Architectural Constants .............................. 217
    C	     Configurable Constants ............................... 219
    C.1	     Global parameters .................................... 219
    C.2	     Area parameters ...................................... 220
    C.3	     Router interface parameters .......................... 221
    C.4	     Virtual link parameters .............................. 224
    C.5	     NBMA network parameters .............................. 224
    C.6	     Point-to-MultiPoint network parameters ............... 225
    C.7	     Host route	parameters ................................ 226
    D	     Authentication ....................................... 227
    D.1	     Null authentication .................................. 227
    D.2	     Simple password authentication ....................... 228
    D.3	     Cryptographic authentication ......................... 228
    D.4	     Message generation	................................... 231
    D.4.1    Generating	Null authentication ....................... 231
    D.4.2    Generating	Simple password	authentication ............ 232
    D.4.3    Generating	Cryptographic authentication .............. 232
    D.5	     Message verification ................................. 234
    D.5.1    Verifying Null authentication ........................ 234
    D.5.2    Verifying Simple password authentication ............. 234
    D.5.3    Verifying Cryptographic authentication ............... 235
    E	     An	algorithm for assigning	Link State IDs ............ 236
    F	     Multiple interfaces to the	same network/subnet ....... 239
    G	     Differences from RFC 2178 ............................ 240
    G.1	     Flooding modifications ............................... 240
    G.2	     Changes to	external path preferences ................. 241
    G.3	     Incomplete	resolution of virtual next hops	........... 241
    G.4	     Routing table lookup ................................. 241
	     Security Considerations .............................. 243
	     Author's Address ..................................... 243
	     Full Copyright Statement ............................. 244

Moy			    Standards Track			[Page 5]



RFC 2328		     OSPF Version 2		      April 1998

1.  Introduction

    This document is a specification of	the Open Shortest Path First
    (OSPF) TCP/IP internet routing protocol.  OSPF is classified as an
    Interior Gateway Protocol (IGP).  This means that it distributes
    routing information	between	routers	belonging to a single Autonomous
    System.  The OSPF protocol is based	on link-state or SPF technology.
    This is a departure	from the Bellman-Ford base used	by traditional
    TCP/IP internet routing protocols.

    The	OSPF protocol was developed by the OSPF	working	group of the
    Internet Engineering Task Force.  It has been designed expressly for
    the	TCP/IP internet	environment, including explicit	support	for CIDR
    and	the tagging of externally-derived routing information.	OSPF
    also provides for the authentication of routing updates, and
    utilizes IP	multicast when sending/receiving the updates.  In
    addition, much work	has been done to produce a protocol that
    responds quickly to	topology changes, yet involves small amounts of
    routing protocol traffic.

    1.1.  Protocol overview

	OSPF routes IP packets based solely on the destination IP
	address	found in the IP	packet header.	IP packets are routed
	"as is"	-- they	are not	encapsulated in	any further protocol
	headers	as they	transit	the Autonomous System.	OSPF is	a
	dynamic	routing	protocol.  It quickly detects topological
	changes	in the AS (such	as router interface failures) and
	calculates new loop-free routes	after a	period of convergence.
	This period of convergence is short and	involves a minimum of
	routing	traffic.

	In a link-state	routing	protocol, each router maintains	a
	database describing the	Autonomous System's topology.  This
	database is referred to	as the link-state database. Each
	participating router has an identical database.	 Each individual
	piece of this database is a particular router's	local state
	(e.g., the router's usable interfaces and reachable neighbors).
	The router distributes its local state throughout the Autonomous
	System by flooding.

Moy			    Standards Track			[Page 6]



RFC 2328		     OSPF Version 2		      April 1998

	All routers run	the exact same algorithm, in parallel.	From the
	link-state database, each router constructs a tree of shortest
	paths with itself as root.  This shortest-path tree gives the
	route to each destination in the Autonomous System.  Externally
	derived	routing	information appears on the tree	as leaves.

	When several equal-cost	routes to a destination	exist, traffic
	is distributed equally among them.  The	cost of	a route	is
	described by a single dimensionless metric.

	OSPF allows sets of networks to	be grouped together.  Such a
	grouping is called an area.  The topology of an	area is	hidden
	from the rest of the Autonomous	System.	 This information hiding
	enables	a significant reduction	in routing traffic.  Also,
	routing	within the area	is determined only by the area's own
	topology, lending the area protection from bad routing data.  An
	area is	a generalization of an IP subnetted network.

	OSPF enables the flexible configuration	of IP subnets.	Each
	route distributed by OSPF has a	destination and	mask.  Two
	different subnets of the same IP network number	may have
	different sizes	(i.e., different masks).  This is commonly
	referred to as variable	length subnetting.  A packet is	routed
	to the best (i.e., longest or most specific) match.  Host routes
	are considered to be subnets whose masks are "all ones"
	(0xffffffff).

	All OSPF protocol exchanges are	authenticated.	This means that
	only trusted routers can participate in	the Autonomous System's
	routing.  A variety of authentication schemes can be used; in
	fact, separate authentication schemes can be configured	for each
	IP subnet.

	Externally derived routing data	(e.g., routes learned from an
	Exterior Gateway Protocol such as BGP; see [Ref23]) is
	advertised throughout the Autonomous System.  This externally
	derived	data is	kept separate from the OSPF protocol's link
	state data.  Each external route can also be tagged by the
	advertising router, enabling the passing of additional
	information between routers on the boundary of the Autonomous
	System.

Moy			    Standards Track			[Page 7]



RFC 2328		     OSPF Version 2		      April 1998

    1.2.  Definitions of commonly used terms

	This section provides definitions for terms that have a	specific
	meaning	to the OSPF protocol and that are used throughout the
	text.  The reader unfamiliar with the Internet Protocol	Suite is
	referred to [Ref13] for	an introduction	to IP.

	Router
	    A level three Internet Protocol packet switch.  Formerly
	    called a gateway in	much of	the IP literature.

	Autonomous System
	    A group of routers exchanging routing information via a
	    common routing protocol.  Abbreviated as AS.

	Interior Gateway Protocol
	    The	routing	protocol spoken	by the routers belonging to an
	    Autonomous system.	Abbreviated as IGP.  Each Autonomous
	    System has a single	IGP.  Separate Autonomous Systems may be
	    running different IGPs.

	Router ID
	    A 32-bit number assigned to	each router running the	OSPF
	    protocol.  This number uniquely identifies the router within
	    an Autonomous System.

	Network
	    In this memo, an IP	network/subnet/supernet.  It is	possible
	    for	one physical network to	be assigned multiple IP
	    network/subnet numbers.  We	consider these to be separate
	    networks.  Point-to-point physical networks	are an exception
	    - they are considered a single network no matter how many
	    (if	any at all) IP network/subnet numbers are assigned to
	    them.

	Network	mask
	    A 32-bit number indicating the range of IP addresses
	    residing on	a single IP network/subnet/supernet.  This
	    specification displays network masks as hexadecimal	numbers.

Moy			    Standards Track			[Page 8]



RFC 2328		     OSPF Version 2		      April 1998

	    For	example, the network mask for a	class C	IP network is
	    displayed as 0xffffff00.  Such a mask is often displayed
	    elsewhere in the literature	as 255.255.255.0.

	Point-to-point networks
	    A network that joins a single pair of routers.  A 56Kb
	    serial line	is an example of a point-to-point network.

	Broadcast networks
	    Networks supporting	many (more than	two) attached routers,
	    together with the capability to address a single physical
	    message to all of the attached routers (broadcast).
	    Neighboring	routers	are discovered dynamically on these nets
	    using OSPF's Hello Protocol.  The Hello Protocol itself
	    takes advantage of the broadcast capability.  The OSPF
	    protocol makes further use of multicast capabilities, if
	    they exist.	 Each pair of routers on a broadcast network is
	    assumed to be able to communicate directly.	An ethernet is
	    an example of a broadcast network.

	Non-broadcast networks
	    Networks supporting	many (more than	two) routers, but having
	    no broadcast capability.  Neighboring routers are maintained
	    on these nets using	OSPF's Hello Protocol.	However, due to
	    the	lack of	broadcast capability, some configuration
	    information	may be necessary to aid	in the discovery of
	    neighbors.	On non-broadcast networks, OSPF	protocol packets
	    that are normally multicast	need to	be sent	to each
	    neighboring	router,	in turn. An X.25 Public	Data Network
	    (PDN) is an	example	of a non-broadcast network.

	    OSPF runs in one of	two modes over non-broadcast networks.
	    The	first mode, called non-broadcast multi-access or NBMA,
	    simulates the operation of OSPF on a broadcast network. The
	    second mode, called	Point-to-MultiPoint, treats the	non-
	    broadcast network as a collection of point-to-point	links.
	    Non-broadcast networks are referred	to as NBMA networks or
	    Point-to-MultiPoint	networks, depending on OSPF's mode of
	    operation over the network.

Moy			    Standards Track			[Page 9]



RFC 2328		     OSPF Version 2		      April 1998

	Interface
	    The	connection between a router and	one of its attached
	    networks.  An interface has	state information associated
	    with it, which is obtained from the	underlying lower level
	    protocols and the routing protocol itself.	An interface to
	    a network has associated with it a single IP address and
	    mask (unless the network is	an unnumbered point-to-point
	    network).  An interface is sometimes also referred to as a
	    link.

	Neighboring routers
	    Two	routers	that have interfaces to	a common network.
	    Neighbor relationships are maintained by, and usually
	    dynamically	discovered by, OSPF's Hello Protocol.

	Adjacency
	    A relationship formed between selected neighboring routers
	    for	the purpose of exchanging routing information.	Not
	    every pair of neighboring routers become adjacent.

	Link state advertisement
	    Unit of data describing the	local state of a router	or
	    network. For a router, this	includes the state of the
	    router's interfaces	and adjacencies.  Each link state
	    advertisement is flooded throughout	the routing domain. The
	    collected link state advertisements	of all routers and
	    networks forms the protocol's link state database.
	    Throughout this memo, link state advertisement is
	    abbreviated	as LSA.

	Hello Protocol
	    The	part of	the OSPF protocol used to establish and	maintain
	    neighbor relationships.  On	broadcast networks the Hello
	    Protocol can also dynamically discover neighboring routers.

	Flooding
	    The	part of	the OSPF protocol that distributes and
	    synchronizes the link-state	database between OSPF routers.

	Designated Router
	    Each broadcast and NBMA network that has at	least two
	    attached routers has a Designated Router.  The Designated

Moy			    Standards Track		       [Page 10]



RFC 2328		     OSPF Version 2		      April 1998

	    Router generates an	LSA for	the network and	has other
	    special responsibilities in	the running of the protocol.
	    The	Designated Router is elected by	the Hello Protocol.

	    The	Designated Router concept enables a reduction in the
	    number of adjacencies required on a	broadcast or NBMA
	    network.  This in turn reduces the amount of routing
	    protocol traffic and the size of the link-state database.

	Lower-level protocols
	    The	underlying network access protocols that provide
	    services to	the Internet Protocol and in turn the OSPF
	    protocol.  Examples	of these are the X.25 packet and frame
	    levels for X.25 PDNs, and the ethernet data	link layer for
	    ethernets.

    1.3.  Brief	history	of link-state routing technology

	OSPF is	a link state routing protocol.	Such protocols are also
	referred to in the literature as SPF-based or distributed-
	database protocols.  This section gives	a brief	description of
	the developments in link-state technology that have influenced
	the OSPF protocol.

	The first link-state routing protocol was developed for	use in
	the ARPANET packet switching network.  This protocol is
	described in [Ref3].  It has formed the	starting point for all
	other link-state protocols.  The homogeneous ARPANET
	environment, i.e., single-vendor packet	switches connected by
	synchronous serial lines, simplified the design	and
	implementation of the original protocol.

	Modifications to this protocol were proposed in	[Ref4].	 These
	modifications dealt with increasing the	fault tolerance	of the
	routing	protocol through, among	other things, adding a checksum
	to the LSAs (thereby detecting database	corruption).  The paper
	also included means for	reducing the routing traffic overhead in
	a link-state protocol.	This was accomplished by introducing
	mechanisms which enabled the interval between LSA originations
	to be increased	by an order of magnitude.

Moy			    Standards Track		       [Page 11]



RFC 2328		     OSPF Version 2		      April 1998

	A link-state algorithm has also	been proposed for use as an ISO
	IS-IS routing protocol.	 This protocol is described in [Ref2].
	The protocol includes methods for data and routing traffic
	reduction when operating over broadcast	networks.  This	is
	accomplished by	election of a Designated Router	for each
	broadcast network, which then originates an LSA	for the	network.

	The OSPF Working Group of the IETF has extended	this work in
	developing the OSPF protocol.  The Designated Router concept has
	been greatly enhanced to further reduce	the amount of routing
	traffic	required.  Multicast capabilities are utilized for
	additional routing bandwidth reduction.	 An area routing scheme
	has been developed enabling information
	hiding/protection/reduction.  Finally, the algorithms have been
	tailored for efficient operation in TCP/IP internets.

    1.4.  Organization of this document

	The first three	sections of this specification give a general
	overview of the	protocol's capabilities	and functions.	Sections
	4-16 explain the protocol's mechanisms in detail.  Packet
	formats, protocol constants and	configuration items are
	specified in the appendices.

	Labels such as HelloInterval encountered in the	text refer to
	protocol constants.  They may or may not be configurable.
	Architectural constants	are summarized in Appendix B.
	Configurable constants are summarized in Appendix C.

	The detailed specification of the protocol is presented	in terms
	of data	structures.  This is done in order to make the
	explanation more precise.  Implementations of the protocol are
	required to support the	functionality described, but need not
	use the	precise	data structures	that appear in this memo.

    1.5.  Acknowledgments

	The author would like to thank Ran Atkinson, Fred Baker, Jeffrey
	Burgan,	Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra
	Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan,	Zhaohui

Moy			    Standards Track		       [Page 12]



RFC 2328		     OSPF Version 2		      April 1998

	Zhang and the rest of the OSPF Working Group for the ideas and
	support	they have given	to this	project.

	The OSPF Point-to-MultiPoint interface is based	on work	done by
	Fred Baker.

	The OSPF Cryptographic Authentication option was developed by
	Fred Baker and Ran Atkinson.

2.  The	Link-state Database: organization and calculations

    The	following subsections describe the organization	of OSPF's link-
    state database, and	the routing calculations that are performed on
    the	database in order to produce a router's	routing	table.

    2.1.  Representation of routers and	networks

	The Autonomous System's	link-state database describes a	directed
	graph.	The vertices of	the graph consist of routers and
	networks.  A graph edge	connects two routers when they are
	attached via a physical	point-to-point network.	 An edge
	connecting a router to a network indicates that	the router has
	an interface on	the network. Networks can be either transit or
	stub networks. Transit networks	are those capable of carrying
	data traffic that is neither locally originated	nor locally
	destined. A transit network is represented by a	graph vertex
	having both incoming and outgoing edges. A stub	network's vertex
	has only incoming edges.

	The neighborhood of each network node in the graph depends on
	the network's type (point-to-point, broadcast, NBMA or Point-
	to-MultiPoint) and the number of routers having	an interface to
	the network.  Three cases are depicted in Figure 1a.  Rectangles
	indicate routers.  Circles and oblongs indicate	networks.
	Router names are prefixed with the letters RT and network names
	with the letter	N.  Router interface names are prefixed	by the
	letter I.  Lines between routers indicate point-to-point
	networks.  The left side of the	figure shows networks with their
	connected routers, with	the resulting graphs shown on the right.

Moy			    Standards Track		       [Page 13]



RFC 2328		     OSPF Version 2		      April 1998

						  **FROM**

					   *	  |RT1|RT2|
		+---+Ia	   +---+	   *   ------------
		|RT1|------|RT2|	   T   RT1|   |	X |
		+---+	 Ib+---+	   O   RT2| X |	  |
					   *	Ia|   |	X |
					   *	Ib| X |	  |

		     Physical point-to-point networks

						  **FROM**
		      +---+		   *
		      |RT7|		   *	  |RT7|	N3|
		      +---+		   T   ------------
			|		   O   RT7|   |	  |
	    +----------------------+	   *	N3| X |	  |
		       N3		   *

			      Stub networks

						  **FROM**
		+---+	   +---+
		|RT3|	   |RT4|	      |RT3|RT4|RT5|RT6|N2 |
		+---+	   +---+	*  ------------------------
		  |    N2    |		*  RT3|	  |   |	  |   |	X |
	    +----------------------+	T  RT4|	  |   |	  |   |	X |
		  |	     |		O  RT5|	  |   |	  |   |	X |
		+---+	   +---+	*  RT6|	  |   |	  |   |	X |
		|RT5|	   |RT6|	*   N2|	X | X |	X | X |	  |
		+---+	   +---+

			  Broadcast or NBMA networks

		    Figure 1a: Network map components

Moy			    Standards Track		       [Page 14]



RFC 2328		     OSPF Version 2		      April 1998

	     Networks and routers are represented by vertices.
	     An	edge connects Vertex A to Vertex B iff the
	     intersection of Column A and Row B	is marked with
				  an X.

	The top	of Figure 1a shows two routers connected by a point-to-
	point link. In the resulting link-state	database graph,	the two
	router vertices	are directly connected by a pair of edges, one
	in each	direction. Interfaces to point-to-point	networks need
	not be assigned	IP addresses.  When interface addresses	are
	assigned, they are modelled as stub links, with	each router
	advertising a stub connection to the other router's interface
	address. Optionally, an	IP subnet can be assigned to the point-
	to-point network. In this case,	both routers advertise a stub
	link to	the IP subnet, instead of advertising each others' IP
	interface addresses.

	The middle of Figure 1a	shows a	network	with only one attached
	router (i.e., a	stub network). In this case, the network appears
	on the end of a	stub connection	in the link-state database's
	graph.

	When multiple routers are attached to a	broadcast network, the
	link-state database graph shows	all routers bidirectionally
	connected to the network vertex. This is pictured at the bottom
	of Figure 1a.

	Each network (stub or transit) in the graph has	an IP address
	and associated network mask.  The mask indicates the number of
	nodes on the network.  Hosts attached directly to routers
	(referred to as	host routes) appear on the graph as stub
	networks.  The network mask for	a host route is	always
	0xffffffff, which indicates the	presence of a single node.

	2.1.1.	Representation of non-broadcast	networks

	    As mentioned previously, OSPF can run over non-broadcast
	    networks in	one of two modes: NBMA or Point-to-MultiPoint.
	    The	choice of mode determines the way that the Hello

Moy			    Standards Track		       [Page 15]



RFC 2328		     OSPF Version 2		      April 1998

	    protocol and flooding work over the	non-broadcast network,
	    and	the way	that the network is represented	in the link-
	    state database.

	    In NBMA mode, OSPF emulates	operation over a broadcast
	    network: a Designated Router is elected for	the NBMA
	    network, and the Designated	Router originates an LSA for the
	    network. The graph representation for broadcast networks and
	    NBMA networks is identical.	This representation is pictured
	    in the middle of Figure 1a.

	    NBMA mode is the most efficient way	to run OSPF over non-
	    broadcast networks,	both in	terms of link-state database
	    size and in	terms of the amount of routing protocol	traffic.
	    However, it	has one	significant restriction: it requires all
	    routers attached to	the NBMA network to be able to
	    communicate	directly. This restriction may be met on some
	    non-broadcast networks, such as an ATM subnet utilizing
	    SVCs. But it is often not met on other non-broadcast
	    networks, such as PVC-only Frame Relay networks. On	non-
	    broadcast networks where not all routers can communicate
	    directly you can break the non-broadcast network into
	    logical subnets, with the routers on each subnet being able
	    to communicate directly, and then run each separate	subnet
	    as an NBMA network (see [Ref15]). This however requires
	    quite a bit	of administrative overhead, and	is prone to
	    misconfiguration. It is probably better to run such	a non-
	    broadcast network in Point-to-Multipoint mode.

	    In Point-to-MultiPoint mode, OSPF treats all router-to-
	    router connections over the	non-broadcast network as if they
	    were point-to-point	links. No Designated Router is elected
	    for	the network, nor is there an LSA generated for the
	    network. In	fact, a	vertex for the Point-to-MultiPoint
	    network does not appear in the graph of the	link-state
	    database.

	    Figure 1b illustrates the link-state database representation
	    of a Point-to-MultiPoint network. On the left side of the
	    figure, a Point-to-MultiPoint network is pictured. It is
	    assumed that all routers can communicate directly, except
	    for	routers	RT4 and	RT5. I3	though I6 indicate the routers'

Moy			    Standards Track		       [Page 16]



RFC 2328		     OSPF Version 2		      April 1998

	    IP interface addresses on the Point-to-MultiPoint network.
	    In the graphical representation of the link-state database,
	    routers that can communicate directly over the Point-to-
	    MultiPoint network are joined by bidirectional edges, and
	    each router	also has a stub	connection to its own IP
	    interface address (which is	in contrast to the
	    representation of real point-to-point links; see Figure 1a).

	    On some non-broadcast networks, use	of Point-to-MultiPoint
	    mode and data-link protocols such as Inverse ARP (see
	    [Ref14]) will allow	autodiscovery of OSPF neighbors	even
	    though broadcast support is	not available.

						  **FROM**
		+---+	   +---+
		|RT3|	   |RT4|	      |RT3|RT4|RT5|RT6|
		+---+	   +---+	*  --------------------
		I3|    N2    |I4	*  RT3|	  | X |	X | X |
	    +----------------------+	T  RT4|	X |   |	  | X |
		I5|	     |I6	O  RT5|	X |   |	  | X |
		+---+	   +---+	*  RT6|	X | X |	X |   |
		|RT5|	   |RT6|	*   I3|	X |   |	  |   |
		+---+	   +---+	    I4|	  | X |	  |   |
					    I5|	  |   |	X |   |
					    I6|	  |   |	  | X |

		    Figure 1b: Network map components
		       Point-to-MultiPoint networks

	     All routers can communicate directly over N2, except
		routers	RT4 and	RT5. I3	through	I6 indicate IP
			   interface addresses

Moy			    Standards Track		       [Page 17]



RFC 2328		     OSPF Version 2		      April 1998

	2.1.2.	An example link-state database

	    Figure 2 shows a sample map	of an Autonomous System.  The
	    rectangle labelled H1 indicates a host, which has a	SLIP
	    connection to Router RT12.	Router RT12 is therefore
	    advertising	a host route.  Lines between routers indicate
	    physical point-to-point networks.  The only	point-to-point
	    network that has been assigned interface addresses is the
	    one	joining	Routers	RT6 and	RT10.  Routers RT5 and RT7 have
	    BGP	connections to other Autonomous	Systems.  A set	of BGP-
	    learned routes have	been displayed for both	of these
	    routers.

	    A cost is associated with the output side of each router
	    interface.	This cost is configurable by the system
	    administrator.  The	lower the cost,	the more likely	the
	    interface is to be used to forward data traffic.  Costs are
	    also associated with the externally	derived	routing	data
	    (e.g., the BGP-learned routes).

	    The	directed graph resulting from the map in Figure	2 is
	    depicted in	Figure 3.  Arcs	are labelled with the cost of
	    the	corresponding router output interface.	Arcs having no
	    labelled cost have a cost of 0.  Note that arcs leading from
	    networks to	routers	always have cost 0; they are significant
	    nonetheless.  Note also that the externally	derived	routing
	    data appears on the	graph as stubs.

	    The	link-state database is pieced together from LSAs
	    generated by the routers.  In the associated graphical
	    representation, the	neighborhood of	each router or transit
	    network is represented in a	single,	separate LSA.  Figure 4
	    shows these	LSAs graphically. Router RT12 has an interface
	    to two broadcast networks and a SLIP line to a host.
	    Network N6 is a broadcast network with three attached
	    routers.  The cost of all links from Network N6 to its
	    attached routers is	0.  Note that the LSA for Network N6 is
	    actually generated by one of the network's attached	routers:
	    the	router that has	been elected Designated	Router for the
	    network.

Moy			    Standards Track		       [Page 18]



RFC 2328		     OSPF Version 2		      April 1998

		 +
		 | 3+---+		      N12      N14
	       N1|--|RT1|\ 1			\ N13 /
		 |  +---+ \			8\ |8/8
		 +	   \ ____		  \|/
			    /	 \   1+---+8	8+---+6
			   *  N3  *---|RT4|------|RT5|--------+
			    \____/    +---+	 +---+	      |
		  +	    /	|		   |7	      |
		  | 3+---+ /	|		   |	      |
		N2|--|RT2|/1	|1		   |6	      |
		  |  +---+    +---+8		6+---+	      |
		  +	      |RT3|--------------|RT6|	      |
			      +---+		 +---+	      |
				|2		 Ia|7	      |
				|		   |	      |
			   +---------+		   |	      |
			       N4		   |	      |
						   |	      |
						   |	      |
		       N11			   |	      |
		   +---------+			   |	      |
			|			   |	      |	   N12
			|3			   |	      |6 2/
		      +---+			   |	    +---+/
		      |RT9|			   |	    |RT7|---N15
		      +---+			   |	    +---+ 9
			|1		     +	   |	      |1
		       _|__		     |	 Ib|5	    __|_
		      /	   \	  1+----+2   |	3+----+1   /	\
		     *	N9  *------|RT11|----|---|RT10|---*  N6	 *
		      \____/	   +----+    |	 +----+	   \____/
			|		     |		      |
			|1		     +		      |1
	     +--+   10+----+		    N8		    +---+
	     |H1|-----|RT12|				    |RT8|
	     +--+SLIP +----+				    +---+
			|2				      |4
			|				      |
		   +---------+				  +--------+
		       N10				      N7

Moy			    Standards Track		       [Page 19]



RFC 2328		     OSPF Version 2		      April 1998

		    Figure 2: A	sample Autonomous System

				**FROM**

		 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
		 |1 |2 |3 |4 |5	|6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
	      ----- ---------------------------------------------
	      RT1|  |  |  |  |	|  |  |	 |  |  |  |  |0	|  |  |	 |
	      RT2|  |  |  |  |	|  |  |	 |  |  |  |  |0	|  |  |	 |
	      RT3|  |  |  |  |	|6 |  |	 |  |  |  |  |0	|  |  |	 |
	      RT4|  |  |  |  |8	|  |  |	 |  |  |  |  |0	|  |  |	 |
	      RT5|  |  |  |8 |	|6 |6 |	 |  |  |  |  |	|  |  |	 |
	      RT6|  |  |8 |  |7	|  |  |	 |  |5 |  |  |	|  |  |	 |
	      RT7|  |  |  |  |6	|  |  |	 |  |  |  |  |	|0 |  |	 |
	  *   RT8|  |  |  |  |	|  |  |	 |  |  |  |  |	|0 |  |	 |
	  *   RT9|  |  |  |  |	|  |  |	 |  |  |  |  |	|  |  |0 |
	  T  RT10|  |  |  |  |	|7 |  |	 |  |  |  |  |	|0 |0 |	 |
	  O  RT11|  |  |  |  |	|  |  |	 |  |  |  |  |	|  |0 |0 |
	  *  RT12|  |  |  |  |	|  |  |	 |  |  |  |  |	|  |  |0 |
	  *    N1|3 |  |  |  |	|  |  |	 |  |  |  |  |	|  |  |	 |
	       N2|  |3 |  |  |	|  |  |	 |  |  |  |  |	|  |  |	 |
	       N3|1 |1 |1 |1 |	|  |  |	 |  |  |  |  |	|  |  |	 |
	       N4|  |  |2 |  |	|  |  |	 |  |  |  |  |	|  |  |	 |
	       N6|  |  |  |  |	|  |1 |1 |  |1 |  |  |	|  |  |	 |
	       N7|  |  |  |  |	|  |  |4 |  |  |  |  |	|  |  |	 |
	       N8|  |  |  |  |	|  |  |	 |  |3 |2 |  |	|  |  |	 |
	       N9|  |  |  |  |	|  |  |	 |1 |  |1 |1 |	|  |  |	 |
	      N10|  |  |  |  |	|  |  |	 |  |  |  |2 |	|  |  |	 |
	      N11|  |  |  |  |	|  |  |	 |3 |  |  |  |	|  |  |	 |
	      N12|  |  |  |  |8	|  |2 |	 |  |  |  |  |	|  |  |	 |
	      N13|  |  |  |  |8	|  |  |	 |  |  |  |  |	|  |  |	 |
	      N14|  |  |  |  |8	|  |  |	 |  |  |  |  |	|  |  |	 |
	      N15|  |  |  |  |	|  |9 |	 |  |  |  |  |	|  |  |	 |
	       H1|  |  |  |  |	|  |  |	 |  |  |  |10|	|  |  |	 |

		     Figure 3: The resulting directed graph

		 Networks and routers are represented by vertices.
		 An edge of cost X connects Vertex A to	Vertex B iff
		 the intersection of Column A and Row B	is marked
				     with an X.

Moy			    Standards Track		       [Page 20]



RFC 2328		     OSPF Version 2		      April 1998

		     **FROM**			    **FROM**

		  |RT12|N9|N10|H1|		   |RT9|RT11|RT12|N9|
	   *  --------------------	    *  ----------------------
	   *  RT12|    |  |   |	 |	    *	RT9|   |    |	 |0 |
	   T	N9|1   |  |   |	 |	    T  RT11|   |    |	 |0 |
	   O   N10|2   |  |   |	 |	    O  RT12|   |    |	 |0 |
	   *	H1|10  |  |   |	 |	    *	 N9|   |    |	 |  |
	   *				    *
		RT12's router-LSA	       N9's network-LSA

		  Figure 4: Individual link state components

	      Networks and routers are represented by vertices.
	      An edge of cost X	connects Vertex	A to Vertex B iff
	      the intersection of Column A and Row B is	marked
				  with an X.

    2.2.  The shortest-path tree

	When no	OSPF areas are configured, each	router in the Autonomous
	System has an identical	link-state database, leading to	an
	identical graphical representation.  A router generates	its
	routing	table from this	graph by calculating a tree of shortest
	paths with the router itself as	root.  Obviously, the shortest-
	path tree depends on the router	doing the calculation.	The
	shortest-path tree for Router RT6 in our example is depicted in
	Figure 5.

	The tree gives the entire path to any destination network or
	host.  However,	only the next hop to the destination is	used in
	the forwarding process.	 Note also that	the best route to any
	router has also	been calculated.  For the processing of	external
	data, we note the next hop and distance	to any router
	advertising external routes.  The resulting routing table for
	Router RT6 is pictured in Table	2.  Note that there is a
	separate route for each	end of a numbered point-to-point network
	(in this case, the serial line between Routers RT6 and RT10).

	Routes to networks belonging to	other AS'es (such as N12) appear
	as dashed lines	on the shortest	path tree in Figure 5.	Use of

Moy			    Standards Track		       [Page 21]



RFC 2328		     OSPF Version 2		      April 1998

				RT6(origin)
		    RT5	o------------o-----------o Ib
		       /|\    6	     |\	    7
		     8/8|8\	     | \
		     /	|  \	    6|	\
		    o	|   o	     |	 \7
		   N12	o  N14	     |	  \
		       N13	  2  |	   \
			    N4 o-----o RT3  \
				    /	     \	  5
				  1/	 RT10 o-------o	Ia
				  /	      |\
		       RT4 o-----o N3	     3|	\1
				/|	      |	 \ N6	  RT7
			       / |	   N8 o	  o---------o
			      /	 |	      |	  |	   /|
			 RT2 o	 o RT1	      |	  |	 2/ |9
			    /	 |	      |	  |RT8	 /  |
			   /3	 |3	 RT11 o	  o	o   o
			  /	 |	      |	  |    N12 N15
		      N2 o	 o N1	     1|	  |4
					      |	  |
					   N9 o	  o N7
					     /|
					    / |
			N11	 RT9	   /  |RT12
			 o--------o-------o   o--------o H1
			     3		      |	  10
					      |2
					      |
					      o	N10

		     Figure 5: The SPF tree for	Router RT6

	      Edges that are not marked	with a cost have a cost	of
	      of zero (these are network-to-router links). Routes
	      to networks N12-N15 are external information that	is
			 considered in Section 2.3

Moy			    Standards Track		       [Page 22]



RFC 2328		     OSPF Version 2		      April 1998

		   Destination	 Next  Hop   Distance
		   __________________________________
		   N1		 RT3	     10
		   N2		 RT3	     10
		   N3		 RT3	     7
		   N4		 RT3	     8
		   Ib		 *	     7
		   Ia		 RT10	     12
		   N6		 RT10	     8
		   N7		 RT10	     12
		   N8		 RT10	     10
		   N9		 RT10	     11
		   N10		 RT10	     13
		   N11		 RT10	     14
		   H1		 RT10	     21
		   __________________________________
		   RT5		 RT5	     6
		   RT7		 RT10	     8

    Table 2: The portion of Router RT6's routing table listing local
			     destinations.

	this externally	derived	routing	information is considered in the
	next section.

    2.3.  Use of external routing information

	After the tree is created the external routing information is
	examined.  This	external routing information may originate from
	another	routing	protocol such as BGP, or be statically
	configured (static routes).  Default routes can	also be	included
	as part	of the Autonomous System's external routing information.

	External routing information is	flooded	unaltered throughout the
	AS.  In	our example, all the routers in	the Autonomous System
	know that Router RT7 has two external routes, with metrics 2 and
	9.

	OSPF supports two types	of external metrics.  Type 1 external
	metrics	are expressed in the same units	as OSPF	interface cost

Moy			    Standards Track		       [Page 23]



RFC 2328		     OSPF Version 2		      April 1998

	(i.e., in terms	of the link state metric).  Type 2 external
	metrics	are an order of	magnitude larger; any Type 2 metric is
	considered greater than	the cost of any	path internal to the AS.
	Use of Type 2 external metrics assumes that routing between
	AS'es is the major cost	of routing a packet, and eliminates the
	need for conversion of external	costs to internal link state
	metrics.

	As an example of Type 1	external metric	processing, suppose that
	the Routers RT7	and RT5	in Figure 2 are	advertising Type 1
	external metrics.  For each advertised external	route, the total
	cost from Router RT6 is	calculated as the sum of the external
	route's	advertised cost	and the	distance from Router RT6 to the
	advertising router.  When two routers are advertising the same
	external destination, RT6 picks	the advertising	router providing
	the minimum total cost.	RT6 then sets the next hop to the
	external destination equal to the next hop that	would be used
	when routing packets to	the chosen advertising router.

	In Figure 2, both Router RT5 and RT7 are advertising an	external
	route to destination Network N12.  Router RT7 is preferred since
	it is advertising N12 at a distance of 10 (8+2)	to Router RT6,
	which is better	than Router RT5's 14 (6+8).  Table 3 shows the
	entries	that are added to the routing table when external routes
	are examined:

			 Destination   Next  Hop   Distance
			 __________________________________
			 N12	       RT10	   10
			 N13	       RT5	   14
			 N14	       RT5	   14
			 N15	       RT10	   17

		 Table 3: The portion of Router	RT6's routing table
			   listing external destinations.

	Processing of Type 2 external metrics is simpler.  The AS
	boundary router	advertising the	smallest external metric is

Moy			    Standards Track		       [Page 24]



RFC 2328		     OSPF Version 2		      April 1998

	chosen,	regardless of the internal distance to the AS boundary
	router.	 Suppose in our	example	both Router RT5	and Router RT7
	were advertising Type 2	external routes.  Then all traffic
	destined for Network N12 would be forwarded to Router RT7, since
	2 < 8.	When several equal-cost	Type 2 routes exist, the
	internal distance to the advertising routers is	used to	break
	the tie.

	Both Type 1 and	Type 2 external	metrics	can be present in the AS
	at the same time.  In that event, Type 1 external metrics always
	take precedence.

	This section has assumed that packets destined for external
	destinations are always	routed through the advertising AS
	boundary router.  This is not always desirable.	 For example,
	suppose	in Figure 2 there is an	additional router attached to
	Network	N6, called Router RTX.	Suppose	further	that RTX does
	not participate	in OSPF	routing, but does exchange BGP
	information with the AS	boundary router	RT7.  Then, Router RT7
	would end up advertising OSPF external routes for all
	destinations that should be routed to RTX.  An extra hop will
	sometimes be introduced	if packets for these destinations need
	always be routed first to Router RT7 (the advertising router).

	To deal	with this situation, the OSPF protocol allows an AS
	boundary router	to specify a "forwarding address" in its AS-
	external-LSAs.	In the above example, Router RT7 would specify
	RTX's IP address as the	"forwarding address" for all those
	destinations whose packets should be routed directly to	RTX.

	The "forwarding	address" has one other application.  It	enables
	routers	in the Autonomous System's interior to function	as
	"route servers".  For example, in Figure 2 the router RT6 could
	become a route server, gaining external	routing	information
	through	a combination of static	configuration and external
	routing	protocols.  RT6	would then start advertising itself as
	an AS boundary router, and would originate a collection	of OSPF
	AS-external-LSAs.  In each AS-external-LSA, Router RT6 would
	specify	the correct Autonomous System exit point to use	for the
	destination through appropriate	setting	of the LSA's "forwarding
	address" field.

Moy			    Standards Track		       [Page 25]



RFC 2328		     OSPF Version 2		      April 1998

    2.4.  Equal-cost multipath

	The above discussion has been simplified by considering	only a
	single route to	any destination.  In reality, if multiple
	equal-cost routes to a destination exist, they are all
	discovered and used.  This requires no conceptual changes to the
	algorithm, and its discussion is postponed until we consider the
	tree-building process in more detail.

	With equal cost	multipath, a router potentially	has several
	available next hops towards any	given destination.

3.  Splitting the AS into Areas

    OSPF allows	collections of contiguous networks and hosts to	be
    grouped together.  Such a group, together with the routers having
    interfaces to any one of the included networks, is called an area.
    Each area runs a separate copy of the basic	link-state routing
    algorithm.	This means that	each area has its own link-state
    database and corresponding graph, as explained in the previous
    section.

    The	topology of an area is invisible from the outside of the area.
    Conversely,	routers	internal to a given area know nothing of the
    detailed topology external to the area.  This isolation of knowledge
    enables the	protocol to effect a marked reduction in routing traffic
    as compared	to treating the	entire Autonomous System as a single
    link-state domain.

    With the introduction of areas, it is no longer true that all
    routers in the AS have an identical	link-state database.  A	router
    actually has a separate link-state database	for each area it is
    connected to.  (Routers connected to multiple areas	are called area
    border routers).  Two routers belonging to the same	area have, for
    that area, identical area link-state databases.

    Routing in the Autonomous System takes place on two	levels,
    depending on whether the source and	destination of a packet	reside
    in the same	area (intra-area routing is used) or different areas
    (inter-area	routing	is used).  In intra-area routing, the packet is
    routed solely on information obtained within the area; no routing

Moy			    Standards Track		       [Page 26]



RFC 2328		     OSPF Version 2		      April 1998

    information	obtained from outside the area can be used.  This
    protects intra-area	routing	from the injection of bad routing
    information.  We discuss inter-area	routing	in Section 3.2.

    3.1.  The backbone of the Autonomous System

	The OSPF backbone is the special OSPF Area 0 (often written as
	Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP
	addresses). The	OSPF backbone always contains all area border
	routers. The backbone is responsible for distributing routing
	information between non-backbone areas.	The backbone must be
	contiguous. However, it	need not be physically contiguous;
	backbone connectivity can be established/maintained through the
	configuration of virtual links.

	Virtual	links can be configured	between	any two	backbone routers
	that have an interface to a common non-backbone	area.  Virtual
	links belong to	the backbone.  The protocol treats two routers
	joined by a virtual link as if they were connected by an
	unnumbered point-to-point backbone network.  On	the graph of the
	backbone, two such routers are joined by arcs whose costs are
	the intra-area distances between the two routers.  The routing
	protocol traffic that flows along the virtual link uses	intra-
	area routing only.

    3.2.  Inter-area routing

	When routing a packet between two non-backbone areas the
	backbone is used.  The path that the packet will travel	can be
	broken up into three contiguous	pieces:	an intra-area path from
	the source to an area border router, a backbone	path between the
	source and destination areas, and then another intra-area path
	to the destination.  The algorithm finds the set of such paths
	that have the smallest cost.

	Looking	at this	another	way, inter-area	routing	can be pictured
	as forcing a star configuration	on the Autonomous System, with
	the backbone as	hub and	each of	the non-backbone areas as
	spokes.

Moy			    Standards Track		       [Page 27]



RFC 2328		     OSPF Version 2		      April 1998

	The topology of	the backbone dictates the backbone paths used
	between	areas.	The topology of	the backbone can be enhanced by
	adding virtual links.  This gives the system administrator some
	control	over the routes	taken by inter-area traffic.

	The correct area border	router to use as the packet exits the
	source area is chosen in exactly the same way routers
	advertising external routes are	chosen.	 Each area border router
	in an area summarizes for the area its cost to all networks
	external to the	area.  After the SPF tree is calculated	for the
	area, routes to	all inter-area destinations are	calculated by
	examining the summaries	of the area border routers.

    3.3.  Classification of routers

	Before the introduction	of areas, the only OSPF	routers	having a
	specialized function were those	advertising external routing
	information, such as Router RT5	in Figure 2.  When the AS is
	split into OSPF	areas, the routers are further divided according
	to function into the following four overlapping	categories:

	Internal routers
	    A router with all directly connected networks belonging to
	    the	same area. These routers run a single copy of the basic
	    routing algorithm.

	Area border routers
	    A router that attaches to multiple areas.  Area border
	    routers run	multiple copies	of the basic algorithm,	one copy
	    for	each attached area. Area border	routers	condense the
	    topological	information of their attached areas for
	    distribution to the	backbone.  The backbone	in turn
	    distributes	the information	to the other areas.

	Backbone routers
	    A router that has an interface to the backbone area.  This
	    includes all routers that interface	to more	than one area
	    (i.e., area	border routers).  However, backbone routers do
	    not	have to	be area	border routers.	 Routers with all
	    interfaces connecting to the backbone area are supported.

Moy			    Standards Track		       [Page 28]



RFC 2328		     OSPF Version 2		      April 1998

	AS boundary routers
	    A router that exchanges routing information	with routers
	    belonging to other Autonomous Systems.  Such a router
	    advertises AS external routing information throughout the
	    Autonomous System.	The paths to each AS boundary router are
	    known by every router in the AS.  This classification is
	    completely independent of the previous classifications: AS
	    boundary routers may be internal or	area border routers, and
	    may	or may not participate in the backbone.

    3.4.  A sample area	configuration

	Figure 6 shows a sample	area configuration.  The first area
	consists of networks N1-N4, along with their attached routers
	RT1-RT4.  The second area consists of networks N6-N8, along with
	their attached routers RT7, RT8, RT10 and RT11.	 The third area
	consists of networks N9-N11 and	Host H1, along with their
	attached routers RT9, RT11 and RT12.  The third	area has been
	configured so that networks N9-N11 and Host H1 will all	be
	grouped	into a single route, when advertised external to the
	area (see Section 3.5 for more details).

	In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are
	internal routers.  Routers RT3,	RT4, RT7, RT10 and RT11	are area
	border routers.	 Finally, as before, Routers RT5 and RT7 are AS
	boundary routers.

	Figure 7 shows the resulting link-state	database for the Area 1.
	The figure completely describes	that area's intra-area routing.
	It also	shows the complete view	of the internet	for the	two
	internal routers RT1 and RT2.  It is the job of	the area border
	routers, RT3 and RT4, to advertise into	Area 1 the distances to
	all destinations external to the area.	These are indicated in
	Figure 7 by the	dashed stub routes.  Also, RT3 and RT4 must
	advertise into Area 1 the location of the AS boundary routers
	RT5 and	RT7.  Finally, AS-external-LSAs	from RT5 and RT7 are
	flooded	throughout the entire AS, and in particular throughout
	Area 1.	 These LSAs are	included in Area 1's database, and yield
	routes to Networks N12-N15.

	Routers	RT3 and	RT4 must also summarize	Area 1's topology for

Moy			    Standards Track		       [Page 29]



RFC 2328		     OSPF Version 2		      April 1998

	     ...........................
	     .	 +		       .
	     .	 | 3+---+	       .      N12      N14
	     . N1|--|RT1|\ 1	       .	\ N13 /
	     .	 |  +---+ \	       .	8\ |8/8
	     .	 +	   \ ____      .	  \|/
	     .		    /	 \   1+---+8	8+---+6
	     .		   *  N3  *---|RT4|------|RT5|--------+
	     .		    \____/    +---+	 +---+	      |
	     .	  +	    /	   \   .	   |7	      |
	     .	  | 3+---+ /	    \  .	   |	      |
	     .	N2|--|RT2|/1	    1\ .	   |6	      |
	     .	  |  +---+	      +---+8	6+---+	      |
	     .	  +		      |RT3|------|RT6|	      |
	     .			      +---+	 +---+	      |
	     .			    2/ .	 Ia|7	      |
	     .			    /  .	   |	      |
	     .		   +---------+ .	   |	      |
	     .Area 1	       N4      .	   |	      |
	     ...........................	   |	      |
	  ..........................		   |	      |
	  .	       N11	   .		   |	      |
	  .	   +---------+	   .		   |	      |
	  .		|	   .		   |	      |	   N12
	  .		|3	   .		 Ib|5	      |6 2/
	  .	      +---+	   .		 +----+	    +---+/
	  .	      |RT9|	   .	.........|RT10|.....|RT7|---N15.
	  .	      +---+	   .	.	 +----+	    +---+ 9    .
	  .		|1	   .	.    +	/3    1\      |1       .
	  .	       _|__	   .	.    | /	\   __|_       .
	  .	      /	   \	  1+----+2   |/		 \ /	\      .
	  .	     *	N9  *------|RT11|----|		  *  N6	 *     .
	  .	      \____/	   +----+    |		   \____/      .
	  .		|	   .	.    |		      |	       .
	  .		|1	   .	.    +		      |1       .
	  .  +--+   10+----+	   .	.   N8		    +---+      .
	  .  |H1|-----|RT12|	   .	.		    |RT8|      .
	  .  +--+SLIP +----+	   .	.		    +---+      .
	  .		|2	   .	.		      |4       .
	  .		|	   .	.		      |	       .
	  .	   +---------+	   .	.		  +--------+   .

Moy			    Standards Track		       [Page 30]



RFC 2328		     OSPF Version 2		      April 1998

	  .	       N10	   .	.		      N7       .
	  .			   .	.Area 2			       .
	  .Area	3		   .	................................
	  ..........................

		    Figure 6: A	sample OSPF area configuration

	distribution to	the backbone.  Their backbone LSAs are shown in
	Table 4.  These	summaries show which networks are contained in
	Area 1 (i.e., Networks N1-N4), and the distance	to these
	networks from the routers RT3 and RT4 respectively.

	The link-state database	for the	backbone is shown in Figure 8.
	The set	of routers pictured are	the backbone routers.  Router
	RT11 is	a backbone router because it belongs to	two areas.  In
	order to make the backbone connected, a	virtual	link has been
	configured between Routers R10 and R11.

	The area border	routers	RT3, RT4, RT7, RT10 and	RT11 condense
	the routing information	of their attached non-backbone areas for
	distribution via the backbone; these are the dashed stubs that
	appear in Figure 8.  Remember that the third area has been
	configured to condense Networks	N9-N11 and Host	H1 into	a single
	route.	This yields a single dashed line for networks N9-N11 and
	Host H1	in Figure 8.  Routers RT5 and RT7 are AS boundary
	routers; their externally derived information also appears on
	the graph in Figure 8 as stubs.

		     Network   RT3 adv.	  RT4 adv.
		     _____________________________
		     N1	       4	  4
		     N2	       4	  4
		     N3	       1	  1
		     N4	       2	  3

	      Table 4: Networks	advertised to the backbone
			by Routers RT3 and RT4.

Moy			    Standards Track		       [Page 31]



RFC 2328		     OSPF Version 2		      April 1998

			       **FROM**

			  |RT|RT|RT|RT|RT|RT|
			  |1 |2	|3 |4 |5 |7 |N3|
		       ----- -------------------
		       RT1|  |	|  |  |	 |  |0 |
		       RT2|  |	|  |  |	 |  |0 |
		       RT3|  |	|  |  |	 |  |0 |
		   *   RT4|  |	|  |  |	 |  |0 |
		   *   RT5|  |	|14|8 |	 |  |  |
		   T   RT7|  |	|20|14|	 |  |  |
		   O	N1|3 |	|  |  |	 |  |  |
		   *	N2|  |3	|  |  |	 |  |  |
		   *	N3|1 |1	|1 |1 |	 |  |  |
			N4|  |	|2 |  |	 |  |  |
		     Ia,Ib|  |	|20|27|	 |  |  |
			N6|  |	|16|15|	 |  |  |
			N7|  |	|20|19|	 |  |  |
			N8|  |	|18|18|	 |  |  |
		 N9-N11,H1|  |	|29|36|	 |  |  |
		       N12|  |	|  |  |8 |2 |  |
		       N13|  |	|  |  |8 |  |  |
		       N14|  |	|  |  |8 |  |  |
		       N15|  |	|  |  |	 |9 |  |

		      Figure 7:	Area 1's Database.

	      Networks and routers are represented by vertices.
	      An edge of cost X	connects Vertex	A to Vertex B iff
	      the intersection of Column A and Row B is	marked
			       with an X.

Moy			    Standards Track		       [Page 32]



RFC 2328		     OSPF Version 2		      April 1998

				  **FROM**

			    |RT|RT|RT|RT|RT|RT|RT
			    |3 |4 |5 |6	|7 |10|11|
			 ------------------------
			 RT3|  |  |  |6	|  |  |	 |
			 RT4|  |  |8 |	|  |  |	 |
			 RT5|  |8 |  |6	|6 |  |	 |
			 RT6|8 |  |7 |	|  |5 |	 |
			 RT7|  |  |6 |	|  |  |	 |
		     *	RT10|  |  |  |7	|  |  |2 |
		     *	RT11|  |  |  |	|  |3 |	 |
		     T	  N1|4 |4 |  |	|  |  |	 |
		     O	  N2|4 |4 |  |	|  |  |	 |
		     *	  N3|1 |1 |  |	|  |  |	 |
		     *	  N4|2 |3 |  |	|  |  |	 |
			  Ia|  |  |  |	|  |5 |	 |
			  Ib|  |  |  |7	|  |  |	 |
			  N6|  |  |  |	|1 |1 |3 |
			  N7|  |  |  |	|5 |5 |7 |
			  N8|  |  |  |	|4 |3 |2 |
		   N9-N11,H1|  |  |  |	|  |  |11|
			 N12|  |  |8 |	|2 |  |	 |
			 N13|  |  |8 |	|  |  |	 |
			 N14|  |  |8 |	|  |  |	 |
			 N15|  |  |  |	|9 |  |	 |

		     Figure 8: The backbone's database.

	      Networks and routers are represented by vertices.
	      An edge of cost X	connects Vertex	A to Vertex B iff
	      the intersection of Column A and Row B is	marked
				 with an X.

	The backbone enables the exchange of summary information between
	area border routers.  Every area border	router hears the area
	summaries from all other area border routers.  It then forms a
	picture	of the distance	to all networks	outside	of its area by
	examining the collected	LSAs, and adding in the	backbone
	distance to each advertising router.

Moy			    Standards Track		       [Page 33]



RFC 2328		     OSPF Version 2		      April 1998

	Again using Routers RT3	and RT4	as an example, the procedure
	goes as	follows: They first calculate the SPF tree for the
	backbone.  This	gives the distances to all other area border
	routers.  Also noted are the distances to networks (Ia and Ib)
	and AS boundary	routers	(RT5 and RT7) that belong to the
	backbone.  This	calculation is shown in	Table 5.

	Next, by looking at the	area summaries from these area border
	routers, RT3 and RT4 can determine the distance	to all networks
	outside	their area.  These distances are then advertised
	internally to the area by RT3 and RT4.	The advertisements that
	Router RT3 and RT4 will	make into Area 1 are shown in Table 6.
	Note that Table	6 assumes that an area range has been configured
	for the	backbone which groups Ia and Ib	into a single LSA.

	The information	imported into Area 1 by	Routers	RT3 and	RT4
	enables	an internal router, such as RT1, to choose an area
	border router intelligently.  Router RT1 would use RT4 for
	traffic	to Network N6, RT3 for traffic to Network N10, and would

			      dist  from   dist	 from
			      RT3	   RT4
		   __________________________________
		   to  RT3    *		   21
		   to  RT4    22	   *
		   to  RT7    20	   14
		   to  RT10   15	   22
		   to  RT11   18	   25
		   __________________________________
		   to  Ia     20	   27
		   to  Ib     15	   22
		   __________________________________
		   to  RT5    14	   8
		   to  RT7    20	   14

		 Table 5: Backbone distances calculated
			by Routers RT3 and RT4.

Moy			    Standards Track		       [Page 34]



RFC 2328		     OSPF Version 2		      April 1998

		   Destination	 RT3 adv.   RT4	adv.
		   _________________________________
		   Ia,Ib	 20	    27
		   N6		 16	    15
		   N7		 20	    19
		   N8		 18	    18
		   N9-N11,H1	 29	    36
		   _________________________________
		   RT5		 14	    8
		   RT7		 20	    14

	      Table 6: Destinations advertised into Area 1
			by Routers RT3 and RT4.

	load share between the two for traffic to Network N8.

	Router RT1 can also determine in this manner the shortest path
	to the AS boundary routers RT5 and RT7.	 Then, by looking at RT5
	and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or
	RT7 when sending to a destination in another Autonomous	System
	(one of	the networks N12-N15).

	Note that a failure of the line	between	Routers	RT6 and	RT10
	will cause the backbone	to become disconnected.	 Configuring a
	virtual	link between Routers RT7 and RT10 will give the	backbone
	more connectivity and more resistance to such failures.

    3.5.  IP subnetting	support

	OSPF attaches an IP address mask to each advertised route.  The
	mask indicates the range of addresses being described by the
	particular route.  For example,	a summary-LSA for the
	destination 128.185.0.0	with a mask of 0xffff0000 actually is
	describing a single route to the collection of destinations
	128.185.0.0 - 128.185.255.255.	Similarly, host	routes are
	always advertised with a mask of 0xffffffff, indicating	the
	presence of only a single destination.

Moy			    Standards Track		       [Page 35]



RFC 2328		     OSPF Version 2		      April 1998

	Including the mask with	each advertised	destination enables the
	implementation of what is commonly referred to as variable-
	length subnetting.  This means that a single IP	class A, B, or C
	network	number can be broken up	into many subnets of various
	sizes.	For example, the network 128.185.0.0 could be broken up
	into 62	variable-sized subnets:	15 subnets of size 4K, 15
	subnets	of size	256, and 32 subnets of size 8.	Table 7	shows
	some of	the resulting network addresses	together with their
	masks.

		  Network address   IP address mask   Subnet size
		  _______________________________________________
		  128.185.16.0	    0xfffff000	      4K
		  128.185.1.0	    0xffffff00	      256
		  128.185.0.8	    0xfffffff8	      8

			 Table 7: Some sample subnet sizes.

	There are many possible	ways of	dividing up a class A, B, and C
	network	into variable sized subnets.  The precise procedure for
	doing so is beyond the scope of	this specification.  This
	specification however establishes the following	guideline: When
	an IP packet is	forwarded, it is always	forwarded to the network
	that is	the best match for the packet's	destination.  Here best
	match is synonymous with the longest or	most specific match.
	For example, the default route with destination	of 0.0.0.0 and
	mask 0x00000000	is always a match for every IP destination.  Yet
	it is always less specific than	any other match.  Subnet masks
	must be	assigned so that the best match	for any	IP destination
	is unambiguous.

	Attaching an address mask to each route	also enables the support
	of IP supernetting. For	example, a single physical network
	segment	could be assigned the [address,mask] pair
	[192.9.4.0,0xfffffc00].	The segment would then be single IP
	network, containing addresses from the four consecutive	class C
	network	numbers	192.9.4.0 through 192.9.7.0. Such addressing is
	now becoming commonplace with the advent of CIDR (see [Ref10]).

Moy			    Standards Track		       [Page 36]



RFC 2328		     OSPF Version 2		      April 1998

	In order to get	better aggregation at area boundaries, area
	address	ranges can be employed (see Section C.2	for more
	details).  Each	address	range is defined as an [address,mask]
	pair.  Many separate networks may then be contained in a single
	address	range, just as a subnetted network is composed of many
	separate subnets.  Area	border routers then summarize the area
	contents (for distribution to the backbone) by advertising a
	single route for each address range.  The cost of the route is
	the maximum cost to any	of the networks	falling	in the specified
	range.

	For example, an	IP subnetted network might be configured as a
	single OSPF area.  In that case, a single address range	could be
	configured:  a class A,	B, or C	network	number along with its
	natural	IP mask.  Inside the area, any number of variable sized
	subnets	could be defined.  However, external to	the area a
	single route for the entire subnetted network would be
	distributed, hiding even the fact that the network is subnetted
	at all.	 The cost of this route	is the maximum of the set of
	costs to the component subnets.

    3.6.  Supporting stub areas

	In some	Autonomous Systems, the	majority of the	link-state
	database may consist of	AS-external-LSAs.  An OSPF AS-external-
	LSA is usually flooded throughout the entire AS.  However, OSPF
	allows certain areas to	be configured as "stub areas".	AS-
	external-LSAs are not flooded into/throughout stub areas;
	routing	to AS external destinations in these areas is based on a
	(per-area) default only.  This reduces the link-state database
	size, and therefore the	memory requirements, for a stub	area's
	internal routers.

	In order to take advantage of the OSPF stub area support,
	default	routing	must be	used in	the stub area.	This is
	accomplished as	follows.  One or more of the stub area's area
	border routers must advertise a	default	route into the stub area
	via summary-LSAs.  These summary defaults are flooded throughout
	the stub area, but no further.	(For this reason these defaults
	pertain	only to	the particular stub area).  These summary
	default	routes will be used for	any destination	that is	not

Moy			    Standards Track		       [Page 37]



RFC 2328		     OSPF Version 2		      April 1998

	explicitly reachable by	an intra-area or inter-area path (i.e.,
	AS external destinations).

	An area	can be configured as a stub when there is a single exit
	point from the area, or	when the choice	of exit	point need not
	be made	on a per-external-destination basis.  For example, Area
	3 in Figure 6 could be configured as a stub area, because all
	external traffic must travel though its	single area border
	router RT11.  If Area 3	were configured	as a stub, Router RT11
	would advertise	a default route	for distribution inside	Area 3
	(in a summary-LSA), instead of flooding	the AS-external-LSAs for
	Networks N12-N15 into/throughout the area.

	The OSPF protocol ensures that all routers belonging to	an area
	agree on whether the area has been configured as a stub.  This
	guarantees that	no confusion will arise	in the flooding	of AS-
	external-LSAs.

	There are a couple of restrictions on the use of stub areas.
	Virtual	links cannot be	configured through stub	areas.	In
	addition, AS boundary routers cannot be	placed internal	to stub
	areas.

    3.7.  Partitions of	areas

	OSPF does not actively attempt to repair area partitions.  When
	an area	becomes	partitioned, each component simply becomes a
	separate area.	The backbone then performs routing between the
	new areas.  Some destinations reachable	via intra-area routing
	before the partition will now require inter-area routing.

	However, in order to maintain full routing after the partition,
	an address range must not be split across multiple components of
	the area partition. Also, the backbone itself must not
	partition.  If it does,	parts of the Autonomous	System will
	become unreachable.  Backbone partitions can be	repaired by
	configuring virtual links (see Section 15).

	Another	way to think about area	partitions is to look at the
	Autonomous System graph	that was introduced in Section 2.  Area
	IDs can	be viewed as colors for	the graph's edges.[1] Each edge

Moy			    Standards Track		       [Page 38]



RFC 2328		     OSPF Version 2		      April 1998

	of the graph connects to a network, or is itself a point-to-
	point network.	In either case,	the edge is colored with the
	network's Area ID.

	A group	of edges, all having the same color, and interconnected
	by vertices, represents	an area.  If the topology of the
	Autonomous System is intact, the graph will have several regions
	of color, each color being a distinct Area ID.

	When the AS topology changes, one of the areas may become
	partitioned.  The graph	of the AS will then have multiple
	regions	of the same color (Area	ID).  The routing in the
	Autonomous System will continue	to function as long as these
	regions	of same	color are connected by the single backbone
	region.

Moy			    Standards Track		       [Page 39]



RFC 2328		     OSPF Version 2		      April 1998

4.  Functional Summary

    A separate copy of OSPF's basic routing algorithm runs in each area.
    Routers having interfaces to multiple areas	run multiple copies of
    the	algorithm.  A brief summary of the routing algorithm follows.

    When a router starts, it first initializes the routing protocol data
    structures.	 The router then waits for indications from the	lower-
    level protocols that its interfaces	are functional.

    A router then uses the OSPF's Hello	Protocol to acquire neighbors.
    The	router sends Hello packets to its neighbors, and in turn
    receives their Hello packets.  On broadcast	and point-to-point
    networks, the router dynamically detects its neighboring routers by
    sending its	Hello packets to the multicast address AllSPFRouters.
    On non-broadcast networks, some configuration information may be
    necessary in order to discover neighbors.  On broadcast and	NBMA
    networks the Hello Protocol	also elects a Designated router	for the
    network.

    The	router will attempt to form adjacencies	with some of its newly
    acquired neighbors.	 Link-state databases are synchronized between
    pairs of adjacent routers.	On broadcast and NBMA networks,	the
    Designated Router determines which routers should become adjacent.

    Adjacencies	control	the distribution of routing information.
    Routing updates are	sent and received only on adjacencies.

    A router periodically advertises its state,	which is also called
    link state.	 Link state is also advertised when a router's state
    changes.  A	router's adjacencies are reflected in the contents of
    its	LSAs.  This relationship between adjacencies and link state
    allows the protocol	to detect dead routers in a timely fashion.

    LSAs are flooded throughout	the area.  The flooding	algorithm is
    reliable, ensuring that all	routers	in an area have	exactly	the same
    link-state database.  This database	consists of the	collection of
    LSAs originated by each router belonging to	the area.  From	this
    database each router calculates a shortest-path tree, with itself as
    root.  This	shortest-path tree in turn yields a routing table for
    the	protocol.

Moy			    Standards Track		       [Page 40]



RFC 2328		     OSPF Version 2		      April 1998

    4.1.  Inter-area routing

	The previous section described the operation of	the protocol
	within a single	area.  For intra-area routing, no other	routing
	information is pertinent.  In order to be able to route	to
	destinations outside of	the area, the area border routers inject
	additional routing information into the	area.  This additional
	information is a distillation of the rest of the Autonomous
	System's topology.

	This distillation is accomplished as follows: Each area	border
	router is by definition	connected to the backbone.  Each area
	border router summarizes the topology of its attached non-
	backbone areas for transmission	on the backbone, and hence to
	all other area border routers.	An area	border router then has
	complete topological information concerning the	backbone, and
	the area summaries from	each of	the other area border routers.
	From this information, the router calculates paths to all
	inter-area destinations.  The router then advertises these paths
	into its attached areas.  This enables the area's internal
	routers	to pick	the best exit router when forwarding traffic
	inter-area destinations.

    4.2.  AS external routes

	Routers	that have information regarding	other Autonomous Systems
	can flood this information throughout the AS.  This external
	routing	information is distributed verbatim to every
	participating router.  There is	one exception: external	routing
	information is not flooded into	"stub" areas (see Section 3.6).

	To utilize external routing information, the path to all routers
	advertising external information must be known throughout the AS
	(excepting the stub areas).  For that reason, the locations of
	these AS boundary routers are summarized by the	(non-stub) area
	border routers.

Moy			    Standards Track		       [Page 41]



RFC 2328		     OSPF Version 2		      April 1998

    4.3.  Routing protocol packets

	The OSPF protocol runs directly	over IP, using IP protocol 89.
	OSPF does not provide any explicit fragmentation/reassembly
	support.  When fragmentation is	necessary, IP
	fragmentation/reassembly is used.  OSPF	protocol packets have
	been designed so that large protocol packets can generally be
	split into several smaller protocol packets.  This practice is
	recommended; IP	fragmentation should be	avoided	whenever
	possible.

	Routing	protocol packets should	always be sent with the	IP TOS
	field set to 0.	 If at all possible, routing protocol packets
	should be given	preference over	regular	IP data	traffic, both
	when being sent	and received.  As an aid to accomplishing this,
	OSPF protocol packets should have their	IP precedence field set
	to the value Internetwork Control (see [Ref5]).

	All OSPF protocol packets share	a common protocol header that is
	described in Appendix A.  The OSPF packet types	are listed below
	in Table 8.  Their formats are also described in Appendix A.

	     Type   Packet  name	   Protocol  function
	     __________________________________________________________
	     1	    Hello		   Discover/maintain  neighbors
	     2	    Database Description   Summarize database contents
	     3	    Link State Request	   Database download
	     4	    Link State Update	   Database update
	     5	    Link State Ack	   Flooding acknowledgment

			    Table 8: OSPF packet types.

	OSPF's Hello protocol uses Hello packets to discover and
	maintain neighbor relationships.  The Database Description and
	Link State Request packets are used in the forming of
	adjacencies.  OSPF's reliable update mechanism is implemented by
	the Link State Update and Link State Acknowledgment packets.

Moy			    Standards Track		       [Page 42]



RFC 2328		     OSPF Version 2		      April 1998

	Each Link State	Update packet carries a	set of new link	state
	advertisements (LSAs) one hop further away from	their point of
	origination.  A	single Link State Update packet	may contain the
	LSAs of	several	routers.  Each LSA is tagged with the ID of the
	originating router and a checksum of its link state contents.
	Each LSA also has a type field;	the different types of OSPF LSAs
	are listed below in Table 9.

	OSPF routing packets (with the exception of Hellos) are	sent
	only over adjacencies.	This means that	all OSPF protocol
	packets	travel a single	IP hop,	except those that are sent over
	virtual	adjacencies.  The IP source address of an OSPF protocol
	packet is one end of a router adjacency, and the IP destination
	address	is either the other end	of the adjacency or an IP
	multicast address.

    4.4.  Basic	implementation requirements

	An implementation of OSPF requires the following pieces	of
	system support:

	Timers
	    Two	different kind of timers are required.	The first kind,
	    called "single shot	timers", fire once and cause a protocol
	    event to be	processed.  The	second kind, called "interval
	    timers", fire at continuous	intervals.  These are used for
	    the	sending	of packets at regular intervals.  A good example
	    of this is the regular broadcast of	Hello packets. The
	    granularity	of both	kinds of timers	is one second.

	    Interval timers should be implemented to avoid drift.  In
	    some router	implementations, packet	processing can affect
	    timer execution.  When multiple routers are	attached to a
	    single network, all	doing broadcasts, this can lead	to the
	    synchronization of routing packets (which should be
	    avoided).  If timers cannot	be implemented to avoid	drift,
	    small random amounts should	be added to/subtracted from the
	    interval timer at each firing.

Moy			    Standards Track		       [Page 43]



RFC 2328		     OSPF Version 2		      April 1998

	LS     LSA		  LSA description
	type   name
	________________________________________________________
	1      Router-LSAs	  Originated by	all routers.
				  This LSA describes
				  the collected	states of the
				  router's interfaces to an
				  area.	Flooded	throughout a
				  single area only.
	________________________________________________________
	2      Network-LSAs	  Originated for broadcast
				  and NBMA networks by
				  the Designated Router. This
				  LSA contains the
				  list of routers connected
				  to the network. Flooded
				  throughout a single area only.
	________________________________________________________
	3,4    Summary-LSAs	  Originated by	area border
				  routers, and flooded through-
				  out the LSA's	associated
				  area.	Each summary-LSA
				  describes a route to a
				  destination outside the area,
				  yet still inside the AS
				  (i.e., an inter-area route).
				  Type 3 summary-LSAs describe
				  routes to networks. Type 4
				  summary-LSAs describe
				  routes to AS boundary	routers.
	________________________________________________________
	5      AS-external-LSAs	  Originated by	AS boundary
				  routers, and flooded through-
				  out the AS. Each
				  AS-external-LSA describes
				  a route to a destination in
				  another Autonomous System.
				  Default routes for the AS can
				  also be described by
				  AS-external-LSAs.

Moy			    Standards Track		       [Page 44]



RFC 2328		     OSPF Version 2		      April 1998

	    Table 9: OSPF link state advertisements (LSAs).

	IP multicast
	    Certain OSPF packets take the form of IP multicast
	    datagrams.	Support	for receiving and sending IP multicast
	    datagrams, along with the appropriate lower-level protocol
	    support, is	required.  The IP multicast datagrams used by
	    OSPF never travel more than	one hop. For this reason, the
	    ability to forward IP multicast datagrams is not required.
	    For	information on IP multicast, see [Ref7].

	Variable-length	subnet support
	    The	router's IP protocol support must include the ability to
	    divide a single IP class A,	B, or C	network	number into many
	    subnets of various sizes.  This is commonly	called
	    variable-length subnetting;	see Section 3.5	for details.

	IP supernetting	support
	    The	router's IP protocol support must include the ability to
	    aggregate contiguous collections of	IP class A, B, and C
	    networks into larger quantities called supernets.
	    Supernetting has been proposed as one way to improve the
	    scaling of IP routing in the worldwide Internet. For more
	    information	on IP supernetting, see	[Ref10].

	Lower-level protocol support
	    The	lower level protocols referred to here are the network
	    access protocols, such as the Ethernet data	link layer.
	    Indications	must be	passed from these protocols to OSPF as
	    the	network	interface goes up and down.  For example, on an
	    ethernet it	would be valuable to know when the ethernet
	    transceiver	cable becomes unplugged.

	Non-broadcast lower-level protocol support
	    On non-broadcast networks, the OSPF	Hello Protocol can be
	    aided by providing an indication when an attempt is	made to
	    send a packet to a dead or non-existent router.  For
	    example, on	an X.25	PDN a dead neighboring router may be

Moy			    Standards Track		       [Page 45]



RFC 2328		     OSPF Version 2		      April 1998

	    indicated by the reception of a X.25 clear with an
	    appropriate	cause and diagnostic, and this information would
	    be passed to OSPF.

	List manipulation primitives
	    Much of the	OSPF functionality is described	in terms of its
	    operation on lists of LSAs.	 For example, the collection of
	    LSAs that will be retransmitted to an adjacent router until
	    acknowledged are described as a list.  Any particular LSA
	    may	be on many such	lists.	An OSPF	implementation needs to
	    be able to manipulate these	lists, adding and deleting
	    constituent	LSAs as	necessary.

	Tasking	support
	    Certain procedures described in this specification invoke
	    other procedures.  At times, these other procedures	should
	    be executed	in-line, that is, before the current procedure
	    is finished.  This is indicated in the text	by instructions
	    to execute a procedure.  At	other times, the other
	    procedures are to be executed only when the	current
	    procedure has finished.  This is indicated by instructions
	    to schedule	a task.

    4.5.  Optional OSPF	capabilities

	The OSPF protocol defines several optional capabilities.  A
	router indicates the optional capabilities that	it supports in
	its OSPF Hello packets,	Database Description packets and in its
	LSAs.  This enables routers supporting a mix of	optional
	capabilities to	coexist	in a single Autonomous System.

	Some capabilities must be supported by all routers attached to a
	specific area.	In this	case, a	router will not	accept a
	neighbor's Hello Packet	unless there is	a match	in reported
	capabilities (i.e., a capability mismatch prevents a neighbor
	relationship from forming).  An	example	of this	is the
	ExternalRoutingCapability (see below).

	Other capabilities can be negotiated during the	Database
	Exchange process.  This	is accomplished	by specifying the
	optional capabilities in Database Description packets.	A

Moy			    Standards Track		       [Page 46]



RFC 2328		     OSPF Version 2		      April 1998

	capability mismatch with a neighbor in this case will result in
	only a subset of the link state	database being exchanged between
	the two	neighbors.

	The routing table build	process	can also be affected by	the
	presence/absence of optional capabilities.  For	example, since
	the optional capabilities are reported in LSAs,	routers
	incapable of certain functions can be avoided when building the
	shortest path tree.

	The OSPF optional capabilities defined in this memo are	listed
	below.	See Section A.2	for more information.

	ExternalRoutingCapability
	    Entire OSPF	areas can be configured	as "stubs" (see	Section
	    3.6).  AS-external-LSAs will not be	flooded	into stub areas.
	    This capability is represented by the E-bit	in the OSPF
	    Options field (see Section A.2).  In order to ensure
	    consistent configuration of	stub areas, all	routers
	    interfacing	to such	an area	must have the E-bit clear in
	    their Hello	packets	(see Sections 9.5 and 10.5).

5.  Protocol Data Structures

    The	OSPF protocol is described herein in terms of its operation on
    various protocol data structures.  The following list comprises the
    top-level OSPF data	structures.  Any initialization	that needs to be
    done is noted.  OSPF areas,	interfaces and neighbors also have
    associated data structures that are	described later	in this
    specification.

    Router ID
	A 32-bit number	that uniquely identifies this router in	the AS.
	One possible implementation strategy would be to use the
	smallest IP interface address belonging	to the router. If a
	router's OSPF Router ID	is changed, the	router's OSPF software
	should be restarted before the new Router ID takes effect.  In
	this case the router should flush its self-originated LSAs from
	the routing domain (see	Section	14.1) before restarting, or they
	will persist for up to MaxAge minutes.

Moy			    Standards Track		       [Page 47]



RFC 2328		     OSPF Version 2		      April 1998

    Area structures
	Each one of the	areas to which the router is connected has its
	own data structure.  This data structure describes the working
	of the basic OSPF algorithm.  Remember that each area runs a
	separate copy of the basic OSPF	algorithm.

    Backbone (area) structure
	The OSPF backbone area is responsible for the dissemination of
	inter-area routing information.

    Virtual links configured
	The virtual links configured with this router as one endpoint.
	In order to have configured virtual links, the router itself
	must be	an area	border router.	Virtual	links are identified by
	the Router ID of the other endpoint -- which is	another	area
	border router.	These two endpoint routers must	be attached to a
	common area, called the	virtual	link's Transit area.  Virtual
	links are part of the backbone,	and behave as if they were
	unnumbered point-to-point networks between the two routers.  A
	virtual	link uses the intra-area routing of its	Transit	area to
	forward	packets.  Virtual links	are brought up and down	through
	the building of	the shortest-path trees	for the	Transit	area.

    List of external routes
	These are routes to destinations external to the Autonomous
	System,	that have been gained either through direct experience
	with another routing protocol (such as BGP), or	through
	configuration information, or through a	combination of the two
	(e.g., dynamic external	information to be advertised by	OSPF
	with configured	metric). Any router having these external routes
	is called an AS	boundary router.  These	routes are advertised by
	the router into	the OSPF routing domain	via AS-external-LSAs.

    List of AS-external-LSAs
	Part of	the link-state database.  These	have originated	from the
	AS boundary routers.  They comprise routes to destinations
	external to the	Autonomous System.  Note that, if the router is
	itself an AS boundary router, some of these AS-external-LSAs
	have been self-originated.

Moy			    Standards Track		       [Page 48]



RFC 2328		     OSPF Version 2		      April 1998

    The	routing	table
	Derived	from the link-state database.  Each entry in the routing
	table is indexed by a destination, and contains	the
	destination's cost and a set of	paths to use in	forwarding
	packets	to the destination. A path is described	by its type and
	next hop.  For more information, see Section 11.

    Figure 9 shows the collection of data structures present in	a
    typical router.  The router	pictured is RT10, from the map in Figure
    6.	Note that Router RT10 has a virtual link configured to Router
    RT11, with Area 2 as the link's Transit area.  This	is indicated by
    the	dashed line in Figure 9.  When the virtual link	becomes	active,
    through the	building of the	shortest path tree for Area 2, it
    becomes an interface to the	backbone (see the two backbone
    interfaces depicted	in Figure 9).

6.  The	Area Data Structure

    The	area data structure contains all the information used to run the
    basic OSPF routing algorithm. Each area maintains its own link-state
    database. A	network	belongs	to a single area, and a	router interface
    connects to	a single area. Each router adjacency also belongs to a
    single area.

    The	OSPF backbone is the special OSPF area responsible for
    disseminating inter-area routing information.

    The	area link-state	database consists of the collection of router-
    LSAs, network-LSAs and summary-LSAs	that have originated from the
    area's routers.  This information is flooded throughout a single
    area only.	The list of AS-external-LSAs (see Section 5) is	also
    considered to be part of each area's link-state database.

    Area ID
	A 32-bit number	identifying the	area. The Area ID of 0.0.0.0 is
	reserved for the backbone.

    List of area address ranges
	In order to aggregate routing information at area boundaries,
	area address ranges can	be employed. Each address range	is
	specified by an	[address,mask] pair and	a status indication of
	either Advertise or DoNotAdvertise (see	Section	12.4.3).

Moy			    Standards Track		       [Page 49]



RFC 2328		     OSPF Version 2		      April 1998

			      +----+
			      |RT10|------+
			      +----+	   \+-------------+
			     /	    \	    |Routing Table|
			    /	     \	    +-------------+
			   /	      \
	      +------+	  /	       \    +--------+
	      |Area 2|---+		+---|Backbone|
	      +------+***********+	    +--------+
	     /	      \		  *	   /	      \
	    /	       \	   *	  /	       \
       +---------+  +---------+	   +------------+	+------------+
       |Interface|  |Interface|	   |Virtual Link|	|Interface Ib|
       |  to N6	 |  |  to N8  |	   |   to RT11	|	+------------+
       +---------+  +---------+	   +------------+	      |
	   /  \		  |		  |		      |
	  /    \	  |		  |		      |
   +--------+ +--------+  |	   +-------------+	+------------+
   |Neighbor| |Neighbor|  |	   |Neighbor RT11|	|Neighbor RT6|
   |  RT8   | |	 RT7   |  |	   +-------------+	+------------+
   +--------+ +--------+  |
			  |
		     +-------------+
		     |Neighbor RT11|
		     +-------------+

		Figure 9: Router RT10's	Data structures

    Associated router interfaces
	This router's interfaces connecting to the area.  A router
	interface belongs to one and only one area (or the backbone).
	For the	backbone area this list	includes all the virtual links.
	A virtual link is identified by	the Router ID of its other
	endpoint; its cost is the cost of the shortest intra-area path
	through	the Transit area that exists between the two routers.

Moy			    Standards Track		       [Page 50]



RFC 2328		     OSPF Version 2		      April 1998

    List of router-LSAs
	A router-LSA is	generated by each router in the	area.  It
	describes the state of the router's interfaces to the area.

    List of network-LSAs
	One network-LSA	is generated for each transit broadcast	and NBMA
	network	in the area.  A	network-LSA describes the set of routers
	currently connected to the network.

    List of summary-LSAs
	Summary-LSAs originate from the	area's area border routers.
	They describe routes to	destinations internal to the Autonomous
	System,	yet external to	the area (i.e.,	inter-area
	destinations).

    Shortest-path tree
	The shortest-path tree for the area, with this router itself as
	root.  Derived from the	collected router-LSAs and network-LSAs
	by the Dijkstra	algorithm (see Section 16.1).

    TransitCapability
	This parameter indicates whether the area can carry data traffic
	that neither originates	nor terminates in the area itself. This
	parameter is calculated	when the area's	shortest-path tree is
	built (see Section 16.1, where TransitCapability is set	to TRUE
	if and only if there are one or	more fully adjacent virtual
	links using the	area as	Transit	area), and is used as an input
	to a subsequent	step of	the routing table build	process	(see
	Section	16.3). When an area's TransitCapability	is set to TRUE,
	the area is said to be a "transit area".

    ExternalRoutingCapability
	Whether	AS-external-LSAs will be flooded into/throughout the
	area.  This is a configurable parameter.  If AS-external-LSAs
	are excluded from the area, the	area is	called a "stub". Within
	stub areas, routing to AS external destinations	will be	based
	solely on a default summary route.  The	backbone cannot	be
	configured as a	stub area.  Also, virtual links	cannot be
	configured through stub	areas.	For more information, see
	Section	3.6.

Moy			    Standards Track		       [Page 51]



RFC 2328		     OSPF Version 2		      April 1998

    StubDefaultCost
	If the area has	been configured	as a stub area,	and the	router
	itself is an area border router, then the StubDefaultCost
	indicates the cost of the default summary-LSA that the router
	should advertise into the area.	See Section 12.4.3 for more
	information.

    Unless otherwise specified,	the remaining sections of this document
    refer to the operation of the OSPF protocol	within a single	area.

7.  Bringing Up	Adjacencies

    OSPF creates adjacencies between neighboring routers for the purpose
    of exchanging routing information.	Not every two neighboring
    routers will become	adjacent.  This	section	covers the generalities
    involved in	creating adjacencies.  For further details consult
    Section 10.

    7.1.  The Hello Protocol

	The Hello Protocol is responsible for establishing and
	maintaining neighbor relationships.  It	also ensures that
	communication between neighbors	is bidirectional.  Hello packets
	are sent periodically out all router interfaces.  Bidirectional
	communication is indicated when	the router sees	itself listed in
	the neighbor's Hello Packet.  On broadcast and NBMA networks,
	the Hello Protocol elects a Designated Router for the network.

	The Hello Protocol works differently on	broadcast networks, NBMA
	networks and Point-to-MultiPoint networks.  On broadcast
	networks, each router advertises itself	by periodically
	multicasting Hello Packets.  This allows neighbors to be
	discovered dynamically.	 These Hello Packets contain the
	router's view of the Designated	Router's identity, and the list
	of routers whose Hello Packets have been seen recently.

	On NBMA	networks some configuration information	may be necessary
	for the	operation of the Hello Protocol.  Each router that may
	potentially become Designated Router has a list	of all other

Moy			    Standards Track		       [Page 52]



RFC 2328		     OSPF Version 2		      April 1998

	routers	attached to the	network.  A router, having Designated
	Router potential, sends	Hello Packets to all other potential
	Designated Routers when	its interface to the NBMA network first
	becomes	operational.  This is an attempt to find the Designated
	Router for the network.	 If the	router itself is elected
	Designated Router, it begins sending Hello Packets to all other
	routers	attached to the	network.

	On Point-to-MultiPoint networks, a router sends	Hello Packets to
	all neighbors with which it can	communicate directly. These
	neighbors may be discovered dynamically	through	a protocol such
	as Inverse ARP (see [Ref14]), or they may be configured.

	After a	neighbor has been discovered, bidirectional
	communication ensured, and (if on a broadcast or NBMA network) a
	Designated Router elected, a decision is made regarding	whether
	or not an adjacency should be formed with the neighbor (see
	Section	10.4). If an adjacency is to be	formed,	the first step
	is to synchronize the neighbors' link-state databases.	This is
	covered	in the next section.

    7.2.  The Synchronization of Databases

	In a link-state	routing	algorithm, it is very important	for all
	routers' link-state databases to stay synchronized.  OSPF
	simplifies this	by requiring only adjacent routers to remain
	synchronized.  The synchronization process begins as soon as the
	routers	attempt	to bring up the	adjacency.  Each router
	describes its database by sending a sequence of	Database
	Description packets to its neighbor.  Each Database Description
	Packet describes a set of LSAs belonging to the	router's
	database.  When	the neighbor sees an LSA that is more recent
	than its own database copy, it makes a note that this newer LSA
	should be requested.

	This sending and receiving of Database Description packets is
	called the "Database Exchange Process".	 During	this process,
	the two	routers	form a master/slave relationship.  Each	Database
	Description Packet has a sequence number.  Database Description
	Packets	sent by	the master (polls) are acknowledged by the slave
	through	echoing	of the sequence	number.	 Both polls and	their

Moy			    Standards Track		       [Page 53]



RFC 2328		     OSPF Version 2		      April 1998

	responses contain summaries of link state data.	 The master is
	the only one allowed to	retransmit Database Description	Packets.
	It does	so only	at fixed intervals, the	length of which	is the
	configured per-interface constant RxmtInterval.

	Each Database Description contains an indication that there are
	more packets to	follow --- the M-bit.  The Database Exchange
	Process	is over	when a router has received and sent Database
	Description Packets with the M-bit off.

	During and after the Database Exchange Process,	each router has
	a list of those	LSAs for which the neighbor has	more up-to-date
	instances.  These LSAs are requested in	Link State Request
	Packets.  Link State Request packets that are not satisfied are
	retransmitted at fixed intervals of time RxmtInterval.	When the
	Database Description Process has completed and all Link	State
	Requests have been satisfied, the databases are	deemed
	synchronized and the routers are marked	fully adjacent.	 At this
	time the adjacency is fully functional and is advertised in the
	two routers' router-LSAs.

	The adjacency is used by the flooding procedure	as soon	as the
	Database Exchange Process begins.  This	simplifies database
	synchronization, and guarantees	that it	finishes in a
	predictable period of time.

    7.3.  The Designated Router

	Every broadcast	and NBMA network has a Designated Router.  The
	Designated Router performs two main functions for the routing
	protocol:

	o   The	Designated Router originates a network-LSA on behalf of
	    the	network.  This LSA lists the set of routers (including
	    the	Designated Router itself) currently attached to	the
	    network.  The Link State ID	for this LSA (see Section
	    12.1.4) is the IP interface	address	of the Designated
	    Router.  The IP network number can then be obtained	by using
	    the	network's subnet/network mask.

Moy			    Standards Track		       [Page 54]



RFC 2328		     OSPF Version 2		      April 1998

	o   The	Designated Router becomes adjacent to all other	routers
	    on the network.  Since the link state databases are
	    synchronized across	adjacencies (through adjacency bring-up
	    and	then the flooding procedure), the Designated Router
	    plays a central part in the	synchronization	process.

	The Designated Router is elected by the	Hello Protocol.	 A
	router's Hello Packet contains its Router Priority, which is
	configurable on	a per-interface	basis.	In general, when a
	router's interface to a	network	first becomes functional, it
	checks to see whether there is currently a Designated Router for
	the network.  If there is, it accepts that Designated Router,
	regardless of its Router Priority.  (This makes	it harder to
	predict	the identity of	the Designated Router, but ensures that
	the Designated Router changes less often.  See below.)
	Otherwise, the router itself becomes Designated	Router if it has
	the highest Router Priority on the network.  A more detailed
	(and more accurate) description	of Designated Router election is
	presented in Section 9.4.

	The Designated Router is the endpoint of many adjacencies.  In
	order to optimize the flooding procedure on broadcast networks,
	the Designated Router multicasts its Link State	Update Packets
	to the address AllSPFRouters, rather than sending separate
	packets	over each adjacency.

	Section	2 of this document discusses the directed graph
	representation of an area.  Router nodes are labelled with their
	Router ID.  Transit network nodes are actually labelled	with the
	IP address of their Designated Router.	It follows that	when the
	Designated Router changes, it appears as if the	network	node on
	the graph is replaced by an entirely new node.	This will cause
	the network and	all its	attached routers to originate new LSAs.
	Until the link-state databases again converge, some temporary
	loss of	connectivity may result.  This may result in ICMP
	unreachable messages being sent	in response to data traffic.
	For that reason, the Designated	Router should change only
	infrequently.  Router Priorities should	be configured so that
	the most dependable router on a	network	eventually becomes
	Designated Router.

Moy			    Standards Track		       [Page 55]



RFC 2328		     OSPF Version 2		      April 1998

    7.4.  The Backup Designated	Router

	In order to make the transition	to a new Designated Router
	smoother, there	is a Backup Designated Router for each broadcast
	and NBMA network.  The Backup Designated Router	is also	adjacent
	to all routers on the network, and becomes Designated Router
	when the previous Designated Router fails.  If there were no
	Backup Designated Router, when a new Designated	Router became
	necessary, new adjacencies would have to be formed between the
	new Designated Router and all other routers attached to	the
	network.  Part of the adjacency	forming	process	is the
	synchronizing of link-state databases, which can potentially
	take quite a long time.	 During	this time, the network would not
	be available for transit data traffic.	The Backup Designated
	obviates the need to form these	adjacencies, since they	already
	exist.	This means the period of disruption in transit traffic
	lasts only as long as it takes to flood	the new	LSAs (which
	announce the new Designated Router).

	The Backup Designated Router does not generate a network-LSA for
	the network.  (If it did, the transition to a new Designated
	Router would be	even faster.  However, this is a tradeoff
	between	database size and speed	of convergence when the
	Designated Router disappears.)

	The Backup Designated Router is	also elected by	the Hello
	Protocol.  Each	Hello Packet has a field that specifies	the
	Backup Designated Router for the network.

	In some	steps of the flooding procedure, the Backup Designated
	Router plays a passive role, letting the Designated Router do
	more of	the work.  This	cuts down on the amount	of local routing
	traffic.  See Section 13.3 for more information.

    7.5.  The graph of adjacencies

	An adjacency is	bound to the network that the two routers have
	in common.  If two routers have	multiple networks in common,
	they may have multiple adjacencies between them.

Moy			    Standards Track		       [Page 56]



RFC 2328		     OSPF Version 2		      April 1998

	One can	picture	the collection of adjacencies on a network as
	forming	an undirected graph.  The vertices consist of routers,
	with an	edge joining two routers if they are adjacent.	The
	graph of adjacencies describes the flow	of routing protocol
	packets, and in	particular Link	State Update Packets, through
	the Autonomous System.

	Two graphs are possible, depending on whether a	Designated
	Router is elected for the network.  On physical	point-to-point
	networks, Point-to-MultiPoint networks and virtual links,
	neighboring routers become adjacent whenever they can
	communicate directly.  In contrast, on broadcast and NBMA
	networks only the Designated Router and	the Backup Designated
	Router become adjacent to all other routers attached to	the
	network.

	  +---+		   +---+
	  |RT1|------------|RT2|	    o---------------o
	  +---+	   N1	   +---+	   RT1		   RT2

						 RT7
						  o---------+
	    +---+   +---+   +---+		 /|\	    |
	    |RT7|   |RT3|   |RT4|		/ | \	    |
	    +---+   +---+   +---+	       /  |  \	    |
	      |	      |	      |		      /	  |   \	    |
	 +-----------------------+	  RT5o RT6o    oRT4 |
		  |	  |	N2	      *	  *   *	    |
		+---+	+---+		       *  *  *	    |
		|RT5|	|RT6|			* * *	    |
		+---+	+---+			 ***	    |
						  o---------+
						 RT3

		  Figure 10: The graph of adjacencies

Moy			    Standards Track		       [Page 57]



RFC 2328		     OSPF Version 2		      April 1998

	These graphs are shown in Figure 10.  It is assumed that Router
	RT7 has	become the Designated Router, and Router RT3 the Backup
	Designated Router, for the Network N2.	The Backup Designated
	Router performs	a lesser function during the flooding procedure
	than the Designated Router (see	Section	13.3).	This is	the
	reason for the dashed lines connecting the Backup Designated
	Router RT3.

8.  Protocol Packet Processing

    This section discusses the general processing of OSPF routing
    protocol packets.  It is very important that the router link-state
    databases remain synchronized.  For	this reason, routing protocol
    packets should get preferential treatment over ordinary data
    packets, both in sending and receiving.

    Routing protocol packets are sent along adjacencies	only (with the
    exception of Hello packets,	which are used to discover the
    adjacencies).  This	means that all routing protocol	packets	travel a
    single IP hop, except those	sent over virtual links.

    All	routing	protocol packets begin with a standard header.	The
    sections below provide details on how to fill in and verify	this
    standard header.  Then, for	each packet type, the section giving
    more details on that particular packet type's processing is	listed.

    8.1.  Sending protocol packets

	When a router sends a routing protocol packet, it fills	in the
	fields of the standard OSPF packet header as follows.  For more
	details	on the header format consult Section A.3.1:

	Version	#
	    Set	to 2, the version number of the	protocol as documented
	    in this specification.

	Packet type
	    The	type of	OSPF packet, such as Link state	Update or Hello
	    Packet.

Moy			    Standards Track		       [Page 58]



RFC 2328		     OSPF Version 2		      April 1998

	Packet length
	    The	length of the entire OSPF packet in bytes, including the
	    standard OSPF packet header.

	Router ID
	    The	identity of the	router itself (who is originating the
	    packet).

	Area ID
	    The	OSPF area that the packet is being sent	into.

	Checksum
	    The	standard IP 16-bit one's complement checksum of	the
	    entire OSPF	packet,	excluding the 64-bit authentication
	    field.  This checksum is calculated	as part	of the
	    appropriate	authentication procedure; for some OSPF
	    authentication types, the checksum calculation is omitted.
	    See	Section	D.4 for	details.

	AuType and Authentication
	    Each OSPF packet exchange is authenticated.	 Authentication
	    types are assigned by the protocol and are documented in
	    Appendix D.	 A different authentication procedure can be
	    used for each IP network/subnet.  Autype indicates the type
	    of authentication procedure	in use.	The 64-bit
	    authentication field is then for use by the	chosen
	    authentication procedure.  This procedure should be	the last
	    called when	forming	the packet to be sent. See Section D.4
	    for	details.

	The IP destination address for the packet is selected as
	follows.  On physical point-to-point networks, the IP
	destination is always set to the address AllSPFRouters.	 On all
	other network types (including virtual links), the majority of
	OSPF packets are sent as unicasts, i.e., sent directly to the
	other end of the adjacency.  In	this case, the IP destination is
	just the Neighbor IP address associated	with the other end of
	the adjacency (see Section 10).	 The only packets not sent as
	unicasts are on	broadcast networks; on these networks Hello
	packets	are sent to the	multicast destination AllSPFRouters, the
	Designated Router and its Backup send both Link	State Update

Moy			    Standards Track		       [Page 59]



RFC 2328		     OSPF Version 2		      April 1998

	Packets	and Link State Acknowledgment Packets to the multicast
	address	AllSPFRouters, while all other routers send both their
	Link State Update and Link State Acknowledgment	Packets	to the
	multicast address AllDRouters.

	Retransmissions	of Link	State Update packets are ALWAYS	sent
	directly to the	neighbor. On multi-access networks, this means
	that retransmissions should be sent to the neighbor's IP
	address.

	The IP source address should be	set to the IP address of the
	sending	interface.  Interfaces to unnumbered point-to-point
	networks have no associated IP address.	 On these interfaces,
	the IP source should be	set to any of the other	IP addresses
	belonging to the router.  For this reason, there must be at
	least one IP address assigned to the router.[2]	Note that, for
	most purposes, virtual links act precisely the same as
	unnumbered point-to-point networks.  However, each virtual link
	does have an IP	interface address (discovered during the routing
	table build process) which is used as the IP source when sending
	packets	over the virtual link.

	For more information on	the format of specific OSPF packet
	types, consult the sections listed in Table 10.

	     Type   Packet name		   detailed section (transmit)
	     _________________________________________________________
	     1	    Hello		   Section  9.5
	     2	    Database description   Section 10.8
	     3	    Link state request	   Section 10.9
	     4	    Link state update	   Section 13.3
	     5	    Link state ack	   Section 13.5

      Table 10:	Sections describing OSPF protocol packet transmission.

Moy			    Standards Track		       [Page 60]



RFC 2328		     OSPF Version 2		      April 1998

    8.2.  Receiving protocol packets

	Whenever a protocol packet is received by the router it	is
	marked with the	interface it was received on.  For routers that
	have virtual links configured, it may not be immediately obvious
	which interface	to associate the packet	with.  For example,
	consider the Router RT11 depicted in Figure 6.	If RT11	receives
	an OSPF	protocol packet	on its interface to Network N8,	it may
	want to	associate the packet with the interface	to Area	2, or
	with the virtual link to Router	RT10 (which is part of the
	backbone).  In the following, we assume	that the packet	is
	initially associated with the non-virtual  link.[3]

	In order for the packet	to be accepted at the IP level,	it must
	pass a number of tests,	even before the	packet is passed to OSPF
	for processing:

	o   The	IP checksum must be correct.

	o   The	packet's IP destination	address	must be	the IP address
	    of the receiving interface,	or one of the IP multicast
	    addresses AllSPFRouters or AllDRouters.

	o   The	IP protocol specified must be OSPF (89).

	o   Locally originated packets should not be passed on to OSPF.
	    That is, the source	IP address should be examined to make
	    sure this is not a multicast packet	that the router	itself
	    generated.

	Next, the OSPF packet header is	verified.  The fields specified
	in the header must match those configured for the receiving
	interface.  If they do not, the	packet should be discarded:

	o   The	version	number field must specify protocol version 2.

	o   The	Area ID	found in the OSPF header must be verified.  If
	    both of the	following cases	fail, the packet should	be
	    discarded.	The Area ID specified in the header must either:

Moy			    Standards Track		       [Page 61]



RFC 2328		     OSPF Version 2		      April 1998

	    (1)	Match the Area ID of the receiving interface.  In this
		case, the packet has been sent over a single hop.
		Therefore, the packet's	IP source address is required to
		be on the same network as the receiving	interface.  This
		can be verified	by comparing the packet's IP source
		address	to the interface's IP address, after masking
		both addresses with the	interface mask.	 This comparison
		should not be performed	on point-to-point networks. On
		point-to-point networks, the interface addresses of each
		end of the link	are assigned independently, if they are
		assigned at all.

	    (2)	Indicate the backbone.	In this	case, the packet has
		been sent over a virtual link.	The receiving router
		must be	an area	border router, and the Router ID
		specified in the packet	(the source router) must be the
		other end of a configured virtual link.	 The receiving
		interface must also attach to the virtual link's
		configured Transit area.  If all of these checks
		succeed, the packet is accepted	and is from now	on
		associated with	the virtual link (and the backbone
		area).

	o   Packets whose IP destination is AllDRouters	should only be
	    accepted if	the state of the receiving interface is	DR or
	    Backup (see	Section	9.1).

	o   The	AuType specified in the	packet must match the AuType
	    specified for the associated area.

	o   The	packet must be authenticated.  The authentication
	    procedure is indicated by the setting of AuType (see
	    Appendix D).  The authentication procedure may use one or
	    more Authentication	keys, which can	be configured on a per-
	    interface basis.  The authentication procedure may also
	    verify the checksum	field in the OSPF packet header	(which,
	    when used, is set to the standard IP 16-bit	one's complement
	    checksum of	the OSPF packet's contents after excluding the
	    64-bit authentication field).  If the authentication
	    procedure fails, the packet	should be discarded.

Moy			    Standards Track		       [Page 62]



RFC 2328		     OSPF Version 2		      April 1998

	If the packet type is Hello, it	should then be further processed
	by the Hello Protocol (see Section 10.5).  All other packet
	types are sent/received	only on	adjacencies.  This means that
	the packet must	have been sent by one of the router's active
	neighbors.  If the receiving interface connects	to a broadcast
	network, Point-to-MultiPoint network or	NBMA network the sender
	is identified by the IP	source address found in	the packet's IP
	header.	 If the	receiving interface connects to	a point-to-point
	network	or a virtual link, the sender is identified by the
	Router ID (source router) found	in the packet's	OSPF header.
	The data structure associated with the receiving interface
	contains the list of active neighbors.	Packets	not matching any
	active neighbor	are discarded.

	At this	point all received protocol packets are	associated with
	an active neighbor.  For the further input processing of
	specific packet	types, consult the sections listed in Table 11.

	      Type   Packet name	    detailed section (receive)
	      ________________________________________________________
	      1	     Hello		    Section 10.5
	      2	     Database description   Section 10.6
	      3	     Link state	request	    Section 10.7
	      4	     Link state	update	    Section 13
	      5	     Link state	ack	    Section 13.7

      Table 11:	Sections describing OSPF protocol packet reception.

9.  The	Interface Data Structure

    An OSPF interface is the connection	between	a router and a network.
    We assume a	single OSPF interface to each attached network/subnet,
    although supporting	multiple interfaces on a single	network	is
    considered in Appendix F. Each interface structure has at most one
    IP interface address.

Moy			    Standards Track		       [Page 63]



RFC 2328		     OSPF Version 2		      April 1998

    An OSPF interface can be considered	to belong to the area that
    contains the attached network.  All	routing	protocol packets
    originated by the router over this interface are labelled with the
    interface's	Area ID.  One or more router adjacencies may develop
    over an interface.	A router's LSAs	reflect	the state of its
    interfaces and their associated adjacencies.

    The	following data items are associated with an interface.	Note
    that a number of these items are actually configuration for	the
    attached network; such items must be the same for all routers
    connected to the network.

    Type
	The OSPF interface type	is either point-to-point, broadcast,
	NBMA, Point-to-MultiPoint or virtual link.

    State
	The functional level of	an interface.  State determines	whether
	or not full adjacencies	are allowed to form over the interface.
	State is also reflected	in the router's	LSAs.

    IP interface address
	The IP address associated with the interface.  This appears as
	the IP source address in all routing protocol packets originated
	over this interface.  Interfaces to unnumbered point-to-point
	networks do not	have an	associated IP address.

    IP interface mask
	Also referred to as the	subnet mask, this indicates the	portion
	of the IP interface address that identifies the	attached
	network.  Masking the IP interface address with	the IP interface
	mask yields the	IP network number of the attached network.  On
	point-to-point networks	and virtual links, the IP interface mask
	is not defined.	On these networks, the link itself is not
	assigned an IP network number, and so the addresses of each side
	of the link are	assigned independently,	if they	are assigned at
	all.

    Area ID
	The Area ID of the area	to which the attached network belongs.
	All routing protocol packets originating from the interface are
	labelled with this Area	ID.

Moy			    Standards Track		       [Page 64]



RFC 2328		     OSPF Version 2		      April 1998

    HelloInterval
	The length of time, in seconds,	between	the Hello packets that
	the router sends on the	interface.  Advertised in Hello	packets
	sent out this interface.

    RouterDeadInterval
	The number of seconds before the router's neighbors will declare
	it down, when they stop	hearing	the router's Hello Packets.
	Advertised in Hello packets sent out this interface.

    InfTransDelay
	The estimated number of	seconds	it takes to transmit a Link
	State Update Packet over this interface.  LSAs contained in the
	Link State Update packet will have their age incremented by this
	amount before transmission.  This value	should take into account
	transmission and propagation delays; it	must be	greater	than
	zero.

    Router Priority
	An 8-bit unsigned integer.  When two routers attached to a
	network	both attempt to	become Designated Router, the one with
	the highest Router Priority takes precedence.  A router	whose
	Router Priority	is set to 0 is ineligible to become Designated
	Router on the attached network.	 Advertised in Hello packets
	sent out this interface.

    Hello Timer
	An interval timer that causes the interface to send a Hello
	packet.	 This timer fires every	HelloInterval seconds.	Note
	that on	non-broadcast networks a separate Hello	packet is sent
	to each	qualified neighbor.

    Wait Timer
	A single shot timer that causes	the interface to exit the
	Waiting	state, and as a	consequence select a Designated	Router
	on the network.	 The length of the timer is RouterDeadInterval
	seconds.

    List of neighboring	routers
	The other routers attached to this network.  This list is formed
	by the Hello Protocol.	Adjacencies will be formed to some of

Moy			    Standards Track		       [Page 65]



RFC 2328		     OSPF Version 2		      April 1998

	these neighbors.  The set of adjacent neighbors	can be
	determined by an examination of	all of the neighbors' states.

    Designated Router
	The Designated Router selected for the attached	network.  The
	Designated Router is selected on all broadcast and NBMA	networks
	by the Hello Protocol.	Two pieces of identification are kept
	for the	Designated Router: its Router ID and its IP interface
	address	on the network.	 The Designated	Router advertises link
	state for the network; this network-LSA	is labelled with the
	Designated Router's IP address.	 The Designated	Router is
	initialized to 0.0.0.0,	which indicates	the lack of a Designated
	Router.

    Backup Designated Router
	The Backup Designated Router is	also selected on all broadcast
	and NBMA networks by the Hello Protocol.  All routers on the
	attached network become	adjacent to both the Designated	Router
	and the	Backup Designated Router.  The Backup Designated Router
	becomes	Designated Router when the current Designated Router
	fails.	The Backup Designated Router is	initialized to 0.0.0.0,
	indicating the lack of a Backup	Designated Router.

    Interface output cost(s)
	The cost of sending a data packet on the interface, expressed in
	the link state metric.	This is	advertised as the link cost for
	this interface in the router-LSA. The cost of an interface must
	be greater than	zero.

    RxmtInterval
	The number of seconds between LSA retransmissions, for
	adjacencies belonging to this interface.  Also used when
	retransmitting Database	Description and	Link State Request
	Packets.

    AuType
	The type of authentication used	on the attached	network/subnet.
	Authentication types are defined in Appendix D.	 All OSPF packet
	exchanges are authenticated.  Different	authentication schemes
	may be used on different networks/subnets.

Moy			    Standards Track		       [Page 66]



RFC 2328		     OSPF Version 2		      April 1998

    Authentication key
	This configured	data allows the	authentication procedure to
	generate and/or	verify OSPF protocol packets.  The
	Authentication key can be configured on	a per-interface	basis.
	For example, if	the AuType indicates simple password, the
	Authentication key would be a 64-bit clear password which is
	inserted into the OSPF packet header. If instead Autype
	indicates Cryptographic	authentication,	then the Authentication
	key is a shared	secret which enables the generation/verification
	of message digests which are appended to the OSPF protocol
	packets. When Cryptographic authentication is used, multiple
	simultaneous keys are supported	in order to achieve smooth key
	transition (see	Section	D.3).

    9.1.  Interface states

	The various states that	router interfaces may attain is
	documented in this section.  The states	are listed in order of
	progressing functionality.  For	example, the inoperative state
	is listed first, followed by a list of intermediate states
	before the final, fully	functional state is achieved.  The
	specification makes use	of this	ordering by sometimes making
	references such	as "those interfaces in	state greater than X".
	Figure 11 shows	the graph of interface state changes.  The arcs
	of the graph are labelled with the event causing the state
	change.	 These events are documented in	Section	9.2.  The
	interface state	machine	is described in	more detail in Section
	9.3.

	Down
	    This is the	initial	interface state.  In this state, the
	    lower-level	protocols have indicated that the interface is
	    unusable.  No protocol traffic at all will be sent or
	    received on	such a interface.  In this state, interface
	    parameters should be set to	their initial values.  All
	    interface timers should be disabled, and there should be no
	    adjacencies	associated with	the interface.

	Loopback
	    In this state, the router's	interface to the network is

Moy			    Standards Track		       [Page 67]



RFC 2328		     OSPF Version 2		      April 1998

				  +----+   UnloopInd   +--------+
				  |Down|<--------------|Loopback|
				  +----+	       +--------+
				     |
				     |InterfaceUp
			  +-------+  |		     +--------------+
			  |Waiting|<-+-------------->|Point-to-point|
			  +-------+		     +--------------+
			      |
		     WaitTimer|BackupSeen
			      |
			      |
			      |	  NeighborChange
	  +------+	     +-+<---------------- +-------+
	  |Backup|<----------|?|----------------->|DROther|
	  +------+---------->+-+<-----+		  +-------+
		    Neighbor  |	      |
		    Change    |	      |Neighbor
			      |	      |Change
			      |	    +--+
			      +---->|DR|
				    +--+

		      Figure 11: Interface State changes

		 In addition to	the state transitions pictured,
		 Event InterfaceDown always forces Down	State, and
		 Event LoopInd always forces Loopback State

	    looped back.  The interface	may be looped back in hardware
	    or software.  The interface	will be	unavailable for	regular
	    data traffic.  However, it may still be desirable to gain
	    information	on the quality of this interface, either through
	    sending ICMP pings to the interface	or through something
	    like a bit error test.  For	this reason, IP	packets	may
	    still be addressed to an interface in Loopback state.  To

Moy			    Standards Track		       [Page 68]



RFC 2328		     OSPF Version 2		      April 1998

	    facilitate this, such interfaces are advertised in router-
	    LSAs as single host	routes,	whose destination is the IP
	    interface address.[4]

	Waiting
	    In this state, the router is trying	to determine the
	    identity of	the (Backup) Designated	Router for the network.
	    To do this,	the router monitors the	Hello Packets it
	    receives.  The router is not allowed to elect a Backup
	    Designated Router nor a Designated Router until it
	    transitions	out of Waiting state.  This prevents unnecessary
	    changes of (Backup)	Designated Router.

	Point-to-point
	    In this state, the interface is operational, and connects
	    either to a	physical point-to-point	network	or to a	virtual
	    link.  Upon	entering this state, the router	attempts to form
	    an adjacency with the neighboring router.  Hello Packets are
	    sent to the	neighbor every HelloInterval seconds.

	DR Other
	    The	interface is to	a broadcast or NBMA network on which
	    another router has been selected to	be the Designated
	    Router.  In	this state, the	router itself has not been
	    selected Backup Designated Router either.  The router forms
	    adjacencies	to both	the Designated Router and the Backup
	    Designated Router (if they exist).

	Backup
	    In this state, the router itself is	the Backup Designated
	    Router on the attached network.  It	will be	promoted to
	    Designated Router when the present Designated Router fails.
	    The	router establishes adjacencies to all other routers
	    attached to	the network.  The Backup Designated Router
	    performs slightly different	functions during the Flooding
	    Procedure, as compared to the Designated Router (see Section
	    13.3).  See	Section	7.4 for	more details on	the functions
	    performed by the Backup Designated Router.

	DR  In this state, this	router itself is the Designated	Router
	    on the attached network.  Adjacencies are established to all
	    other routers attached to the network.  The	router must also

Moy			    Standards Track		       [Page 69]



RFC 2328		     OSPF Version 2		      April 1998

	    originate a	network-LSA for	the network node.  The network-
	    LSA	will contain links to all routers (including the
	    Designated Router itself) attached to the network.	See
	    Section 7.3	for more details on the	functions performed by
	    the	Designated Router.

    9.2.  Events causing interface state changes

	State changes can be effected by a number of events.  These
	events are pictured as the labelled arcs in Figure 11.	The
	label definitions are listed below.  For a detailed explanation
	of the effect of these events on OSPF protocol operation,
	consult	Section	9.3.

	InterfaceUp
	    Lower-level	protocols have indicated that the network
	    interface is operational.  This enables the	interface to
	    transition out of Down state.  On virtual links, the
	    interface operational indication is	actually a result of the
	    shortest path calculation (see Section 16.7).

	WaitTimer
	    The	Wait Timer has fired, indicating the end of the	waiting
	    period that	is required before electing a (Backup)
	    Designated Router.

	BackupSeen
	    The	router has detected the	existence or non-existence of a
	    Backup Designated Router for the network.  This is done in
	    one	of two ways.  First, an	Hello Packet may be received
	    from a neighbor claiming to	be itself the Backup Designated
	    Router.  Alternatively, an Hello Packet may	be received from
	    a neighbor claiming	to be itself the Designated Router, and
	    indicating that there is no	Backup Designated Router.  In
	    either case	there must be bidirectional communication with
	    the	neighbor, i.e.,	the router must	also appear in the
	    neighbor's Hello Packet.  This event signals an end	to the
	    Waiting state.

Moy			    Standards Track		       [Page 70]



RFC 2328		     OSPF Version 2		      April 1998

	NeighborChange
	    There has been a change in the set of bidirectional
	    neighbors associated with the interface.  The (Backup)
	    Designated Router needs to be recalculated.	 The following
	    neighbor changes lead to the NeighborChange	event.	For an
	    explanation	of neighbor states, see	Section	10.1.

	    o	Bidirectional communication has	been established to a
		neighbor.  In other words, the state of	the neighbor has
		transitioned to	2-Way or higher.

	    o	There is no longer bidirectional communication with a
		neighbor.  In other words, the state of	the neighbor has
		transitioned to	Init or	lower.

	    o	One of the bidirectional neighbors is newly declaring
		itself as either Designated Router or Backup Designated
		Router.	 This is detected through examination of that
		neighbor's Hello Packets.

	    o	One of the bidirectional neighbors is no longer
		declaring itself as Designated Router, or is no	longer
		declaring itself as Backup Designated Router.  This is
		again detected through examination of that neighbor's
		Hello Packets.

	    o	The advertised Router Priority for a bidirectional
		neighbor has changed.  This is again detected through
		examination of that neighbor's Hello Packets.

	LoopInd
	    An indication has been received that the interface is now
	    looped back	to itself.  This indication can	be received
	    either from	network	management or from the lower level
	    protocols.

	UnloopInd
	    An indication has been received that the interface is no
	    longer looped back.	 As with the LoopInd event, this

Moy			    Standards Track		       [Page 71]



RFC 2328		     OSPF Version 2		      April 1998

	    indication can be received either from network management or
	    from the lower level protocols.

	InterfaceDown
	    Lower-level	protocols indicate that	this interface is no
	    longer functional.	No matter what the current interface
	    state is, the new interface	state will be Down.

    9.3.  The Interface	state machine

	A detailed description of the interface	state changes follows.
	Each state change is invoked by	an event (Section 9.2).	 This
	event may produce different effects, depending on the current
	state of the interface.	 For this reason, the state machine
	below is organized by current interface	state and received
	event.	Each entry in the state	machine	describes the resulting
	new interface state and	the required set of additional actions.

	When an	interface's state changes, it may be necessary to
	originate a new	router-LSA.  See Section 12.4 for more details.

	Some of	the required actions below involve generating events for
	the neighbor state machine.  For example, when an interface
	becomes	inoperative, all neighbor connections associated with
	the interface must be destroyed.  For more information on the
	neighbor state machine,	see Section 10.3.

	 State(s):  Down

	    Event:  InterfaceUp

	New state:  Depends upon action	routine

	   Action:  Start the interval Hello Timer, enabling the
		    periodic sending of	Hello packets out the interface.
		    If the attached network is a physical point-to-point
		    network, Point-to-MultiPoint network or virtual
		    link, the interface	state transitions to Point-to-
		    Point.  Else, if the router	is not eligible	to
		    become Designated Router the interface state
		    transitions	to DR Other.

Moy			    Standards Track		       [Page 72]



RFC 2328		     OSPF Version 2		      April 1998

		    Otherwise, the attached network is a broadcast or
		    NBMA network and the router	is eligible to become
		    Designated Router.	In this	case, in an attempt to
		    discover the attached network's Designated Router
		    the	interface state	is set to Waiting and the single
		    shot Wait Timer is started.	 Additionally, if the
		    network is an NBMA network examine the configured
		    list of neighbors for this interface and generate
		    the	neighbor event Start for each neighbor that is
		    also eligible to become Designated Router.

	 State(s):  Waiting

	    Event:  BackupSeen

	New state:  Depends upon action	routine.

	   Action:  Calculate the attached network's Backup Designated
		    Router and Designated Router, as shown in Section
		    9.4.  As a result of this calculation, the new state
		    of the interface will be either DR Other, Backup or
		    DR.

	 State(s):  Waiting

	    Event:  WaitTimer

	New state:  Depends upon action	routine.

	   Action:  Calculate the attached network's Backup Designated
		    Router and Designated Router, as shown in Section
		    9.4.  As a result of this calculation, the new state
		    of the interface will be either DR Other, Backup or
		    DR.

	 State(s):  DR Other, Backup or	DR

	    Event:  NeighborChange

Moy			    Standards Track		       [Page 73]



RFC 2328		     OSPF Version 2		      April 1998

	New state:  Depends upon action	routine.

	   Action:  Recalculate	the attached network's Backup Designated
		    Router and Designated Router, as shown in Section
		    9.4.  As a result of this calculation, the new state
		    of the interface will be either DR Other, Backup or
		    DR.

	 State(s):  Any	State

	    Event:  InterfaceDown

	New state:  Down

	   Action:  All	interface variables are	reset, and interface
		    timers disabled.  Also, all	neighbor connections
		    associated with the	interface are destroyed.  This
		    is done by generating the event KillNbr on all
		    associated neighbors (see Section 10.2).

	 State(s):  Any	State

	    Event:  LoopInd

	New state:  Loopback

	   Action:  Since this interface is no longer connected	to the
		    attached network the actions associated with the
		    above InterfaceDown	event are executed.

	 State(s):  Loopback

	    Event:  UnloopInd

	New state:  Down

	   Action:  No actions are necessary.  For example, the
		    interface variables	have already been reset	upon
		    entering the Loopback state.  Note that reception of

Moy			    Standards Track		       [Page 74]



RFC 2328		     OSPF Version 2		      April 1998

		    an InterfaceUp event is necessary before the
		    interface again becomes fully functional.

    9.4.  Electing the Designated Router

	This section describes the algorithm used for calculating a
	network's Designated Router and	Backup Designated Router.  This
	algorithm is invoked by	the Interface state machine.  The
	initial	time a router runs the election	algorithm for a	network,
	the network's Designated Router	and Backup Designated Router are
	initialized to 0.0.0.0.	 This indicates	the lack of both a
	Designated Router and a	Backup Designated Router.

	The Designated Router election algorithm proceeds as follows:
	Call the router	doing the calculation Router X.	 The list of
	neighbors attached to the network and having established
	bidirectional communication with Router	X is examined.	This
	list is	precisely the collection of Router X's neighbors (on
	this network) whose state is greater than or equal to 2-Way (see
	Section	10.1).	Router X itself	is also	considered to be on the
	list.  Discard all routers from	the list that are ineligible to
	become Designated Router.  (Routers having Router Priority of 0
	are ineligible to become Designated Router.)  The following
	steps are then executed, considering only those	routers	that
	remain on the list:

	(1) Note the current values for	the network's Designated Router
	    and	Backup Designated Router.  This	is used	later for
	    comparison purposes.

	(2) Calculate the new Backup Designated	Router for the network
	    as follows.	 Only those routers on the list	that have not
	    declared themselves	to be Designated Router	are eligible to
	    become Backup Designated Router.  If one or	more of	these
	    routers have declared themselves Backup Designated Router
	    (i.e., they	are currently listing themselves as Backup
	    Designated Router, but not as Designated Router, in	their
	    Hello Packets) the one having highest Router Priority is
	    declared to	be Backup Designated Router.  In case of a tie,
	    the	one having the highest Router ID is chosen.  If	no
	    routers have declared themselves Backup Designated Router,

Moy			    Standards Track		       [Page 75]



RFC 2328		     OSPF Version 2		      April 1998

	    choose the router having highest Router Priority, (again
	    excluding those routers who	have declared themselves
	    Designated Router),	and again use the Router ID to break
	    ties.

	(3) Calculate the new Designated Router	for the	network	as
	    follows.  If one or	more of	the routers have declared
	    themselves Designated Router (i.e.,	they are currently
	    listing themselves as Designated Router in their Hello
	    Packets) the one having highest Router Priority is declared
	    to be Designated Router.  In case of a tie,	the one	having
	    the	highest	Router ID is chosen.  If no routers have
	    declared themselves	Designated Router, assign the Designated
	    Router to be the same as the newly elected Backup Designated
	    Router.

	(4) If Router X	is now newly the Designated Router or newly the
	    Backup Designated Router, or is now	no longer the Designated
	    Router or no longer	the Backup Designated Router, repeat
	    steps 2 and	3, and then proceed to step 5.	For example, if
	    Router X is	now the	Designated Router, when	step 2 is
	    repeated X will no longer be eligible for Backup Designated
	    Router election.  Among other things, this will ensure that
	    no router will declare itself both Backup Designated Router
	    and	Designated Router.[5]

	(5) As a result	of these calculations, the router itself may now
	    be Designated Router or Backup Designated Router.  See
	    Sections 7.3 and 7.4 for the additional duties this	would
	    entail.  The router's interface state should be set
	    accordingly.  If the router	itself is now Designated Router,
	    the	new interface state is DR.  If the router itself is now
	    Backup Designated Router, the new interface	state is Backup.
	    Otherwise, the new interface state is DR Other.

	(6) If the attached network is an NBMA network,	and the	router
	    itself has just become either Designated Router or Backup
	    Designated Router, it must start sending Hello Packets to
	    those neighbors that are not eligible to become Designated
	    Router (see	Section	9.5.1).	 This is done by invoking the
	    neighbor event Start for each neighbor having a Router
	    Priority of	0.

Moy			    Standards Track		       [Page 76]



RFC 2328		     OSPF Version 2		      April 1998

	(7) If the above calculations have caused the identity of either
	    the	Designated Router or Backup Designated Router to change,
	    the	set of adjacencies associated with this	interface will
	    need to be modified.  Some adjacencies may need to be
	    formed, and	others may need	to be broken.  To accomplish
	    this, invoke the event AdjOK?  on all neighbors whose state
	    is at least	2-Way.	This will cause	their eligibility for
	    adjacency to be reexamined (see Sections 10.3 and 10.4).

	The reason behind the election algorithm's complexity is the
	desire for an orderly transition from Backup Designated	Router
	to Designated Router, when the current Designated Router fails.
	This orderly transition	is ensured through the introduction of
	hysteresis: no new Backup Designated Router can	be chosen until
	the old	Backup accepts its new Designated Router
	responsibilities.

	The above procedure may	elect the same router to be both
	Designated Router and Backup Designated	Router,	although that
	router will never be the calculating router (Router X) itself.
	The elected Designated Router may not be the router having the
	highest	Router Priority, nor will the Backup Designated	Router
	necessarily have the second highest Router Priority.  If Router
	X is not itself	eligible to become Designated Router, it is
	possible that neither a	Backup Designated Router nor a
	Designated Router will be selected in the above	procedure.  Note
	also that if Router X is the only attached router that is
	eligible to become Designated Router, it will select itself as
	Designated Router and there will be no Backup Designated Router
	for the	network.

    9.5.  Sending Hello	packets

	Hello packets are sent out each	functioning router interface.
	They are used to discover and maintain neighbor
	relationships.[6] On broadcast and NBMA	networks, Hello	Packets
	are also used to elect the Designated Router and Backup
	Designated Router.

Moy			    Standards Track		       [Page 77]



RFC 2328		     OSPF Version 2		      April 1998

	The format of an Hello packet is detailed in Section A.3.2.  The
	Hello Packet contains the router's Router Priority (used in
	choosing the Designated	Router), and the interval between Hello
	Packets	sent out the interface (HelloInterval).	 The Hello
	Packet also indicates how often	a neighbor must	be heard from to
	remain active (RouterDeadInterval).  Both HelloInterval	and
	RouterDeadInterval must	be the same for	all routers attached to
	a common network.  The Hello packet also contains the IP address
	mask of	the attached network (Network Mask).  On unnumbered
	point-to-point networks	and on virtual links this field	should
	be set to 0.0.0.0.

	The Hello packet's Options field describes the router's	optional
	OSPF capabilities.  One	optional capability is defined in this
	specification (see Sections 4.5	and A.2).  The E-bit of	the
	Options	field should be	set if and only	if the attached	area is
	capable	of processing AS-external-LSAs (i.e., it is not	a stub
	area).	If the E-bit is	set incorrectly	the neighboring	routers
	will refuse to accept the Hello	Packet (see Section 10.5).
	Unrecognized bits in the Hello Packet's	Options	field should be
	set to zero.

	In order to ensure two-way communication between adjacent
	routers, the Hello packet contains the list of all routers on
	the network from which Hello Packets have been seen recently.
	The Hello packet also contains the router's current choice for
	Designated Router and Backup Designated	Router.	 A value of
	0.0.0.0	in these fields	means that one has not yet been
	selected.

	On broadcast networks and physical point-to-point networks,
	Hello packets are sent every HelloInterval seconds to the IP
	multicast address AllSPFRouters.  On virtual links, Hello
	packets	are sent as unicasts (addressed	directly to the	other
	end of the virtual link) every HelloInterval seconds. On Point-
	to-MultiPoint networks,	separate Hello packets are sent	to each
	attached neighbor every	HelloInterval seconds. Sending of Hello
	packets	on NBMA	networks is covered in the next	section.

Moy			    Standards Track		       [Page 78]



RFC 2328		     OSPF Version 2		      April 1998

	9.5.1.	Sending	Hello packets on NBMA networks

	    Static configuration information may be necessary in order
	    for	the Hello Protocol to function on non-broadcast	networks
	    (see Sections C.5 and C.6).	 On NBMA networks, every
	    attached router which is eligible to become	Designated
	    Router becomes aware of all	of its neighbors on the	network
	    (either through configuration or by	some unspecified
	    mechanism).	 Each neighbor is labelled with	the neighbor's
	    Designated Router eligibility.

	    The	interface state	must be	at least Waiting for any Hello
	    Packets to be sent out the NBMA interface.	Hello Packets
	    are	then sent directly (as unicasts) to some subset	of a
	    router's neighbors.	 Sometimes an Hello Packet is sent
	    periodically on a timer; at	other times it is sent as a
	    response to	a received Hello Packet.  A router's hello-
	    sending behavior varies depending on whether the router
	    itself is eligible to become Designated Router.

	    If the router is eligible to become	Designated Router, it
	    must periodically send Hello Packets to all	neighbors that
	    are	also eligible.	In addition, if	the router is itself the
	    Designated Router or Backup	Designated Router, it must also
	    send periodic Hello	Packets	to all other neighbors.	 This
	    means that any two eligible	routers	are always exchanging
	    Hello Packets, which is necessary for the correct operation
	    of the Designated Router election algorithm.  To minimize
	    the	number of Hello	Packets	sent, the number of eligible
	    routers on an NBMA network should be kept small.

	    If the router is not eligible to become Designated Router,
	    it must periodically send Hello Packets to both the
	    Designated Router and the Backup Designated	Router (if they
	    exist).  It	must also send an Hello	Packet in reply	to an
	    Hello Packet received from any eligible neighbor (other than
	    the	current	Designated Router and Backup Designated	Router).
	    This is needed to establish	an initial bidirectional
	    relationship with any potential Designated Router.

	    When sending Hello packets periodically to any neighbor, the
	    interval between Hello Packets is determined by the

Moy			    Standards Track		       [Page 79]



RFC 2328		     OSPF Version 2		      April 1998

	    neighbor's state.  If the neighbor is in state Down, Hello
	    Packets are	sent every PollInterval	seconds.  Otherwise,
	    Hello Packets are sent every HelloInterval seconds.

10.  The Neighbor Data Structure

    An OSPF router converses with its neighboring routers.  Each
    separate conversation is described by a "neighbor data structure".
    Each conversation is bound to a particular OSPF router interface,
    and	is identified either by	the neighboring	router's OSPF Router ID
    or by its Neighbor IP address (see below).	Thus if	the OSPF router
    and	another	router have multiple attached networks in common,
    multiple conversations ensue, each described by a unique neighbor
    data structure.  Each separate conversation	is loosely referred to
    in the text	as being a separate "neighbor".

    The	neighbor data structure	contains all information pertinent to
    the	forming	or formed adjacency between the	two neighbors.
    (However, remember that not	all neighbors become adjacent.)	 An
    adjacency can be viewed as a highly	developed conversation between
    two	routers.

    State
	The functional level of	the neighbor conversation.  This is
	described in more detail in Section 10.1.

    Inactivity Timer
	A single shot timer whose firing indicates that	no Hello Packet
	has been seen from this	neighbor recently.  The	length of the
	timer is RouterDeadInterval seconds.

    Master/Slave
	When the two neighbors are exchanging databases, they form a
	master/slave relationship.  The	master sends the first Database
	Description Packet, and	is the only part that is allowed to
	retransmit.  The slave can only	respond	to the master's	Database
	Description Packets.  The master/slave relationship is
	negotiated in state ExStart.

Moy			    Standards Track		       [Page 80]



RFC 2328		     OSPF Version 2		      April 1998

    DD Sequence	Number
	The DD Sequence	number of the Database Description packet that
	is currently being sent	to the neighbor.

    Last received Database Description packet
	The initialize(I), more	(M) and	master(MS) bits, Options field,
	and DD sequence	number contained in the	last Database
	Description packet received from the neighbor. Used to determine
	whether	the next Database Description packet received from the
	neighbor is a duplicate.

    Neighbor ID
	The OSPF Router	ID of the neighboring router.  The Neighbor ID
	is learned when	Hello packets are received from	the neighbor, or
	is configured if this is a virtual adjacency (see Section C.4).

    Neighbor Priority
	The Router Priority of the neighboring router.	Contained in the
	neighbor's Hello packets, this item is used when selecting the
	Designated Router for the attached network.

    Neighbor IP	address
	The IP address of the neighboring router's interface to	the
	attached network.  Used	as the Destination IP address when
	protocol packets are sent as unicasts along this adjacency.
	Also used in router-LSAs as the	Link ID	for the	attached network
	if the neighboring router is selected to be Designated Router
	(see Section 12.4.1).  The Neighbor IP address is learned when
	Hello packets are received from	the neighbor.  For virtual
	links, the Neighbor IP address is learned during the routing
	table build process (see Section 15).

    Neighbor Options
	The optional OSPF capabilities supported by the	neighbor.
	Learned	during the Database Exchange process (see Section 10.6).
	The neighbor's optional	OSPF capabilities are also listed in its
	Hello packets.	This enables received Hello Packets to be
	rejected (i.e.,	neighbor relationships will not	even start to
	form) if there is a mismatch in	certain	crucial	OSPF
	capabilities (see Section 10.5).  The optional OSPF capabilities
	are documented in Section 4.5.

Moy			    Standards Track		       [Page 81]



RFC 2328		     OSPF Version 2		      April 1998

    Neighbor's Designated Router
	The neighbor's idea of the Designated Router.  If this is the
	neighbor itself, this is important in the local	calculation of
	the Designated Router.	Defined	only on	broadcast and NBMA
	networks.

    Neighbor's Backup Designated Router
	The neighbor's idea of the Backup Designated Router.  If this is
	the neighbor itself, this is important in the local calculation
	of the Backup Designated Router.  Defined only on broadcast and
	NBMA networks.

    The	next set of variables are lists	of LSAs.  These	lists describe
    subsets of the area	link-state database.  This memo	defines	five
    distinct types of LSAs, all	of which may be	present	in an area
    link-state database: router-LSAs, network-LSAs, and	Type 3 and 4
    summary-LSAs (all stored in	the area data structure), and AS-
    external-LSAs (stored in the global	data structure).

    Link state retransmission list
	The list of LSAs that have been	flooded	but not	acknowledged on
	this adjacency.	 These will be retransmitted at	intervals until
	they are acknowledged, or until	the adjacency is destroyed.

    Database summary list
	The complete list of LSAs that make up the area	link-state
	database, at the moment	the neighbor goes into Database	Exchange
	state.	This list is sent to the neighbor in Database
	Description packets.

    Link state request list
	The list of LSAs that need to be received from this neighbor in
	order to synchronize the two neighbors'	link-state databases.
	This list is created as	Database Description packets are
	received, and is then sent to the neighbor in Link State Request
	packets.  The list is depleted as appropriate Link State Update
	packets	are received.

Moy			    Standards Track		       [Page 82]



RFC 2328		     OSPF Version 2		      April 1998

    10.1.  Neighbor states

	The state of a neighbor	(really, the state of a	conversation
	being held with	a neighboring router) is documented in the
	following sections.  The states	are listed in order of
	progressing functionality.  For	example, the inoperative state
	is listed first, followed by a list of intermediate states
	before the final, fully	functional state is achieved.  The
	specification makes use	of this	ordering by sometimes making
	references such	as "those neighbors/adjacencies	in state greater
	than X".  Figures 12 and 13 show the graph of neighbor state
	changes.  The arcs of the graphs are labelled with the event
	causing	the state change.  The neighbor	events are documented in
	Section	10.2.

	The graph in Figure 12 shows the state changes effected	by the
	Hello Protocol.	 The Hello Protocol is responsible for neighbor
	acquisition and	maintenance, and for ensuring two way
	communication between neighbors.

	The graph in Figure 13 shows the forming of an adjacency.  Not
	every two neighboring routers become adjacent (see Section
	10.4).	The adjacency starts to	form when the neighbor is in
	state ExStart.	After the two routers discover their
	master/slave status, the state transitions to Exchange.	 At this
	point the neighbor starts to be	used in	the flooding procedure,
	and the	two neighboring	routers	begin synchronizing their
	databases.  When this synchronization is finished, the neighbor
	is in state Full and we	say that the two routers are fully
	adjacent.  At this point the adjacency is listed in LSAs.

	For a more detailed description	of neighbor state changes,
	together with the additional actions involved in each change,
	see Section 10.3.

	Down
	    This is the	initial	state of a neighbor conversation.  It
	    indicates that there has been no recent information	received
	    from the neighbor.	On NBMA	networks, Hello	packets	may
	    still be sent to "Down" neighbors, although	at a reduced
	    frequency (see Section 9.5.1).

Moy			    Standards Track		       [Page 83]



RFC 2328		     OSPF Version 2		      April 1998

				   +----+
				   |Down|
				   +----+
				     |\
				     | \Start
				     |	\      +-------+
			     Hello   |	 +---->|Attempt|
			    Received |	       +-------+
				     |		   |
			     +----+<-+		   |HelloReceived
			     |Init|<---------------+
			     +----+<--------+
				|	    |
				|2-Way	    |1-Way
				|Received   |Received
				|	    |
	      +-------+		|	 +-----+
	      |ExStart|<--------+------->|2-Way|
	      +-------+			 +-----+

	      Figure 12: Neighbor state	changes	(Hello Protocol)

		  In addition to the state transitions pictured,
		  Event	KillNbr	always forces Down State,
		  Event	InactivityTimer	always forces Down State,
		  Event	LLDown always forces Down State

Moy			    Standards Track		       [Page 84]



RFC 2328		     OSPF Version 2		      April 1998

				  +-------+
				  |ExStart|
				  +-------+
				    |
		     NegotiationDone|
				    +->+--------+
				       |Exchange|
				    +--+--------+
				    |
			    Exchange|
			      Done  |
		    +----+	    |	   +-------+
		    |Full|<---------+----->|Loading|
		    +----+<-+		   +-------+
			    |  LoadingDone     |
			    +------------------+

	    Figure 13: Neighbor	state changes (Database	Exchange)

		In addition to the state transitions pictured,
		Event SeqNumberMismatch	forces ExStart state,
		Event BadLSReq forces ExStart state,
		Event 1-Way forces Init	state,
		Event KillNbr always forces Down State,
		Event InactivityTimer always forces Down State,
		Event LLDown always forces Down	State,
		Event AdjOK? leads to adjacency	forming/breaking

	Attempt
	    This state is only valid for neighbors attached to NBMA
	    networks.  It indicates that no recent information has been
	    received from the neighbor,	but that a more	concerted effort
	    should be made to contact the neighbor.  This is done by
	    sending the	neighbor Hello packets at intervals of
	    HelloInterval (see Section 9.5.1).

	Init
	    In this state, an Hello packet has recently	been seen from
	    the	neighbor.  However, bidirectional communication	has not
	    yet	been established with the neighbor (i.e., the router
	    itself did not appear in the neighbor's Hello packet).  All

Moy			    Standards Track		       [Page 85]



RFC 2328		     OSPF Version 2		      April 1998

	    neighbors in this state (or	higher)	are listed in the Hello
	    packets sent from the associated interface.

	2-Way
	    In this state, communication between the two routers is
	    bidirectional.  This has been assured by the operation of
	    the	Hello Protocol.	 This is the most advanced state short
	    of beginning adjacency establishment.  The (Backup)
	    Designated Router is selected from the set of neighbors in
	    state 2-Way	or greater.

	ExStart
	    This is the	first step in creating an adjacency between the
	    two	neighboring routers.  The goal of this step is to decide
	    which router is the	master,	and to decide upon the initial
	    DD sequence	number.	 Neighbor conversations	in this	state or
	    greater are	called adjacencies.

	Exchange
	    In this state the router is	describing its entire link state
	    database by	sending	Database Description packets to	the
	    neighbor.  Each Database Description Packet	has a DD
	    sequence number, and is explicitly acknowledged.  Only one
	    Database Description Packet	is allowed outstanding at any
	    one	time.  In this state, Link State Request Packets may
	    also be sent asking	for the	neighbor's more	recent LSAs.
	    All	adjacencies in Exchange	state or greater are used by the
	    flooding procedure.	 In fact, these	adjacencies are	fully
	    capable of transmitting and	receiving all types of OSPF
	    routing protocol packets.

	Loading
	    In this state, Link	State Request packets are sent to the
	    neighbor asking for	the more recent	LSAs that have been
	    discovered (but not	yet received) in the Exchange state.

	Full
	    In this state, the neighboring routers are fully adjacent.
	    These adjacencies will now appear in router-LSAs and
	    network-LSAs.

Moy			    Standards Track		       [Page 86]



RFC 2328		     OSPF Version 2		      April 1998

    10.2.  Events causing neighbor state changes

	State changes can be effected by a number of events.  These
	events are shown in the	labels of the arcs in Figures 12 and 13.
	The label definitions are as follows:

	HelloReceived
	    An Hello packet has	been received from the neighbor.

	Start
	    This is an indication that Hello Packets should now	be sent
	    to the neighbor at intervals of HelloInterval seconds.  This
	    event is generated only for	neighbors associated with NBMA
	    networks.

	2-WayReceived
	    Bidirectional communication	has been realized between the
	    two	neighboring routers.  This is indicated	by the router
	    seeing itself in the neighbor's Hello packet.

	NegotiationDone
	    The	Master/Slave relationship has been negotiated, and DD
	    sequence numbers have been exchanged.  This	signals	the
	    start of the sending/receiving of Database Description
	    packets.  For more information on the generation of	this
	    event, consult Section 10.8.

	ExchangeDone
	    Both routers have successfully transmitted a full sequence
	    of Database	Description packets.  Each router now knows what
	    parts of its link state database are out of	date.  For more
	    information	on the generation of this event, consult Section
	    10.8.

	BadLSReq
	    A Link State Request has been received for an LSA not
	    contained in the database.	This indicates an error	in the
	    Database Exchange process.

	Loading	Done
	    Link State Updates have been received for all out-of-date

Moy			    Standards Track		       [Page 87]



RFC 2328		     OSPF Version 2		      April 1998

	    portions of	the database.  This is indicated by the	Link
	    state request list becoming	empty after the	Database
	    Exchange process has completed.

	AdjOK?
	    A decision must be made as to whether an adjacency should be
	    established/maintained with	the neighbor.  This event will
	    start some adjacencies forming, and	destroy	others.

	The following events cause well	developed neighbors to revert to
	lesser states.	Unlike the above events, these events may occur
	when the neighbor conversation is in any of a number of	states.

	SeqNumberMismatch
	    A Database Description packet has been received that either
	    a) has an unexpected DD sequence number, b)	unexpectedly has
	    the	Init bit set or	c) has an Options field	differing from
	    the	last Options field received in a Database Description
	    packet.  Any of these conditions indicate that some	error
	    has	occurred during	adjacency establishment.

	1-Way
	    An Hello packet has	been received from the neighbor, in
	    which the router is	not mentioned.	This indicates that
	    communication with the neighbor is not bidirectional.

	KillNbr
	    This  is  an  indication that  all	communication  with  the
	    neighbor  is now  impossible,  forcing  the	 neighbor  to
	    revert  to	Down  state.

	InactivityTimer
	    The	inactivity Timer has fired.  This means	that no	Hello
	    packets have been seen recently from the neighbor.	The
	    neighbor reverts to	Down state.

	LLDown
	    This is an indication from the lower level protocols that
	    the	neighbor is now	unreachable.  For example, on an X.25
	    network this could be indicated by an X.25 clear indication

Moy			    Standards Track		       [Page 88]



RFC 2328		     OSPF Version 2		      April 1998

	    with appropriate cause and diagnostic fields.  This	event
	    forces the neighbor	into Down state.

    10.3.  The Neighbor	state machine

	A detailed description of the neighbor state changes follows.
	Each state change is invoked by	an event (Section 10.2).  This
	event may produce different effects, depending on the current
	state of the neighbor.	For this reason, the state machine below
	is organized by	current	neighbor state and received event.  Each
	entry in the state machine describes the resulting new neighbor
	state and the required set of additional actions.

	When a neighbor's state	changes, it may	be necessary to	rerun
	the Designated Router election algorithm.  This	is determined by
	whether	the interface NeighborChange event is generated	(see
	Section	9.2).  Also, if	the Interface is in DR state (the router
	is itself Designated Router), changes in neighbor state	may
	cause a	new network-LSA	to be originated (see Section 12.4).

	When the neighbor state	machine	needs to invoke	the interface
	state machine, it should be done as a scheduled	task (see
	Section	4.4).  This simplifies things, by ensuring that	neither
	state machine will be executed recursively.

	 State(s):  Down

	    Event:  Start

	New state:  Attempt

	   Action:  Send an Hello Packet to the	neighbor (this neighbor
		    is always associated with an NBMA network) and start
		    the	Inactivity Timer for the neighbor.  The	timer's
		    later firing would indicate	that communication with
		    the	neighbor was not attained.

	 State(s):  Attempt

Moy			    Standards Track		       [Page 89]



RFC 2328		     OSPF Version 2		      April 1998

	    Event:  HelloReceived

	New state:  Init

	   Action:  Restart the	Inactivity Timer for the neighbor, since
		    the	neighbor has now been heard from.

	 State(s):  Down

	    Event:  HelloReceived

	New state:  Init

	   Action:  Start the Inactivity Timer for the neighbor.  The
		    timer's later firing would indicate	that the
		    neighbor is	dead.

	 State(s):  Init or greater

	    Event:  HelloReceived

	New state:  No state change.

	   Action:  Restart the	Inactivity Timer for the neighbor, since
		    the	neighbor has again been	heard from.

	 State(s):  Init

	    Event:  2-WayReceived

	New state:  Depends upon action	routine.

	   Action:  Determine whether an adjacency should be established
		    with the neighbor (see Section 10.4).  If not, the
		    new	neighbor state is 2-Way.

		    Otherwise (an adjacency should be established) the
		    neighbor state transitions to ExStart.  Upon
		    entering this state, the router increments the DD

Moy			    Standards Track		       [Page 90]



RFC 2328		     OSPF Version 2		      April 1998

		    sequence number in the neighbor data structure.  If
		    this is the	first time that	an adjacency has been
		    attempted, the DD sequence number should be	assigned
		    some unique	value (like the	time of	day clock).  It
		    then declares itself master	(sets the master/slave
		    bit	to master), and	starts sending Database
		    Description	Packets, with the initialize (I), more
		    (M)	and master (MS)	bits set.  This	Database
		    Description	Packet should be otherwise empty.  This
		    Database Description Packet	should be retransmitted
		    at intervals of RxmtInterval until the next	state is
		    entered (see Section 10.8).

	 State(s):  ExStart

	    Event:  NegotiationDone

	New state:  Exchange

	   Action:  The	router must list the contents of its entire area
		    link state database	in the neighbor	Database summary
		    list.  The area link state database	consists of the
		    router-LSAs, network-LSAs and summary-LSAs contained
		    in the area	structure, along with the AS-external-
		    LSAs contained in the global structure.  AS-
		    external-LSAs are omitted from a virtual neighbor's
		    Database summary list.  AS-external-LSAs are omitted
		    from the Database summary list if the area has been
		    configured as a stub (see Section 3.6).  LSAs whose
		    age	is equal to MaxAge are instead added to	the
		    neighbor's Link state retransmission list.	A
		    summary of the Database summary list will be sent to
		    the	neighbor in Database Description packets.  Each
		    Database Description Packet	has a DD sequence
		    number, and	is explicitly acknowledged.  Only one
		    Database Description Packet	is allowed outstanding
		    at any one time.  For more detail on the sending and
		    receiving of Database Description packets, see
		    Sections 10.8 and 10.6.

Moy			    Standards Track		       [Page 91]



RFC 2328		     OSPF Version 2		      April 1998

	 State(s):  Exchange

	    Event:  ExchangeDone

	New state:  Depends upon action	routine.

	   Action:  If the neighbor Link state request list is empty,
		    the	new neighbor state is Full.  No	other action is
		    required.  This is an adjacency's final state.

		    Otherwise, the new neighbor	state is Loading.  Start
		    (or	continue) sending Link State Request packets to
		    the	neighbor (see Section 10.9).  These are	requests
		    for	the neighbor's more recent LSAs	(which were
		    discovered but not yet received in the Exchange
		    state).  These LSAs	are listed in the Link state
		    request list associated with the neighbor.

	 State(s):  Loading

	    Event:  Loading Done

	New state:  Full

	   Action:  No action required.	 This is an adjacency's	final
		    state.

	 State(s):  2-Way

	    Event:  AdjOK?

	New state:  Depends upon action	routine.

	   Action:  Determine whether an adjacency should be formed with
		    the	neighboring router (see	Section	10.4).	If not,
		    the	neighbor state remains at 2-Way.  Otherwise,
		    transition the neighbor state to ExStart and perform
		    the	actions	associated with	the above state	machine
		    entry for state Init and event 2-WayReceived.

Moy			    Standards Track		       [Page 92]



RFC 2328		     OSPF Version 2		      April 1998

	 State(s):  ExStart or greater

	    Event:  AdjOK?

	New state:  Depends upon action	routine.

	   Action:  Determine whether the neighboring router should
		    still be adjacent.	If yes,	there is no state change
		    and	no further action is necessary.

		    Otherwise, the (possibly partially formed) adjacency
		    must be destroyed.	The neighbor state transitions
		    to 2-Way.  The Link	state retransmission list,
		    Database summary list and Link state request list
		    are	cleared	of LSAs.

	 State(s):  Exchange or	greater

	    Event:  SeqNumberMismatch

	New state:  ExStart

	   Action:  The	(possibly partially formed) adjacency is torn
		    down, and then an attempt is made at
		    reestablishment.  The neighbor state first
		    transitions	to ExStart.  The Link state
		    retransmission list, Database summary list and Link
		    state request list are cleared of LSAs.  Then the
		    router increments the DD sequence number in	the
		    neighbor data structure, declares itself master
		    (sets the master/slave bit to master), and starts
		    sending Database Description Packets, with the
		    initialize (I), more (M) and master	(MS) bits set.
		    This Database Description Packet should be otherwise
		    empty (see Section 10.8).

	 State(s):  Exchange or	greater

	    Event:  BadLSReq

Moy			    Standards Track		       [Page 93]



RFC 2328		     OSPF Version 2		      April 1998

	New state:  ExStart

	   Action:  The	action for event BadLSReq is exactly the same as
		    for	the neighbor event SeqNumberMismatch.  The
		    (possibly partially	formed)	adjacency is torn down,
		    and	then an	attempt	is made	at reestablishment.  For
		    more information, see the neighbor state machine
		    entry that is invoked when event SeqNumberMismatch
		    is generated in state Exchange or greater.

	 State(s):  Any	state

	    Event:  KillNbr

	New state:  Down

	   Action:  The	Link state retransmission list,	Database summary
		    list and Link state	request	list are cleared of
		    LSAs.  Also, the Inactivity	Timer is disabled.

	 State(s):  Any	state

	    Event:  LLDown

	New state:  Down

	   Action:  The	Link state retransmission list,	Database summary
		    list and Link state	request	list are cleared of
		    LSAs.  Also, the Inactivity	Timer is disabled.

	 State(s):  Any	state

	    Event:  InactivityTimer

	New state:  Down

	   Action:  The	Link state retransmission list,	Database summary
		    list and Link state	request	list are cleared of
		    LSAs.

Moy			    Standards Track		       [Page 94]



RFC 2328		     OSPF Version 2		      April 1998

	 State(s):  2-Way or greater

	    Event:  1-WayReceived

	New state:  Init

	   Action:  The	Link state retransmission list,	Database summary
		    list and Link state	request	list are cleared of
		    LSAs.

	 State(s):  2-Way or greater

	    Event:  2-WayReceived

	New state:  No state change.

	   Action:  No action required.

	 State(s):  Init

	    Event:  1-WayReceived

	New state:  No state change.

	   Action:  No action required.

    10.4.  Whether to become adjacent

	Adjacencies are	established with some subset of	the router's
	neighbors.  Routers connected by point-to-point	networks,
	Point-to-MultiPoint networks and virtual links always become
	adjacent.  On broadcast	and NBMA networks, all routers become
	adjacent to both the Designated	Router and the Backup Designated
	Router.

	The adjacency-forming decision occurs in two places in the
	neighbor state machine.	 First,	when bidirectional communication
	is initially established with the neighbor, and	secondly, when
	the identity of	the attached network's (Backup)	Designated

Moy			    Standards Track		       [Page 95]



RFC 2328		     OSPF Version 2		      April 1998

	Router changes.	 If the	decision is made to not	attempt	an
	adjacency, the state of	the neighbor communication stops at 2-
	Way.

	An adjacency should be established with	a bidirectional	neighbor
	when at	least one of the following conditions holds:

	o   The	underlying network type	is point-to-point

	o   The	underlying network type	is Point-to-MultiPoint

	o   The	underlying network type	is virtual link

	o   The	router itself is the Designated	Router

	o   The	router itself is the Backup Designated Router

	o   The	neighboring router is the Designated Router

	o   The	neighboring router is the Backup Designated Router

    10.5.  Receiving Hello Packets

	This section explains the detailed processing of a received
	Hello Packet.  (See Section A.3.2 for the format of Hello
	packets.)  The generic input processing	of OSPF	packets	will
	have checked the validity of the IP header and the OSPF	packet
	header.	 Next, the values of the Network Mask, HelloInterval,
	and RouterDeadInterval fields in the received Hello packet must
	be checked against the values configured for the receiving
	interface.  Any	mismatch causes	processing to stop and the
	packet to be dropped.  In other	words, the above fields	are
	really describing the attached network's configuration.	However,
	there is one exception to the above rule: on point-to-point
	networks and on	virtual	links, the Network Mask	in the received
	Hello Packet should be ignored.

	The receiving interface	attaches to a single OSPF area (this
	could be the backbone).	 The setting of	the E-bit found	in the
	Hello Packet's Options field must match	this area's

Moy			    Standards Track		       [Page 96]



RFC 2328		     OSPF Version 2		      April 1998

	ExternalRoutingCapability.  If AS-external-LSAs	are not	flooded
	into/throughout	the area (i.e, the area	is a "stub") the E-bit
	must be	clear in received Hello	Packets, otherwise the E-bit
	must be	set.  A	mismatch causes	processing to stop and the
	packet to be dropped.  The setting of the rest of the bits in
	the Hello Packet's Options field should	be ignored.

	At this	point, an attempt is made to match the source of the
	Hello Packet to	one of the receiving interface's neighbors.  If
	the receiving interface	connects to a broadcast, Point-to-
	MultiPoint or NBMA network the source is identified by the IP
	source address found in	the Hello's IP header.	If the receiving
	interface connects to a	point-to-point link or a virtual link,
	the source is identified by the	Router ID found	in the Hello's
	OSPF packet header.  The interface's current list of neighbors
	is contained in	the interface's	data structure.	 If a matching
	neighbor structure cannot be found, (i.e., this	is the first
	time the neighbor has been detected), one is created.  The
	initial	state of a newly created neighbor is set to Down.

	When receiving an Hello	Packet from a neighbor on a broadcast,
	Point-to-MultiPoint or NBMA network, set the neighbor
	structure's Neighbor ID	equal to the Router ID found in	the
	packet's OSPF header.  For these network types,	the neighbor
	structure's Router Priority field, Neighbor's Designated Router
	field, and Neighbor's Backup Designated	Router field are also
	set equal to the corresponding fields found in the received
	Hello Packet; changes in these fields should be	noted for
	possible use in	the steps below.  When receiving an Hello on a
	point-to-point network (but not	on a virtual link) set the
	neighbor structure's Neighbor IP address to the	packet's IP
	source address.

	Now the	rest of	the Hello Packet is examined, generating events
	to be given to the neighbor and	interface state	machines.  These
	state machines are specified either to be executed or scheduled
	(see Section 4.4).  For	example, by specifying below that the
	neighbor state machine be executed in line, several neighbor
	state transitions may be effected by a single received Hello:

Moy			    Standards Track		       [Page 97]



RFC 2328		     OSPF Version 2		      April 1998

	o   Each Hello Packet causes the neighbor state	machine	to be
	    executed with the event HelloReceived.

	o   Then the list of neighbors contained in the	Hello Packet is
	    examined.  If the router itself appears in this list, the
	    neighbor state machine should be executed with the event 2-
	    WayReceived.  Otherwise, the neighbor state	machine	should
	    be executed	with the event 1-WayReceived, and the processing
	    of the packet stops.

	o   Next, if a change in the neighbor's	Router Priority	field
	    was	noted, the receiving interface's state machine is
	    scheduled with the event NeighborChange.

	o   If the neighbor is both declaring itself to	be Designated
	    Router (Hello Packet's Designated Router field = Neighbor IP
	    address) and the Backup Designated Router field in the
	    packet is equal to 0.0.0.0 and the receiving interface is in
	    state Waiting, the receiving interface's state machine is
	    scheduled with the event BackupSeen.  Otherwise, if	the
	    neighbor is	declaring itself to be Designated Router and it
	    had	not previously,	or the neighbor	is not declaring itself
	    Designated Router where it had previously, the receiving
	    interface's	state machine is scheduled with	the event
	    NeighborChange.

	o   If the neighbor is declaring itself	to be Backup Designated
	    Router (Hello Packet's Backup Designated Router field =
	    Neighbor IP	address) and the receiving interface is	in state
	    Waiting, the receiving interface's state machine is
	    scheduled with the event BackupSeen.  Otherwise, if	the
	    neighbor is	declaring itself to be Backup Designated Router
	    and	it had not previously, or the neighbor is not declaring
	    itself Backup Designated Router where it had previously, the
	    receiving interface's state	machine	is scheduled with the
	    event NeighborChange.

	On NBMA	networks, receipt of an	Hello Packet may also cause an
	Hello Packet to	be sent	back to	the neighbor in	response. See
	Section	9.5.1 for more details.

Moy			    Standards Track		       [Page 98]



RFC 2328		     OSPF Version 2		      April 1998

    10.6.  Receiving Database Description Packets

	This section explains the detailed processing of a received
	Database Description Packet.  The incoming Database Description
	Packet has already been	associated with	a neighbor and receiving
	interface by the generic input packet processing (Section 8.2).
	Whether	the Database Description packet	should be accepted, and
	if so, how it should be	further	processed depends upon the
	neighbor state.

	If a Database Description packet is accepted, the following
	packet fields should be	saved in the corresponding neighbor data
	structure under	"last received Database	Description packet":
	the packet's initialize(I), more (M) and master(MS) bits,
	Options	field, and DD sequence number. If these	fields are set
	identically in two consecutive Database	Description packets
	received from the neighbor, the	second Database	Description
	packet is considered to	be a "duplicate" in the	processing
	described below.

	If the Interface MTU field in the Database Description packet
	indicates an IP	datagram size that is larger than the router can
	accept on the receiving	interface without fragmentation, the
	Database Description packet is rejected.  Otherwise, if	the
	neighbor state is:

	Down
	    The	packet should be rejected.

	Attempt
	    The	packet should be rejected.

	Init
	    The	neighbor state machine should be executed with the event
	    2-WayReceived.  This causes	an immediate state change to
	    either state 2-Way or state	ExStart. If the	new state is
	    ExStart, the processing of the current packet should then
	    continue in	this new state by falling through to case
	    ExStart below.

Moy			    Standards Track		       [Page 99]



RFC 2328		     OSPF Version 2		      April 1998

	2-Way
	    The	packet should be ignored.  Database Description	Packets
	    are	used only for the purpose of bringing up adjacencies.[7]

	ExStart
	    If the received packet matches one of the following	cases,
	    then the neighbor state machine should be executed with the
	    event NegotiationDone (causing the state to	transition to
	    Exchange), the packet's Options field should be recorded in
	    the	neighbor structure's Neighbor Options field and	the
	    packet should be accepted as next in sequence and processed
	    further (see below).  Otherwise, the packet	should be
	    ignored.

	    o	The initialize(I), more	(M) and	master(MS) bits	are set,
		the contents of	the packet are empty, and the neighbor's
		Router ID is larger than the router's own.  In this case
		the router is now Slave.  Set the master/slave bit to
		slave, and set the neighbor data structure's DD	sequence
		number to that specified by the	master.

	    o	The initialize(I) and master(MS) bits are off, the
		packet's DD sequence number equals the neighbor	data
		structure's DD sequence	number (indicating
		acknowledgment)	and the	neighbor's Router ID is	smaller
		than the router's own.	In this	case the router	is
		Master.

	Exchange
	    Duplicate Database Description packets are discarded by the
	    master, and	cause the slave	to retransmit the last Database
	    Description	packet that it had sent. Otherwise (the	packet
	    is not a duplicate):

	    o	If the state of	the MS-bit is inconsistent with	the
		master/slave state of the connection, generate the
		neighbor event SeqNumberMismatch and stop processing the
		packet.

	    o	If the initialize(I) bit is set, generate the neighbor
		event SeqNumberMismatch	and stop processing the	packet.

Moy			    Standards Track		      [Page 100]



RFC 2328		     OSPF Version 2		      April 1998

	    o	If the packet's	Options	field indicates	a different set
		of optional OSPF capabilities than were	previously
		received from the neighbor (recorded in	the Neighbor
		Options	field of the neighbor structure), generate the
		neighbor event SeqNumberMismatch and stop processing the
		packet.

	    o	Database Description packets must be processed in
		sequence, as indicated by the packets' DD sequence
		numbers. If the	router is master, the next packet
		received should	have DD	sequence number	equal to the DD
		sequence number	in the neighbor	data structure.	If the
		router is slave, the next packet received should have DD
		sequence number	equal to one more than the DD sequence
		number stored in the neighbor data structure. In either
		case, if the packet is the next	in sequence it should be
		accepted and its contents processed as specified below.

	    o	Else, generate the neighbor event SeqNumberMismatch and
		stop processing	the packet.

	Loading	or Full
	    In this state, the router has sent and received an entire
	    sequence of	Database Description Packets.  The only	packets
	    received should be duplicates (see above).	In particular,
	    the	packet's Options field should match the	set of optional
	    OSPF capabilities previously indicated by the neighbor
	    (stored in the neighbor structure's	Neighbor Options field).
	    Any	other packets received,	including the reception	of a
	    packet with	the Initialize(I) bit set, should generate the
	    neighbor event SeqNumberMismatch.[8] Duplicates should be
	    discarded by the master.  The slave	must respond to
	    duplicates by repeating the	last Database Description packet
	    that it had	sent.

	When the router	accepts	a received Database Description	Packet
	as the next in sequence	the packet contents are	processed as
	follows.  For each LSA listed, the LSA's LS type is checked for
	validity.  If the LS type is unknown (e.g., not	one of the LS
	types 1-5 defined by this specification), or if	this is	an AS-
	external-LSA (LS type =	5) and the neighbor is associated with a

Moy			    Standards Track		      [Page 101]



RFC 2328		     OSPF Version 2		      April 1998

	stub area, generate the	neighbor event SeqNumberMismatch and
	stop processing	the packet.  Otherwise,	the router looks up the
	LSA in its database to see whether it also has an instance of
	the LSA.  If it	does not, or if	the database copy is less recent
	(see Section 13.1), the	LSA is put on the Link state request
	list so	that it	can be requested (immediately or at some later
	time) in Link State Request Packets.

	When the router	accepts	a received Database Description	Packet
	as the next in sequence, it also performs the following	actions,
	depending on whether it	is master or slave:

	Master
	    Increments the DD sequence number in the neighbor data
	    structure.	If the router has already sent its entire
	    sequence of	Database Description Packets, and the just
	    accepted packet has	the more bit (M) set to	0, the neighbor
	    event ExchangeDone is generated.  Otherwise, it should send
	    a new Database Description to the slave.

	Slave
	    Sets the DD	sequence number	in the neighbor	data structure
	    to the DD sequence number appearing	in the received	packet.
	    The	slave must send	a Database Description Packet in reply.
	    If the received packet has the more	bit (M)	set to 0, and
	    the	packet to be sent by the slave will also have the M-bit
	    set	to 0, the neighbor event ExchangeDone is generated.
	    Note that the slave	always generates this event before the
	    master.

    10.7.  Receiving Link State	Request	Packets

	This section explains the detailed processing of received Link
	State Request packets.	Received Link State Request Packets
	specify	a list of LSAs that the	neighbor wishes	to receive.
	Link State Request Packets should be accepted when the neighbor
	is in states Exchange, Loading,	or Full.  In all other states
	Link State Request Packets should be ignored.

Moy			    Standards Track		      [Page 102]



RFC 2328		     OSPF Version 2		      April 1998

	Each LSA specified in the Link State Request packet should be
	located	in the router's	database, and copied into Link State
	Update packets for transmission	to the neighbor.  These	LSAs
	should NOT be placed on	the Link state retransmission list for
	the neighbor.  If an LSA cannot	be found in the	database,
	something has gone wrong with the Database Exchange process, and
	neighbor event BadLSReq	should be generated.

    10.8.  Sending Database Description	Packets

	This section describes how Database Description	Packets	are sent
	to a neighbor. The Database Description	packet's Interface MTU
	field is set to	the size of the	largest	IP datagram that can be
	sent out the sending interface,	without	fragmentation.	Common
	MTUs in	use in the Internet can	be found in Table 7-1 of
	[Ref22]. Interface MTU should be set to	0 in Database
	Description packets sent over virtual links.

	The router's optional OSPF capabilities	(see Section 4.5) are
	transmitted to the neighbor in the Options field of the	Database
	Description packet.  The router	should maintain	the same set of
	optional capabilities throughout the Database Exchange and
	flooding procedures.  If for some reason the router's optional
	capabilities change, the Database Exchange procedure should be
	restarted by reverting to neighbor state ExStart.  One optional
	capability is defined in this specification (see Sections 4.5
	and A.2). The E-bit should be set if and only if the attached
	network	belongs	to a non-stub area. Unrecognized bits in the
	Options	field should be	set to zero.

	The sending of Database	Description packets depends on the
	neighbor's state.  In state ExStart the	router sends empty
	Database Description packets, with the initialize (I), more (M)
	and master (MS)	bits set.  These packets are retransmitted every
	RxmtInterval seconds.

	In state Exchange the Database Description Packets actually
	contain	summaries of the link state information	contained in the
	router's database.  Each LSA in	the area's link-state database
	(at the	time the neighbor transitions into Exchange state) is
	listed in the neighbor Database	summary	list.  Each new	Database

Moy			    Standards Track		      [Page 103]



RFC 2328		     OSPF Version 2		      April 1998

	Description Packet copies its DD sequence number from the
	neighbor data structure	and then describes the current top of
	the Database summary list.  Items are removed from the Database
	summary	list when the previous packet is acknowledged.

	In state Exchange, the determination of	when to	send a Database
	Description packet depends on whether the router is master or
	slave:

	Master
	    Database Description packets are sent when either a) the
	    slave acknowledges the previous Database Description packet
	    by echoing the DD sequence number or b) RxmtInterval seconds
	    elapse without an acknowledgment, in which case the	previous
	    Database Description packet	is retransmitted.

	Slave
	    Database Description packets are sent only in response to
	    Database Description packets received from the master.  If
	    the	Database Description packet received from the master is
	    new, a new Database	Description packet is sent, otherwise
	    the	previous Database Description packet is	resent.

	In states Loading and Full the slave must resend its last
	Database Description packet in response	to duplicate Database
	Description packets received from the master.  For this	reason
	the slave must wait RouterDeadInterval seconds before freeing
	the last Database Description packet.  Reception of a Database
	Description packet from	the master after this interval will
	generate a SeqNumberMismatch neighbor event.

    10.9.  Sending Link	State Request Packets

	In neighbor states Exchange or Loading,	the Link state request
	list contains a	list of	those LSAs that	need to	be obtained from
	the neighbor.  To request these	LSAs, a	router sends the
	neighbor the beginning of the Link state request list, packaged
	in a Link State	Request	packet.

Moy			    Standards Track		      [Page 104]



RFC 2328		     OSPF Version 2		      April 1998

	When the neighbor responds to these requests with the proper
	Link State Update packet(s), the Link state request list is
	truncated and a	new Link State Request packet is sent.	This
	process	continues until	the Link state request list becomes
	empty. LSAs on the Link	state request list that	have been
	requested, but not yet received, are packaged into Link	State
	Request	packets	for retransmission at intervals	of RxmtInterval.
	There should be	at most	one Link State Request packet
	outstanding at any one time.

	When the Link state request list becomes empty,	and the	neighbor
	state is Loading (i.e.,	a complete sequence of Database
	Description packets has	been sent to and received from the
	neighbor), the Loading Done neighbor event is generated.

    10.10.  An Example

	Figure 14 shows	an example of an adjacency forming.  Routers RT1
	and RT2	are both connected to a	broadcast network.  It is
	assumed	that RT2 is the	Designated Router for the network, and
	that RT2 has a higher Router ID	than Router RT1.

	The neighbor state changes realized by each router are listed on
	the sides of the figure.

	At the beginning of Figure 14, Router RT1's interface to the
	network	becomes	operational.  It begins	sending	Hello Packets,
	although it doesn't know the identity of the Designated	Router
	or of any other	neighboring routers.  Router RT2 hears this
	hello (moving the neighbor to Init state), and in its next Hello
	Packet indicates that it is itself the Designated Router and
	that it	has heard Hello	Packets	from RT1.  This	in turn	causes
	RT1 to go to state ExStart, as it starts to bring up the
	adjacency.

	RT1 begins by asserting	itself as the master.  When it sees that
	RT2 is indeed the master (because of RT2's higher Router ID),
	RT1 transitions	to slave state and adopts its neighbor's DD
	sequence number.  Database Description packets are then
	exchanged, with	polls coming from the master (RT2) and responses
	from the slave (RT1).  This sequence of	Database Description

Moy			    Standards Track		      [Page 105]



RFC 2328		     OSPF Version 2		      April 1998

	    +---+					  +---+
	    |RT1|					  |RT2|
	    +---+					  +---+

	    Down					  Down
			    Hello(DR=0,seen=0)
		       ------------------------------>
			 Hello (DR=RT2,seen=RT1,...)	  Init
		       <------------------------------
	    ExStart	   D-D (Seq=x,I,M,Master)
		       ------------------------------>
			   D-D (Seq=y,I,M,Master)	  ExStart
		       <------------------------------
	    Exchange	   D-D (Seq=y,M,Slave)
		       ------------------------------>
			   D-D (Seq=y+1,M,Master)	  Exchange
		       <------------------------------
			   D-D (Seq=y+1,M,Slave)
		       ------------------------------>
				     ...
				     ...
				     ...
			   D-D (Seq=y+n, Master)
		       <------------------------------
			   D-D (Seq=y+n, Slave)
	     Loading   ------------------------------>
				 LS Request		   Full
		       ------------------------------>
				 LS Update
		       <------------------------------
				 LS Request
		       ------------------------------>
				 LS Update
		       <------------------------------
	     Full

Moy			    Standards Track		      [Page 106]



RFC 2328		     OSPF Version 2		      April 1998

		   Figure 14: An adjacency bring-up example

	Packets	ends when both the poll	and associated response	has the
	M-bit off.

	In this	example, it is assumed that RT2	has a completely up to
	date database.	In that	case, RT2 goes immediately into	Full
	state.	RT1 will go into Full state after updating the necessary
	parts of its database.	This is	done by	sending	Link State
	Request	Packets, and receiving Link State Update Packets in
	response.  Note	that, while RT1	has waited until a complete set
	of Database Description	Packets	has been received (from	RT2)
	before sending any Link	State Request Packets, this need not be
	the case.  RT1 could have interleaved the sending of Link State
	Request	Packets	with the reception of Database Description
	Packets.

11.  The Routing Table Structure

    The	routing	table data structure contains all the information
    necessary to forward an IP data packet toward its destination.  Each
    routing table entry	describes the collection of best paths to a
    particular destination.  When forwarding an	IP data	packet,	the
    routing table entry	providing the best match for the packet's IP
    destination	is located.  The matching routing table	entry then
    provides the next hop towards the packet's destination.  OSPF also
    provides for the existence of a default route (Destination ID =
    DefaultDestination,	Address	Mask =	0x00000000).  When the default
    route exists, it matches all IP destinations (although any other
    matching entry is a	better match).	Finding	the routing table entry
    that best matches an IP destination	is further described in	Section
    11.1.

    There is a single routing table in each router.  Two sample	routing
    tables are described in Sections 11.2 and 11.3.  The building of the
    routing table is discussed in Section 16.

Moy			    Standards Track		      [Page 107]



RFC 2328		     OSPF Version 2		      April 1998

    The	rest of	this section defines the fields	found in a routing table
    entry.  The	first set of fields describes the routing table	entry's
    destination.

    Destination	Type
	Destination type is either "network" or	"router". Only network
	entries	are actually used when forwarding IP data traffic.
	Router routing table entries are used solely as	intermediate
	steps in the routing table build process.

	A network is a range of	IP addresses, to which IP data traffic
	may be forwarded.  This	includes IP networks (class A, B, or C),
	IP subnets, IP supernets and single IP hosts.  The default route
	also falls into	this category.

	Router entries are kept	for area border	routers	and AS boundary
	routers.  Routing table	entries	for area border	routers	are used
	when calculating the inter-area	routes (see Section 16.2), and
	when maintaining configured virtual links (see Section 15).
	Routing	table entries for AS boundary routers are used when
	calculating the	AS external routes (see	Section	16.4).

    Destination	ID
	The destination's identifier or	name.  This depends on the
	Destination Type.  For networks, the identifier	is their
	associated IP address.	For routers, the identifier is the OSPF
	Router ID.[9]

    Address Mask
	Only defined for networks.  The	network's IP address together
	with its address mask defines a	range of IP addresses.	For IP
	subnets, the address mask is referred to as the	subnet mask.
	For host routes, the mask is "all ones"	(0xffffffff).

    Optional Capabilities
	When the destination is	a router this field indicates the
	optional OSPF capabilities supported by	the destination	router.
	The only optional capability defined by	this specification is
	the ability to process AS-external-LSAs.  For a	further
	discussion of OSPF's optional capabilities, see	Section	4.5.

Moy			    Standards Track		      [Page 108]



RFC 2328		     OSPF Version 2		      April 1998

    The	set of paths to	use for	a destination may vary based on	the OSPF
    area to which the paths belong.  This means	that there may be
    multiple routing table entries for the same	destination, depending
    on the values of the next field.

    Area
	This field indicates the area whose link state information has
	led to the routing table entry's collection of paths.  This is
	called the entry's associated area.  For sets of AS external
	paths, this field is not defined.  For destinations of type
	"router", there	may be separate	sets of	paths (and therefore
	separate routing table entries)	associated with	each of	several
	areas. For example, this will happen when two area border
	routers	share multiple areas in	common.	 For destinations of
	type "network",	only the set of	paths associated with the best
	area (the one providing	the preferred route) is	kept.

    The	rest of	the routing table entry	describes the set of paths to
    the	destination.  The following fields pertain to the set of paths
    as a whole.	 In other words, each one of the paths contained in a
    routing table entry	is of the same path-type and cost (see below).

    Path-type
	There are four possible	types of paths used to route traffic to
	the destination, listed	here in	decreasing order of preference:
	intra-area, inter-area,	type 1 external	or type	2 external.
	Intra-area paths indicate destinations belonging to one	of the
	router's attached areas.  Inter-area paths are paths to
	destinations in	other OSPF areas.  These are discovered	through
	the examination	of received summary-LSAs.  AS external paths are
	paths to destinations external to the AS.  These are detected
	through	the examination	of received AS-external-LSAs.

    Cost
	The link state cost of the path	to the destination.  For all
	paths except type 2 external paths this	describes the entire
	path's cost.  For Type 2 external paths, this field describes
	the cost of the	portion	of the path internal to	the AS.	 This

Moy			    Standards Track		      [Page 109]



RFC 2328		     OSPF Version 2		      April 1998

	cost is	calculated as the sum of the costs of the path's
	constituent links.

    Type 2 cost
	Only valid for type 2 external paths.  For these paths,	this
	field indicates	the cost of the	path's external	portion.  This
	cost has been advertised by an AS boundary router, and is the
	most significant part of the total path	cost.  For example, a
	type 2 external	path with type 2 cost of 5 is always preferred
	over a path with type 2	cost of	10, regardless of the cost of
	the two	paths' internal	components.

    Link State Origin
	Valid only for intra-area paths, this field indicates the LSA
	(router-LSA or network-LSA) that directly references the
	destination.  For example, if the destination is a transit
	network, this is the transit network's network-LSA.  If	the
	destination is a stub network, this is the router-LSA for the
	attached router.  The LSA is discovered	during the shortest-path
	tree calculation (see Section 16.1).  Multiple LSAs may
	reference the destination, however a tie-breaking scheme always
	reduces	the choice to a	single LSA. The	Link State Origin field
	is not used by the OSPF	protocol, but it is used by the	routing
	table calculation in OSPF's Multicast routing extensions
	(MOSPF).

    When multiple paths	of equal path-type and cost exist to a
    destination	(called	elsewhere "equal-cost" paths), they are	stored
    in a single	routing	table entry.  Each one of the "equal-cost" paths
    is distinguished by	the following fields:

    Next hop
	The outgoing router interface to use when forwarding traffic to
	the destination.  On broadcast,	Point-to-MultiPoint and	NBMA
	networks, the next hop also includes the IP address of the next
	router (if any)	in the path towards the	destination.

    Advertising	router
	Valid only for inter-area and AS external paths.  This field
	indicates the Router ID	of the router advertising the summary-
	LSA or AS-external-LSA that led	to this	path.

Moy			    Standards Track		      [Page 110]



RFC 2328		     OSPF Version 2		      April 1998

    11.1.  Routing table lookup

	When an	IP data	packet is received, an OSPF router finds the
	routing	table entry that best matches the packet's destination.
	This routing table entry then provides the outgoing interface
	and next hop router to use in forwarding the packet. This
	section	describes the process of finding the best matching
	routing	table entry.

	Before the lookup begins, "discard" routing table entries should
	be inserted into the routing table for each of the router's
	active area address ranges (see	Section	3.5).  (An area	range is
	considered "active" if the range contains one or more networks
	reachable by intra-area	paths.)	The destination	of a "discard"
	entry is the set of addresses described	by its associated active
	area address range, and	the path type of each "discard"	entry is
	set to "inter-area".[10]

	Several	routing	table entries may match	the destination	address.
	In this	case, the "best	match" is the routing table entry that
	provides the most specific (longest) match. Another way	of
	saying this is to choose the entry that	specifies the narrowest
	range of IP addresses.[11] For example,	the entry for the
	address/mask pair of (128.185.1.0, 0xffffff00) is more specific
	than an	entry for the pair (128.185.0.0, 0xffff0000). The
	default	route is the least specific match, since it matches all
	destinations. (Note that for any single	routing	table entry,
	multiple paths may be possible.	In these cases,	the calculations
	in Sections 16.1, 16.2,	and 16.4 always	yield the paths	having
	the most preferential path-type, as described in Section 11).

	If there is no matching	routing	table entry, or	the best match
	routing	table entry is one of the above	"discard" routing table
	entries, then the packet's IP destination is considered
	unreachable. Instead of	being forwarded, the packet should then
	be discarded and an ICMP destination unreachable message should
	be returned to the packet's source.

    11.2.  Sample routing table, without areas

	Consider the Autonomous	System pictured	in Figure 2.  No OSPF
	areas have been	configured.  A single metric is	shown per

Moy			    Standards Track		      [Page 111]



RFC 2328		     OSPF Version 2		      April 1998

	outbound interface.  The calculation of	Router RT6's routing
	table proceeds as described in Section 2.2.  The resulting
	routing	table is shown in Table	12.  Destination types are
	abbreviated: Network as	"N", Router as "R".

	There are no instances of multiple equal-cost shortest paths in
	this example.  Also, since there are no	areas, there are no
	inter-area paths.

	Routers	RT5 and	RT7 are	AS boundary routers.  Intra-area routes
	have been calculated to	Routers	RT5 and	RT7.  This allows
	external routes	to be calculated to the	destinations advertised
	by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15).	It is
	assumed	all AS-external-LSAs originated	by RT5 and RT7 are
	advertising type 1 external metrics.  This results in type 1
	external paths being calculated	to destinations	N12-N15.

    11.3.  Sample routing table, with areas

	Consider the previous example, this time split into OSPF areas.
	An OSPF	area configuration is pictured in Figure 6.  Router
	RT4's routing table will be described for this area
	configuration.	Router RT4 has a connection to Area 1 and a
	backbone connection.  This causes Router RT4 to	view the AS as
	the concatenation of the two graphs shown in Figures 7 and 8.
	The resulting routing table is displayed in Table 13.

	Again, Routers RT5 and RT7 are AS boundary routers.  Routers
	RT3, RT4, RT7, RT10 and	RT11 are area border routers.  Note that
	there are two routing entries for the area border router RT3,
	since it has two areas in common with RT4 (Area	1 and the
	backbone).

	Backbone paths have been calculated to all area	border routers.
	These are used when determining	the inter-area routes.	Note
	that all of the	inter-area routes are associated with the
	backbone; this is always the case when the calculating router is
	itself an area border router.  Routing information is condensed
	at area	boundaries.  In	this example, we assume	that Area 3 has
	been defined so	that networks N9-N11 and the host route	to H1

Moy			    Standards Track		      [Page 112]



RFC 2328		     OSPF Version 2		      April 1998

      Type   Dest   Area   Path	 Type	 Cost	Next	 Adv.
						Hop(s)	 Router(s)
      ____________________________________________________________
      N	     N1	    0	   intra-area	 10	RT3	 *
      N	     N2	    0	   intra-area	 10	RT3	 *
      N	     N3	    0	   intra-area	 7	RT3	 *
      N	     N4	    0	   intra-area	 8	RT3	 *
      N	     Ib	    0	   intra-area	 7	*	 *
      N	     Ia	    0	   intra-area	 12	RT10	 *
      N	     N6	    0	   intra-area	 8	RT10	 *
      N	     N7	    0	   intra-area	 12	RT10	 *
      N	     N8	    0	   intra-area	 10	RT10	 *
      N	     N9	    0	   intra-area	 11	RT10	 *
      N	     N10    0	   intra-area	 13	RT10	 *
      N	     N11    0	   intra-area	 14	RT10	 *
      N	     H1	    0	   intra-area	 21	RT10	 *
      R	     RT5    0	   intra-area	 6	RT5	 *
      R	     RT7    0	   intra-area	 8	RT10	 *
      ____________________________________________________________
      N	     N12    *	   type	1 ext.	 10	RT10	 RT7
      N	     N13    *	   type	1 ext.	 14	RT5	 RT5
      N	     N14    *	   type	1 ext.	 14	RT5	 RT5
      N	     N15    *	   type	1 ext.	 17	RT10	 RT7

	       Table 12: The routing table for Router RT6
			 (no configured	areas).

	are all	condensed to a single route when advertised into the
	backbone (by Router RT11).  Note that the cost of this route is
	the maximum of the set of costs	to its individual components.

	There is a virtual link	configured between Routers RT10	and
	RT11.  Without this configured virtual link, RT11 would	be
	unable to advertise a route for	networks N9-N11	and Host H1 into
	the backbone, and there	would not be an	entry for these	networks
	in Router RT4's	routing	table.

	In this	example	there are two equal-cost paths to Network N12.
	However, they both use the same	next hop (Router RT5).

Moy			    Standards Track		      [Page 113]



RFC 2328		     OSPF Version 2		      April 1998

	Router RT4's routing table would improve (i.e.,	some of	the
	paths in the routing table would become	shorter) if an
	additional virtual link	were configured	between	Router RT4 and
	Router RT3.  The new virtual link would	itself be associated
	with the first entry for area border router RT3	in Table 13 (an
	intra-area path	through	Area 1).  This would yield a cost of 1
	for the	virtual	link.  The routing table entries changes that
	would be caused	by the addition	of this	virtual	link are shown

   Type	  Dest	      Area   Path  Type	   Cost	  Next	    Adv.
						  Hops(s)   Router(s)
   __________________________________________________________________
   N	  N1	      1	     intra-area	   4	  RT1	    *
   N	  N2	      1	     intra-area	   4	  RT2	    *
   N	  N3	      1	     intra-area	   1	  *	    *
   N	  N4	      1	     intra-area	   3	  RT3	    *
   R	  RT3	      1	     intra-area	   1	  *	    *
   __________________________________________________________________
   N	  Ib	      0	     intra-area	   22	  RT5	    *
   N	  Ia	      0	     intra-area	   27	  RT5	    *
   R	  RT3	      0	     intra-area	   21	  RT5	    *
   R	  RT5	      0	     intra-area	   8	  *	    *
   R	  RT7	      0	     intra-area	   14	  RT5	    *
   R	  RT10	      0	     intra-area	   22	  RT5	    *
   R	  RT11	      0	     intra-area	   25	  RT5	    *
   __________________________________________________________________
   N	  N6	      0	     inter-area	   15	  RT5	    RT7
   N	  N7	      0	     inter-area	   19	  RT5	    RT7
   N	  N8	      0	     inter-area	   18	  RT5	    RT7
   N	  N9-N11,H1   0	     inter-area	   36	  RT5	    RT11
   __________________________________________________________________
   N	  N12	      *	     type 1 ext.   16	  RT5	    RT5,RT7
   N	  N13	      *	     type 1 ext.   16	  RT5	    RT5
   N	  N14	      *	     type 1 ext.   16	  RT5	    RT5
   N	  N15	      *	     type 1 ext.   23	  RT5	    RT7

		  Table	13: Router RT4's routing table
		       in the presence of areas.

Moy			    Standards Track		      [Page 114]



RFC 2328		     OSPF Version 2		      April 1998

	in Table 14.

12.  Link State	Advertisements (LSAs)

    Each router	in the Autonomous System originates one	or more	link
    state advertisements (LSAs).  This memo defines five distinct types
    of LSAs, which are described in Section 4.3.  The collection of LSAs
    forms the link-state database.  Each separate type of LSA has a
    separate function.	Router-LSAs and	network-LSAs describe how an
    area's routers and networks	are interconnected.  Summary-LSAs
    provide a way of condensing	an area's routing information.	AS-
    external-LSAs provide a way	of transparently advertising
    externally-derived routing information throughout the Autonomous
    System.

    Each LSA begins with a standard 20-byte header.  This LSA header is
    discussed below.

    Type   Dest	       Area   Path  Type   Cost	  Next	   Adv.
						  Hop(s)   Router(s)
    ________________________________________________________________
    N	   Ib	       0      intra-area   16	  RT3	   *
    N	   Ia	       0      intra-area   21	  RT3	   *
    R	   RT3	       0      intra-area   1	  *	   *
    R	   RT10	       0      intra-area   16	  RT3	   *
    R	   RT11	       0      intra-area   19	  RT3	   *
    ________________________________________________________________
    N	   N9-N11,H1   0      inter-area   30	  RT3	   RT11

		  Table	14: Changes resulting from an
			additional virtual link.

Moy			    Standards Track		      [Page 115]



RFC 2328		     OSPF Version 2		      April 1998

    12.1.  The LSA Header

	The LSA	header contains	the LS type, Link State	ID and
	Advertising Router fields.  The	combination of these three
	fields uniquely	identifies the LSA.

	There may be several instances of an LSA present in the
	Autonomous System, all at the same time.  It must then be
	determined which instance is more recent.  This	determination is
	made by	examining the LS sequence, LS checksum and LS age
	fields.	 These fields are also contained in the	20-byte	LSA
	header.

	Several	of the OSPF packet types list LSAs.  When the instance
	is not important, an LSA is referred to	by its LS type,	Link
	State ID and Advertising Router	(see Link State	Request
	Packets).  Otherwise, the LS sequence number, LS age and LS
	checksum fields	must also be referenced.

	A detailed explanation of the fields contained in the LSA header
	follows.

	12.1.1.	 LS age

	    This field is the age of the LSA in	seconds.  It should be
	    processed as an unsigned 16-bit integer.  It is set	to 0
	    when the LSA is originated.	 It must be incremented	by
	    InfTransDelay on every hop of the flooding procedure.  LSAs
	    are	also aged as they are held in each router's database.

	    The	age of an LSA is never incremented past	MaxAge.	 LSAs
	    having age MaxAge are not used in the routing table
	    calculation.  When an LSA's	age first reaches MaxAge, it is
	    reflooded.	An LSA of age MaxAge is	finally	flushed	from the
	    database when it is	no longer needed to ensure database
	    synchronization.  For more information on the aging	of LSAs,
	    consult Section 14.

	    The	LS age field is	examined when a	router receives	two
	    instances of an LSA, both having identical LS sequence
	    numbers and	LS checksums.  An instance of age MaxAge is then

Moy			    Standards Track		      [Page 116]



RFC 2328		     OSPF Version 2		      April 1998

	    always accepted as most recent; this allows	old LSAs to be
	    flushed quickly from the routing domain.  Otherwise, if the
	    ages differ	by more	than MaxAgeDiff, the instance having the
	    smaller age	is accepted as most recent.[12]	See Section 13.1
	    for	more details.

	12.1.2.	 Options

	    The	Options	field in the LSA header	indicates which	optional
	    capabilities are associated	with the LSA.  OSPF's optional
	    capabilities are described in Section 4.5.	One optional
	    capability is defined by this specification, represented by
	    the	E-bit found in the Options field.  The unrecognized bits
	    in the Options field should	be set to zero.

	    The	E-bit represents OSPF's	ExternalRoutingCapability.  This
	    bit	should be set in all LSAs associated with the backbone,
	    and	all LSAs associated with non-stub areas	(see Section
	    3.6).  It should also be set in all	AS-external-LSAs.  It
	    should be reset in all router-LSAs,	network-LSAs and
	    summary-LSAs associated with a stub	area.  For all LSAs, the
	    setting of the E-bit is for	informational purposes only; it
	    does not affect the	routing	table calculation.

	12.1.3.	 LS type

	    The	LS type	field dictates the format and function of the
	    LSA.  LSAs of different types have different names (e.g.,
	    router-LSAs	or network-LSAs).  All LSA types defined by this
	    memo, except the AS-external-LSAs (LS type = 5), are flooded
	    throughout a single	area only.  AS-external-LSAs are flooded
	    throughout the entire Autonomous System, excepting stub
	    areas (see Section 3.6).  Each separate LSA	type is	briefly
	    described below in Table 15.

	12.1.4.	 Link State ID

	    This field identifies the piece of the routing domain that
	    is being described by the LSA.  Depending on the LSA's LS
	    type, the Link State ID takes on the values	listed in Table

Moy			    Standards Track		      [Page 117]



RFC 2328		     OSPF Version 2		      April 1998

	    LS Type   LSA description
	    ________________________________________________
	    1	      These are	the router-LSAs.
		      They describe the	collected
		       states of the router's
		      interfaces. For more information,
		      consult Section 12.4.1.
	    ________________________________________________
	    2	      These are	the network-LSAs.
		      They describe the	set of routers
		      attached to the network. For
		      more information,	consult
		      Section 12.4.2.
	    ________________________________________________
	    3 or 4    These are	the summary-LSAs.
		      They describe inter-area routes,
		      and enable the condensation of
		      routing information at area
		      borders. Originated by area border
		      routers, the Type	3 summary-LSAs
		      describe routes to networks while	the
		      Type 4 summary-LSAs describe routes to
		      AS boundary routers.
	    ________________________________________________
	    5	      These are	the AS-external-LSAs.
		      Originated by AS boundary	routers,
		      they describe routes
		      to destinations external to the
		      Autonomous System. A default route for
		      the Autonomous System can	also be
		      described	by an AS-external-LSA.

	    Table 15: OSPF link	state advertisements (LSAs).

	    16.

	    Actually, for Type 3 summary-LSAs (LS type = 3) and	AS-
	    external-LSAs (LS type = 5), the Link State	ID may

Moy			    Standards Track		      [Page 118]



RFC 2328		     OSPF Version 2		      April 1998

	    LS Type   Link State ID
	    _______________________________________________
	    1	      The originating router's Router ID.
	    2	      The IP interface address of the
		      network's	Designated Router.
	    3	      The destination network's	IP address.
	    4	      The Router ID of the described AS
		      boundary router.
	    5	      The destination network's	IP address.

		   Table 16: The LSA's Link State ID.

	    additionally have one or more of the destination network's
	    "host" bits	set. For example, when originating an AS-
	    external-LSA for the network 10.0.0.0 with mask of
	    255.0.0.0, the Link	State ID can be	set to anything	in the
	    range 10.0.0.0 through 10.255.255.255 inclusive (although
	    10.0.0.0 should be used whenever possible).	The freedom to
	    set	certain	host bits allows a router to originate separate
	    LSAs for two networks having the same address but different
	    masks. See Appendix	E for details.

	    When the LSA is describing a network (LS type = 2, 3 or 5),
	    the	network's IP address is	easily derived by masking the
	    Link State ID with the network/subnet mask contained in the
	    body of the	LSA.  When the LSA is describing a router (LS
	    type = 1 or	4), the	Link State ID is always	the described
	    router's OSPF Router ID.

	    When an AS-external-LSA (LS	Type = 5) is describing	a
	    default route, its Link State ID is	set to
	    DefaultDestination (0.0.0.0).

	12.1.5.	 Advertising Router

	    This field specifies the OSPF Router ID of the LSA's
	    originator.	 For router-LSAs, this field is	identical to the
	    Link State ID field.  Network-LSAs are originated by the

Moy			    Standards Track		      [Page 119]



RFC 2328		     OSPF Version 2		      April 1998

	    network's Designated Router.  Summary-LSAs originated by
	    area border	routers.  AS-external-LSAs are originated by AS
	    boundary routers.

	12.1.6.	 LS sequence number

	    The	sequence number	field is a signed 32-bit integer.  It is
	    used to detect old and duplicate LSAs.  The	space of
	    sequence numbers is	linearly ordered.  The larger the
	    sequence number (when compared as signed 32-bit integers)
	    the	more recent the	LSA.  To describe to sequence number
	    space more precisely, let N	refer in the discussion	below to
	    the	constant 2**31.

	    The	sequence number	-N (0x80000000)	is reserved (and
	    unused).  This leaves -N + 1 (0x80000001) as the smallest
	    (and therefore oldest) sequence number; this sequence number
	    is referred	to as the constant InitialSequenceNumber. A
	    router uses	InitialSequenceNumber the first	time it
	    originates any LSA.	 Afterwards, the LSA's sequence	number
	    is incremented each	time the router	originates a new
	    instance of	the LSA.  When an attempt is made to increment
	    the	sequence number	past the maximum value of N - 1
	    (0x7fffffff; also referred to as MaxSequenceNumber), the
	    current instance of	the LSA	must first be flushed from the
	    routing domain.  This is done by prematurely aging the LSA
	    (see Section 14.1) and reflooding it.  As soon as this flood
	    has	been acknowledged by all adjacent neighbors, a new
	    instance can be originated with sequence number of
	    InitialSequenceNumber.

	    The	router may be forced to	promote	the sequence number of
	    one	of its LSAs when a more	recent instance	of the LSA is
	    unexpectedly received during the flooding process.	This
	    should be a	rare event.  This may indicate that an out-of-
	    date LSA, originated by the	router itself before its last
	    restart/reload, still exists in the	Autonomous System.  For
	    more information see Section 13.4.

Moy			    Standards Track		      [Page 120]



RFC 2328		     OSPF Version 2		      April 1998

	12.1.7.	 LS checksum

	    This field is the checksum of the complete contents	of the
	    LSA, excepting the LS age field.  The LS age field is
	    excepted so	that an	LSA's age can be incremented without
	    updating the checksum.  The	checksum used is the same that
	    is used for	ISO connectionless datagrams; it is commonly
	    referred to	as the Fletcher	checksum.  It is documented in
	    Annex B of [Ref6].	The LSA	header also contains the length
	    of the LSA in bytes; subtracting the size of the LS	age
	    field (two bytes) yields the amount	of data	to checksum.

	    The	checksum is used to detect data	corruption of an LSA.
	    This corruption can	occur while an LSA is being flooded, or
	    while it is	being held in a	router's memory.  The LS
	    checksum field cannot take on the value of zero; the
	    occurrence of such a value should be considered a checksum
	    failure.  In other words, calculation of the checksum is not
	    optional.

	    The	checksum of an LSA is verified in two cases:  a) when it
	    is received	in a Link State	Update Packet and b) at	times
	    during the aging of	the link state database.  The detection
	    of a checksum failure leads	to separate actions in each
	    case.  See Sections	13 and 14 for more details.

	    Whenever the LS sequence number field indicates that two
	    instances of an LSA	are the	same, the LS checksum field is
	    examined.  If there	is a difference, the instance with the
	    larger LS checksum is considered to	be most	recent.[13] See
	    Section 13.1 for more details.

    12.2.  The link state database

	A router has a separate	link state database for	every area to
	which it belongs. All routers belonging	to the same area have
	identical link state databases for the area.

	The databases for each individual area are always dealt	with
	separately.  The shortest path calculation is performed
	separately for each area (see Section 16).  Components of the

Moy			    Standards Track		      [Page 121]



RFC 2328		     OSPF Version 2		      April 1998

	area link-state	database are flooded throughout	the area only.
	Finally, when an adjacency (belonging to Area A) is being
	brought	up, only the database for Area A is synchronized between
	the two	routers.

	The area database is composed of router-LSAs, network-LSAs and
	summary-LSAs (all listed in the	area data structure).  In
	addition, external routes (AS-external-LSAs) are included in all
	non-stub area databases	(see Section 3.6).

	An implementation of OSPF must be able to access individual
	pieces of an area database.  This lookup function is based on an
	LSA's LS type, Link State ID and Advertising Router.[14] There
	will be	a single instance (the most up-to-date)	of each	LSA in
	the database.  The database lookup function is invoked during
	the LSA	flooding procedure (Section 13)	and the	routing	table
	calculation (Section 16).  In addition,	using this lookup
	function the router can	determine whether it has itself	ever
	originated a particular	LSA, and if so,	with what LS sequence
	number.

	An LSA is added	to a router's database when either a) it is
	received during	the flooding process (Section 13) or b)	it is
	originated by the router itself	(Section 12.4).	 An LSA	is
	deleted	from a router's	database when either a)	it has been
	overwritten by a newer instance	during the flooding process
	(Section 13) or	b) the router originates a newer instance of one
	of its self-originated LSAs (Section 12.4) or c) the LSA ages
	out and	is flushed from	the routing domain (Section 14).
	Whenever an LSA	is deleted from	the database it	must also be
	removed	from all neighbors' Link state retransmission lists (see
	Section	10).

    12.3.  Representation of TOS

	For backward compatibility with	previous versions of the OSPF
	specification ([Ref9]),	TOS-specific information can be	included
	in router-LSAs,	summary-LSAs and AS-external-LSAs.  The	encoding
	of TOS in OSPF LSAs is specified in Table 17. That table relates
	the OSPF encoding to the IP packet header's TOS	field (defined
	in [Ref12]).  The OSPF encoding	is expressed as	a decimal

Moy			    Standards Track		      [Page 122]



RFC 2328		     OSPF Version 2		      April 1998

	integer, and the IP packet header's TOS	field is expressed in
	the binary TOS values used in [Ref12].

		    OSPF encoding   RFC	1349 TOS values
		    ___________________________________________
		    0		    0000 normal	service
		    2		    0001 minimize monetary cost
		    4		    0010 maximize reliability
		    6		    0011
		    8		    0100 maximize throughput
		    10		    0101
		    12		    0110
		    14		    0111
		    16		    1000 minimize delay
		    18		    1001
		    20		    1010
		    22		    1011
		    24		    1100
		    26		    1101
		    28		    1110
		    30		    1111

			Table 17: Representing TOS in OSPF.

    12.4.  Originating LSAs

	Into any given OSPF area, a router will	originate several LSAs.
	Each router originates a router-LSA.  If the router is also the
	Designated Router for any of the area's	networks, it will
	originate network-LSAs for those networks.

	Area border routers originate a	single summary-LSA for each
	known inter-area destination.  AS boundary routers originate a
	single AS-external-LSA for each	known AS external destination.
	Destinations are advertised one	at a time so that the change in
	any single route can be	flooded	without	reflooding the entire
	collection of routes.  During the flooding procedure, many LSAs
	can be carried by a single Link	State Update packet.

Moy			    Standards Track		      [Page 123]



RFC 2328		     OSPF Version 2		      April 1998

	As an example, consider	Router RT4 in Figure 6.	 It is an area
	border router, having a	connection to Area 1 and the backbone.
	Router RT4 originates 5	distinct LSAs into the backbone	(one
	router-LSA, and	one summary-LSA	for each of the	networks N1-N4).
	Router RT4 will	also originate 8 distinct LSAs into Area 1 (one
	router-LSA and seven summary-LSAs as pictured in Figure	7).  If
	RT4 has	been selected as Designated Router for Network N3, it
	will also originate a network-LSA for N3 into Area 1.

	In this	same figure, Router RT5	will be	originating 3 distinct
	AS-external-LSAs (one for each of the networks N12-N14).  These
	will be	flooded	throughout the entire AS, assuming that	none of
	the areas have been configured as stubs.  However, if area 3 has
	been configured	as a stub area,	the AS-external-LSAs for
	networks N12-N14 will not be flooded into area 3 (see Section
	3.6).  Instead,	Router RT11 would originate a default summary-
	LSA that would be flooded throughout area 3 (see Section
	12.4.3).  This instructs all of	area 3's internal routers to
	send their AS external traffic to RT11.

	Whenever a new instance	of an LSA is originated, its LS	sequence
	number is incremented, its LS age is set to 0, its LS checksum
	is calculated, and the LSA is added to the link	state database
	and flooded out	the appropriate	interfaces.  See Section 13.2
	for details concerning the installation	of the LSA into	the link
	state database.	 See Section 13.3 for details concerning the
	flooding of newly originated LSAs.

	The ten	events that can	cause a	new instance of	an LSA to be
	originated are:

	(1) The	LS age field of	one of the router's self-originated LSAs
	    reaches the	value LSRefreshTime. In	this case, a new
	    instance of	the LSA	is originated, even though the contents
	    of the LSA (apart from the LSA header) will	be the same.
	    This guarantees periodic originations of all LSAs.	This
	    periodic updating of LSAs adds robustness to the link state
	    algorithm.	LSAs that solely describe unreachable
	    destinations should	not be refreshed, but should instead be
	    flushed from the routing domain (see Section 14.1).

Moy			    Standards Track		      [Page 124]



RFC 2328		     OSPF Version 2		      April 1998

	When whatever is being described by an LSA changes, a new LSA is
	originated.  However, two instances of the same	LSA may	not be
	originated within the time period MinLSInterval.  This may
	require	that the generation of the next	instance be delayed by
	up to MinLSInterval.  The following events may cause the
	contents of an LSA to change.  These events should cause new
	originations if	and only if the	contents of the	new LSA	would be
	different:

	(2) An interface's state changes (see Section 9.1).  This may
	    mean that it is necessary to produce a new instance	of the
	    router-LSA.

	(3) An attached	network's Designated Router changes.  A	new
	    router-LSA should be originated.  Also, if the router itself
	    is now the Designated Router, a new	network-LSA should be
	    produced.  If the router itself is no longer the Designated
	    Router, any	network-LSA that it might have originated for
	    the	network	should be flushed from the routing domain (see
	    Section 14.1).

	(4) One	of the neighboring routers changes to/from the FULL
	    state.  This may mean that it is necessary to produce a new
	    instance of	the router-LSA.	 Also, if the router is	itself
	    the	Designated Router for the attached network, a new
	    network-LSA	should be produced.

	The next four events concern area border routers only:

	(5) An intra-area route	has been added/deleted/modified	in the
	    routing table.  This may cause a new instance of a summary-
	    LSA	(for this route) to be originated in each attached area
	    (possibly including	the backbone).

	(6) An inter-area route	has been added/deleted/modified	in the
	    routing table.  This may cause a new instance of a summary-
	    LSA	(for this route) to be originated in each attached area
	    (but NEVER for the backbone).

Moy			    Standards Track		      [Page 125]



RFC 2328		     OSPF Version 2		      April 1998

	(7) The	router becomes newly attached to an area.  The router
	    must then originate	summary-LSAs into the newly attached
	    area for all pertinent intra-area and inter-area routes in
	    the	router's routing table.	 See Section 12.4.3 for	more
	    details.

	(8) When the state of one of the router's configured virtual
	    links changes, it may be necessary to originate a new
	    router-LSA into the	virtual	link's Transit area (see the
	    discussion of the router-LSA's bit V in Section 12.4.1), as
	    well as originating	a new router-LSA into the backbone.

	The last two events concern AS boundary	routers	(and former AS
	boundary routers) only:

	(9) An external	route gained through direct experience with an
	    external routing protocol (like BGP) changes.  This	will
	    cause an AS	boundary router	to originate a new instance of
	    an AS-external-LSA.

	(10)
	    A router ceases to be an AS	boundary router, perhaps after
	    restarting.	In this	situation the router should flush all
	    AS-external-LSAs that it had previously originated.	 These
	    LSAs can be	flushed	via the	premature aging	procedure
	    specified in Section 14.1.

	The construction of each type of LSA is	explained in detail
	below.	In general, these sections describe the	contents of the
	LSA body (i.e.,	the part coming	after the 20-byte LSA header).
	For information	concerning the building	of the LSA header, see
	Section	12.1.

	12.4.1.	 Router-LSAs

	    A router originates	a router-LSA for each area that	it
	    belongs to.	 Such an LSA describes the collected states of
	    the	router's links to the area.  The LSA is	flooded
	    throughout the particular area, and	no further.

Moy			    Standards Track		      [Page 126]



RFC 2328		     OSPF Version 2		      April 1998

		  ....................................
		  . 192.1.2		      Area 1 .
		  .	+			     .
		  .	|			     .
		  .	| 3+---+1		     .
		  .  N1	|--|RT1|-----+		     .
		  .	|  +---+      \		     .
		  .	|	       \  _______N3  .
		  .	+		\/	 \   .	1+---+
		  .			* 192.1.1 *------|RT4|
		  .	+		/\_______/   .	 +---+
		  .	|	       /     |	     .
		  .	| 3+---+1     /	     |	     .
		  .  N2	|--|RT2|-----+	    1|	     .
		  .	|  +---+	   +---+8    .	       6+---+
		  .	|		   |RT3|----------------|RT6|
		  .	+		   +---+     .		+---+
		  . 192.1.3		     |2	     .	 18.10.0.6|7
		  .			     |	     .		  |
		  .		      +------------+ .
		  .			192.1.4	(N4) .
		  ....................................

		    Figure 15: Area 1 with IP addresses	shown

	    The	format of a router-LSA is shown	in Appendix A (Section
	    A.4.2).  The first 20 bytes	of the LSA consist of the
	    generic LSA	header that was	discussed in Section 12.1.
	    router-LSAs	have LS	type = 1.

	    A router also indicates whether it is an area border router,
	    or an AS boundary router, by setting the appropriate bits
	    (bit B and bit E, respectively) in its router-LSAs.	This
	    enables paths to those types of routers to be saved	in the
	    routing table, for later processing	of summary-LSAs	and AS-
	    external-LSAs.  Bit	B should be set	whenever the router is
	    actively attached to two or	more areas, even if the	router
	    is not currently attached to the OSPF backbone area.  Bit E
	    should never be set	in a router-LSA	for a stub area	(stub
	    areas cannot contain AS boundary routers).

Moy			    Standards Track		      [Page 127]



RFC 2328		     OSPF Version 2		      April 1998

	    In addition, the router sets bit V in its router-LSA for
	    Area A if and only if the router is	the endpoint of	one or
	    more fully adjacent	virtual	links having Area A as their
	    Transit area. The setting of bit V enables other routers in
	    Area A to discover whether the area	supports transit traffic
	    (see TransitCapability in Section 6).

	    The	router-LSA then	describes the router's working
	    connections	(i.e., interfaces or links) to the area.  Each
	    link is typed according to the kind	of attached network.
	    Each link is also labelled with its	Link ID.  This Link ID
	    gives a name to the	entity that is on the other end	of the
	    link.  Table 18 summarizes the values used for the Type and
	    Link ID fields.

		   Link	type   Description	 Link ID
		   __________________________________________________
		   1	       Point-to-point	 Neighbor Router ID
			       link
		   2	       Link to transit	 Interface address of
			       network		 Designated Router
		   3	       Link to stub	 IP network number
			       network
		   4	       Virtual link	 Neighbor Router ID

			   Table 18: Link descriptions in the
				      router-LSA.

	    In addition, the Link Data field is	specified for each link.
	    This field gives 32	bits of	extra information for the link.
	    For	links to transit networks, numbered point-to-point links
	    and	virtual	links, this field specifies the	IP interface
	    address of the associated router interface (this is	needed
	    by the routing table calculation, see Section 16.1.1).  For
	    links to stub networks, this field specifies the stub
	    network's IP address mask.	For unnumbered point-to-point
	    links, the Link Data field should be set to	the unnumbered
	    interface's	MIB-II [Ref8] ifIndex value.

Moy			    Standards Track		      [Page 128]



RFC 2328		     OSPF Version 2		      April 1998

	    Finally, the cost of using the link	for output is specified.
	    The	output cost of a link is configurable.	With the
	    exception of links to stub networks, the output cost must
	    always be non-zero.

	    To further describe	the process of building	the list of link
	    descriptions, suppose a router wishes to build a router-LSA
	    for	Area A.	 The router examines its collection of interface
	    data structures.  For each interface, the following	steps
	    are	taken:

	    o	If the attached	network	does not belong	to Area	A, no
		links are added	to the LSA, and	the next interface
		should be examined.

	    o	If the state of	the interface is Down, no links	are
		added.

	    o	If the state of	the interface is Loopback, add a Type 3
		link (stub network) as long as this is not an interface
		to an unnumbered point-to-point	network.  The Link ID
		should be set to the IP	interface address, the Link Data
		set to the mask	0xffffffff (indicating a host route),
		and the	cost set to 0.

	    o	Otherwise, the link descriptions added to the router-LSA
		depend on the OSPF interface type. Link	descriptions
		used for point-to-point	interfaces are specified in
		Section	12.4.1.1, for virtual links in Section 12.4.1.2,
		for broadcast and NBMA interfaces in 12.4.1.3, and for
		Point-to-MultiPoint interfaces in 12.4.1.4.

	    After consideration	of all the router interfaces, host links
	    are	added to the router-LSA	by examining the list of
	    attached hosts belonging to	Area A.	 A host	route is
	    represented	as a Type 3 link (stub network)	whose Link ID is
	    the	host's IP address, Link	Data is	the mask of all	ones
	    (0xffffffff), and cost the host's configured cost (see
	    Section C.7).

Moy			    Standards Track		      [Page 129]



RFC 2328		     OSPF Version 2		      April 1998

	    12.4.1.1.  Describing point-to-point interfaces

		For point-to-point interfaces, one or more link
		descriptions are added to the router-LSA as follows:

		o   If the neighboring router is fully adjacent, add a
		    Type 1 link	(point-to-point). The Link ID should be
		    set	to the Router ID of the	neighboring router. For
		    numbered point-to-point networks, the Link Data
		    should specify the IP interface address. For
		    unnumbered point-to-point networks,	the Link Data
		    field should specify the interface's MIB-II	[Ref8]
		    ifIndex value. The cost should be set to the output
		    cost of the	point-to-point interface.

		o   In addition, as long as the	state of the interface
		    is "Point-to-Point"	(and regardless	of the
		    neighboring	router state), a Type 3	link (stub
		    network) should be added. There are	two forms that
		    this stub link can take:

		    Option 1
			Assuming that the neighboring router's IP
			address	is known, set the Link ID of the Type 3
			link to	the neighbor's IP address, the Link Data
			to the mask 0xffffffff (indicating a host
			route),	and the	cost to	the interface's
			configured output cost.[15]

		    Option 2
			If a subnet has	been assigned to the point-to-
			point link, set	the Link ID of the Type	3 link
			to the subnet's	IP address, the	Link Data to the
			subnet's mask, and the cost to the interface's
			configured output cost.[16]

	    12.4.1.2.  Describing broadcast and	NBMA interfaces

		For operational	broadcast and NBMA interfaces, a single
		link description is added to the router-LSA as follows:

Moy			    Standards Track		      [Page 130]



RFC 2328		     OSPF Version 2		      April 1998

		o   If the state of the	interface is Waiting, add a Type
		    3 link (stub network) with Link ID set to the IP
		    network number of the attached network, Link Data
		    set	to the attached	network's address mask,	and cost
		    equal to the interface's configured	output cost.

		o   Else, there	has been a Designated Router elected for
		    the	attached network.  If the router is fully
		    adjacent to	the Designated Router, or if the router
		    itself is Designated Router	and is fully adjacent to
		    at least one other router, add a single Type 2 link
		    (transit network) with Link	ID set to the IP
		    interface address of the attached network's
		    Designated Router (which may be the	router itself),
		    Link Data set to the router's own IP interface
		    address, and cost equal to the interface's
		    configured output cost.  Otherwise,	add a link as if
		    the	interface state	were Waiting (see above).

	    12.4.1.3.  Describing virtual links

		For virtual links, a link description is added to the
		router-LSA only	when the virtual neighbor is fully
		adjacent. In this case,	add a Type 4 link (virtual link)
		with Link ID set to the	Router ID of the virtual
		neighbor, Link Data set	to the IP interface address
		associated with	the virtual link and cost set to the
		cost calculated	for the	virtual	link during the	routing
		table calculation (see Section 15).

	    12.4.1.4.  Describing Point-to-MultiPoint interfaces

		For operational	Point-to-MultiPoint interfaces,	one or
		more link descriptions are added to the	router-LSA as
		follows:

		o   A single Type 3 link (stub network)	is added with
		    Link ID set	to the router's	own IP interface
		    address, Link Data set to the mask 0xffffffff
		    (indicating	a host route), and cost	set to 0.

Moy			    Standards Track		      [Page 131]



RFC 2328		     OSPF Version 2		      April 1998

		o   For	each fully adjacent neighbor associated	with the
		    interface, add an additional Type 1	link (point-to-
		    point) with	Link ID	set to the Router ID of	the
		    neighboring	router,	Link Data set to the IP
		    interface address and cost equal to	the interface's
		    configured output cost.

	    12.4.1.5.  Examples	of router-LSAs

		Consider the router-LSAs generated by Router RT3, as
		pictured in Figure 6.  The area	containing Router RT3
		(Area 1) has been redrawn, with	actual network
		addresses, in Figure 15.  Assume that the last byte of
		all of RT3's interface addresses is 3, giving it the
		interface addresses 192.1.1.3 and 192.1.4.3, and that
		the other routers have similar addressing schemes.  In
		addition, assume that all links	are functional,	and that
		Router IDs are assigned	as the smallest	IP interface
		address.

		RT3 originates two router-LSAs,	one for	Area 1 and one
		for the	backbone.  Assume that Router RT4 has been
		selected as the	Designated router for network 192.1.1.0.
		RT3's router-LSA for Area 1 is then shown below.  It
		indicates that RT3 has two connections to Area 1, the
		first a	link to	the transit network 192.1.1.0 and the
		second a link to the stub network 192.1.4.0.  Note that
		the transit network is identified by the IP interface of
		its Designated Router (i.e., the Link ID = 192.1.1.4
		which is the Designated	Router RT4's IP	interface to
		192.1.1.0).  Note also that RT3	has indicated that it is
		an area	border router.

	; RT3's	router-LSA for Area 1

	LS age = 0		       ;always true on origination
	Options	= (E-bit)	       ;
	LS type	= 1		       ;indicates router-LSA
	Link State ID =	192.1.1.3      ;RT3's Router ID
	Advertising Router = 192.1.1.3 ;RT3's Router ID
	bit E =	0		       ;not an AS boundary router

Moy			    Standards Track		      [Page 132]



RFC 2328		     OSPF Version 2		      April 1998

	bit B =	1		       ;area border router
	#links = 2
	       Link ID = 192.1.1.4     ;IP address of Desig. Rtr.
	       Link Data = 192.1.1.3   ;RT3's IP interface to net
	       Type = 2		       ;connects to transit network
	       # TOS metrics = 0
	       metric =	1

	       Link ID = 192.1.4.0     ;IP Network number
	       Link Data = 0xffffff00  ;Network	mask
	       Type = 3		       ;connects to stub network
	       # TOS metrics = 0
	       metric =	2

		    Next RT3's router-LSA for the backbone is shown.  It
		    indicates that RT3 has a single attachment to the
		    backbone.  This attachment is via an unnumbered
		    point-to-point link	to Router RT6.	RT3 has	again
		    indicated that it is an area border	router.

	; RT3's	router-LSA for the backbone

	LS age = 0		       ;always true on origination
	Options	= (E-bit)	       ;
	LS type	= 1		       ;indicates router-LSA
	Link State ID =	192.1.1.3      ;RT3's router ID
	Advertising Router = 192.1.1.3 ;RT3's router ID
	bit E =	0		       ;not an AS boundary router
	bit B =	1		       ;area border router
	#links = 1
	       Link ID = 18.10.0.6     ;Neighbor's Router ID
	       Link Data = 0.0.0.3     ;MIB-II ifIndex of P-P link
	       Type = 1		       ;connects to router
	       # TOS metrics = 0
	       metric =	8

	12.4.2.	 Network-LSAs

	    A network-LSA is generated for every transit broadcast or
	    NBMA network.  (A transit network is a network having two or
	    more attached routers).  The network-LSA describes all the
	    routers that are attached to the network.

Moy			    Standards Track		      [Page 133]



RFC 2328		     OSPF Version 2		      April 1998

	    The	Designated Router for the network originates the LSA.
	    The	Designated Router originates the LSA only if it	is fully
	    adjacent to	at least one other router on the network.  The
	    network-LSA	is flooded throughout the area that contains the
	    transit network, and no further.  The network-LSA lists
	    those routers that are fully adjacent to the Designated
	    Router; each fully adjacent	router is identified by	its OSPF
	    Router ID.	The Designated Router includes itself in this
	    list.

	    The	Link State ID for a network-LSA	is the IP interface
	    address of the Designated Router.  This value, masked by the
	    network's address mask (which is also contained in the
	    network-LSA) yields	the network's IP address.

	    A router that has formerly been the	Designated Router for a
	    network, but is no longer, should flush the	network-LSA that
	    it had previously originated.  This	LSA is no longer used in
	    the	routing	table calculation.  It is flushed by prematurely
	    incrementing the LSA's age to MaxAge and reflooding	(see
	    Section 14.1). In addition,	in those rare cases where a
	    router's Router ID has changed, any	network-LSAs that were
	    originated with the	router's previous Router ID must be
	    flushed. Since the router may have no idea what it's
	    previous Router ID might have been,	these network-LSAs are
	    indicated by having	their Link State ID equal to one of the
	    router's IP	interface addresses and	their Advertising Router
	    equal to some value	other than the router's	current	Router
	    ID (see Section 13.4 for more details).

	    12.4.2.1.  Examples	of network-LSAs

		Again consider the area	configuration in Figure	6.
		Network-LSAs are originated for	Network	N3 in Area 1,
		Networks N6 and	N8 in Area 2, and Network N9 in	Area 3.
		Assuming that Router RT4 has been selected as the
		Designated Router for Network N3, the following
		network-LSA is generated by RT4	on behalf of Network N3
		(see Figure 15 for the address assignments):

	; Network-LSA for Network N3

Moy			    Standards Track		      [Page 134]



RFC 2328		     OSPF Version 2		      April 1998

	LS age = 0		       ;always true on origination
	Options	= (E-bit)	       ;
	LS type	= 2		       ;indicates network-LSA
	Link State ID =	192.1.1.4      ;IP address of Desig. Rtr.
	Advertising Router = 192.1.1.4 ;RT4's Router ID
	Network	Mask = 0xffffff00
	       Attached	Router = 192.1.1.4    ;Router ID
	       Attached	Router = 192.1.1.1    ;Router ID
	       Attached	Router = 192.1.1.2    ;Router ID
	       Attached	Router = 192.1.1.3    ;Router ID

	12.4.3.	 Summary-LSAs

	    The	destination described by a summary-LSA is either an IP
	    network, an	AS boundary router or a	range of IP addresses.
	    Summary-LSAs are flooded throughout	a single area only.  The
	    destination	described is one that is external to the area,
	    yet	still belongs to the Autonomous	System.

	    Summary-LSAs are originated	by area	border routers.	 The
	    precise summary routes to advertise	into an	area are
	    determined by examining the	routing	table structure	(see
	    Section 11)	in accordance with the algorithm described
	    below. Note	that only intra-area routes are	advertised into
	    the	backbone, while	both intra-area	and inter-area routes
	    are	advertised into	the other areas.

	    To determine which routes to advertise into	an attached Area
	    A, each routing table entry	is processed as	follows.
	    Remember that each routing table entry describes a set of
	    equal-cost best paths to a particular destination:

	    o	Only Destination Types of network and AS boundary router
		are advertised in summary-LSAs.	 If the	routing	table
		entry's	Destination Type is area border	router,	examine
		the next routing table entry.

	    o	AS external routes are never advertised	in summary-LSAs.
		If the routing table entry has Path-type of type 1
		external or type 2 external, examine the next routing
		table entry.

Moy			    Standards Track		      [Page 135]



RFC 2328		     OSPF Version 2		      April 1998

	    o	Else, if the area associated with this set of paths is
		the Area A itself, do not generate a summary-LSA for the
		route.[17]

	    o	Else, if the next hops associated with this set	of paths
		belong to Area A itself, do not	generate a summary-LSA
		for the	route.[18] This	is the logical equivalent of a
		Distance Vector	protocol's split horizon logic.

	    o	Else, if the routing table cost	equals or exceeds the
		value LSInfinity, a summary-LSA	cannot be generated for
		this route.

	    o	Else, if the destination of this route is an AS	boundary
		router,	a summary-LSA should be	originated if and only
		if the routing table entry describes the preferred path
		to the AS boundary router (see Step 3 of Section 16.4).
		If so, a Type 4	summary-LSA is originated for the
		destination, with Link State ID	equal to the AS	boundary
		router's Router	ID and metric equal to the routing table
		entry's	cost. Note: these LSAs should not be generated
		if Area	A has been configured as a stub	area.

	    o	Else, the Destination type is network. If this is an
		inter-area route, generate a Type 3 summary-LSA	for the
		destination, with Link State ID	equal to the network's
		address	(if necessary, the Link	State ID can also have
		one or more of the network's host bits set; see	Appendix
		E for details) and metric equal	to the routing table
		cost.

	    o	The one	remaining case is an intra-area	route to a
		network.  This means that the network is contained in
		one of the router's directly attached areas.  In
		general, this information must be condensed before
		appearing in summary-LSAs.  Remember that an area has a
		configured list	of address ranges, each	range consisting
		of an [address,mask] pair and a	status indication of
		either Advertise or DoNotAdvertise.  At	most a single
		Type 3 summary-LSA is originated for each range. When
		the range's status indicates Advertise,	a Type 3
		summary-LSA is generated with Link State ID equal to the

Moy			    Standards Track		      [Page 136]



RFC 2328		     OSPF Version 2		      April 1998

		range's	address	(if necessary, the Link	State ID can
		also have one or more of the range's "host" bits set;
		see Appendix E for details) and	cost equal to the
		largest	cost of	any of the component networks. When the
		range's	status indicates DoNotAdvertise, the Type 3
		summary-LSA is suppressed and the component networks
		remain hidden from other areas.

		By default, if a network is not	contained in any
		explicitly configured address range, a Type 3 summary-
		LSA is generated with Link State ID equal to the
		network's address (if necessary, the Link State	ID can
		also have one or more of the network's "host" bits set;
		see Appendix E for details) and	metric equal to	the
		network's routing table	cost.

		If an area is capable of carrying transit traffic (i.e.,
		its TransitCapability is set to	TRUE), routing
		information concerning backbone	networks should	not be
		condensed before being summarized into the area.  Nor
		should the advertisement of backbone networks into
		transit	areas be suppressed.  In other words, the
		backbone's configured ranges should be ignored when
		originating summary-LSAs into transit areas.

	    If a router	advertises a summary-LSA for a destination which
	    then becomes unreachable, the router must then flush the LSA
	    from the routing domain by setting its age to MaxAge and
	    reflooding (see Section 14.1).  Also, if the destination is
	    still reachable, yet can no	longer be advertised according
	    to the above procedure (e.g., it is	now an inter-area route,
	    when it used to be an intra-area route associated with some
	    non-backbone area; it would	thus no	longer be advertisable
	    to the backbone), the LSA should also be flushed from the
	    routing domain.

	    12.4.3.1.  Originating summary-LSAs	into stub areas

		The algorithm in Section 12.4.3	is optional when Area A
		is an OSPF stub	area. Area border routers connecting to
		a stub area can	originate summary-LSAs into the	area

Moy			    Standards Track		      [Page 137]



RFC 2328		     OSPF Version 2		      April 1998

		according to the Section 12.4.3's algorithm, or	can
		choose to originate only a subset of the summary-LSAs,
		possibly under configuration control.  The fewer LSAs
		originated, the	smaller	the stub area's	link state
		database, further reducing the demands on its routers'
		resources. However, omitting LSAs may also lead	to sub-
		optimal	inter-area routing, although routing will
		continue to function.

		As specified in	Section	12.4.3,	Type 4 summary-LSAs
		(ASBR-summary-LSAs) are	never originated into stub
		areas.

		In a stub area,	instead	of importing external routes
		each area border router	originates a "default summary-
		LSA" into the area. The	Link State ID for the default
		summary-LSA is set to DefaultDestination, and the metric
		set to the (per-area) configurable parameter
		StubDefaultCost.  Note that StubDefaultCost need not be
		configured identically in all of the stub area's area
		border routers.

	    12.4.3.2.  Examples	of summary-LSAs

		Consider again the area	configuration in Figure	6.
		Routers	RT3, RT4, RT7, RT10 and	RT11 are all area border
		routers, and therefore are originating summary-LSAs.
		Consider in particular Router RT4.  Its	routing	table
		was calculated as the example in Section 11.3.	RT4
		originates summary-LSAs	into both the backbone and Area
		1.  Into the backbone, Router RT4 originates separate
		LSAs for each of the networks N1-N4.  Into Area	1,
		Router RT4 originates separate LSAs for	networks N6-N8
		and the	AS boundary routers RT5,RT7.  It also condenses
		host routes Ia and Ib into a single summary-LSA.
		Finally, the routes to networks	N9,N10,N11 and Host H1
		are advertised by a single summary-LSA.	 This
		condensation was originally performed by the router
		RT11.

Moy			    Standards Track		      [Page 138]



RFC 2328		     OSPF Version 2		      April 1998

		These LSAs are illustrated graphically in Figures 7 and
		8.  Two	of the summary-LSAs originated by Router RT4
		follow.	 The actual IP addresses for the networks and
		routers	in question have been assigned in Figure 15.

	; Summary-LSA for Network N1,
	; originated by	Router RT4 into	the backbone

	LS age = 0		    ;always true on origination
	Options	= (E-bit)	    ;
	LS type	= 3		    ;Type 3 summary-LSA
	Link State ID =	192.1.2.0   ;N1's IP network number
	Advertising Router = 192.1.1.4	     ;RT4's ID
	metric = 4

	; Summary-LSA for AS boundary router RT7
	; originated by	Router RT4 into	Area 1

	LS age = 0		    ;always true on origination
	Options	= (E-bit)	    ;
	LS type	= 4		    ;Type 4 summary-LSA
	Link State ID =	Router RT7's ID
	Advertising Router = 192.1.1.4	     ;RT4's ID
	metric = 14

	12.4.4.	 AS-external-LSAs

	    AS-external-LSAs describe routes to	destinations external to
	    the	Autonomous System.  Most AS-external-LSAs describe
	    routes to specific external	destinations; in these cases the
	    LSA's Link State ID	is set to the destination network's IP
	    address (if	necessary, the Link State ID can also have one
	    or more of the network's "host" bits set; see Appendix E for
	    details).  However,	a default route	for the	Autonomous
	    System can be described in an AS-external-LSA by setting the
	    LSA's Link State ID	to DefaultDestination (0.0.0.0).  AS-
	    external-LSAs are originated by AS boundary	routers.  An AS
	    boundary router originates a single	AS-external-LSA	for each
	    external route that	it has learned,	either through another
	    routing protocol (such as BGP), or through configuration
	    information.

Moy			    Standards Track		      [Page 139]



RFC 2328		     OSPF Version 2		      April 1998

	    AS-external-LSAs are the only type of LSAs that are	flooded
	    throughout the entire Autonomous System; all other types of
	    LSAs are specific to a single area.	 However, AS-external-
	    LSAs are not flooded into/throughout stub areas (see Section
	    3.6).  This	enables	a reduction in link state database size
	    for	routers	internal to stub areas.

	    The	metric that is advertised for an external route	can be
	    one	of two types.  Type 1 metrics are comparable to	the link
	    state metric.  Type	2 metrics are assumed to be larger than
	    the	cost of	any intra-AS path.

	    If a router	advertises an AS-external-LSA for a destination
	    which then becomes unreachable, the	router must then flush
	    the	LSA from the routing domain by setting its age to MaxAge
	    and	reflooding (see	Section	14.1).

	    12.4.4.1.  Examples	of AS-external-LSAs

		Consider once again the	AS pictured in Figure 6.  There
		are two	AS boundary routers: RT5 and RT7.  Router RT5
		originates three AS-external-LSAs, for networks	N12-N14.
		Router RT7 originates two AS-external-LSAs, for	networks
		N12 and	N15.  Assume that RT7 has learned its route to
		N12 via	BGP, and that it wishes	to advertise a Type 2
		metric to the AS.  RT7 would then originate the
		following LSA for N12:

	; AS-external-LSA for Network N12,
	; originated by	Router RT7

	LS age = 0		    ;always true on origination
	Options	= (E-bit)	    ;
	LS type	= 5		    ;AS-external-LSA
	Link State ID =	N12's IP network number
	Advertising Router = Router RT7's ID
	bit E =	1		    ;Type 2 metric
	metric = 2
	Forwarding address = 0.0.0.0

Moy			    Standards Track		      [Page 140]



RFC 2328		     OSPF Version 2		      April 1998

		    In the above example, the forwarding address field
		    has	been set to 0.0.0.0, indicating	that packets for
		    the	external destination should be forwarded to the
		    advertising	OSPF router (RT7).  This is not	always
		    desirable.	Consider the example pictured in Figure
		    16.	 There are three OSPF routers (RTA, RTB	and RTC)
		    connected to a common network.  Only one of	these
		    routers, RTA, is exchanging	BGP information	with the
		    non-OSPF router RTX.  RTA must then	originate AS-
		    external-LSAs for those destinations it has	learned
		    from RTX.  By using	the AS-external-LSA's forwarding
		    address field, RTA can specify that	packets	for
		    these destinations be forwarded directly to	RTX.
		    Without this feature, Routers RTB and RTC would take
		    an extra hop to get	to these destinations.

		    Note that when the forwarding address field	is non-
		    zero, it should point to a router belonging	to
		    another Autonomous System.

		    A forwarding address can also be specified for the
		    default route.  For	example, in figure 16 RTA may
		    want to specify that all externally-destined packets
		    should by default be forwarded to its BGP peer RTX.
		    The	resulting AS-external-LSA is pictured below.
		    Note that the Link State ID	is set to
		    DefaultDestination.

	; Default route, originated by Router RTA
	; Packets forwarded through RTX

	LS age = 0		    ;always true on origination
	Options	= (E-bit)	    ;
	LS type	= 5		    ;AS-external-LSA
	Link State ID =	DefaultDestination  ; default route
	Advertising Router = Router RTA's ID
	bit E =	1		    ;Type 2 metric
	metric = 1
	Forwarding address = RTX's IP address

		    In figure 16, suppose instead that both RTA	and RTB
		    exchange BGP information with RTX.	In this	case,

Moy			    Standards Track		      [Page 141]



RFC 2328		     OSPF Version 2		      April 1998

		    RTA	and RTB	would originate	the same set of	AS-
		    external-LSAs.  These LSAs,	if they	specify	the same
		    metric, would be functionally equivalent since they
		    would specify the same destination and forwarding
		    address (RTX).  This leads to a clear duplication of
		    effort.  If	only one of RTA	or RTB originated the
		    set	of AS-external-LSAs, the routing would remain
		    the	same, and the size of the link state database
		    would decrease.  However, it must be unambiguously
		    defined as to which	router originates the LSAs
		    (otherwise neither may, or the identity of the
		    originator may oscillate).	The following rule is
		    thereby established: if two	routers, both reachable
		    from one another, originate	functionally equivalent
		    AS-external-LSAs (i.e., same destination, cost and
		    non-zero forwarding	address), then the LSA
		    originated by the router having the	highest	OSPF
		    Router ID is used.	The router having the lower OSPF
		    Router ID can then flush its LSA.  Flushing	an LSA
		    is discussed in Section 14.1.

				+
				|
		      +---+.....|.BGP
		      |RTA|-----|.....+---+
		      +---+	|-----|RTX|
				|     +---+
		      +---+	|
		      |RTB|-----|
		      +---+	|
				|
		      +---+	|
		      |RTC|-----|
		      +---+	|
				|
				+

	       Figure 16: Forwarding address example

Moy			    Standards Track		      [Page 142]



RFC 2328		     OSPF Version 2		      April 1998

13.  The Flooding Procedure

    Link State Update packets provide the mechanism for	flooding LSAs.
    A Link State Update	packet may contain several distinct LSAs, and
    floods each	LSA one	hop further from its point of origination.  To
    make the flooding procedure	reliable, each LSA must	be acknowledged
    separately.	 Acknowledgments are transmitted in Link State
    Acknowledgment packets.  Many separate acknowledgments can also be
    grouped together into a single packet.

    The	flooding procedure starts when a Link State Update packet has
    been received.  Many consistency checks have been made on the
    received packet before being handed	to the flooding	procedure (see
    Section 8.2).  In particular, the Link State Update	packet has been
    associated with a particular neighbor, and a particular area.  If
    the	neighbor is in a lesser	state than Exchange, the packet	should
    be dropped without further processing.

    All	types of LSAs, other than AS-external-LSAs, are	associated with
    a specific area.  However, LSAs do not contain an area field.  An
    LSA's area must be deduced from the	Link State Update packet header.

    For	each LSA contained in a	Link State Update packet, the following
    steps are taken:

    (1)	Validate the LSA's LS checksum.	 If the	checksum turns out to be
	invalid, discard the LSA and get the next one from the Link
	State Update packet.

    (2)	Examine	the LSA's LS type.  If the LS type is unknown, discard
	the LSA	and get	the next one from the Link State Update	Packet.
	This specification defines LS types 1-5	(see Section 4.3).

    (3)	Else if	this is	an AS-external-LSA (LS type = 5), and the area
	has been configured as a stub area, discard the	LSA and	get the
	next one from the Link State Update Packet.  AS-external-LSAs
	are not	flooded	into/throughout	stub areas (see	Section	3.6).

    (4)	Else if	the LSA's LS age is equal to MaxAge, and there is
	currently no instance of the LSA in the	router's link state
	database, and none of router's neighbors are in	states Exchange

Moy			    Standards Track		      [Page 143]



RFC 2328		     OSPF Version 2		      April 1998

	or Loading, then take the following actions: a)	Acknowledge the
	receipt	of the LSA by sending a	Link State Acknowledgment packet
	back to	the sending neighbor (see Section 13.5), and b)	Discard
	the LSA	and examine the	next LSA (if any) listed in the	Link
	State Update packet.

    (5)	Otherwise, find	the instance of	this LSA that is currently
	contained in the router's link state database.	If there is no
	database copy, or the received LSA is more recent than the
	database copy (see Section 13.1	below for the determination of
	which LSA is more recent) the following	steps must be performed:

	(a) If there is	already	a database copy, and if	the database
	    copy was received via flooding and installed less than
	    MinLSArrival seconds ago, discard the new LSA (without
	    acknowledging it) and examine the next LSA (if any)	listed
	    in the Link	State Update packet.

	(b) Otherwise immediately flood	the new	LSA out	some subset of
	    the	router's interfaces (see Section 13.3).	 In some cases
	    (e.g., the state of	the receiving interface	is DR and the
	    LSA	was received from a router other than the Backup DR) the
	    LSA	will be	flooded	back out the receiving interface.  This
	    occurrence should be noted for later use by	the
	    acknowledgment process (Section 13.5).

	(c) Remove the current database	copy from all neighbors' Link
	    state retransmission lists.

	(d) Install the	new LSA	in the link state database (replacing
	    the	current	database copy).	 This may cause	the routing
	    table calculation to be scheduled.	In addition, timestamp
	    the	new LSA	with the current time (i.e., the time it was
	    received).	The flooding procedure cannot overwrite	the
	    newly installed LSA	until MinLSArrival seconds have	elapsed.
	    The	LSA installation process is discussed further in Section
	    13.2.

	(e) Possibly acknowledge the receipt of	the LSA	by sending a
	    Link State Acknowledgment packet back out the receiving
	    interface.	This is	explained below	in Section 13.5.

Moy			    Standards Track		      [Page 144]



RFC 2328		     OSPF Version 2		      April 1998

	(f) If this new	LSA indicates that it was originated by	the
	    receiving router itself (i.e., is considered a self-
	    originated LSA), the router	must take special action, either
	    updating the LSA or	in some	cases flushing it from the
	    routing domain. For	a description of how self-originated
	    LSAs are detected and subsequently handled,	see Section
	    13.4.

    (6)	Else, if there is an instance of the LSA on the	sending
	neighbor's Link	state request list, an error has occurred in the
	Database Exchange process.  In this case, restart the Database
	Exchange process by generating the neighbor event BadLSReq for
	the sending neighbor and stop processing the Link State	Update
	packet.

    (7)	Else, if the received LSA is the same instance as the database
	copy (i.e., neither one	is more	recent)	the following two steps
	should be performed:

	(a) If the LSA is listed in the	Link state retransmission list
	    for	the receiving adjacency, the router itself is expecting
	    an acknowledgment for this LSA.  The router	should treat the
	    received LSA as an acknowledgment by removing the LSA from
	    the	Link state retransmission list.	 This is termed	an
	    "implied acknowledgment".  Its occurrence should be	noted
	    for	later use by the acknowledgment	process	(Section 13.5).

	(b) Possibly acknowledge the receipt of	the LSA	by sending a
	    Link State Acknowledgment packet back out the receiving
	    interface.	This is	explained below	in Section 13.5.

    (8)	Else, the database copy	is more	recent.	 If the	database copy
	has LS age equal to MaxAge and LS sequence number equal	to
	MaxSequenceNumber, simply discard the received LSA without
	acknowledging it. (In this case, the LSA's LS sequence number is
	wrapping, and the MaxSequenceNumber LSA	must be	completely
	flushed	before any new LSA instance can	be introduced).
	Otherwise, as long as the database copy	has not	been sent in a
	Link State Update within the last MinLSArrival seconds,	send the
	database copy back to the sending neighbor, encapsulated within
	a Link State Update Packet. The	Link State Update Packet should
	be sent	directly to the	neighbor. In so	doing, do not put the

Moy			    Standards Track		      [Page 145]



RFC 2328		     OSPF Version 2		      April 1998

	database copy of the LSA on the	neighbor's link	state
	retransmission list, and do not	acknowledge the	received (less
	recent)	LSA instance.

    13.1.  Determining which LSA is newer

	When a router encounters two instances of an LSA, it must
	determine which	is more	recent.	 This occurred above when
	comparing a received LSA to its	database copy.	This comparison
	must also be done during the Database Exchange procedure which
	occurs during adjacency	bring-up.

	An LSA is identified by	its LS type, Link State	ID and
	Advertising Router.  For two instances of the same LSA,	the LS
	sequence number, LS age, and LS	checksum fields	are used to
	determine which	instance is more recent:

	o   The	LSA having the newer LS	sequence number	is more	recent.
	    See	Section	12.1.6 for an explanation of the LS sequence
	    number space.  If both instances have the same LS sequence
	    number, then:

	o   If the two instances have different	LS checksums, then the
	    instance having the	larger LS checksum (when considered as a
	    16-bit unsigned integer) is	considered more	recent.

	o   Else, if only one of the instances has its LS age field set
	    to MaxAge, the instance of age MaxAge is considered	to be
	    more recent.

	o   Else, if the LS age	fields of the two instances differ by
	    more than MaxAgeDiff, the instance having the smaller
	    (younger) LS age is	considered to be more recent.

	o   Else, the two instances are	considered to be identical.

Moy			    Standards Track		      [Page 146]



RFC 2328		     OSPF Version 2		      April 1998

    13.2.  Installing LSAs in the database

	Installing a new LSA in	the database, either as	the result of
	flooding or a newly self-originated LSA, may cause the OSPF
	routing	table structure	to be recalculated.  The contents of the
	new LSA	should be compared to the old instance,	if present.  If
	there is no difference,	there is no need to recalculate	the
	routing	table. When comparing an LSA to	its previous instance,
	the following are all considered to be differences in contents:

	    o	The LSA's Options field	has changed.

	    o	One of the LSA instances has LS	age set	to MaxAge, and
		the other does not.

	    o	The length field in the	LSA header has changed.

	    o	The body of the	LSA (i.e., anything outside the	20-byte
		LSA header) has	changed. Note that this	excludes changes
		in LS Sequence Number and LS Checksum.

	If the contents	are different, the following pieces of the
	routing	table must be recalculated, depending on the new LSA's
	LS type	field:

	Router-LSAs and	network-LSAs
	    The	entire routing table must be recalculated, starting with
	    the	shortest path calculations for each area (not just the
	    area whose link-state database has changed).  The reason
	    that the shortest path calculation cannot be restricted to
	    the	single changed area has	to do with the fact that AS
	    boundary routers may belong	to multiple areas.  A change in
	    the	area currently providing the best route	may force the
	    router to use an intra-area	route provided by a different
	    area.[19]

	Summary-LSAs
	    The	best route to the destination described	by the summary-
	    LSA	must be	recalculated (see Section 16.5).  If this
	    destination	is an AS boundary router, it may also be
	    necessary to re-examine all	the AS-external-LSAs.

Moy			    Standards Track		      [Page 147]



RFC 2328		     OSPF Version 2		      April 1998

	AS-external-LSAs
	    The	best route to the destination described	by the AS-
	    external-LSA must be recalculated (see Section 16.6).

	Also, any old instance of the LSA must be removed from the
	database when the new LSA is installed.	 This old instance must
	also be	removed	from all neighbors' Link state retransmission
	lists (see Section 10).

    13.3.  Next	step in	the flooding procedure

	When a new (and	more recent) LSA has been received, it must be
	flooded	out some set of	the router's interfaces.  This section
	describes the second part of flooding procedure	(the first part
	being the processing that occurred in Section 13), namely,
	selecting the outgoing interfaces and adding the LSA to	the
	appropriate neighbors' Link state retransmission lists.	 Also
	included in this part of the flooding procedure	is the
	maintenance of the neighbors' Link state request lists.

	This section is	equally	applicable to the flooding of an LSA
	that the router	itself has just	originated (see	Section	12.4).
	For these LSAs,	this section provides the entirety of the
	flooding procedure (i.e., the processing of Section 13 is not
	performed, since, for example, the LSA has not been received
	from a neighbor	and therefore does not need to be acknowledged).

	Depending upon the LSA's LS type, the LSA can be flooded out
	only certain interfaces.  These	interfaces, defined by the
	following, are called the eligible interfaces:

	AS-external-LSAs (LS Type = 5)
	    AS-external-LSAs are flooded throughout the	entire AS, with
	    the	exception of stub areas	(see Section 3.6).  The	eligible
	    interfaces are all the router's interfaces,	excluding
	    virtual links and those interfaces attaching to stub areas.

	All other LS types
	    All	other types are	specific to a single area (Area	A).  The

Moy			    Standards Track		      [Page 148]



RFC 2328		     OSPF Version 2		      April 1998

	    eligible interfaces	are all	those interfaces attaching to
	    the	Area A.	 If Area A is the backbone, this includes all
	    the	virtual	links.

	Link state databases must remain synchronized over all
	adjacencies associated with the	above eligible interfaces.  This
	is accomplished	by executing the following steps on each
	eligible interface.  It	should be noted	that this procedure may
	decide not to flood an LSA out a particular interface, if there
	is a high probability that the attached	neighbors have already
	received the LSA.  However, in these cases the flooding
	procedure must be absolutely sure that the neighbors eventually
	do receive the LSA, so the LSA is still	added to each
	adjacency's Link state retransmission list.  For each eligible
	interface:

	(1) Each of the	neighbors attached to this interface are
	    examined, to determine whether they	must receive the new
	    LSA.  The following	steps are executed for each neighbor:

	    (a)	If the neighbor	is in a	lesser state than Exchange, it
		does not participate in	flooding, and the next neighbor
		should be examined.

	    (b)	Else, if the adjacency is not yet full (neighbor state
		is Exchange or Loading), examine the Link state	request
		list associated	with this adjacency.  If there is an
		instance of the	new LSA	on the list, it	indicates that
		the neighboring	router has an instance of the LSA
		already.  Compare the new LSA to the neighbor's	copy:

		o   If the new LSA is less recent, then	examine	the next
		    neighbor.

		o   If the two copies are the same instance, then delete
		    the	LSA from the Link state	request	list, and
		    examine the	next neighbor.[20]

		o   Else, the new LSA is more recent.  Delete the LSA
		    from the Link state	request	list.

Moy			    Standards Track		      [Page 149]



RFC 2328		     OSPF Version 2		      April 1998

	    (c)	If the new LSA was received from this neighbor,	examine
		the next neighbor.

	    (d)	At this	point we are not positive that the neighbor has
		an up-to-date instance of this new LSA.	 Add the new LSA
		to the Link state retransmission list for the adjacency.
		This ensures that the flooding procedure is reliable;
		the LSA	will be	retransmitted at intervals until an
		acknowledgment is seen from the	neighbor.

	(2) The	router must now	decide whether to flood	the new	LSA out
	    this interface.  If	in the previous	step, the LSA was NOT
	    added to any of the	Link state retransmission lists, there
	    is no need to flood	the LSA	out the	interface and the next
	    interface should be	examined.

	(3) If the new LSA was received	on this	interface, and it was
	    received from either the Designated	Router or the Backup
	    Designated Router, chances are that	all the	neighbors have
	    received the LSA already.  Therefore, examine the next
	    interface.

	(4) If the new LSA was received	on this	interface, and the
	    interface state is Backup (i.e., the router	itself is the
	    Backup Designated Router), examine the next	interface.  The
	    Designated Router will do the flooding on this interface.
	    However, if	the Designated Router fails the	router (i.e.,
	    the	Backup Designated Router) will end up retransmitting the
	    updates.

	(5) If this step is reached, the LSA must be flooded out the
	    interface.	Send a Link State Update packet	(including the
	    new	LSA as contents) out the interface.  The LSA's LS age
	    must be incremented	by InfTransDelay (which	must be	> 0)
	    when it is copied into the outgoing	Link State Update packet
	    (until the LS age field reaches the	maximum	value of
	    MaxAge).

	    On broadcast networks, the Link State Update packets are
	    multicast.	The destination	IP address specified for the
	    Link State Update Packet depends on	the state of the
	    interface.	If the interface state is DR or	Backup,	the

Moy			    Standards Track		      [Page 150]



RFC 2328		     OSPF Version 2		      April 1998

	    address AllSPFRouters should be used.  Otherwise, the
	    address AllDRouters	should be used.

	    On non-broadcast networks, separate	Link State Update
	    packets must be sent, as unicasts, to each adjacent	neighbor
	    (i.e., those in state Exchange or greater).	 The destination
	    IP addresses for these packets are the neighbors' IP
	    addresses.

    13.4.  Receiving self-originated LSAs

	It is a	common occurrence for a	router to receive self-
	originated LSAs	via the	flooding procedure. A self-originated
	LSA is detected	when either 1) the LSA's Advertising Router is
	equal to the router's own Router ID or 2) the LSA is a network-
	LSA and	its Link State ID is equal to one of the router's own IP
	interface addresses.

	However, if the	received self-originated LSA is	newer than the
	last instance that the router actually originated, the router
	must take special action.  The reception of such an LSA
	indicates that there are LSAs in the routing domain that were
	originated by the router before	the last time it was restarted.
	In most	cases, the router must then advance the	LSA's LS
	sequence number	one past the received LS sequence number, and
	originate a new	instance of the	LSA.

	It may be the case the router no longer	wishes to originate the
	received LSA. Possible examples	include: 1) the	LSA is a
	summary-LSA or AS-external-LSA and the router no longer	has an
	(advertisable) route to	the destination, 2) the	LSA is a
	network-LSA but	the router is no longer	Designated Router for
	the network or 3) the LSA is a network-LSA whose Link State ID
	is one of the router's own IP interface	addresses but whose
	Advertising Router is not equal	to the router's	own Router ID
	(this latter case should be rare, and it indicates that	the
	router's Router	ID has changed since originating the LSA).  In
	all these cases, instead of updating the LSA, the LSA should be
	flushed	from the routing domain	by incrementing	the received
	LSA's LS age to	MaxAge and reflooding (see Section 14.1).

Moy			    Standards Track		      [Page 151]



RFC 2328		     OSPF Version 2		      April 1998

    13.5.  Sending Link	State Acknowledgment packets

	Each newly received LSA	must be	acknowledged.  This is usually
	done by	sending	Link State Acknowledgment packets.  However,
	acknowledgments	can also be accomplished implicitly by sending
	Link State Update packets (see step 7a of Section 13).

	Many acknowledgments may be grouped together into a single Link
	State Acknowledgment packet.  Such a packet is sent back out the
	interface which	received the LSAs.  The	packet can be sent in
	one of two ways: delayed and sent on an	interval timer,	or sent
	directly to a particular neighbor.  The	particular
	acknowledgment strategy	used depends on	the circumstances
	surrounding the	receipt	of the LSA.

	Sending	delayed	acknowledgments	accomplishes several things: 1)
	it facilitates the packaging of	multiple acknowledgments in a
	single Link State Acknowledgment packet, 2) it enables a single
	Link State Acknowledgment packet to indicate acknowledgments to
	several	neighbors at once (through multicasting) and 3)	it
	randomizes the Link State Acknowledgment packets sent by the
	various	routers	attached to a common network.  The fixed
	interval between a router's delayed transmissions must be short
	(less than RxmtInterval) or needless retransmissions will ensue.

	Direct acknowledgments are sent	directly to a particular
	neighbor in response to	the receipt of duplicate LSAs. Direct
	acknowledgments	are sent immediately when the duplicate	is
	received. On multi-access networks, these acknowledgments are
	sent directly to the neighbor's	IP address.

	The precise procedure for sending Link State Acknowledgment
	packets	is described in	Table 19.  The circumstances surrounding
	the receipt of the LSA are listed in the left column.  The
	acknowledgment action then taken is listed in one of the two
	right columns.	This action depends on the state of the
	concerned interface; interfaces	in state Backup	behave
	differently from interfaces in all other states.  Delayed
	acknowledgments	must be	delivered to all adjacent routers
	associated with	the interface.	On broadcast networks, this is
	accomplished by	sending	the delayed Link State Acknowledgment
	packets	as multicasts.	The Destination	IP address used	depends

Moy			    Standards Track		      [Page 152]



RFC 2328		     OSPF Version 2		      April 1998

				     Action taken in state
   Circumstances	    Backup		  All other states
   _________________________________________________________________
   LSA	has		    No	acknowledgment	  No  acknowledgment
   been	 flooded back	    sent.		  sent.
   out receiving  in-
   terface  (see Sec-
   tion	13, step 5b).
   _________________________________________________________________
   LSA	 is		    Delayed acknowledg-	  Delayed	ack-
   more	 recent	 than	    ment sent if adver-	  nowledgment sent.
   database copy, but	    tisement   received
   was	 not  flooded	    from    Designated
   back	out receiving	    Router,  otherwise
   interface		    do nothing
   _________________________________________________________________
   LSA is a		    Delayed acknowledg-	  No  acknowledgment
   duplicate, and was	    ment sent if adver-	  sent.
   treated as an  im-	    tisement   received
   plied  acknowledg-	    from    Designated
   ment	(see  Section	    Router,  otherwise
   13, step 7a).	    do nothing
   _________________________________________________________________
   LSA is a		    Direct acknowledg-	  Direct acknowledg-
   duplicate, and was	    ment sent.		  ment sent.
   not treated as  an
   implied	 ack-
   nowledgment.
   _________________________________________________________________
   LSA's LS		    Direct acknowledg-	  Direct acknowledg-
   age is equal	to	    ment sent.		  ment sent.
   MaxAge, and there is
   no current instance
   of the LSA
   in the link state
   database, and none
   of router's neighbors
   are in states Exchange

Moy			    Standards Track		      [Page 153]



RFC 2328		     OSPF Version 2		      April 1998

   or Loading (see
   Section 13, step 4).

	     Table 19: Sending link state acknowledgements.

	on the state of	the interface.	If the interface state is DR or
	Backup,	the destination	AllSPFRouters is used.	In all other
	states,	the destination	AllDRouters is used.  On non-broadcast
	networks, delayed Link State Acknowledgment packets must be
	unicast	separately over	each adjacency (i.e., neighbor whose
	state is >= Exchange).

	The reasoning behind sending the above packets as multicasts is
	best explained by an example.  Consider	the network
	configuration depicted in Figure 15.  Suppose RT4 has been
	elected	as Designated Router, and RT3 as Backup	Designated
	Router for the network N3.  When Router	RT4 floods a new LSA to
	Network	N3, it is received by routers RT1, RT2,	and RT3.  These
	routers	will not flood the LSA back onto net N3, but they still
	must ensure that their link-state databases remain synchronized
	with their adjacent neighbors.	So RT1,	RT2, and RT4 are waiting
	to see an acknowledgment from RT3.  Likewise, RT4 and RT3 are
	both waiting to	see acknowledgments from RT1 and RT2.  This is
	best achieved by sending the acknowledgments as	multicasts.

	The reason that	the acknowledgment logic for Backup DRs	is
	slightly different is because they perform differently during
	the flooding of	LSAs (see Section 13.3,	step 4).

    13.6.  Retransmitting LSAs

	LSAs flooded out an adjacency are placed on the	adjacency's Link
	state retransmission list.  In order to	ensure that flooding is
	reliable, these	LSAs are retransmitted until they are
	acknowledged.  The length of time between retransmissions is a
	configurable per-interface value, RxmtInterval.	 If this is set

Moy			    Standards Track		      [Page 154]



RFC 2328		     OSPF Version 2		      April 1998

	too low	for an interface, needless retransmissions will	ensue.
	If the value is	set too	high, the speed	of the flooding, in the
	face of	lost packets, may be affected.

	Several	retransmitted LSAs may fit into	a single Link State
	Update packet.	When LSAs are to be retransmitted, only	the
	number fitting in a single Link	State Update packet should be
	sent.  Another packet of retransmissions can be	sent whenever
	some of	the LSAs are acknowledged, or on the next firing of the
	retransmission timer.

	Link State Update Packets carrying retransmissions are always
	sent directly to the neighbor. On multi-access networks, this
	means that retransmissions are sent directly to	the neighbor's
	IP address.  Each LSA's	LS age must be incremented by
	InfTransDelay (which must be > 0) when it is copied into the
	outgoing Link State Update packet (until the LS	age field
	reaches	the maximum value of MaxAge).

	If an adjacent router goes down, retransmissions may occur until
	the adjacency is destroyed by OSPF's Hello Protocol.  When the
	adjacency is destroyed,	the Link state retransmission list is
	cleared.

    13.7.  Receiving link state	acknowledgments

	Many consistency checks	have been made on a received Link State
	Acknowledgment packet before it	is handed to the flooding
	procedure.  In particular, it has been associated with a
	particular neighbor.  If this neighbor is in a lesser state than
	Exchange, the Link State Acknowledgment	packet is discarded.

	Otherwise, for each acknowledgment in the Link State
	Acknowledgment packet, the following steps are performed:

	o   Does the LSA acknowledged have an instance on the Link state
	    retransmission list	for the	neighbor?  If not, examine the
	    next acknowledgment.  Otherwise:

Moy			    Standards Track		      [Page 155]



RFC 2328		     OSPF Version 2		      April 1998

	o   If the acknowledgment is for the same instance that	is
	    contained on the list, remove the item from	the list and
	    examine the	next acknowledgment.  Otherwise:

	o   Log	the questionable acknowledgment, and examine the next
	    one.

14.  Aging The Link State Database

    Each LSA has an LS age field.  The LS age is expressed in seconds.
    An LSA's LS	age field is incremented while it is contained in a
    router's database.	Also, when copied into a Link State Update
    Packet for flooding	out a particular interface, the	LSA's LS age is
    incremented	by InfTransDelay.

    An LSA's LS	age is never incremented past the value	MaxAge.	 LSAs
    having age MaxAge are not used in the routing table	calculation.  As
    a router ages its link state database, an LSA's LS age may reach
    MaxAge.[21]	At this	time, the router must attempt to flush the LSA
    from the routing domain.  This is done simply by reflooding	the
    MaxAge LSA just as if it was a newly originated LSA	(see Section
    13.3).

    When creating a Database summary list for a	newly forming adjacency,
    any	MaxAge LSAs present in the link	state database are added to the
    neighbor's Link state retransmission list instead of the neighbor's
    Database summary list.  See	Section	10.3 for more details.

    A MaxAge LSA must be removed immediately from the router's link
    state database as soon as both a) it is no longer contained	on any
    neighbor Link state	retransmission lists and b) none of the	router's
    neighbors are in states Exchange or	Loading.

    When, in the process of aging the link state database, an LSA's LS
    age	hits a multiple	of CheckAge, its LS checksum should be verified.
    If the LS checksum is incorrect, a program or memory error has been
    detected, and at the very least the	router itself should be
    restarted.

Moy			    Standards Track		      [Page 156]



RFC 2328		     OSPF Version 2		      April 1998

    14.1.  Premature aging of LSAs

	An LSA can be flushed from the routing domain by setting its LS
	age to MaxAge, while leaving its LS sequence number alone, and
	then reflooding	the LSA.  This procedure follows the same course
	as flushing an LSA whose LS age	has naturally reached the value
	MaxAge (see Section 14).  In particular, the MaxAge LSA	is
	removed	from the router's link state database as soon as a) it
	is no longer contained on any neighbor Link state retransmission
	lists and b) none of the router's neighbors are	in states
	Exchange or Loading.  We call the setting of an	LSA's LS age to
	MaxAge "premature aging".

	Premature aging	is used	when it	is time	for a self-originated
	LSA's sequence number field to wrap.  At this point, the current
	LSA instance (having LS	sequence number	MaxSequenceNumber) must
	be prematurely aged and	flushed	from the routing domain	before a
	new instance with sequence number equal	to InitialSequenceNumber
	can be originated.  See	Section	12.1.6 for more	information.

	Premature aging	can also be used when, for example, one	of the
	router's previously advertised external	routes is no longer
	reachable.  In this circumstance, the router can flush its AS-
	external-LSA from the routing domain via premature aging. This
	procedure is preferable	to the alternative, which is to
	originate a new	LSA for	the destination	specifying a metric of
	LSInfinity.  Premature aging is	also be	used when unexpectedly
	receiving self-originated LSAs during the flooding procedure
	(see Section 13.4).

	A router may only prematurely age its own self-originated LSAs.
	The router may not prematurely age LSAs	that have been
	originated by other routers. An	LSA is considered self-
	originated when	either 1) the LSA's Advertising	Router is equal
	to the router's	own Router ID or 2) the	LSA is a network-LSA and
	its Link State ID is equal to one of the router's own IP
	interface addresses.

Moy			    Standards Track		      [Page 157]



RFC 2328		     OSPF Version 2		      April 1998

15.  Virtual Links

    The	single backbone	area (Area ID =	0.0.0.0) cannot	be disconnected,
    or some areas of the Autonomous System will	become unreachable.  To
    establish/maintain connectivity of the backbone, virtual links can
    be configured through non-backbone areas.  Virtual links serve to
    connect physically separate	components of the backbone.  The two
    endpoints of a virtual link	are area border	routers.  The virtual
    link must be configured in both routers.  The configuration
    information	in each	router consists	of the other virtual endpoint
    (the other area border router), and	the non-backbone area the two
    routers have in common (called the Transit area).  Virtual links
    cannot be configured through stub areas (see Section 3.6).

    The	virtual	link is	treated	as if it were an unnumbered point-to-
    point network belonging to the backbone and	joining	the two	area
    border routers.  An	attempt	is made	to establish an	adjacency over
    the	virtual	link.  When this adjacency is established, the virtual
    link will be included in backbone router-LSAs, and OSPF packets
    pertaining to the backbone area will flow over the adjacency.  Such
    an adjacency has been referred to in this document as a "virtual
    adjacency".

    In each endpoint router, the cost and viability of the virtual link
    is discovered by examining the routing table entry for the other
    endpoint router.  (The entry's associated area must	be the
    configured Transit area).  This is called the virtual link's
    corresponding routing table	entry.	The InterfaceUp	event occurs for
    a virtual link when	its corresponding routing table	entry becomes
    reachable.	Conversely, the	InterfaceDown event occurs when	its
    routing table entry	becomes	unreachable.  In other words, the
    virtual link's viability is	determined by the existence of an
    intra-area path, through the Transit area, between the two
    endpoints.	Note that a virtual link whose underlying path has cost
    greater than hexadecimal 0xffff (the maximum size of an interface
    cost in a router-LSA) should be considered inoperational (i.e.,
    treated the	same as	if the path did	not exist).

    The	other details concerning virtual links are as follows:

    o	AS-external-LSAs are NEVER flooded over	virtual	adjacencies.
	This would be duplication of effort, since the same AS-

Moy			    Standards Track		      [Page 158]



RFC 2328		     OSPF Version 2		      April 1998

	external-LSAs are already flooded throughout the virtual link's
	Transit	area.  For this	same reason, AS-external-LSAs are not
	summarized over	virtual	adjacencies during the Database	Exchange
	process.

    o	The cost of a virtual link is NOT configured.  It is defined to
	be the cost of the intra-area path between the two defining area
	border routers.	 This cost appears in the virtual link's
	corresponding routing table entry.  When the cost of a virtual
	link changes, a	new router-LSA should be originated for	the
	backbone area.

    o	Just as	the virtual link's cost	and viability are determined by
	the routing table build	process	(through construction of the
	routing	table entry for	the other endpoint), so	are the	IP
	interface address for the virtual interface and	the virtual
	neighbor's IP address.	These are used when sending OSPF
	protocol packets over the virtual link.	Note that when one (or
	both) of the virtual link endpoints connect to the Transit area
	via an unnumbered point-to-point link, it may be impossible to
	calculate either the virtual interface's IP address and/or the
	virtual	neighbor's IP address, thereby causing the virtual link
	to fail.

    o	In each	endpoint's router-LSA for the backbone,	the virtual link
	is represented as a Type 4 link	whose Link ID is set to	the
	virtual	neighbor's OSPF	Router ID and whose Link Data is set to
	the virtual interface's	IP address.  See Section 12.4.1	for more
	information.

    o	A non-backbone area can	carry transit data traffic (i.e., is
	considered a "transit area") if	and only if it serves as the
	Transit	area for one or	more fully adjacent virtual links (see
	TransitCapability in Sections 6	and 16.1). Such	an area	requires
	special	treatment when summarizing backbone networks into it
	(see Section 12.4.3), and during the routing calculation (see
	Section	16.3).

    o	The time between link state retransmissions, RxmtInterval, is
	configured for a virtual link.	This should be well over the
	expected round-trip delay between the two routers.  This may be

Moy			    Standards Track		      [Page 159]



RFC 2328		     OSPF Version 2		      April 1998

	hard to	estimate for a virtual link; it	is better to err on the
	side of	making it too large.

16.  Calculation of the	routing	table

    This section details the OSPF routing table	calculation.  Using its
    attached areas' link state databases as input, a router runs the
    following algorithm, building its routing table step by step.  At
    each step, the router must access individual pieces	of the link
    state databases (e.g., a router-LSA	originated by a	certain	router).
    This access	is performed by	the lookup function discussed in Section
    12.2.  The lookup process may return an LSA	whose LS age is	equal to
    MaxAge.  Such an LSA should	not be used in the routing table
    calculation, and is	treated	just as	if the lookup process had
    failed.

    The	OSPF routing table's organization is explained in Section 11.
    Two	examples of the	routing	table build process are	presented in
    Sections 11.2 and 11.3.  This process can be broken	into the
    following steps:

    (1)	The present routing table is invalidated.  The routing table is
	built again from scratch.  The old routing table is saved so
	that changes in	routing	table entries can be identified.

    (2)	The intra-area routes are calculated by	building the shortest-
	path tree for each attached area.  In particular, all routing
	table entries whose Destination	Type is	"area border router" are
	calculated in this step.  This step is described in two	parts.
	At first the tree is constructed by only considering those links
	between	routers	and transit networks.  Then the	stub networks
	are incorporated into the tree.	During the area's shortest-path
	tree calculation, the area's TransitCapability is also
	calculated for later use in Step 4.

    (3)	The inter-area routes are calculated, through examination of
	summary-LSAs.  If the router is	attached to multiple areas
	(i.e., it is an	area border router), only backbone summary-LSAs
	are examined.

Moy			    Standards Track		      [Page 160]



RFC 2328		     OSPF Version 2		      April 1998

    (4)	In area	border routers connecting to one or more transit areas
	(i.e, non-backbone areas whose TransitCapability is found to be
	TRUE), the transit areas' summary-LSAs are examined to see
	whether	better paths exist using the transit areas than	were
	found in Steps 2-3 above.

    (5)	Routes to external destinations	are calculated,	through
	examination of AS-external-LSAs.  The locations	of the AS
	boundary routers (which	originate the AS-external-LSAs)	have
	been determined	in steps 2-4.

    Steps 2-5 are explained in further detail below.

    Changes made to routing table entries as a result of these
    calculations can cause the OSPF protocol to	take further actions.
    For	example, a change to an	intra-area route will cause an area
    border router to originate new summary-LSAs	(see Section 12.4).  See
    Section 16.7 for a complete	list of	the OSPF protocol actions
    resulting from routing table changes.

    16.1.  Calculating the shortest-path tree for an area

	This calculation yields	the set	of intra-area routes associated
	with an	area (called hereafter Area A).	 A router calculates the
	shortest-path tree using itself	as the root.[22] The formation
	of the shortest	path tree is done here in two stages.  In the
	first stage, only links	between	routers	and transit networks are
	considered.  Using the Dijkstra	algorithm, a tree is formed from
	this subset of the link	state database.	 In the	second stage,
	leaves are added to the	tree by	considering the	links to stub
	networks.

	The procedure will be explained	using the graph	terminology that
	was introduced in Section 2.  The area's link state database is
	represented as a directed graph.  The graph's vertices are
	routers, transit networks and stub networks.  The first	stage of
	the procedure concerns only the	transit	vertices (routers and
	transit	networks) and their connecting links.  Throughout the
	shortest path calculation, the following data is also associated
	with each transit vertex:

Moy			    Standards Track		      [Page 161]



RFC 2328		     OSPF Version 2		      April 1998

	Vertex (node) ID
	    A 32-bit number which together with	the vertex type	(router
	    or network)	uniquely identifies the	vertex.	 For router
	    vertices the Vertex	ID is the router's OSPF	Router ID.  For
	    network vertices, it is the	IP address of the network's
	    Designated Router.

	An LSA
	    Each transit vertex	has an associated LSA.	For router
	    vertices, this is a	router-LSA.  For transit networks, this
	    is a network-LSA (which is actually	originated by the
	    network's Designated Router).  In any case,	the LSA's Link
	    State ID is	always equal to	the above Vertex ID.

	List of	next hops
	    The	list of	next hops for the current set of shortest paths
	    from the root to this vertex.  There can be	multiple
	    shortest paths due to the equal-cost multipath capability.
	    Each next hop indicates the	outgoing router	interface to use
	    when forwarding traffic to the destination.	 On broadcast,
	    Point-to-MultiPoint	and NBMA networks, the next hop	also
	    includes the IP address of the next	router (if any)	in the
	    path towards the destination.

	Distance from root
	    The	link state cost	of the current set of shortest paths
	    from the root to the vertex.  The link state cost of a path
	    is calculated as the sum of	the costs of the path's
	    constituent	links (as advertised in	router-LSAs and
	    network-LSAs).  One	path is	said to	be "shorter" than
	    another if it has a	smaller	link state cost.

	The first stage	of the procedure (i.e.,	the Dijkstra algorithm)
	can now	be summarized as follows. At each iteration of the
	algorithm, there is a list of candidate	vertices.  Paths from
	the root to these vertices have	been found, but	not necessarily
	the shortest ones.  However, the paths to the candidate	vertex
	that is	closest	to the root are	guaranteed to be shortest; this
	vertex is added	to the shortest-path tree, removed from	the
	candidate list,	and its	adjacent vertices are examined for
	possible addition to/modification of the candidate list.  The

Moy			    Standards Track		      [Page 162]



RFC 2328		     OSPF Version 2		      April 1998

	algorithm then iterates	again.	It terminates when the candidate
	list becomes empty.

	The following steps describe the algorithm in detail.  Remember
	that we	are computing the shortest path	tree for Area A.  All
	references to link state database lookup below are from	Area A's
	database.

	(1) Initialize the algorithm's data structures.	 Clear the list
	    of candidate vertices.  Initialize the shortest-path tree to
	    only the root (which is the	router doing the calculation).
	    Set	Area A's TransitCapability to FALSE.

	(2) Call the vertex just added to the tree vertex V.  Examine
	    the	LSA associated with vertex V.  This is a lookup	in the
	    Area A's link state	database based on the Vertex ID.  If
	    this is a router-LSA, and bit V of the router-LSA (see
	    Section A.4.2) is set, set Area A's	TransitCapability to
	    TRUE.  In any case,	each link described by the LSA gives the
	    cost to an adjacent	vertex.	 For each described link, (say
	    it joins vertex V to vertex	W):

	    (a)	If this	is a link to a stub network, examine the next
		link in	V's LSA.  Links	to stub	networks will be
		considered in the second stage of the shortest path
		calculation.

	    (b)	Otherwise, W is	a transit vertex (router or transit
		network).  Look	up the vertex W's LSA (router-LSA or
		network-LSA) in	Area A's link state database.  If the
		LSA does not exist, or its LS age is equal to MaxAge, or
		it does	not have a link	back to	vertex V, examine the
		next link in V's LSA.[23]

	    (c)	If vertex W is already on the shortest-path tree,
		examine	the next link in the LSA.

	    (d)	Calculate the link state cost D	of the resulting path
		from the root to vertex	W.  D is equal to the sum of the
		link state cost	of the (already	calculated) shortest
		path to	vertex V and the advertised cost of the	link
		between	vertices V and W.  If D	is:

Moy			    Standards Track		      [Page 163]



RFC 2328		     OSPF Version 2		      April 1998

		o   Greater than the value that	already	appears	for
		    vertex W on	the candidate list, then examine the
		    next link.

		o   Equal to the value that appears for	vertex W on the
		    candidate list, calculate the set of next hops that
		    result from	using the advertised link.  Input to
		    this calculation is	the destination	(W), and its
		    parent (V).	 This calculation is shown in Section
		    16.1.1.  This set of hops should be	added to the
		    next hop values that appear	for W on the candidate
		    list.

		o   Less than the value	that appears for vertex	W on the
		    candidate list, or if W does not yet appear	on the
		    candidate list, then set the entry for W on	the
		    candidate list to indicate a distance of D from the
		    root.  Also	calculate the list of next hops	that
		    result from	using the advertised link, setting the
		    next hop values for	W accordingly.	The next hop
		    calculation	is described in	Section	16.1.1;	it takes
		    as input the destination (W) and its parent	(V).

	(3) If at this step the	candidate list is empty, the shortest-
	    path tree (of transit vertices) has	been completely	built
	    and	this stage of the procedure terminates.	 Otherwise,
	    choose the vertex belonging	to the candidate list that is
	    closest to the root, and add it to the shortest-path tree
	    (removing it from the candidate list in the	process). Note
	    that when there is a choice	of vertices closest to the root,
	    network vertices must be chosen before router vertices in
	    order to necessarily find all equal-cost paths. This is
	    consistent with the	tie-breakers that were introduced in the
	    modified Dijkstra algorithm	used by	OSPF's Multicast routing
	    extensions (MOSPF).

	(4) Possibly modify the	routing	table.	For those routing table
	    entries modified, the associated area will be set to Area A,
	    the	path type will be set to intra-area, and the cost will
	    be set to the newly	discovered shortest path's calculated
	    distance.

Moy			    Standards Track		      [Page 164]



RFC 2328		     OSPF Version 2		      April 1998

	    If the newly added vertex is an area border	router or AS
	    boundary router, a routing table entry is added whose
	    destination	type is	"router".  The Options field found in
	    the	associated router-LSA is copied	into the routing table
	    entry's Optional capabilities field. Call the newly	added
	    vertex Router X.  If Router	X is the endpoint of one of the
	    calculating	router's virtual links,	and the	virtual	link
	    uses Area A	as Transit area:  the virtual link is declared
	    up,	the IP address of the virtual interface	is set to the IP
	    address of the outgoing interface calculated above for
	    Router X, and the virtual neighbor's IP address is set to
	    Router X's interface address (contained in Router X's
	    router-LSA)	that points back to the	root of	the shortest-
	    path tree; equivalently, this is the interface that	points
	    back to Router X's parent vertex on	the shortest-path tree
	    (similar to	the calculation	in Section 16.1.1).

	    If the newly added vertex is a transit network, the	routing
	    table entry	for the	network	is located.  The entry's
	    Destination	ID is the IP network number, which can be
	    obtained by	masking	the Vertex ID (Link State ID) with its
	    associated subnet mask (found in the body of the associated
	    network-LSA).  If the routing table	entry already exists
	    (i.e., there is already an intra-area route	to the
	    destination	installed in the routing table), multiple
	    vertices have mapped to the	same IP	network.  For example,
	    this can occur when	a new Designated Router	is being
	    established.  In this case,	the current routing table entry
	    should be overwritten if and only if the newly found path is
	    just as short and the current routing table	entry's	Link
	    State Origin has a smaller Link State ID than the newly
	    added vertex' LSA.

	    If there is	no routing table entry for the network (the
	    usual case), a routing table entry for the IP network should
	    be added.  The routing table entry's Link State Origin
	    should be set to the newly added vertex' LSA.

	(5) Iterate the	algorithm by returning to Step 2.

Moy			    Standards Track		      [Page 165]



RFC 2328		     OSPF Version 2		      April 1998

	The stub networks are added to the tree	in the procedure's
	second stage.  In this stage, all router vertices are again
	examined.  Those that have been	determined to be unreachable in
	the above first	phase are discarded.  For each reachable router
	vertex (call it	V), the	associated router-LSA is found in the
	link state database.  Each stub	network	link appearing in the
	LSA is then examined, and the following	steps are executed:

	(1) Calculate the distance D of	stub network from the root.  D
	    is equal to	the distance from the root to the router vertex
	    (calculated	in stage 1), plus the stub network link's
	    advertised cost.  Compare this distance to the current best
	    cost to the	stub network.  This is done by looking up the
	    stub network's current routing table entry.	 If the
	    calculated distance	D is larger, go	on to examine the next
	    stub network link in the LSA.

	(2) If this step is reached, the stub network's	routing	table
	    entry must be updated.  Calculate the set of next hops that
	    would result from using the	stub network link.  This
	    calculation	is shown in Section 16.1.1; input to this
	    calculation	is the destination (the	stub network) and the
	    parent vertex (the router vertex).	If the distance	D is the
	    same as the	current	routing	table cost, simply add this set
	    of next hops to the	routing	table entry's list of next hops.
	    In this case, the routing table already has	a Link State
	    Origin.  If	this Link State	Origin is a router-LSA whose
	    Link State ID is smaller than V's Router ID, reset the Link
	    State Origin to V's	router-LSA.

	    Otherwise D	is smaller than	the routing table cost.
	    Overwrite the current routing table	entry by setting the
	    routing table entry's cost to D, and by setting the	entry's
	    list of next hops to the newly calculated set.  Set	the
	    routing table entry's Link State Origin to V's router-LSA.
	    Then go on to examine the next stub	network	link.

	For all	routing	table entries added/modified in	the second
	stage, the associated area will	be set to Area A and the path
	type will be set to intra-area.	 When the list of reachable
	router-LSAs is exhausted, the second stage is completed.  At

Moy			    Standards Track		      [Page 166]



RFC 2328		     OSPF Version 2		      April 1998

	this time, all intra-area routes associated with Area A	have
	been determined.

	The specification does not require that	the above two stage
	method be used to calculate the	shortest path tree.  However, if
	another	algorithm is used, an identical	tree must be produced.
	For this reason, it is important to note that links between
	transit	vertices must be bidirectional in order	to be included
	in the above tree.  It should also be mentioned	that more
	efficient algorithms exist for calculating the tree; for
	example, the incremental SPF algorithm described in [Ref1].

	16.1.1.	 The next hop calculation

	    This section explains how to calculate the current set of
	    next hops to use for a destination.	 Each next hop consists
	    of the outgoing interface to use in	forwarding packets to
	    the	destination together with the IP address of the	next hop
	    router (if any).  The next hop calculation is invoked each
	    time a shorter path	to the destination is discovered.  This
	    can	happen in either stage of the shortest-path tree
	    calculation	(see Section 16.1).  In	stage 1	of the
	    shortest-path tree calculation a shorter path is found as
	    the	destination is added to	the candidate list, or when the
	    destination's entry	on the candidate list is modified (Step
	    2d of Stage	1).  In	stage 2	a shorter path is discovered
	    each time the destination's	routing	table entry is modified
	    (Step 2 of Stage 2).

	    The	set of next hops to use	for the	destination may	be
	    recalculated several times during the shortest-path	tree
	    calculation, as shorter and	shorter	paths are discovered.
	    In the end,	the destination's routing table	entry will
	    always reflect the next hops resulting from	the absolute
	    shortest path(s).

	    Input to the next hop calculation is a) the	destination and
	    b) its parent in the current shortest path between the root
	    (the calculating router) and the destination.  The parent is
	    always a transit vertex (i.e., always a router or a	transit
	    network).

Moy			    Standards Track		      [Page 167]



RFC 2328		     OSPF Version 2		      April 1998

	    If there is	at least one intervening router	in the current
	    shortest path between the destination and the root,	the
	    destination	simply inherits	the set	of next	hops from the
	    parent.  Otherwise,	there are two cases.  In the first case,
	    the	parent vertex is the root (the calculating router
	    itself).  This means that the destination is either	a
	    directly connected network or directly connected router.
	    The	outgoing interface in this case	is simply the OSPF
	    interface connecting to the	destination network/router. If
	    the	destination is a router	which connects to the
	    calculating	router via a Point-to-MultiPoint network, the
	    destination's next hop IP address(es) can be determined by
	    examining the destination's	router-LSA: each link pointing
	    back to the	calculating router and having a	Link Data field
	    belonging to the Point-to-MultiPoint network provides an IP
	    address of the next	hop router. If the destination is a
	    directly connected network,	or a router which connects to
	    the	calculating router via a point-to-point	interface, no
	    next hop IP	address	is required. If	the destination	is a
	    router connected to	the calculating	router via a virtual
	    link, the setting of the next hop should be	deferred until
	    the	calculation in Section 16.3.

	    In the second case,	the parent vertex is a network that
	    directly connects the calculating router to	the destination
	    router.  The list of next hops is then determined by
	    examining the destination's	router-LSA.  For each link in
	    the	router-LSA that	points back to the parent network, the
	    link's Link	Data field provides the	IP address of a	next hop
	    router.  The outgoing interface to use can then be derived
	    from the next hop IP address (or it	can be inherited from
	    the	parent network).

    16.2.  Calculating the inter-area routes

	The inter-area routes are calculated by	examining summary-LSAs.
	If the router has active attachments to	multiple areas,	only
	backbone summary-LSAs are examined.  Routers attached to a
	single area examine that area's	summary-LSAs.  In either case,
	the summary-LSAs examined below	are all	part of	a single area's
	link state database (call it Area A).

Moy			    Standards Track		      [Page 168]



RFC 2328		     OSPF Version 2		      April 1998

	Summary-LSAs are originated by the area	border routers.	 Each
	summary-LSA in Area A is considered in turn.  Remember that the
	destination described by a summary-LSA is either a network (Type
	3 summary-LSAs)	or an AS boundary router (Type 4 summary-LSAs).
	For each summary-LSA:

	(1) If the cost	specified by the LSA is	LSInfinity, or if the
	    LSA's LS age is equal to MaxAge, then examine the the next
	    LSA.

	(2) If the LSA was originated by the calculating router	itself,
	    examine the	next LSA.

	(3) If it is a Type 3 summary-LSA, and the collection of
	    destinations described by the summary-LSA equals one of the
	    router's configured	area address ranges (see Section 3.5),
	    and	the particular area address range is active, then the
	    summary-LSA	should be ignored.  "Active" means that	there
	    are	one or more reachable (by intra-area paths) networks
	    contained in the area range.

	(4) Else, call the destination described by the	LSA N (for Type
	    3 summary-LSAs, N's	address	is obtained by masking the LSA's
	    Link State ID with the network/subnet mask contained in the
	    body of the	LSA), and the area border originating the LSA
	    BR.	 Look up the routing table entry for BR	having Area A as
	    its	associated area.  If no	such entry exists for router BR
	    (i.e., BR is unreachable in	Area A), do nothing with this
	    LSA	and consider the next in the list.  Else, this LSA
	    describes an inter-area path to destination	N, whose cost is
	    the	distance to BR plus the	cost specified in the LSA. Call
	    the	cost of	this inter-area	path IAC.

	(5) Next, look up the routing table entry for the destination N.
	    (If	N is an	AS boundary router, look up the	"router" routing
	    table entry	associated with	Area A).  If no	entry exists for
	    N or if the	entry's	path type is "type 1 external" or "type
	    2 external", then install the inter-area path to N,	with
	    associated area Area A, cost IAC, next hop equal to	the list
	    of next hops to router BR, and Advertising router equal to
	    BR.

Moy			    Standards Track		      [Page 169]



RFC 2328		     OSPF Version 2		      April 1998

	(6) Else, if the paths present in the table are	intra-area
	    paths, do nothing with the LSA (intra-area paths are always
	    preferred).

	(7) Else, the paths present in the routing table are also
	    inter-area paths.  Install the new path through BR if it is
	    cheaper, overriding	the paths in the routing table.
	    Otherwise, if the new path is the same cost, add it	to the
	    list of paths that appear in the routing table entry.

    16.3.  Examining transit areas' summary-LSAs

	This step is only performed by area border routers attached to
	one or more non-backbone areas that are	capable	of carrying
	transit	traffic	(i.e., "transit	areas",	or those areas whose
	TransitCapability parameter has	been set to TRUE in Step 2 of
	the Dijkstra algorithm (see Section 16.1).

	The purpose of the calculation below is	to examine the transit
	areas to see whether they provide any better (shorter) paths
	than the paths previously calculated in	Sections 16.1 and 16.2.
	Any paths found	that are better	than or	equal to previously
	discovered paths are installed in the routing table.

	The calculation	also determines	the actual next	hop(s) for those
	destinations whose next	hop was	calculated as a	virtual	link in
	Sections 16.1 and 16.2.	 After completion of the calculation
	below, any paths calculated in Sections	16.1 and 16.2 that still
	have unresolved	virtual	next hops should be discarded.

	The calculation	proceeds as follows. All the transit areas'
	summary-LSAs are examined in turn.  Each such summary-LSA
	describes a route through a transit area Area A	to a Network N
	(N's address is	obtained by masking the	LSA's Link State ID with
	the network/subnet mask	contained in the body of the LSA) or in
	the case of a Type 4 summary-LSA, to an	AS boundary router N.
	Suppose	also that the summary-LSA was originated by an area
	border router BR.

	(1) If the cost	advertised by the summary-LSA is LSInfinity, or
	    if the LSA's LS age	is equal to MaxAge, then examine the
	    next LSA.

Moy			    Standards Track		      [Page 170]



RFC 2328		     OSPF Version 2		      April 1998

	(2) If the summary-LSA was originated by the calculating router
	    itself, examine the	next LSA.

	(3) Look up the	routing	table entry for	N. (If N is an AS
	    boundary router, look up the "router" routing table	entry
	    associated with the	backbone area).	If it does not exist, or
	    if the route type is other than intra-area or inter-area, or
	    if the area	associated with	the routing table entry	is not
	    the	backbone area, then examine the	next LSA. In other
	    words, this	calculation only updates backbone intra-area
	    routes found in Section 16.1 and inter-area	routes found in
	    Section 16.2.

	(4) Look up the	routing	table entry for	the advertising	router
	    BR associated with the Area	A. If it is unreachable, examine
	    the	next LSA. Otherwise, the cost to destination N is the
	    sum	of the cost in BR's Area A routing table entry and the
	    cost advertised in the LSA.	Call this cost IAC.

	(5) If this cost is less than the cost occurring in N's	routing
	    table entry, overwrite N's list of next hops with those used
	    for	BR, and	set N's	routing	table cost to IAC. Else, if IAC
	    is the same	as N's current cost, add BR's list of next hops
	    to N's list	of next	hops. In any case, the area associated
	    with N's routing table entry must remain the backbone area,
	    and	the path type (either intra-area or inter-area)	must
	    also remain	the same.

	It is important	to note	that the above calculation never makes
	unreachable destinations reachable, but	instead	just potentially
	finds better paths to already reachable	destinations.  The
	calculation installs any better	cost found into	the routing
	table entry, from which	it may be readvertised in summary-LSAs
	to other areas.

	As an example of the calculation, consider the Autonomous System
	pictured in Figure 17.	There is a single non-backbone area
	(Area 1) that physically divides the backbone into two separate
	pieces.	To maintain connectivity of the	backbone, a virtual link
	has been configured between routers RT1	and RT4. On the	right
	side of	the figure, Network N1 belongs to the backbone.	The
	dotted lines indicate that there is a much shorter intra-area

Moy			    Standards Track		      [Page 171]



RFC 2328		     OSPF Version 2		      April 1998

		      ........................
		      .	Area 1 (transit)     .		  +
		      .			     .		  |
		      .	     +---+1	   1+---+100	  |
		      .	     |RT2|----------|RT4|=========|
		      .	   1/+---+********* +---+	  |
		      .	   /*******	     .		  |
		      .	 1/*Virtual	     .		  |
		   1+---+/*  Link	     .	       Net|work
	     =======|RT1|*		     .		  | N1
		    +---+\		     .		  |
		      .	  \		     .		  |
		      .	   \		     .		  |
		      .	   1\+---+1	   1+---+20	  |
		      .	     |RT3|----------|RT5|=========|
		      .	     +---+	    +---+	  |
		      .			     .		  |
		      ........................		  +

		    Figure 17: Routing through transit areas

	backbone path between router RT5 and Network N1	(cost 20) than
	there is between Router	RT4 and	Network	N1 (cost 100). Both
	Router RT4 and Router RT5 will inject summary-LSAs for Network
	N1 into	Area 1.

	After the shortest-path	tree has been calculated for the
	backbone in Section 16.1, Router RT1 (left end of the virtual
	link) will have	calculated a path through Router RT4 for all
	data traffic destined for Network N1. However, since Router RT5
	is so much closer to Network N1, all routers internal to Area 1
	(e.g., Routers RT2 and RT3) will forward their Network N1
	traffic	towards	Router RT5, instead of RT4. And	indeed,	after
	examining Area 1's summary-LSAs	by the above calculation, Router
	RT1 will also forward Network N1 traffic towards RT5. Note that
	in this	example	the virtual link enables transit data traffic to
	be forwarded through Area 1, but the actual path the transit
	data traffic takes does	not follow the virtual link.  In other
	words, virtual links allow transit traffic to be forwarded
	through	an area, but do	not dictate the	precise	path that the
	traffic	will take.

Moy			    Standards Track		      [Page 172]



RFC 2328		     OSPF Version 2		      April 1998

    16.4.  Calculating AS external routes

	AS external routes are calculated by examining AS-external-LSAs.
	Each of	the AS-external-LSAs is	considered in turn.  Most AS-
	external-LSAs describe routes to specific IP destinations.  An
	AS-external-LSA	can also describe a default route for the
	Autonomous System (Destination ID = DefaultDestination,
	network/subnet mask = 0x00000000).  For	each AS-external-LSA:

	(1) If the cost	specified by the LSA is	LSInfinity, or if the
	    LSA's LS age is equal to MaxAge, then examine the next LSA.

	(2) If the LSA was originated by the calculating router	itself,
	    examine the	next LSA.

	(3) Call the destination described by the LSA N.  N's address is
	    obtained by	masking	the LSA's Link State ID	with the
	    network/subnet mask	contained in the body of the LSA.  Look
	    up the routing table entries (potentially one per attached
	    area) for the AS boundary router (ASBR) that originated the
	    LSA. If no entries exist for router	ASBR (i.e., ASBR is
	    unreachable), do nothing with this LSA and consider	the next
	    in the list.

	    Else, this LSA describes an	AS external path to destination
	    N.	Examine	the forwarding address specified in the	AS-
	    external-LSA.  This	indicates the IP address to which
	    packets for	the destination	should be forwarded.

	    If the forwarding address is set to	0.0.0.0, packets should
	    be sent to the ASBR	itself.	Among the multiple routing table
	    entries for	the ASBR, select the preferred entry as	follows.
	    If RFC1583Compatibility is set to "disabled", prune	the set
	    of routing table entries for the ASBR as described in
	    Section 16.4.1. In any case, among the remaining routing
	    table entries, select the routing table entry with the least
	    cost; when there are multiple least	cost routing table
	    entries the	entry whose associated area has	the largest OSPF
	    Area ID (when considered as	an unsigned 32-bit integer) is
	    chosen.

Moy			    Standards Track		      [Page 173]



RFC 2328		     OSPF Version 2		      April 1998

	    If the forwarding address is non-zero, look	up the
	    forwarding address in the routing table.[24] The matching
	    routing table entry	must specify an	intra-area or inter-area
	    path; if no	such path exists, do nothing with the LSA and
	    consider the next in the list.

	(4) Let	X be the cost specified	by the preferred routing table
	    entry for the ASBR/forwarding address, and Y the cost
	    specified in the LSA.  X is	in terms of the	link state
	    metric, and	Y is a type 1 or 2 external metric.

	(5) Look up the	routing	table entry for	the destination	N.  If
	    no entry exists for	N, install the AS external path	to N,
	    with next hop equal	to the list of next hops to the
	    forwarding address,	and advertising	router equal to	ASBR.
	    If the external metric type	is 1, then the path-type is set
	    to type 1 external and the cost is equal to	X+Y.  If the
	    external metric type is 2, the path-type is	set to type 2
	    external, the link state component of the route's cost is X,
	    and	the type 2 cost	is Y.

	(6) Compare the	AS external path described by the LSA with the
	    existing paths in N's routing table	entry, as follows. If
	    the	new path is preferred, it replaces the present paths in
	    N's	routing	table entry.  If the new path is of equal
	    preference,	it is added to N's routing table entry's list of
	    paths.

	    (a)	Intra-area and inter-area paths	are always preferred
		over AS	external paths.

	    (b)	Type 1 external	paths are always preferred over	type 2
		external paths.	When all paths are type	2 external
		paths, the paths with the smallest advertised type 2
		metric are always preferred.

	    (c)	If the new AS external path is still indistinguishable
		from the current paths in the N's routing table	entry,
		and RFC1583Compatibility is set	to "disabled", select
		the preferred paths based on the intra-AS paths	to the
		ASBR/forwarding	addresses, as specified	in Section
		16.4.1.

Moy			    Standards Track		      [Page 174]



RFC 2328		     OSPF Version 2		      April 1998

	    (d)	If the new AS external path is still indistinguishable
		from the current paths in the N's routing table	entry,
		select the preferred path based	on a least cost
		comparison.  Type 1 external paths are compared	by
		looking	at the sum of the distance to the forwarding
		address	and the	advertised type	1 metric (X+Y).	 Type 2
		external paths advertising equal type 2	metrics	are
		compared by looking at the distance to the forwarding
		addresses.

	16.4.1.	 External path preferences

	    When multiple intra-AS paths are available to
	    ASBRs/forwarding addresses,	the following rules indicate
	    which paths	are preferred. These rules apply when the same
	    ASBR is reachable through multiple areas, or when trying to
	    decide which of several AS-external-LSAs should be
	    preferred. In the former case the paths all	terminate at the
	    same ASBR, while in	the latter the paths terminate at
	    separate ASBRs/forwarding addresses. In either case, each
	    path is represented	by a separate routing table entry as
	    defined in Section 11.

	    This section only applies when RFC1583Compatibility	is set
	    to "disabled".

	    The	path preference	rules, stated from highest to lowest
	    preference,	are as follows.	Note that as a result of these
	    rules, there may still be multiple paths of	the highest
	    preference.	In this	case, the path to use must be determined
	    based on cost, as described	in Section 16.4.

	    o	Intra-area paths using non-backbone areas are always the
		most preferred.

	    o	The other paths, intra-area backbone paths and inter-
		area paths, are	of equal preference.

    16.5.  Incremental updates -- summary-LSAs

	When a new summary-LSA is received, it is not necessary	to
	recalculate the	entire routing table.  Call the	destination

Moy			    Standards Track		      [Page 175]



RFC 2328		     OSPF Version 2		      April 1998

	described by the summary-LSA N (N's address is obtained	by
	masking	the LSA's Link State ID	with the network/subnet	mask
	contained in the body of the LSA), and let Area	A be the area to
	which the LSA belongs. There are then two separate cases:

	Case 1:	Area A is the backbone and/or the router is not	an area
	    border router.
	    In this case, the following	calculations must be performed.
	    First, if there is presently an inter-area route to	the
	    destination	N, N's routing table entry is invalidated,
	    saving the entry's values for later	comparisons. Then the
	    calculation	in Section 16.2	is run again for the single
	    destination	N. In this calculation,	all of Area A's
	    summary-LSAs that describe a route to N are	examined.  In
	    addition, if the router is an area border router attached to
	    one	or more	transit	areas, the calculation in Section 16.3
	    must be run	again for the single destination.  If the
	    results of these calculations have changed the cost/path to
	    an AS boundary router (as would be the case	for a Type 4
	    summary-LSA) or to any forwarding addresses, all AS-
	    external-LSAs will have to be reexamined by	rerunning the
	    calculation	in Section 16.4.  Otherwise, if	N is now newly
	    unreachable, the calculation in Section 16.4 must be rerun
	    for	the single destination N, in case an alternate external
	    route to N exists.

	Case 2:	Area A is a transit area and the router	is an area
	    border router.
	    In this case, the following	calculations must be performed.
	    First, if N's routing table	entry presently	contains one or
	    more inter-area paths that utilize the transit area	Area A,
	    these paths	should be removed. If this removes all paths
	    from the routing table entry, the entry should be
	    invalidated.  The entry's old values should	be saved for
	    later comparisons. Next the	calculation in Section 16.3 must
	    be run again for the single	destination N. If the results of
	    this calculation have caused the cost to N to increase, the
	    complete routing table calculation must be rerun starting
	    with the Dijkstra algorithm	specified in Section 16.1.
	    Otherwise, if the cost/path	to an AS boundary router (as
	    would be the case for a Type 4 summary-LSA)	or to any
	    forwarding addresses has changed, all AS-external-LSAs will

Moy			    Standards Track		      [Page 176]



RFC 2328		     OSPF Version 2		      April 1998

	    have to be reexamined by rerunning the calculation in
	    Section 16.4.  Otherwise, if N is now newly	unreachable, the
	    calculation	in Section 16.4	must be	rerun for the single
	    destination	N, in case an alternate	external route to N
	    exists.

    16.6.  Incremental updates -- AS-external-LSAs

	When a new AS-external-LSA is received,	it is not necessary to
	recalculate the	entire routing table.  Call the	destination
	described by the AS-external-LSA N.  N's address is obtained by
	masking	the LSA's Link State ID	with the network/subnet	mask
	contained in the body of the LSA. If there is already an intra-
	area or	inter-area route to the	destination, no	recalculation is
	necessary (internal routes take	precedence).

	Otherwise, the procedure in Section 16.4 will have to be
	performed, but only for	those AS-external-LSAs whose destination
	is N.  Before this procedure is	performed, the present routing
	table entry for	N should be invalidated.

    16.7.  Events generated as a result	of routing table changes

	Changes	to routing table entries sometimes cause the OSPF area
	border routers to take additional actions.  These routers need
	to act on the following	routing	table changes:

	o   The	cost or	path type of a routing table entry has changed.
	    If the destination described by this entry is a Network or
	    AS boundary	router,	and this is not	simply a change	of AS
	    external routes, new summary-LSAs may have to be generated
	    (potentially one for each attached area, including the
	    backbone).	See Section 12.4.3 for more information.  If a
	    previously advertised entry	has been deleted, or is	no
	    longer advertisable	to a particular	area, the LSA must be
	    flushed from the routing domain by setting its LS age to
	    MaxAge and reflooding (see Section 14.1).

	o   A routing table entry associated with a configured virtual
	    link has changed.  The destination of such a routing table
	    entry is an	area border router.  The change	indicates a
	    modification to the	virtual	link's cost or viability.

Moy			    Standards Track		      [Page 177]



RFC 2328		     OSPF Version 2		      April 1998

	    If the entry indicates that	the area border	router is newly
	    reachable, the corresponding virtual link is now
	    operational.  An InterfaceUp event should be generated for
	    the	virtual	link, which will cause a virtual adjacency to
	    begin to form (see Section 10.3).  At this time the	virtual
	    link's IP interface	address	and the	virtual	neighbor's
	    Neighbor IP	address	are also calculated.

	    If the entry indicates that	the area border	router is no
	    longer reachable, the virtual link and its associated
	    adjacency should be	destroyed.  This means an InterfaceDown
	    event should be generated for the associated virtual link.

	    If the cost	of the entry has changed, and there is a fully
	    established	virtual	adjacency, a new router-LSA for	the
	    backbone must be originated.  This in turn may cause further
	    routing table changes.

    16.8.  Equal-cost multipath

	The OSPF protocol maintains multiple equal-cost	routes to all
	destinations.  This can	be seen	in the steps used above	to
	calculate the routing table, and in the	definition of the
	routing	table structure.

	Each one of the	multiple routes	will be	of the same type
	(intra-area, inter-area, type 1	external or type 2 external),
	cost, and will have the	same associated	area.  However,	each
	route may specify a separate next hop and Advertising router.

	There is no requirement	that a router running OSPF keep	track of
	all possible equal-cost	routes to a destination.  An
	implementation may choose to keep only a fixed number of routes
	to any given destination.  This	does not affect	any of the
	algorithms presented in	this specification.

Moy			    Standards Track		      [Page 178]



RFC 2328		     OSPF Version 2		      April 1998

Footnotes

    [1]The graph's vertices represent either routers, transit networks,
    or stub networks.  Since routers may belong	to multiple areas, it is
    not	possible to color the graph's vertices.

    [2]It is possible for all of a router's interfaces to be unnumbered
    point-to-point links.  In this case, an IP address must be assigned
    to the router.  This address will then be advertised in the	router's
    router-LSA as a host route.

    [3]Note that in these cases	both interfaces, the non-virtual and the
    virtual, would have	the same IP address.

    [4]Note that no host route is generated for, and no	IP packets can
    be addressed to, interfaces	to unnumbered point-to-point networks.
    This is regardless of such an interface's state.

    [5]It is instructive to see	what happens when the Designated Router
    for	the network crashes.  Call the Designated Router for the network
    RT1, and the Backup	Designated Router RT2.	If Router RT1 crashes
    (or	maybe its interface to the network dies), the other routers on
    the	network	will detect RT1's absence within RouterDeadInterval
    seconds.  All routers may not detect this at precisely the same
    time; the routers that detect RT1's	absence	before RT2 does	will,
    for	a time,	select RT2 to be both Designated Router	and Backup
    Designated Router.	When RT2 detects that RT1 is gone it will move
    itself to Designated Router.  At this time,	the remaining router
    having highest Router Priority will	be selected as Backup Designated
    Router.

    [6]On point-to-point networks, the lower level protocols indicate
    whether the	neighbor is up and running.  Likewise, existence of the
    neighbor on	virtual	links is indicated by the routing table
    calculation.  However, in both these cases,	the Hello Protocol is
    still used.	 This ensures that communication between the neighbors
    is bidirectional, and that each of the neighbors has a functioning
    routing protocol layer.

    [7]When the	identity of the	Designated Router is changing, it may be
    quite common for a neighbor	in this	state to send the router a

Moy			    Standards Track		      [Page 179]



RFC 2328		     OSPF Version 2		      April 1998

    Database Description packet; this means that there is some momentary
    disagreement on the	Designated Router's identity.

    [8]Note that it is possible	for a router to	resynchronize any of its
    fully established adjacencies by setting the adjacency's state back
    to ExStart.	 This will cause the other end of the adjacency	to
    process a SeqNumberMismatch	event, and therefore to	also go	back to
    ExStart state.

    [9]The address space of IP networks	and the	address	space of OSPF
    Router IDs may overlap.  That is, a	network	may have an IP address
    which is identical (when considered	as a 32-bit number) to some
    router's Router ID.

    [10]"Discard" entries are necessary	to ensure that route
    summarization at area boundaries will not cause packet looping.

    [11]It is assumed that, for	two different address ranges matching
    the	destination, one range is more specific	than the other.	Non-
    contiguous subnet masks can	be configured to violate this
    assumption.	Such subnet mask configurations	cannot be handled by the
    OSPF protocol.

    [12]MaxAgeDiff is an architectural constant.  It indicates the
    maximum dispersion of ages,	in seconds, that can occur for a single
    LSA	instance as it is flooded throughout the routing domain.  If two
    LSAs differ	by more	than this, they	are assumed to be different
    instances of the same LSA.	This can occur when a router restarts
    and	loses track of the LSA's previous LS sequence number.  See
    Section 13.4 for more details.

    [13]When two LSAs have different LS	checksums, they	are assumed to
    be separate	instances.  This can occur when	a router restarts, and
    loses track	of the LSA's previous LS sequence number.  In the case
    where the two LSAs have the	same LS	sequence number, it is not
    possible to	determine which	LSA is actually	newer.	However, if the
    wrong LSA is accepted as newer, the	originating router will	simply
    originate another instance.	 See Section 13.4 for further details.

    [14]There is one instance where a lookup must be done based	on
    partial information.  This is during the routing table calculation,
    when a network-LSA must be found based solely on its Link State ID.

Moy			    Standards Track		      [Page 180]



RFC 2328		     OSPF Version 2		      April 1998

    The	lookup in this case is still well defined, since no two
    network-LSAs can have the same Link	State ID.

    [15]This is	the way	RFC 1583 specified point-to-point
    representation.  It	has three advantages: a) it does not require
    allocating a subnet	to the point-to-point link, b) it tends	to bias
    the	routing	so that	packets	destined for the point-to-point
    interface will actually be received	over the interface (which is
    useful for diagnostic purposes) and	c) it allows network
    bootstrapping of a neighbor, without requiring that	the bootstrap
    program contain an OSPF implementation.

    [16]This is	the more traditional point-to-point representation used
    by protocols such as RIP.

    [17]This clause covers the case: Inter-area	routes are not
    summarized to the backbone.	 This is because inter-area routes are
    always associated with the backbone	area.

    [18]This clause is only invoked when a non-backbone	Area A supports
    transit data traffic (i.e.,	has TransitCapability set to TRUE).  For
    example, in	the area configuration of Figure 6, Area 2 can support
    transit traffic due	to the configured virtual link between Routers
    RT10 and RT11. As a	result,	Router RT11 need only originate	a single
    summary-LSA	into Area 2 (having the	collapsed destination N9-
    N11,H1), since all of Router RT11's	other eligible routes have next
    hops belonging to Area 2 itself (and as such only need be advertised
    by other area border routers; in this case,	Routers	RT10 and RT7).

    [19]By keeping more	information in the routing table, it is	possible
    for	an implementation to recalculate the shortest path tree	for only
    a single area.  In fact, there are incremental algorithms that allow
    an implementation to recalculate only a portion of a single	area's
    shortest path tree [Ref1].	However, these algorithms are beyond the
    scope of this specification.

    [20]This is	how the	Link state request list	is emptied, which
    eventually causes the neighbor state to transition to Full.	 See
    Section 10.9 for more details.

    [21]It should be a relatively rare occurrence for an LSA's LS age to
    reach MaxAge in this fashion.  Usually, the	LSA will be replaced by

Moy			    Standards Track		      [Page 181]



RFC 2328		     OSPF Version 2		      April 1998

    a more recent instance before it ages out.

    [22]Strictly speaking, because of equal-cost multipath, the
    algorithm does not create a	tree.  We continue to use the "tree"
    terminology	because	that is	what occurs most often in the existing
    literature.

    [23]Note that the presence of any link back	to V is	sufficient; it
    need not be	the matching half of the link under consideration from V
    to W. This is enough to ensure that, before	data traffic flows
    between a pair of neighboring routers, their link state databases
    will be synchronized.

    [24]When the forwarding address is non-zero, it should point to a
    router belonging to	another	Autonomous System.  See	Section	12.4.4
    for	more details.

Moy			    Standards Track		      [Page 182]



RFC 2328		     OSPF Version 2		      April 1998

References

    [Ref1]  McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing
	    Algorithm Improvements", BBN Technical Report 3803,	April
	    1978.

    [Ref2]  Digital Equipment Corporation, "Information	processing
	    systems -- Data communications -- Intermediate System to
	    Intermediate System	Intra-Domain Routing Protocol",	October
	    1987.

    [Ref3]  McQuillan, J., et.al., "The	New Routing Algorithm for the
	    ARPANET", IEEE Transactions	on Communications, May 1980.

    [Ref4]  Perlman, R., "Fault-Tolerant Broadcast of Routing
	    Information", Computer Networks, December 1983.

    [Ref5]  Postel, J.,	"Internet Protocol", STD 5, RFC	791, September
	    1981.

    [Ref6]  McKenzie, A., "ISO Transport Protocol specification	ISO DP
	    8073", RFC 905, April 1984.

    [Ref7]  Deering, S., "Host extensions for IP multicasting",	STD 5,
	    RFC	1112, May 1988.

    [Ref8]  McCloghrie,	K., and	M. Rose, "Management Information Base
	    for	network	management of TCP/IP-based internets: MIB-II",
	    STD	17, RFC	1213, March 1991.

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

    [Ref10] Fuller, V.,	T. Li, J. Yu, and K. Varadhan, "Classless
	    Inter-Domain Routing (CIDR): an Address Assignment and
	    Aggregation	Strategy", RFC1519, September 1993.

    [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
	    1700, October 1994.

    [Ref12] Almquist, P., "Type	of Service in the Internet Protocol
	    Suite", RFC	1349, July 1992.

Moy			    Standards Track		      [Page 183]



RFC 2328		     OSPF Version 2		      April 1998

    [Ref13] Leiner, B.,	et.al.,	"The DARPA Internet Protocol Suite", DDN
	    Protocol Handbook, April 1985.

    [Ref14] Bradley, T., and C.	Brown, "Inverse	Address	Resolution
	    Protocol", RFC 1293, January 1992.

    [Ref15] deSouza, O., and M.	Rodrigues, "Guidelines for Running OSPF
	    Over Frame Relay Networks",	RFC 1586, March	1994.

    [Ref16] Bellovin, S., "Security Problems in	the TCP/IP Protocol
	    Suite", ACM	Computer Communications	Review,	Volume 19,
	    Number 2, pp. 32-38, April 1989.

    [Ref17] Rivest, R.,	"The MD5 Message-Digest	Algorithm", RFC	1321,
	    April 1992.

    [Ref18] Moy, J., "Multicast	Extensions to OSPF", RFC 1584, March
	    1994.

    [Ref19] Coltun, R.,	and V. Fuller, "The OSPF NSSA Option", RFC 1587,
	    March 1994.

    [Ref20] Ferguson, D., "The OSPF External Attributes	LSA", work in
	    progress.

    [Ref21] Moy, J., "Extending	OSPF to	Support	Demand Circuits", RFC
	    1793, April	1995.

    [Ref22] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
	    November 1990.

    [Ref23] Rekhter, Y., and T.	Li, "A Border Gateway Protocol 4 (BGP-
	    4)", RFC 1771, March 1995.

    [Ref24] Hinden, R.,	"Internet Routing Protocol Standardization
	    Criteria", BBN, October 1991.

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

    [Ref26] Rosen, E., "Vulnerabilities	of Network Control Protocols: An
	    Example", Computer Communication Review, July 1981.

Moy			    Standards Track		      [Page 184]



RFC 2328		     OSPF Version 2		      April 1998

A. OSPF	data formats

    This appendix describes the	format of OSPF protocol	packets	and OSPF
    LSAs.  The OSPF protocol runs directly over	the IP network layer.
    Before any data formats are	described, the details of the OSPF
    encapsulation are explained.

    Next the OSPF Options field	is described.  This field describes
    various capabilities that may or may not be	supported by pieces of
    the	OSPF routing domain. The OSPF Options field is contained in OSPF
    Hello packets, Database Description	packets	and in OSPF LSAs.

    OSPF packet	formats	are detailed in	Section	A.3.  A	description of
    OSPF LSAs appears in Section A.4.

A.1 Encapsulation of OSPF packets

    OSPF runs directly over the	Internet Protocol's network layer.  OSPF
    packets are	therefore encapsulated solely by IP and	local data-link
    headers.

    OSPF does not define a way to fragment its protocol	packets, and
    depends on IP fragmentation	when transmitting packets larger than
    the	network	MTU. If	necessary, the length of OSPF packets can be up
    to 65,535 bytes (including the IP header).	The OSPF packet	types
    that are likely to be large	(Database Description Packets, Link
    State Request, Link	State Update, and Link State Acknowledgment
    packets) can usually be split into several separate	protocol
    packets, without loss of functionality.  This is recommended; IP
    fragmentation should be avoided whenever possible.	Using this
    reasoning, an attempt should be made to limit the sizes of OSPF
    packets sent over virtual links to 576 bytes unless	Path MTU
    Discovery is being performed (see [Ref22]).

    The	other important	features of OSPF's IP encapsulation are:

    o	Use of IP multicast.  Some OSPF	messages are multicast,	when
	sent over broadcast networks.  Two distinct IP multicast
	addresses are used.  Packets sent to these multicast addresses
	should never be	forwarded; they	are meant to travel a single hop
	only.  To ensure that these packets will not travel multiple
	hops, their IP TTL must	be set to 1.

Moy			    Standards Track		      [Page 185]



RFC 2328		     OSPF Version 2		      April 1998

	AllSPFRouters
	    This multicast address has been assigned the value
	    224.0.0.5.	All routers running OSPF should	be prepared to
	    receive packets sent to this address.  Hello packets are
	    always sent	to this	destination.  Also, certain OSPF
	    protocol packets are sent to this address during the
	    flooding procedure.

	AllDRouters
	    This multicast address has been assigned the value
	    224.0.0.6.	Both the Designated Router and Backup Designated
	    Router must	be prepared to receive packets destined	to this
	    address.  Certain OSPF protocol packets are	sent to	this
	    address during the flooding	procedure.

    o	OSPF is	IP protocol number 89.	This number has	been registered
	with the Network Information Center.  IP protocol number
	assignments are	documented in [Ref11].

    o	All OSPF routing protocol packets are sent using the normal
	service	TOS value of binary 0000 defined in [Ref12].

    o	Routing	protocol packets are sent with IP precedence set to
	Internetwork Control.  OSPF protocol packets should be given
	precedence over	regular	IP data	traffic, in both sending and
	receiving.  Setting the	IP precedence field in the IP header to
	Internetwork Control [Ref5] may	help implement this objective.

Moy			    Standards Track		      [Page 186]



RFC 2328		     OSPF Version 2		      April 1998

A.2 The	Options	field

    The	OSPF Options field is present in OSPF Hello packets, Database
    Description	packets	and all	LSAs.  The Options field enables OSPF
    routers to support (or not support)	optional capabilities, and to
    communicate	their capability level to other	OSPF routers.  Through
    this mechanism routers of differing	capabilities can be mixed within
    an OSPF routing domain.

    When used in Hello packets,	the Options field allows a router to
    reject a neighbor because of a capability mismatch.	 Alternatively,
    when capabilities are exchanged in Database	Description packets a
    router can choose not to forward certain LSAs to a neighbor	because
    of its reduced functionality.  Lastly, listing capabilities	in LSAs
    allows routers to forward traffic around reduced functionality
    routers, by	excluding them from parts of the routing table
    calculation.

    Five bits of the OSPF Options field	have been assigned, although
    only one (the E-bit) is described completely by this memo. Each bit
    is described briefly below.	Routers	should reset (i.e.  clear)
    unrecognized bits in the Options field when	sending	Hello packets or
    Database Description packets and when originating LSAs. Conversely,
    routers encountering unrecognized Option bits in received Hello
    Packets, Database Description packets or LSAs should ignore	the
    capability and process the packet/LSA normally.

		       +------------------------------------+
		       | * | * | DC | EA | N/P | MC | E	| * |
		       +------------------------------------+

			     The Options field

    E-bit
	This bit describes the way AS-external-LSAs are	flooded, as
	described in Sections 3.6, 9.5,	10.8 and 12.1.2	of this	memo.

    MC-bit
	This bit describes whether IP multicast	datagrams are forwarded
	according to the specifications	in [Ref18].

Moy			    Standards Track		      [Page 187]



RFC 2328		     OSPF Version 2		      April 1998

    N/P-bit
	This bit describes the handling	of Type-7 LSAs,	as specified in
	[Ref19].

    EA-bit
	This bit describes the router's	willingness to receive and
	forward	External-Attributes-LSAs, as specified in [Ref20].

    DC-bit
	This bit describes the router's	handling of demand circuits, as
	specified in [Ref21].

Moy			    Standards Track		      [Page 188]



RFC 2328		     OSPF Version 2		      April 1998

A.3 OSPF Packet	Formats

    There are five distinct OSPF packet	types.	All OSPF packet	types
    begin with a standard 24 byte header.  This	header is described
    first.  Each packet	type is	then described in a succeeding section.
    In these sections each packet's division into fields is displayed,
    and	then the field definitions are enumerated.

    All	OSPF packet types (other than the OSPF Hello packets) deal with
    lists of LSAs.  For	example, Link State Update packets implement the
    flooding of	LSAs throughout	the OSPF routing domain.  Because of
    this, OSPF protocol	packets	cannot be parsed unless	the format of
    LSAs is also understood.  The format of LSAs is described in Section
    A.4.

    The	receive	processing of OSPF packets is detailed in Section 8.2.
    The	sending	of OSPF	packets	is explained in	Section	8.1.

Moy			    Standards Track		      [Page 189]



RFC 2328		     OSPF Version 2		      April 1998

A.3.1 The OSPF packet header

    Every OSPF packet starts with a standard 24	byte header.  This
    header contains all	the information	necessary to determine whether
    the	packet should be accepted for further processing.  This
    determination is described in Section 8.2 of the specification.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |     Type      |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Version #
	The OSPF version number.  This specification documents version 2
	of the protocol.

    Type
	The OSPF packet	types are as follows. See Sections A.3.2 through
	A.3.6 for details.

Moy			    Standards Track		      [Page 190]



RFC 2328		     OSPF Version 2		      April 1998

			  Type	 Description
			  ________________________________
			  1	 Hello
			  2	 Database Description
			  3	 Link State Request
			  4	 Link State Update
			  5	 Link State Acknowledgment

    Packet length
	The length of the OSPF protocol	packet in bytes.  This length
	includes the standard OSPF header.

    Router ID
	The Router ID of the packet's source.

    Area ID
	A 32 bit number	identifying the	area that this packet belongs
	to.  All OSPF packets are associated with a single area.  Most
	travel a single	hop only.  Packets travelling over a virtual
	link are labelled with the backbone Area ID of 0.0.0.0.

    Checksum
	The standard IP	checksum of the	entire contents	of the packet,
	starting with the OSPF packet header but excluding the 64-bit
	authentication field.  This checksum is	calculated as the 16-bit
	one's complement of the	one's complement sum of	all the	16-bit
	words in the packet, excepting the authentication field.  If the
	packet's length	is not an integral number of 16-bit words, the
	packet is padded with a	byte of	zero before checksumming.  The
	checksum is considered to be part of the packet	authentication
	procedure; for some authentication types the checksum
	calculation is omitted.

    AuType
	Identifies the authentication procedure	to be used for the
	packet.	 Authentication	is discussed in	Appendix D of the
	specification.	Consult	Appendix D for a list of the currently
	defined	authentication types.

Moy			    Standards Track		      [Page 191]



RFC 2328		     OSPF Version 2		      April 1998

    Authentication
	A 64-bit field for use by the authentication scheme. See
	Appendix D for details.

Moy			    Standards Track		      [Page 192]



RFC 2328		     OSPF Version 2		      April 1998

A.3.2 The Hello	packet

    Hello packets are OSPF packet type 1.  These packets are sent
    periodically on all	interfaces (including virtual links) in	order to
    establish and maintain neighbor relationships.  In addition, Hello
    Packets are	multicast on those physical networks having a multicast
    or broadcast capability, enabling dynamic discovery	of neighboring
    routers.

    All	routers	connected to a common network must agree on certain
    parameters (Network	mask, HelloInterval and	RouterDeadInterval).
    These parameters are included in Hello packets, so that differences
    can	inhibit	the forming of neighbor	relationships.	A detailed
    explanation	of the receive processing for Hello packets is presented
    in Section 10.5.  The sending of Hello packets is covered in Section
    9.5.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       1       |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Network	Mask			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 HelloInterval	       |    Options    |    Rtr	Pri    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     RouterDeadInterval			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		      Designated Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		   Backup Designated Router		       |

Moy			    Standards Track		      [Page 193]



RFC 2328		     OSPF Version 2		      April 1998

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Neighbor			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

    Network mask
	The network mask associated with this interface.  For example,
	if the interface is to a class B network whose third byte is
	used for subnetting, the network mask is 0xffffff00.

    Options
	The optional capabilities supported by the router, as documented
	in Section A.2.

    HelloInterval
	The number of seconds between this router's Hello packets.

    Rtr	Pri
	This router's Router Priority.	Used in	(Backup) Designated
	Router election.  If set to 0, the router will be ineligible to
	become (Backup)	Designated Router.

    RouterDeadInterval
	The number of seconds before declaring a silent	router down.

    Designated Router
	The identity of	the Designated Router for this network,	in the
	view of	the sending router.  The Designated Router is identified
	here by	its IP interface address on the	network.  Set to 0.0.0.0
	if there is no Designated Router.

    Backup Designated Router
	The identity of	the Backup Designated Router for this network,
	in the view of the sending router.  The	Backup Designated Router
	is identified here by its IP interface address on the network.
	Set to 0.0.0.0 if there	is no Backup Designated	Router.

    Neighbor
	The Router IDs of each router from whom	valid Hello packets have
	been seen recently on the network.  Recently means in the last
	RouterDeadInterval seconds.

Moy			    Standards Track		      [Page 194]



RFC 2328		     OSPF Version 2		      April 1998

A.3.3 The Database Description packet

    Database Description packets are OSPF packet type 2.  These	packets
    are	exchanged when an adjacency is being initialized.  They	describe
    the	contents of the	link-state database.  Multiple packets may be
    used to describe the database.  For	this purpose a poll-response
    procedure is used.	One of the routers is designated to be the
    master, the	other the slave.  The master sends Database Description
    packets (polls) which are acknowledged by Database Description
    packets sent by the	slave (responses).  The	responses are linked to
    the	polls via the packets' DD sequence numbers.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       2       |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 Interface MTU	       |    Options    |0|0|0|0|0|I|M|MS
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     DD	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |							       |
       +-							      -+
       |							       |
       +-		       An LSA Header			      -+
       |							       |
       +-							      -+
       |							       |
       +-							      -+
       |							       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

Moy			    Standards Track		      [Page 195]



RFC 2328		     OSPF Version 2		      April 1998

    The	format of the Database Description packet is very similar to
    both the Link State	Request	and Link State Acknowledgment packets.
    The	main part of all three is a list of items, each	item describing
    a piece of the link-state database.	 The sending of	Database
    Description	Packets	is documented in Section 10.8.	The reception of
    Database Description packets is documented in Section 10.6.

    Interface MTU
	The size in bytes of the largest IP datagram that can be sent
	out the	associated interface, without fragmentation.  The MTUs
	of common Internet link	types can be found in Table 7-1	of
	[Ref22]. Interface MTU should be set to	0 in Database
	Description packets sent over virtual links.

    Options
	The optional capabilities supported by the router, as documented
	in Section A.2.

    I-bit
	The Init bit.  When set	to 1, this packet is the first in the
	sequence of Database Description Packets.

    M-bit
	The More bit.  When set	to 1, it indicates that	more Database
	Description Packets are	to follow.

    MS-bit
	The Master/Slave bit.  When set	to 1, it indicates that	the
	router is the master during the	Database Exchange process.
	Otherwise, the router is the slave.

    DD sequence	number
	Used to	sequence the collection	of Database Description	Packets.
	The initial value (indicated by	the Init bit being set)	should
	be unique.  The	DD sequence number then	increments until the
	complete database description has been sent.

    The	rest of	the packet consists of a (possibly partial) list of the
    link-state database's pieces.  Each	LSA in the database is described
    by its LSA header.	The LSA	header is documented in	Section	A.4.1.
    It contains	all the	information required to	uniquely identify both
    the	LSA and	the LSA's current instance.

Moy			    Standards Track		      [Page 196]



RFC 2328		     OSPF Version 2		      April 1998

A.3.4 The Link State Request packet

    Link State Request packets are OSPF	packet type 3.	After exchanging
    Database Description packets with a	neighboring router, a router may
    find that parts of its link-state database are out-of-date.	 The
    Link State Request packet is used to request the pieces of the
    neighbor's database	that are more up-to-date.  Multiple Link State
    Request packets may	need to	be used.

    A router that sends	a Link State Request packet has	in mind	the
    precise instance of	the database pieces it is requesting. Each
    instance is	defined	by its LS sequence number, LS checksum,	and LS
    age, although these	fields are not specified in the	Link State
    Request Packet itself.  The	router may receive even	more recent
    instances in response.

    The	sending	of Link	State Request packets is documented in Section
    10.9.  The reception of Link State Request packets is documented in
    Section 10.7.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       3       |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  LS type			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

Moy			    Standards Track		      [Page 197]



RFC 2328		     OSPF Version 2		      April 1998

    Each LSA requested is specified by its LS type, Link State ID, and
    Advertising	Router.	 This uniquely identifies the LSA, but not its
    instance.  Link State Request packets are understood to be requests
    for	the most recent	instance (whatever that	might be).

Moy			    Standards Track		      [Page 198]



RFC 2328		     OSPF Version 2		      April 1998

A.3.5 The Link State Update packet

    Link State Update packets are OSPF packet type 4.  These packets
    implement the flooding of LSAs.  Each Link State Update packet
    carries a collection of LSAs one hop further from their origin.
    Several LSAs may be	included in a single packet.

    Link State Update packets are multicast on those physical networks
    that support multicast/broadcast.  In order	to make	the flooding
    procedure reliable,	flooded	LSAs are acknowledged in Link State
    Acknowledgment packets.  If	retransmission of certain LSAs is
    necessary, the retransmitted LSAs are always sent directly to the
    neighbor.  For more	information on the reliable flooding of	LSAs,
    consult Section 13.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       4       |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			    # LSAs			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |							       |
       +-							     +-+
       |			     LSAs			       |
       +-							     +-+
       |			      ...			       |

Moy			    Standards Track		      [Page 199]



RFC 2328		     OSPF Version 2		      April 1998

    # LSAs
	The number of LSAs included in this update.

    The	body of	the Link State Update packet consists of a list	of LSAs.
    Each LSA begins with a common 20 byte header, described in Section
    A.4.1. Detailed formats of the different types of LSAs are described
    in Section A.4.

Moy			    Standards Track		      [Page 200]



RFC 2328		     OSPF Version 2		      April 1998

A.3.6 The Link State Acknowledgment packet

    Link State Acknowledgment Packets are OSPF packet type 5.  To make
    the	flooding of LSAs reliable, flooded LSAs	are explicitly
    acknowledged.  This	acknowledgment is accomplished through the
    sending and	receiving of Link State	Acknowledgment packets.
    Multiple LSAs can be acknowledged in a single Link State
    Acknowledgment packet.

    Depending on the state of the sending interface and	the sender of
    the	corresponding Link State Update	packet,	a Link State
    Acknowledgment packet is sent either to the	multicast address
    AllSPFRouters, to the multicast address AllDRouters, or as a
    unicast.  The sending of Link State	Acknowledgement	packets	is
    documented in Section 13.5.	 The reception of Link State
    Acknowledgement packets is documented in Section 13.7.

    The	format of this packet is similar to that of the	Data Description
    packet.  The body of both packets is simply	a list of LSA headers.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Version #   |       5       |	 Packet	length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Router ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			   Area	ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	   Checksum	       |	     AuType	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		       Authentication			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |							       |
       +-							      -+
       |							       |
       +-			  An LSA Header			      -+
       |							       |
       +-							      -+

Moy			    Standards Track		      [Page 201]



RFC 2328		     OSPF Version 2		      April 1998

       |							       |
       +-							      -+
       |							       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

    Each acknowledged LSA is described by its LSA header.  The LSA
    header is documented in Section A.4.1.  It contains	all the
    information	required to uniquely identify both the LSA and the LSA's
    current instance.

Moy			    Standards Track		      [Page 202]



RFC 2328		     OSPF Version 2		      April 1998

A.4 LSA	formats

    This memo defines five distinct types of LSAs.  Each LSA begins with
    a standard 20 byte LSA header.  This header	is explained in	Section
    A.4.1.  Succeeding sections	then diagram the separate LSA types.

    Each LSA describes a piece of the OSPF routing domain.  Every router
    originates a router-LSA.  In addition, whenever the	router is
    elected Designated Router, it originates a network-LSA.  Other types
    of LSAs may	also be	originated (see	Section	12.4).	All LSAs are
    then flooded throughout the	OSPF routing domain.  The flooding
    algorithm is reliable, ensuring that all routers have the same
    collection of LSAs.	 (See Section 13 for more information concerning
    the	flooding algorithm).  This collection of LSAs is called	the
    link-state database.

    From the link state	database, each router constructs a shortest path
    tree with itself as	root.  This yields a routing table (see	Section
    11).  For the details of the routing table build process, see
    Section 16.

Moy			    Standards Track		      [Page 203]



RFC 2328		     OSPF Version 2		      April 1998

A.4.1 The LSA header

    All	LSAs begin with	a common 20 byte header.  This header contains
    enough information to uniquely identify the	LSA (LS	type, Link State
    ID,	and Advertising	Router).  Multiple instances of	the LSA	may
    exist in the routing domain	at the same time.  It is then necessary
    to determine which instance	is more	recent.	 This is accomplished by
    examining the LS age, LS sequence number and LS checksum fields that
    are	also contained in the LSA header.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	    LS age	       |    Options    |    LS type    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     LS	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 LS checksum	       |	     length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    LS age
	The time in seconds since the LSA was originated.

    Options
	The optional capabilities supported by the described portion of
	the routing domain.  OSPF's optional capabilities are documented
	in Section A.2.

    LS type
	The type of the	LSA.  Each LSA type has	a separate advertisement
	format.	 The LSA types defined in this memo are	as follows (see
	Section	12.1.3 for further explanation):

Moy			    Standards Track		      [Page 204]



RFC 2328		     OSPF Version 2		      April 1998

			LS Type	  Description
			___________________________________
			1	  Router-LSAs
			2	  Network-LSAs
			3	  Summary-LSAs (IP network)
			4	  Summary-LSAs (ASBR)
			5	  AS-external-LSAs

    Link State ID
	This field identifies the portion of the internet environment
	that is	being described	by the LSA.  The contents of this field
	depend on the LSA's LS type.  For example, in network-LSAs the
	Link State ID is set to	the IP interface address of the
	network's Designated Router (from which	the network's IP address
	can be derived).  The Link State ID is further discussed in
	Section	12.1.4.

    Advertising	Router
	The Router ID of the router that originated the	LSA.  For
	example, in network-LSAs this field is equal to	the Router ID of
	the network's Designated Router.

    LS sequence	number
	Detects	old or duplicate LSAs.	Successive instances of	an LSA
	are given successive LS	sequence numbers.  See Section 12.1.6
	for more details.

    LS checksum
	The Fletcher checksum of the complete contents of the LSA,
	including the LSA header but excluding the LS age field. See
	Section	12.1.7 for more	details.

    length
	The length in bytes of the LSA.	 This includes the 20 byte LSA
	header.

Moy			    Standards Track		      [Page 205]



RFC 2328		     OSPF Version 2		      April 1998

A.4.2 Router-LSAs

    Router-LSAs	are the	Type 1 LSAs.  Each router in an	area originates
    a router-LSA.  The LSA describes the state and cost	of the router's
    links (i.e., interfaces) to	the area.  All of the router's links to
    the	area must be described in a single router-LSA.	For details
    concerning the construction	of router-LSAs,	see Section 12.4.1.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	    LS age	       |     Options   |       1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     LS	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 LS checksum	       |	     length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    0	 |V|E|B|	0      |	    # links	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Link ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			 Link Data			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |	    metric	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |	0      |	  TOS  metric	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			  Link ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			 Link Data			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

Moy			    Standards Track		      [Page 206]



RFC 2328		     OSPF Version 2		      April 1998

    In router-LSAs, the	Link State ID field is set to the router's OSPF
    Router ID. Router-LSAs are flooded throughout a single area	only.

    bit	V
	When set, the router is	an endpoint of one or more fully
	adjacent virtual links having the described area as Transit area
	(V is for virtual link endpoint).

    bit	E
	When set, the router is	an AS boundary router (E is for
	external).

    bit	B
	When set, the router is	an area	border router (B is for	border).

    # links
	The number of router links described in	this LSA.  This	must be
	the total collection of	router links (i.e., interfaces)	to the
	area.

    The	following fields are used to describe each router link (i.e.,
    interface).	Each router link is typed (see the below Type field).
    The	Type field indicates the kind of link being described.	It may
    be a link to a transit network, to another router or to a stub
    network.  The values of all	the other fields describing a router
    link depend	on the link's Type.  For example, each link has	an
    associated 32-bit Link Data	field.	For links to stub networks this
    field specifies the	network's IP address mask.  For	other link types
    the	Link Data field	specifies the router interface's IP address.

    Type
	A quick	description of the router link.	 One of	the following.
	Note that host routes are classified as	links to stub networks
	with network mask of 0xffffffff.

Moy			    Standards Track		      [Page 207]



RFC 2328		     OSPF Version 2		      April 1998

		 Type	Description
		 __________________________________________________
		 1	Point-to-point connection to another router
		 2	Connection to a	transit	network
		 3	Connection to a	stub network
		 4	Virtual	link

    Link ID
	Identifies the object that this	router link connects to.  Value
	depends	on the link's Type.  When connecting to	an object that
	also originates	an LSA (i.e., another router or	a transit
	network) the Link ID is	equal to the neighboring LSA's Link
	State ID.  This	provides the key for looking up	the neighboring
	LSA in the link	state database during the routing table
	calculation. See Section 12.2 for more details.

		       Type   Link ID
		       ______________________________________
		       1      Neighboring router's Router ID
		       2      IP address of Designated Router
		       3      IP network/subnet	number
		       4      Neighboring router's Router ID

    Link Data
	Value again depends on the link's Type field. For connections to
	stub networks, Link Data specifies the network's IP address
	mask. For unnumbered point-to-point connections, it specifies
	the interface's	MIB-II [Ref8] ifIndex value. For the other link
	types it specifies the router interface's IP address. This
	latter piece of	information is needed during the routing table
	build process, when calculating	the IP address of the next hop.
	See Section 16.1.1 for more details.

Moy			    Standards Track		      [Page 208]



RFC 2328		     OSPF Version 2		      April 1998

    # TOS
	The number of different	TOS metrics given for this link, not
	counting the required link metric (referred to as the TOS 0
	metric in [Ref9]).  For	example, if no additional TOS metrics
	are given, this	field is set to	0.

    metric
	The cost of using this router link.

    Additional TOS-specific information	may also be included, for
    backward compatibility with	previous versions of the OSPF
    specification ([Ref9]). Within each	link, and for each desired TOS,
    TOS	TOS-specific link information may be encoded as	follows:

    TOS	IP Type	of Service that	this metric refers to.	The encoding of
	TOS in OSPF LSAs is described in Section 12.3.

    TOS	metric
	TOS-specific metric information.

Moy			    Standards Track		      [Page 209]



RFC 2328		     OSPF Version 2		      April 1998

A.4.3 Network-LSAs

    Network-LSAs are the Type 2	LSAs.  A network-LSA is	originated for
    each broadcast and NBMA network in the area	which supports two or
    more routers.  The network-LSA is originated by the	network's
    Designated Router.	The LSA	describes all routers attached to the
    network, including the Designated Router itself.  The LSA's	Link
    State ID field lists the IP	interface address of the Designated
    Router.

    The	distance from the network to all attached routers is zero.  This
    is why metric fields need not be specified in the network-LSA.  For
    details concerning the construction	of network-LSAs, see Section
    12.4.2.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	    LS age	       |      Options  |      2	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     LS	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 LS checksum	       |	     length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			 Network Mask			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Attached Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

    Network Mask
	The IP address mask for	the network.  For example, a class A
	network	would have the mask 0xff000000.

Moy			    Standards Track		      [Page 210]



RFC 2328		     OSPF Version 2		      April 1998

    Attached Router
	The Router IDs of each of the routers attached to the network.
	Actually, only those routers that are fully adjacent to	the
	Designated Router are listed.  The Designated Router includes
	itself in this list.  The number of routers included can be
	deduced	from the LSA header's length field.

Moy			    Standards Track		      [Page 211]



RFC 2328		     OSPF Version 2		      April 1998

A.4.4 Summary-LSAs

    Summary-LSAs are the Type 3	and 4 LSAs.  These LSAs	are originated
    by area border routers. Summary-LSAs describe inter-area
    destinations.  For details concerning the construction of summary-
    LSAs, see Section 12.4.3.

    Type 3 summary-LSAs	are used when the destination is an IP network.
    In this case the LSA's Link	State ID field is an IP	network	number
    (if	necessary, the Link State ID can also have one or more of the
    network's "host" bits set; see Appendix E for details). When the
    destination	is an AS boundary router, a Type 4 summary-LSA is used,
    and	the Link State ID field	is the AS boundary router's OSPF Router
    ID.	 (To see why it	is necessary to	advertise the location of each
    ASBR, consult Section 16.4.)  Other	than the difference in the Link
    State ID field, the	format of Type 3 and 4 summary-LSAs is
    identical.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	    LS age	       |     Options   |    3 or 4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     LS	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 LS checksum	       |	     length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			 Network Mask			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      0	       |		  metric		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TOS       |		TOS  metric		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

Moy			    Standards Track		      [Page 212]



RFC 2328		     OSPF Version 2		      April 1998

    For	stub areas, Type 3 summary-LSAs	can also be used to describe a
    (per-area) default route.  Default summary routes are used in stub
    areas instead of flooding a	complete set of	external routes.  When
    describing a default summary route,	the summary-LSA's Link State ID
    is always set to DefaultDestination	(0.0.0.0) and the Network Mask
    is set to 0.0.0.0.

    Network Mask
	For Type 3 summary-LSAs, this indicates	the destination
	network's IP address mask.  For	example, when advertising the
	location of a class A network the value	0xff000000 would be
	used.  This field is not meaningful and	must be	zero for Type 4
	summary-LSAs.

    metric
	The cost of this route.	 Expressed in the same units as	the
	interface costs	in the router-LSAs.

    Additional TOS-specific information	may also be included, for
    backward compatibility with	previous versions of the OSPF
    specification ([Ref9]). For	each desired TOS, TOS-specific
    information	is encoded as follows:

    TOS	IP Type	of Service that	this metric refers to.	The encoding of
	TOS in OSPF LSAs is described in Section 12.3.

    TOS	metric
	TOS-specific metric information.

Moy			    Standards Track		      [Page 213]



RFC 2328		     OSPF Version 2		      April 1998

A.4.5 AS-external-LSAs

    AS-external-LSAs are the Type 5 LSAs.  These LSAs are originated by
    AS boundary	routers, and describe destinations external to the AS.
    For	details	concerning the construction of AS-external-LSAs, see
    Section 12.4.3.

    AS-external-LSAs usually describe a	particular external destination.
    For	these LSAs the Link State ID field specifies an	IP network
    number (if necessary, the Link State ID can	also have one or more of
    the	network's "host" bits set; see Appendix	E for details).	 AS-
    external-LSAs are also used	to describe a default route.  Default
    routes are used when no specific route exists to the destination.
    When describing a default route, the Link State ID is always set to
    DefaultDestination (0.0.0.0) and the Network Mask is set to	0.0.0.0.

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	    LS age	       |     Options   |      5	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			Link State ID			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     Advertising Router			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		     LS	sequence number			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	 LS checksum	       |	     length	       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			 Network Mask			       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|     0       |		  metric		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		      Forwarding address		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		      External Route Tag		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|    TOS      |		TOS  metric		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		      Forwarding address		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Moy			    Standards Track		      [Page 214]



RFC 2328		     OSPF Version 2		      April 1998

       |		      External Route Tag		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |			      ...			       |

    Network Mask
	The IP address mask for	the advertised destination.  For
	example, when advertising a class A network the	mask 0xff000000
	would be used.

    bit	E
	The type of external metric.  If bit E is set, the metric
	specified is a Type 2 external metric.	This means the metric is
	considered larger than any link	state path.  If	bit E is zero,
	the specified metric is	a Type 1 external metric.  This	means
	that it	is expressed in	the same units as the link state metric
	(i.e., the same	units as interface cost).

    metric
	The cost of this route.	 Interpretation	depends	on the external
	type indication	(bit E above).

    Forwarding address
	Data traffic for the advertised	destination will be forwarded to
	this address.  If the Forwarding address is set	to 0.0.0.0, data
	traffic	will be	forwarded instead to the LSA's originator (i.e.,
	the responsible	AS boundary router).

    External Route Tag
	A 32-bit field attached	to each	external route.	 This is not
	used by	the OSPF protocol itself.  It may be used to communicate
	information between AS boundary	routers; the precise nature of
	such information is outside the	scope of this specification.

    Additional TOS-specific information	may also be included, for
    backward compatibility with	previous versions of the OSPF
    specification ([Ref9]). For	each desired TOS, TOS-specific
    information	is encoded as follows:

    TOS	The Type of Service that the following fields concern.	The
	encoding of TOS	in OSPF	LSAs is	described in Section 12.3.

Moy			    Standards Track		      [Page 215]



RFC 2328		     OSPF Version 2		      April 1998

    bit	E
	For backward-compatibility with	[Ref9].

    TOS	metric
	TOS-specific metric information.

    Forwarding address
	For backward-compatibility with	[Ref9].

    External Route Tag
	For backward-compatibility with	[Ref9].

Moy			    Standards Track		      [Page 216]



RFC 2328		     OSPF Version 2		      April 1998

B. Architectural Constants

    Several OSPF protocol parameters have fixed	architectural values.
    These parameters have been referred	to in the text by names	such as
    LSRefreshTime.  The	same naming convention is used for the
    configurable protocol parameters.  They are	defined	in Appendix C.

    The	name of	each architectural constant follows, together with its
    value and a	short description of its function.

    LSRefreshTime
	The maximum time between distinct originations of any particular
	LSA.  If the LS	age field of one of the	router's self-originated
	LSAs reaches the value LSRefreshTime, a	new instance of	the LSA
	is originated, even though the contents	of the LSA (apart from
	the LSA	header)	will be	the same.  The value of	LSRefreshTime is
	set to 30 minutes.

    MinLSInterval
	The minimum time between distinct originations of any particular
	LSA.  The value	of MinLSInterval is set	to 5 seconds.

    MinLSArrival
	For any	particular LSA,	the minimum time that must elapse
	between	reception of new LSA instances during flooding.	LSA
	instances received at higher frequencies are discarded.	The
	value of MinLSArrival is set to	1 second.

    MaxAge
	The maximum age	that an	LSA can	attain.	When an	LSA's LS age
	field reaches MaxAge, it is reflooded in an attempt to flush the
	LSA from the routing domain (See Section 14). LSAs of age MaxAge
	are not	used in	the routing table calculation.	The value of
	MaxAge is set to 1 hour.

    CheckAge
	When the age of	an LSA in the link state database hits a
	multiple of CheckAge, the LSA's	checksum is verified.  An
	incorrect checksum at this time	indicates a serious error.  The
	value of CheckAge is set to 5 minutes.

Moy			    Standards Track		      [Page 217]



RFC 2328		     OSPF Version 2		      April 1998

    MaxAgeDiff
	The maximum time dispersion that can occur, as an LSA is flooded
	throughout the AS.  Most of this time is accounted for by the
	LSAs sitting on	router output queues (and therefore not	aging)
	during the flooding process.  The value	of MaxAgeDiff is set to
	15 minutes.

    LSInfinity
	The metric value indicating that the destination described by an
	LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
	an alternative to premature aging (see Section 14.1). It is
	defined	to be the 24-bit binary	value of all ones: 0xffffff.

    DefaultDestination
	The Destination	ID that	indicates the default route.  This route
	is used	when no	other matching routing table entry can be found.
	The default destination	can only be advertised in AS-external-
	LSAs and in stub areas'	type 3 summary-LSAs.  Its value	is the
	IP address 0.0.0.0. Its	associated Network Mask	is also	always
	0.0.0.0.

    InitialSequenceNumber
	The value used for LS Sequence Number when originating the first
	instance of any	LSA. Its value is the signed 32-bit integer
	0x80000001.

    MaxSequenceNumber
	The maximum value that LS Sequence Number can attain.  Its value
	is the signed 32-bit integer 0x7fffffff.

Moy			    Standards Track		      [Page 218]



RFC 2328		     OSPF Version 2		      April 1998

C. Configurable	Constants

    The	OSPF protocol has quite	a few configurable parameters.	These
    parameters are listed below.  They are grouped into	general
    functional categories (area	parameters, interface parameters, etc.).
    Sample values are given for	some of	the parameters.

    Some parameter settings need to be consistent among	groups of
    routers.  For example, all routers in an area must agree on	that
    area's parameters, and all routers attached	to a network must agree
    on that network's IP network number	and mask.

    Some parameters may	be determined by router	algorithms outside of
    this specification (e.g., the address of a host connected to the
    router via a SLIP line).  From OSPF's point	of view, these items are
    still configurable.

    C.1	Global parameters

	In general, a separate copy of the OSPF	protocol is run	for each
	area.  Because of this,	most configuration parameters are
	defined	on a per-area basis.  The few global configuration
	parameters are listed below.

	Router ID
	    This is a 32-bit number that uniquely identifies the router
	    in the Autonomous System.  One algorithm for Router	ID
	    assignment is to choose the	largest	or smallest IP address
	    assigned to	the router.  If	a router's OSPF	Router ID is
	    changed, the router's OSPF software	should be restarted
	    before the new Router ID takes effect. Before restarting in
	    order to change its	Router ID, the router should flush its
	    self-originated LSAs from the routing domain (see Section
	    14.1), or they will	persist	for up to MaxAge minutes.

	RFC1583Compatibility
	    Controls the preference rules used in Section 16.4 when
	    choosing among multiple AS-external-LSAs advertising the
	    same destination. When set to "enabled", the preference
	    rules remain those specified by RFC	1583 ([Ref9]). When set
	    to "disabled", the preference rules	are those stated in

Moy			    Standards Track		      [Page 219]



RFC 2328		     OSPF Version 2		      April 1998

	    Section 16.4.1, which prevent routing loops	when AS-
	    external-LSAs for the same destination have	been originated
	    from different areas. Set to "enabled" by default.

	    In order to	minimize the chance of routing loops, all OSPF
	    routers in an OSPF routing domain should have
	    RFC1583Compatibility set identically. When there are routers
	    present that have not been updated with the	functionality
	    specified in Section 16.4.1	of this	memo, all routers should
	    have RFC1583Compatibility set to "enabled".	Otherwise, all
	    routers should have	RFC1583Compatibility set to "disabled",
	    preventing all routing loops.

    C.2	Area parameters

	All routers belonging to an area must agree on that area's
	configuration.	Disagreements between two routers will lead to
	an inability for adjacencies to	form between them, with	a
	resulting hindrance to the flow	of routing protocol and	data
	traffic.  The following	items must be configured for an	area:

	Area ID
	    This is a 32-bit number that identifies the	area.  The Area
	    ID of 0.0.0.0 is reserved for the backbone.	 If the	area
	    represents a subnetted network, the	IP network number of the
	    subnetted network may be used for the Area ID.

	List of	address	ranges
	    An OSPF area is defined as a list of address ranges. Each
	    address range consists of the following items:

	    [IP	address, mask]
		    Describes the collection of	IP addresses contained
		    in the address range. Networks and hosts are
		    assigned to	an area	depending on whether their
		    addresses fall into	one of the area's defining
		    address ranges.  Routers are viewed	as belonging to
		    multiple areas, depending on their attached
		    networks' area membership.

Moy			    Standards Track		      [Page 220]



RFC 2328		     OSPF Version 2		      April 1998

	    Status  Set	to either Advertise or DoNotAdvertise.	Routing
		    information	is condensed at	area boundaries.
		    External to	the area, at most a single route is
		    advertised (via a summary-LSA) for each address
		    range. The route is	advertised if and only if the
		    address range's Status is set to Advertise.
		    Unadvertised ranges	allow the existence of certain
		    networks to	be intentionally hidden	from other
		    areas. Status is set to Advertise by default.

	    As an example, suppose an IP subnetted network is to be its
	    own	OSPF area.  The	area would be configured as a single
	    address range, whose IP address is the address of the
	    subnetted network, and whose mask is the natural class A, B,
	    or C address mask.	A single route would be	advertised
	    external to	the area, describing the entire	subnetted
	    network.

	ExternalRoutingCapability
	    Whether AS-external-LSAs will be flooded into/throughout the
	    area.  If AS-external-LSAs are excluded from the area, the
	    area is called a "stub".  Internal to stub areas, routing to
	    external destinations will be based	solely on a default
	    summary route.  The	backbone cannot	be configured as a stub
	    area.  Also, virtual links cannot be configured through stub
	    areas.  For	more information, see Section 3.6.

	StubDefaultCost
	    If the area	has been configured as a stub area, and	the
	    router itself is an	area border router, then the
	    StubDefaultCost indicates the cost of the default summary-
	    LSA	that the router	should advertise into the area.

    C.3	Router interface parameters

	Some of	the configurable router	interface parameters (such as IP
	interface address and subnet mask) actually imply properties of
	the attached networks, and therefore must be consistent	across
	all the	routers	attached to that network.  The parameters that
	must be	configured for a router	interface are:

Moy			    Standards Track		      [Page 221]



RFC 2328		     OSPF Version 2		      April 1998

	IP interface address
	    The	IP protocol address for	this interface.	 This uniquely
	    identifies the router over the entire internet.  An	IP
	    address is not required on point-to-point networks.	 Such a
	    point-to-point network is called "unnumbered".

	IP interface mask
	    Also referred to as	the subnet/network mask, this indicates
	    the	portion	of the IP interface address that identifies the
	    attached network.  Masking the IP interface	address	with the
	    IP interface mask yields the IP network number of the
	    attached network.  On point-to-point networks and virtual
	    links, the IP interface mask is not	defined. On these
	    networks, the link itself is not assigned an IP network
	    number, and	so the addresses of each side of the link are
	    assigned independently, if they are	assigned at all.

	Area ID
	    The	OSPF area to which the attached	network	belongs.

	Interface output cost
	    The	cost of	sending	a packet on the	interface, expressed in
	    the	link state metric.  This is advertised as the link cost
	    for	this interface in the router's router-LSA. The interface
	    output cost	must always be greater than 0.

	RxmtInterval
	    The	number of seconds between LSA retransmissions, for
	    adjacencies	belonging to this interface.  Also used	when
	    retransmitting Database Description	and Link State Request
	    Packets.  This should be well over the expected round-trip
	    delay between any two routers on the attached network.  The
	    setting of this value should be conservative or needless
	    retransmissions will result.  Sample value for a local area
	    network: 5 seconds.

	InfTransDelay
	    The	estimated number of seconds it takes to	transmit a Link
	    State Update Packet	over this interface.  LSAs contained in
	    the	update packet must have	their age incremented by this
	    amount before transmission.	 This value should take	into
	    account the	transmission and propagation delays of the

Moy			    Standards Track		      [Page 222]



RFC 2328		     OSPF Version 2		      April 1998

	    interface.	It must	be greater than	0.  Sample value for a
	    local area network:	1 second.

	Router Priority
	    An 8-bit unsigned integer.	When two routers attached to a
	    network both attempt to become Designated Router, the one
	    with the highest Router Priority takes precedence.	If there
	    is still a tie, the	router with the	highest	Router ID takes
	    precedence.	 A router whose	Router Priority	is set to 0 is
	    ineligible to become Designated Router on the attached
	    network.  Router Priority is only configured for interfaces
	    to broadcast and NBMA networks.

	HelloInterval
	    The	length of time,	in seconds, between the	Hello Packets
	    that the router sends on the interface.  This value	is
	    advertised in the router's Hello Packets.  It must be the
	    same for all routers attached to a common network.	The
	    smaller the	HelloInterval, the faster topological changes
	    will be detected; however, more OSPF routing protocol
	    traffic will ensue.	 Sample	value for a X.25 PDN network: 30
	    seconds.  Sample value for a local area network: 10	seconds.

	RouterDeadInterval
	    After ceasing to hear a router's Hello Packets, the	number
	    of seconds before its neighbors declare the	router down.
	    This is also advertised in the router's Hello Packets in
	    their RouterDeadInterval field.  This should be some
	    multiple of	the HelloInterval (say 4).  This value again
	    must be the	same for all routers attached to a common
	    network.

	AuType
	    Identifies the authentication procedure to be used on the
	    attached network.  This value must be the same for all
	    routers attached to	the network.  See Appendix D for a
	    discussion of the defined authentication types.

	Authentication key
	    This configured data allows	the authentication procedure to
	    verify OSPF	protocol packets received over the interface.
	    For	example, if the	AuType indicates simple	password, the

Moy			    Standards Track		      [Page 223]



RFC 2328		     OSPF Version 2		      April 1998

	    Authentication key would be	a clear	64-bit password.
	    Authentication keys	associated with	the other OSPF
	    authentication types are discussed in Appendix D.

    C.4	Virtual	link parameters

	Virtual	links are used to restore/increase connectivity	of the
	backbone.  Virtual links may be	configured between any pair of
	area border routers having interfaces to a common (non-backbone)
	area.  The virtual link	appears	as an unnumbered point-to-point
	link in	the graph for the backbone.  The virtual link must be
	configured in both of the area border routers.

	A virtual link appears in router-LSAs (for the backbone) as if
	it were	a separate router interface to the backbone.  As such,
	it has all of the parameters associated	with a router interface
	(see Section C.3).  Although a virtual link acts like an
	unnumbered point-to-point link,	it does	have an	associated IP
	interface address.  This address is used as the	IP source in
	OSPF protocol packets it sends along the virtual link, and is
	set dynamically	during the routing table build process.
	Interface output cost is also set dynamically on virtual links
	to be the cost of the intra-area path between the two routers.
	The parameter RxmtInterval must	be configured, and should be
	well over the expected round-trip delay	between	the two	routers.
	This may be hard to estimate for a virtual link; it is better to
	err on the side	of making it too large.	 Router	Priority is not
	used on	virtual	links.

	A virtual link is defined by the following two configurable
	parameters: the	Router ID of the virtual link's	other endpoint,
	and the	(non-backbone) area through which the virtual link runs
	(referred to as	the virtual link's Transit area).  Virtual links
	cannot be configured through stub areas.

    C.5	NBMA network parameters

	OSPF treats an NBMA network much like it treats	a broadcast
	network.  Since	there may be many routers attached to the
	network, a Designated Router is	selected for the network.  This
	Designated Router then originates a network-LSA, which lists all
	routers	attached to the	NBMA network.

Moy			    Standards Track		      [Page 224]



RFC 2328		     OSPF Version 2		      April 1998

	However, due to	the lack of broadcast capabilities, it may be
	necessary to use configuration parameters in the Designated
	Router selection.  These parameters will only need to be
	configured in those routers that are themselves	eligible to
	become Designated Router (i.e.,	those router's whose Router
	Priority for the network is non-zero), and then	only if	no
	automatic procedure for	discovering neighbors exists:

	List of	all other attached routers
	    The	list of	all other routers attached to the NBMA network.
	    Each router	is listed by its IP interface address on the
	    network.  Also, for	each router listed, that router's
	    eligibility	to become Designated Router must be defined.
	    When an interface to a NBMA	network	comes up, the router
	    sends Hello	Packets	only to	those neighbors	eligible to
	    become Designated Router, until the	identity of the
	    Designated Router is discovered.

	PollInterval
	    If a neighboring router has	become inactive	(Hello Packets
	    have not been seen for RouterDeadInterval seconds),	it may
	    still be necessary to send Hello Packets to	the dead
	    neighbor.  These Hello Packets will	be sent	at the reduced
	    rate PollInterval, which should be much larger than
	    HelloInterval.  Sample value for a PDN X.25	network: 2
	    minutes.

    C.6	Point-to-MultiPoint network parameters

	On Point-to-MultiPoint networks, it may	be necessary to
	configure the set of neighbors that are	directly reachable over
	the Point-to-MultiPoint	network. Each neighbor is identified by
	its IP address on the Point-to-MultiPoint network. Designated
	Routers	are not	elected	on Point-to-MultiPoint networks, so the
	Designated Router eligibility of configured neighbors is
	undefined.

	Alternatively, neighbors on Point-to-MultiPoint	networks may be
	dynamically discovered by lower-level protocols	such as	Inverse
	ARP ([Ref14]).

Moy			    Standards Track		      [Page 225]



RFC 2328		     OSPF Version 2		      April 1998

    C.7	Host route parameters

	Host routes are	advertised in router-LSAs as stub networks with
	mask 0xffffffff.  They indicate	either router interfaces to
	point-to-point networks, looped	router interfaces, or IP hosts
	that are directly connected to the router (e.g., via a SLIP
	line).	For each host directly connected to the	router,	the
	following items	must be	configured:

	Host IP	address
	    The	IP address of the host.

	Cost of	link to	host
	    The	cost of	sending	a packet to the	host, in terms of the
	    link state metric.	However, since the host	probably has
	    only a single connection to	the internet, the actual
	    configured cost in many cases is unimportant (i.e.,	will
	    have no effect on routing).

	Area ID
	    The	OSPF area to which the host belongs.

Moy			    Standards Track		      [Page 226]



RFC 2328		     OSPF Version 2		      April 1998

D. Authentication

    All	OSPF protocol exchanges	are authenticated.  The	OSPF packet
    header (see	Section	A.3.1) includes	an authentication type field,
    and	64-bits	of data	for use	by the appropriate authentication scheme
    (determined	by the type field).

    The	authentication type is configurable on a per-interface (or
    equivalently, on a per-network/subnet) basis.  Additional
    authentication data	is also	configurable on	a per-interface	basis.

    Authentication types 0, 1 and 2 are	defined	by this	specification.
    All	other authentication types are reserved	for definition by the
    IANA (iana@ISI.EDU).  The current list of authentication types is
    described below in Table 20.

		  AuType       Description
		  ___________________________________________
		  0	       Null authentication
		  1	       Simple password
		  2	       Cryptographic authentication
		  All others   Reserved	for assignment by the
			       IANA (iana@ISI.EDU)

		      Table 20:	OSPF authentication types.

    D.1	Null authentication

	Use of this authentication type	means that routing exchanges
	over the network/subnet	are not	authenticated.	The 64-bit
	authentication field in	the OSPF header	can contain anything; it
	is not examined	on packet reception. When employing Null
	authentication,	the entire contents of each OSPF packet	(other
	than the 64-bit	authentication field) are checksummed in order
	to detect data corruption.

Moy			    Standards Track		      [Page 227]



RFC 2328		     OSPF Version 2		      April 1998

    D.2	Simple password	authentication

	Using this authentication type,	a 64-bit field is configured on
	a per-network basis.  All packets sent on a particular network
	must have this configured value	in their OSPF header 64-bit
	authentication field.  This essentially	serves as a "clear" 64-
	bit password. In addition, the entire contents of each OSPF
	packet (other than the 64-bit authentication field) are
	checksummed in order to	detect data corruption.

	Simple password	authentication guards against routers
	inadvertently joining the routing domain; each router must first
	be configured with its attached	networks' passwords before it
	can participate	in routing.  However, simple password
	authentication is vulnerable to	passive	attacks	currently
	widespread in the Internet (see	[Ref16]). Anyone with physical
	access to the network can learn	the password and compromise the
	security of the	OSPF routing domain.

    D.3	Cryptographic authentication

	Using this authentication type,	a shared secret	key is
	configured in all routers attached to a	common network/subnet.
	For each OSPF protocol packet, the key is used to
	generate/verify	a "message digest" that	is appended to the end
	of the OSPF packet. The	message	digest is a one-way function of
	the OSPF protocol packet and the secret	key. Since the secret
	key is never sent over the network in the clear, protection is
	provided against passive attacks.

	The algorithms used to generate	and verify the message digest
	are specified implicitly by the	secret key. This specification
	completely defines the use of OSPF Cryptographic authentication
	when the MD5 algorithm is used.

	In addition, a non-decreasing sequence number is included in
	each OSPF protocol packet to protect against replay attacks.
	This provides long term	protection; however, it	is still
	possible to replay an OSPF packet until	the sequence number
	changes. To implement this feature, each neighbor data structure
	contains a new field called the	"cryptographic sequence	number".
	This field is initialized to zero, and is also set to zero

Moy			    Standards Track		      [Page 228]



RFC 2328		     OSPF Version 2		      April 1998

	0		    1			2		    3
	0 1 2 3	4 5 6 7	8 9 0 1	2 3 4 5	6 7 8 9	0 1 2 3	4 5 6 7	8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |	      0		       |    Key	ID     | Auth Data Len |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |		 Cryptographic sequence	number		       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		   Figure 18: Usage of the Authentication field
		   in the OSPF packet header when Cryptographic
			  Authentication is employed

	whenever the neighbor's	state transitions to "Down". Whenever an
	OSPF packet is accepted	as authentic, the cryptographic	sequence
	number is set to the received packet's sequence	number.

	This specification does	not provide a rollover procedure for the
	cryptographic sequence number. When the	cryptographic sequence
	number that the	router is sending hits the maximum value, the
	router should reset the	cryptographic sequence number that it is
	sending	back to	0. After this is done, the router's neighbors
	will reject the	router's OSPF packets for a period of
	RouterDeadInterval, and	then the router	will be	forced to
	reestablish all	adjacencies over the interface.	However, it is
	expected that many implementations will	use "seconds since
	reboot"	(or "seconds since 1960", etc.)	as the cryptographic
	sequence number. Such a	choice will essentially	prevent
	rollover, since	the cryptographic sequence number field	is 32
	bits in	length.

	The OSPF Cryptographic authentication option does not provide
	confidentiality.

	When cryptographic authentication is used, the 64-bit
	Authentication field in	the standard OSPF packet header	is
	redefined as shown in Figure 18. The new field definitions are
	as follows:

Moy			    Standards Track		      [Page 229]



RFC 2328		     OSPF Version 2		      April 1998

	Key ID
	    This field identifies the algorithm	and secret key used to
	    create the message digest appended to the OSPF packet. Key
	    Identifiers	are unique per-interface (or equivalently, per-
	    subnet).

	Auth Data Len
	    The	length in bytes	of the message digest appended to the
	    OSPF packet.

	Cryptographic sequence number
	    An unsigned	32-bit non-decreasing sequence number. Used to
	    guard against replay attacks.

	The message digest appended to the OSPF	packet is not actually
	considered part	of the OSPF protocol packet: the message digest
	is not included	in the OSPF header's packet length, although it
	is included in the packet's IP header length field.

	Each key is identified by the combination of interface and Key
	ID. An interface may have multiple keys	active at any one time.
	This enables smooth transition from one	key to another.	Each key
	has four time constants	associated with	it. These time constants
	can be expressed in terms of a time-of-day clock, or in	terms of
	a router's local clock (e.g., number of	seconds	since last
	reboot):

	KeyStartAccept
	    The	time that the router will start	accepting packets that
	    have been created with the given key.

	KeyStartGenerate
	    The	time that the router will start	using the key for packet
	    generation.

	KeyStopGenerate
	    The	time that the router will stop using the key for packet
	    generation.

	KeyStopAccept
	    The	time that the router will stop accepting packets that
	    have been created with the given key.

Moy			    Standards Track		      [Page 230]



RFC 2328		     OSPF Version 2		      April 1998

	In order to achieve smooth key transition, KeyStartAccept should
	be less	than KeyStartGenerate and KeyStopGenerate should be less
	than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are
	left unspecified, the key's lifetime is	infinite. When a new key
	replaces an old, the KeyStartGenerate time for the new key must
	be less	than or	equal to the KeyStopGenerate time of the old
	key.

	Key storage should persist across a system restart, warm or
	cold, to avoid operational issues. In the event	that the last
	key associated with an interface expires, it is	unacceptable to
	revert to an unauthenticated condition,	and not	advisable to
	disrupt	routing.  Therefore, the router	should send a "last
	authentication key expiration" notification to the network
	manager	and treat the key as having an infinite	lifetime until
	the lifetime is	extended, the key is deleted by	network
	management, or a new key is configured.

    D.4	Message	generation

	After building the contents of an OSPF packet, the
	authentication procedure indicated by the sending interface's
	Autype value is	called before the packet is sent. The
	authentication procedure modifies the OSPF packet as follows.

	D.4.1 Generating Null authentication

	    When using Null authentication, the	packet is modified as
	    follows:

	    (1)	The Autype field in the	standard OSPF header is	set to
		0.

	    (2)	The checksum field in the standard OSPF	header is set to
		the standard IP	checksum of the	entire contents	of the
		packet,	starting with the OSPF packet header but
		excluding the 64-bit authentication field.  This
		checksum is calculated as the 16-bit one's complement of
		the one's complement sum of all	the 16-bit words in the
		packet,	excepting the authentication field.  If	the

Moy			    Standards Track		      [Page 231]



RFC 2328		     OSPF Version 2		      April 1998

		packet's length	is not an integral number of 16-bit
		words, the packet is padded with a byte	of zero	before
		checksumming.

	D.4.2 Generating Simple	password authentication

	    When using Simple password authentication, the packet is
	    modified as	follows:

	    (1)	The Autype field in the	standard OSPF header is	set to
		1.

	    (2)	The checksum field in the standard OSPF	header is set to
		the standard IP	checksum of the	entire contents	of the
		packet,	starting with the OSPF packet header but
		excluding the 64-bit authentication field.  This
		checksum is calculated as the 16-bit one's complement of
		the one's complement sum of all	the 16-bit words in the
		packet,	excepting the authentication field.  If	the
		packet's length	is not an integral number of 16-bit
		words, the packet is padded with a byte	of zero	before
		checksumming.

	    (3)	The 64-bit authentication field	in the OSPF packet
		header is set to the 64-bit password (i.e.,
		authentication key) that has been configured for the
		interface.

	D.4.3 Generating Cryptographic authentication

	    When using Cryptographic authentication, there may be
	    multiple keys configured for the interface.	In this	case,
	    among the keys that	are valid for message generation (i.e,
	    that have KeyStartGenerate <= current time <
	    KeyStopGenerate) choose the	one with the most recent
	    KeyStartGenerate time. Using this key, modify the packet as
	    follows:

	    (1)	The Autype field in the	standard OSPF header is	set to
		2.

Moy			    Standards Track		      [Page 232]



RFC 2328		     OSPF Version 2		      April 1998

	    (2)	The checksum field in the standard OSPF	header is not
		calculated, but	is instead set to 0.

	    (3)	The Key	ID (see	Figure 18) is set to the chosen	key's
		Key ID.

	    (4)	The Auth Data Len field	is set to the length in	bytes of
		the message digest that	will be	appended to the	OSPF
		packet.	When using MD5 as the authentication algorithm,
		Auth Data Len will be 16.

	    (5)	The 32-bit Cryptographic sequence number (see Figure 18)
		is set to a non-decreasing value (i.e.,	a value	at least
		as large as the	last value sent	out the	interface). The
		precise	values to use in the cryptographic sequence
		number field are implementation-specific. For example,
		it may be based	on a simple counter, or	be based on the
		system's clock.

	    (6)	The message digest is then calculated and appended to
		the OSPF packet.  The authentication algorithm to be
		used in	calculating the	digest is indicated by the key
		itself.	 Input to the authentication algorithm consists
		of the OSPF packet and the secret key. When using MD5 as
		the authentication algorithm, the message digest
		calculation proceeds as	follows:

		(a) The	16 byte	MD5 key	is appended to the OSPF	packet.

		(b) Trailing pad and length fields are added, as
		    specified in [Ref17].

		(c) The	MD5 authentication algorithm is	run over the
		    concatenation of the OSPF packet, secret key, pad
		    and	length fields, producing a 16 byte message
		    digest (see	[Ref17]).

		(d) The	MD5 digest is written over the OSPF key	(i.e.,
		    appended to	the original OSPF packet). The digest is
		    not	counted	in the OSPF packet's length field, but

Moy			    Standards Track		      [Page 233]



RFC 2328		     OSPF Version 2		      April 1998

		    is included	in the packet's	IP length field. Any
		    trailing pad or length fields beyond the digest are
		    not	counted	or transmitted.

    D.5	Message	verification

	When an	OSPF packet has	been received on an interface, it must
	be authenticated. The authentication procedure is indicated by
	the setting of Autype in the standard OSPF packet header, which
	matches	the setting of Autype for the receiving	OSPF interface.

	If an OSPF protocol packet is accepted as authentic, processing
	of the packet continues	as specified in	Section	8.2. Packets
	which fail authentication are discarded.

	D.5.1 Verifying	Null authentication

	    When using Null authentication, the	checksum field in the
	    OSPF header	must be	verified. It must be set to the	16-bit
	    one's complement of	the one's complement sum of all	the 16-
	    bit	words in the packet, excepting the authentication field.
	    (If	the packet's length is not an integral number of 16-bit
	    words, the packet is padded	with a byte of zero before
	    checksumming.)

	D.5.2 Verifying	Simple password	authentication

	    When using Simple password authentication, the received OSPF
	    packet is authenticated as follows:

	    (1)	The checksum field in the OSPF header must be verified.
		It must	be set to the 16-bit one's complement of the
		one's complement sum of	all the	16-bit words in	the
		packet,	excepting the authentication field.  (If the
		packet's length	is not an integral number of 16-bit
		words, the packet is padded with a byte	of zero	before
		checksumming.)

	    (2)	The 64-bit authentication field	in the OSPF packet
		header must be equal to	the 64-bit password (i.e.,
		authentication key) that has been configured for the
		interface.

Moy			    Standards Track		      [Page 234]



RFC 2328		     OSPF Version 2		      April 1998

	D.5.3 Verifying	Cryptographic authentication

	    When using Cryptographic authentication, the received OSPF
	    packet is authenticated as follows:

	    (1)	Locate the receiving interface's configured key	having
		Key ID equal to	that specified in the received OSPF
		packet (see Figure 18).	If the key is not found, or if
		the key	is not valid for reception (i.e., current time <
		KeyStartAccept or current time >= KeyStopAccept), the
		OSPF packet is discarded.

	    (2)	If the cryptographic sequence number found in the OSPF
		header (see Figure 18) is less than the	cryptographic
		sequence number	recorded in the	sending	neighbor's data
		structure, the OSPF packet is discarded.

	    (3)	Verify the appended message digest in the following
		steps:

		(a) The	received digest	is set aside.

		(b) A new digest is calculated,	as specified in	Step 6
		    of Section D.4.3.

		(c) The	calculated and received	digests	are compared. If
		    they do not	match, the OSPF	packet is discarded. If
		    they do match, the OSPF protocol packet is accepted
		    as authentic, and the "cryptographic sequence
		    number" in the neighbor's data structure is	set to
		    the	sequence number	found in the packet's OSPF
		    header.

Moy			    Standards Track		      [Page 235]



RFC 2328		     OSPF Version 2		      April 1998

E. An algorithm	for assigning Link State IDs

    The	Link State ID in AS-external-LSAs and summary-LSAs is usually
    set	to the described network's IP address. However,	if necessary one
    or more of the network's host bits may be set in the Link State ID.
    This allows	the router to originate	separate LSAs for networks
    having the same address, yet different masks. Such networks	can
    occur in the presence of supernetting and subnet 0s	(see [Ref10]).

    This appendix gives	one possible algorithm for setting the host bits
    in Link State IDs.	The choice of such an algorithm	is a local
    decision. Separate routers are free	to use different algorithms,
    since the only LSAs	affected are the ones that the router itself
    originates.	The only requirement on	the algorithms used is that the
    network's IP address should	be used	as the Link State ID whenever
    possible; this maximizes interoperability with OSPF	implementations
    predating RFC 1583.

    The	algorithm below	is stated for AS-external-LSAs.	 This is only
    for	clarity; the exact same	algorithm can be used for summary-LSAs.
    Suppose that the router wishes to originate	an AS-external-LSA for a
    network having address NA and mask NM1. The	following steps	are then
    used to determine the LSA's	Link State ID:

    (1)	Determine whether the router is	already	originating an AS-
	external-LSA with Link State ID	equal to NA (in	such an	LSA the
	router itself will be listed as	the LSA's Advertising Router).
	If not,	the Link State ID is set equal to NA and the algorithm
	terminates. Otherwise,

    (2)	Obtain the network mask	from the body of the already existing
	AS-external-LSA. Call this mask	NM2. There are then two	cases:

	o   NM1	is longer (i.e., more specific)	than NM2. In this case,
	    set	the Link State ID in the new LSA to be the network
	    [NA,NM1] with all the host bits set	(i.e., equal to	NA or'ed
	    together with all the bits that are	not set	in NM1,	which is
	    network [NA,NM1]'s broadcast address).

	o   NM2	is longer than NM1. In this case, change the existing
	    LSA	(having	Link State ID of NA) to	reference the new
	    network [NA,NM1] by	incrementing the sequence number,

Moy			    Standards Track		      [Page 236]



RFC 2328		     OSPF Version 2		      April 1998

	    changing the mask in the body to NM1 and inserting the cost
	    of the new network.	Then originate a new LSA for the old
	    network [NA,NM2], with Link	State ID equal to NA or'ed
	    together with the bits that	are not	set in NM2 (i.e.,
	    network [NA,NM2]'s broadcast address).

    The	above algorithm	assumes	that all masks are contiguous; this
    ensures that when two networks have	the same address, one mask is
    more specific than the other. The algorithm	also assumes that no
    network exists having an address equal to another network's
    broadcast address. Given these two assumptions, the	above algorithm
    always produces unique Link	State IDs. The above algorithm can also
    be reworded	as follows:  When originating an AS-external-LSA, try to
    use	the network number as the Link State ID.  If that produces a
    conflict, examine the two networks in conflict. One	will be	a subset
    of the other. For the less specific	network, use the network number
    as the Link	State ID and for the more specific use the network's
    broadcast address instead (i.e., flip all the "host" bits to 1).  If
    the	most specific network was originated first, this will cause you
    to originate two LSAs at once.

    As an example of the algorithm, consider its operation when	the
    following sequence of events occurs	in a single router (Router A).

    (1)	Router A wants to originate an AS-external-LSA for
	[10.0.0.0,255.255.255.0]:

	(a) A Link State ID of 10.0.0.0	is used.

    (2)	Router A then wants to originate an AS-external-LSA for
	[10.0.0.0,255.255.0.0]:

	(a) The	LSA for	[10.0.0,0,255.255.255.0] is reoriginated using a
	    new	Link State ID of 10.0.0.255.

	(b) A Link State ID of 10.0.0.0	is used	for
	    [10.0.0.0,255.255.0.0].

    (3)	Router A then wants to originate an AS-external-LSA for
	[10.0.0.0,255.0.0.0]:

Moy			    Standards Track		      [Page 237]



RFC 2328		     OSPF Version 2		      April 1998

	(a) The	LSA for	[10.0.0.0,255.255.0.0] is reoriginated using a
	    new	Link State ID of 10.0.255.255.

	(b) A Link State ID of 10.0.0.0	is used	for
	    [10.0.0.0,255.0.0.0].

	(c) The	network	[10.0.0.0,255.255.255.0] keeps its Link	State ID
	    of 10.0.0.255.

Moy			    Standards Track		      [Page 238]



RFC 2328		     OSPF Version 2		      April 1998

F. Multiple interfaces to the same network/subnet

    There are at least two ways	to support multiple physical interfaces
    to the same	IP subnet. Both	methods	will interoperate with
    implementations of RFC 1583	(and of	course this memo). The two
    methods are	sketched briefly below.	An assumption has been made that
    each interface has been assigned a separate	IP address (otherwise,
    support for	multiple interfaces is more of a link-level or ARP issue
    than an OSPF issue).

    Method 1:
	Run the	entire OSPF functionality over both interfaces,	sending
	and receiving hellos, flooding,	supporting separate interface
	and neighbor FSMs for each interface, etc. When	doing this all
	other routers on the subnet will treat the two interfaces as
	separate neighbors, since neighbors are	identified (on broadcast
	and NBMA networks) by their IP address.

	Method 1 has the following disadvantages:

	(1) You	increase the total number of neighbors and adjacencies.

	(2) You	lose the bidirectionality test on both interfaces, since
	    bidirectionality is	based on Router	ID.

	(3) You	have to	consider both interfaces together during the
	    Designated Router election,	since if you declare both to be
	    DR simultaneously you can confuse the tie-breaker (which is
	    Router ID).

    Method 2:
	Run OSPF over only one interface (call it the primary
	interface), but	include	both the primary and secondary
	interfaces in your Router-LSA.

	Method 2 has the following disadvantages:

	(1) You	lose the bidirectionality test on the secondary
	    interface.

	(2) When the primary interface fails, you need to promote the
	    secondary interface	to primary status.

Moy			    Standards Track		      [Page 239]



RFC 2328		     OSPF Version 2		      April 1998

G. Differences from RFC	2178

    This section documents the differences between this	memo and RFC
    2178.  All differences are backward-compatible. Implementations of
    this memo and of RFCs 2178,	1583, and 1247 will interoperate.

    G.1	Flooding modifications

	Three changes have been	made to	the flooding procedure in
	Section	13.

	The first change is to step 4 in Section 13. Now MaxAge	LSAs are
	acknowledged and then discarded	only when both a) there	is no
	database copy of the LSA and b)	none of	router's neighbors are
	in states Exchange or Loading. In all other cases, the MaxAge
	LSA is processed like any other	LSA, installing	the LSA	in the
	database and flooding it out the appropriate interfaces	when the
	LSA is more recent than	the database copy (Step	5 of Section
	13). This change also affects the contents of Table 19.

	The second change is to	step 5a	in Section 13. The MinLSArrival
	check is meant only for	LSAs received during flooding, and
	should not be performed	on those LSAs that the router itself
	originates.

	The third change is to step 8 in Section 13. Confusion between
	routers	as to which LSA	instance is more recent	can cause a
	disastrous amount of flooding in a link-state protocol (see
	[Ref26]). OSPF guards against this problem in two ways:	a) the
	LS age field is	used like a TTL	field in flooding, to eventually
	remove looping LSAs from the network (see Section 13.3), and b)
	routers	refuse to accept LSA updates more frequently than once
	every MinLSArrival seconds (see	Section	13).  However, there is
	still one case in RFC 2178 where disagreements regarding which
	LSA is more recent can cause a lot of flooding traffic:
	responding to old LSAs by reflooding the database copy.	 For
	this reason, Step 8 of Section 13 has been amended to only
	respond	with the database copy when that copy has not been sent
	in any Link State Update within	the last MinLSArrival seconds.

Moy			    Standards Track		      [Page 240]



RFC 2328		     OSPF Version 2		      April 1998

    G.2	Changes	to external path preferences

	There is still the possibility of a routing loop in RFC	2178
	when both a) virtual links are in use and b) the same external
	route is being imported	by multiple ASBRs, each	of which is in a
	separate area. To fix this problem, Section 16.4.1 has been
	revised. To choose the correct ASBR/forwarding address,	intra-
	area paths through non-backbone	areas are always preferred.
	However, intra-area paths through the backbone area (Area 0) and
	inter-area paths are now of equal preference, and must be
	compared solely	based on cost.

	The reasoning behind this change is as follows.	When virtual
	links are in use, an intra-area	backbone path for one router can
	turn into an inter-area	path in	a router several hops closer to
	the destination. Hence,	intra-area backbone paths and inter-area
	paths must be of equal preference. We can safely compare their
	costs, preferring the path with	the smallest cost, due to the
	calculations in	Section	16.3.

	Thanks to Michael Briggs and Jeremy McCooey of the UNH
	InterOperability Lab for pointing out this problem.

    G.3	Incomplete resolution of virtual next hops

	One of the functions of	the calculation	in Section 16.3	is to
	determine the actual next hop(s) for those destinations	whose
	next hop was calculated	as a virtual link in Sections 16.1 and
	16.2.  After completion	of the calculation in Section 16.3, any
	paths calculated in Sections 16.1 and 16.2 that	still have
	unresolved virtual next	hops should be discarded.

    G.4	Routing	table lookup

	The routing table lookup algorithm in Section 11.1 has been
	modified to reflect current practice. The "best	match" routing
	table entry is now always selected to be the one providing the
	most specific (longest)	match. Suppose for example a router is
	forwarding packets to the destination 192.9.1.1. A routing table
	entry for 192.9.1/24 will always be a better match than	the
	routing	table entry for	192.9/16, regardless of	the routing
	table entries' path-types. Note	however	that when multiple paths

Moy			    Standards Track		      [Page 241]



RFC 2328		     OSPF Version 2		      April 1998

	are available for a given routing table	entry, the calculations
	in Sections 16.1, 16.2,	and 16.4 always	yield the paths	having
	the most preferential path-type. (Intra-area paths are the most
	preferred, followed in order by	inter-area, type 1 external and
	type 2 external	paths; see Section 11).

Moy			    Standards Track		      [Page 242]



RFC 2328		     OSPF Version 2		      April 1998

Security Considerations

    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 this memo.

    For	more information, see Sections 8.1, 8.2, and Appendix D.

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			    Standards Track		      [Page 243]



RFC 2328		     OSPF Version 2		      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			    Standards Track		      [Page 244]