RFC 1247
OSPF Version 2
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. TOS capability This item indicates whether the router will calculate separate routes based on TOS. For more information, see Sections 4.5 and 16.9. 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 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
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 [IP address, mask] pairs. Each
pair describes a range of IP addresses. 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. Routing information is condensed at area
boundaries. External to the area, a single route is advertised for
each address range.
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 internet mask. A single route would
be advertised external to the area, describing the entire subnetted
network.
Authentication type
Each area can be configured for a separate type of
authentication. See Appendix E for a discussion of the
defined authentication types.
External routing capability
Whether AS external advertisements will be flooded into/throughout
the area. If AS external advertisements 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 link that the router should
advertise into the area. There can be a separate cost configured
for each IP TOS. See Section 12.4.3 for more information.
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: 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 serial lines. Such a serial line is called "unnumbered". IP interface mask This denotes the portion of the IP interface address that identifies the attached network. This is often referred to as the subnet mask. Interface output cost(s) 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 links advertisement. There may be a separate cost for each IP Type of Service. The interface output cost(s) must always be greater than 0. RxmtInterval The number of seconds between link state advertisement 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. It will need to be larger on low speed serial lines and virtual links. 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. Link state advertisements 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 for the 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 multi-access 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 hello interval, the
faster topological changes will be detected, but more routing
traffic will ensue. Sample value for a X.25 PDN network: 30
seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval
The number of seconds that a router's Hellos have not been seen
before its neighbors declare the router down. This is also
advertised in the router's Hello Packets in the DeadInt 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.
Authentication key
This configured data allows the authentication procedure to generate
and/or verify the authentication field in the OSPF header. For
example, if the authentication type indicates simple password, the
authentication key would be a 64-bit password. This key would be
inserted directly into the OSPF header when originating routing
protocol packets. There could be a separate password for each
network.
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 links advertisements (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 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 Non-broadcast, multi-access network parameters OSPF treats a non-broadcast, multi-access network much like it treats a broadcast network. Since there many be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a networks links advertisement, which lists all routers attached to the non-broadcast network. However, due to the lack of broadcast capabilities, it is necessary to use configuration parameters in the Designated Router selection. These parameters need only be configured in those routers that are themselves eligible to become Designated Router (i.e., those router's whose DR Priority for the network is non-zero): List of all other attached routers The list of all other routers attached to the non-broadcast 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 non- broadcast 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 (hellos have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hellos to the dead neighbor. These Hellos 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 Host route parameters Host routes are advertised in network links advertisements 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. There may be multiple costs configured, one for each IP TOS. However, since the host probably has only a single connection to the internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing).
D. Required Statistics An OSPF implementation must provide a minimum set of statistics indicating the operational state of the protocol. These statistics must be accessible to the user; this will probably be accomplished through some sort of network management interface. It is hoped that these statistics will aid in the debugging of the implementation, and in the analysis of the protocol's performance. The statistics can be broken into two broad categories. The first consists of what we will call logging messages. These are messages produced in real time, with generally a single message produced as the result of a single protocol event. Such messages are also commonly referred to as traps. The second category will be referred to as cumulative statistics. These are counters whose value have collected over time, such as the count of link state retransmissions over the last hour. Also falling into this category are dumps of the various routing data structures. D.1 Logging messages A logging message should be produced on every significant protocol event. The major events are listed below. Most of these events indicate a topological change in the routing domain. However, some number of logging messages can be expected even when the routing domain remains intact for long periods of time. For example, link state originations will still happen due to the link state refresh timer firing. Any of the messages that refer to link state advertisements should print the area associated with the advertisement. There is no area associated with AS external link advertisements. The following list of logging messages indicate topological changes in the routing domain: T1 The state of a router interface changes. Interface state changes are documented in Section 9.3. In general, they will cause new link state advertisements to be originated. The logging message produced should include the interface's IP address (or other name), interface type (virtual link, etc.) and old and new state values (as documented in Section 9.1).
T2 The state of a neighbor changes. Neighbor state changes are
documented in Section 10.3. The logging message produced should
include the neighbor IP address, and old and new state values.
T3 The (Backup) Designated Router has changed on one of the attached
networks. See Section 9.4. The logging message produced should
include the network IP address, and the old and new (Backup)
Designated Routers.
T4 The router is originating a new instance of a link state
advertisement. The logging message produced should indicate the LS
type, Link State ID and Advertising Router associated with the
advertisement (see Section 12.4).
T5 The router has received a new instance of a link state
advertisement. The router receives these in Link State Update
packets. This will cause recalculation of the routing table. The
logging message produced should indicate the advertisement's LS
type, Link State ID and Advertising Router. The message should also
include the neighbor from whom the advertisement was received.
T6 An entry in the routing table has changed (see Section 11). The
logging message produced should indicate the Destination type,
Destination ID, and the old and new paths to the destination.
The following logging messages may indicate that there is a network
configuration error:
C1 A received OSPF packet is rejected due to errors in its IP/OSPF
header. The reasons for rejection are documented in Section 8.2.
They include OSPF checksum failure, authentication failure, and
inability to match the source with an active OSPF neighbor. The
logging message produced should include the IP source and
destination addresses, the router ID in the OSPF header, and the
reason for the rejection.
C2 An incoming Hello packet is rejected due to mismatches between the
Hello's parameters and those configured for the receiving interface
(see Section 10.5). This indicates a configuration problem on the
attached network. The logging message should include the Hello's
source, the receiving interface, and the non-matching parameters.
C3 An incoming Database Description packet, Link State Request Packet,
Link State Acknowledgment Packet or Link State Update packet is
rejected due to the source neighbor being in the wrong state (see
Sections 10.6, 10.7, 13.7 , and 13 respectively). This can be
normal when the identity of the network's Designated Router changes,
causing momentary disagreements over the validity of adjacencies.
The logging message should include the source neighbor, its state,
and the packet's type.
C4 A Database Description packet has been retransmitted. This may mean
that the value of RxmtInterval that has been configured for the
associated interface is too small. The logging message should
include the neighbor to whom the packet is being sent.
The following messages can be caused by packet transmission errors, or
software errors in an OSPF implementation:
E1 The checksum in a received link state advertisement is incorrect.
The advertisement is discarded (see Section 13). The logging
message should include the advertisement's LS type, Link State ID
and Advertising Router (which may be incorrect). The message should
also include the neighbor from whom the advertisement was received.
E2 During the aging process, it is discovered that one of the link
state advertisements in the database has an incorrect checksum.
This indicates memory corruption or a software error in the router
itself. The router should be dumped and restarted.
The following messages are an indication that a router has restarted,
losing track of its previous LS sequence number. Should these messages
continue, it may indicate the presence of duplicate Router IDs:
R1 Two link state advertisements have been seen, whose LS type, Link
State ID, Advertising Router and LS sequence number are the same,
yet with differing LS checksums. These are considered to be
different instances of the same advertisement. The instance with
the larger checksum is accepted as more recent (see Section 12.1.7,
13.1). The logging message should include the LS type, Link State
ID, Advertising Router, LS sequence number and the two differing
checksums.
R2 Two link state advertisements have been seen, whose LS type, Link
State ID, Advertising Router, LS sequence number and LS checksum are
the same, yet can be distinguished by their LS age fields. This
means that one of the advertisement's LS age is MaxAge, or the two
LS age fields differ by more than MaxAgeDiff. The logging message
should include the LS type, Link State ID, Advertising Router, LS
sequence number and the two differing ages.
R3 The router has received an instance of one of its self-originated
advertisements, that is considered to be more recent. This forces
the router to originate a new advertisement (see Section 13.4). The
logging message should include the advertisement's LS type, Link
State ID, and Advertising Router along with the neighbor from whom
the advertisement was received.
R4 An acknowledgment has been received for an instance of an
advertisement that is not currently contained in the router's
database (see Section 13.7). The logging message should detail the
instance being acknowledged and the database copy (if any), along
with the neighbor from whom the acknowledgment was received.
R5 An advertisement has been received through the flooding procedure
that is LESS recent the the router's current database copy (see
Section 13). The logging message should include the received
advertisement's LS type, Link State ID, Advertising Router, LS
sequence number, LS age and LS checksum. Also, the message should
display the neighbor from whom the advertisement was received.
The following messages are indication of normal, yet infrequent protocol
events. These messages will help in the interpretation of some of the
above messages:
N1 The Link state refresh timer has fired for one of the router's
self-originated advertisements (see Section 12.4). A new instance
of the advertisement must be originated. The message should include
the advertisement's LS type, Link State ID and Advertising Router.
N2 One of the advertisements in the router's link state database has
aged to MaxAge (see Section 14). At this point, the advertisement
is no longer included in the routing table calculation, and is
reflooded. The message should list the advertisement's LS type,
Link State ID and Advertising Router.
N3 An advertisement of age MaxAge has been flushed from the router's
database. This occurs after the advertisement has been acknowledged
by all adjacent neighbors. The message should list the
advertisement's LS type, Link State ID and Advertising Router.
D.2 Cumulative statistics
These statistics display collections of the routing data structures.
They should be able to be obtained interactively, through some kind of
network management facility.
All the following statistics displays, with the exception of the area
list, routing table and the AS external links, are specific to a single
area. As noted in Section 4, most OSPF protocol mechanisms work on each
area separately.
The following statistics displays should be available:
(1) A list of all the areas attached to the router, along with the
authentication type to use for the area, the number of router
interfaces attaching to the area, and the total number of nets and
routers belonging to the area.
For example, consider the router RT3 pictured in Figure 15. It has
interfaces to two separate areas, Area 1 and the backbone (Area 0).
Table 20 then indicates that the backbone is using a simple password
for authentication, and that Area 1 is not using any authentication.
The number of nets includes IP networks, subnets, and hosts (this is
the reason for 2 backbone nets -- they are the host routes
corresponding to the serial line between backbone routers RT6 and
RT10).
Area ID # ifcs AuType # nets # routers
______________________________________________
0 1 1 2 7
1 2 0 4 4
Table 20: Sample OSPF area display.
(2) A list of all the router's interfaces to an area, along with their
addresses, output cost, current state, the (Backup) Designated
Router for the attached network, and the number of neighbors
currently associated with the interface. Some number of these
neighbors will have become adjacent, the number of these is noted in
the display also.
Again consider router RT3 in Figure 15. Table 21 below indicates
that RT4 has been selected as Designated Router for network N3, and
router RT1 has been selected as Backup. Adjacencies have been
established to both of these routers. There are no routers besides
RT3 attached to network N4, so it becomes DR, yet still advertises
the network as a stub in its router links advertisements.
Ifc IP address state cost DR Backup # nbrs # adjs
__________________________________________________________________________
192.1.1.3 DR other 1 192.1.1.4 192.1.1.1 3 2
192.1.4.3 DR 2 192.1.4.3 none 0 0
Table 21: Sample OSPF interface display.
(3) The list of neighbors associated with a particular interface. Each
neighbor's IP address, router ID, state, and the length of the three
link state advertisement queues (see Section 10) to the neighbor is
displayed.
Suppose router RT4 is the Designated Router for network N3, and
router RT1 is the Backup Designated router. Suppose also that the
adjacency between router RT3 and RT1 has not yet fully formed. The
display of router RT3's neighbors (associated with its interface to
network N3) may then look like Table 22. The display indicates that
RT3 and RT1 are still in the database exchange procedure, Router RT3
has more Database Description packets to send to RT1, and RT1 has at
least one link state advertisement that RT3 doesn't. Also, there is
a single link state advertisement that has been flooded, but not
acknowledged, to each neighbor that participates in the flooding
procedure (state >= Exchng). (In the following examples we assume
that a router's Router ID is assigned to be its smallest IP
interface address).
Nbr IP address Router ID state LS rxmt len DB summ len LS req len
____________________________________________________________________________
192.1.1.1 192.1.1.1 Exchng 1 10 1
192.1.1.2 192.1.1.2 2-Way 0 0 0
192.1.1.4 192.1.1.4 Full 1 0 0
Table 22: Sample OSPF neighbor display.
(4) A list of the area's link state database. This is the same in all
of the routers attached to the area. It is composed of that area's
router links, network links, and summary links advertisements.
Also, the AS external link advertisements are a part of all the
areas' databases.
The link state database for Area 1 in Figure 15 might look like
Table 23 (compare this with Figure 7). Assume the the Designated
Router for network N3 is router RT4, as above. Both routers RT3 and
RT4 are originating summary link advertisements into Area 1, since
they are area border routers. Routers RT5 and RT7 are AS external
routers. Their location must be described in summary links
advertisements. Also, their AS external link advertisements are
flooded throughout the entire AS.
Router RT3 can locate its self-originated advertisements by looking
for its own router ID (192.1.1.3) in advertisements' Advertising
Router fields.
The LS sequence number, LS age, and LS checksum fields indicate the
advertisement's instance. Their values are stored in the
advertisement's link state header; we have not bothered to make up
values for the example.
LS type Link State ID Advertising Router LS seq no LS age LS checksum
_______________________________________________________________________________
1 192.1.1.1 192.1.1.1 * * *
1 192.1.1.2 192.1.1.2 * * *
1 192.1.1.3 192.1.1.3 * * *
1 192.1.1.4 192.1.1.4 * * *
_______________________________________________________________________________
2 192.1.1.4 192.1.1.4 * * *
_______________________________________________________________________________
3 Ia,Ib 192.1.1.3 * * *
3 N6 192.1.1.3 * * *
3 N7 192.1.1.3 * * *
3 N8 192.1.1.3 * * *
3 N9-N11,H1 192.1.1.3 * * *
3 Ia,Ib 192.1.1.4 * * *
3 N6 192.1.1.4 * * *
3 N7 192.1.1.4 * * *
3 N8 192.1.1.4 * * *
3 N9-N11,H1 192.1.1.4 * * *
4 RT5 192.1.1.3 * * *
4 RT7 192.1.1.3 * * *
4 RT5 192.1.1.4 * * *
4 RT7 192.1.1.4 * * *
_______________________________________________________________________________
4 N12 RT5's ID * * *
4 N13 RT5's ID * * *
4 N14 RT5's ID * * *
4 N12 RT7's ID * * *
LS type Link State ID Advertising Router LS seq no LS age LS checksum
_______________________________________________________________________________
4 N15 RT7's ID * * *
Table 23: Sample OSPF link state database display.
(5) The contents of any particular link state advertisement. For
example, a listing of the router links advertisement for Area 1,
with LS type = 1 and Link State ID = 192.1.1.3 is shown in Section
12.4.1.
(6) A listing of the entire routing table. Several examples are shown
in Section 11. The routing table is calculated from the combined
databases of each attached area (see Section 16). It may be
desirable to sort the routing table by Type of Service, or by
destination, or a combination of the two.
E. 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-area basis. Additional authentication data is configurable on a per-interface basis. For example, if an area uses a simple password scheme for authentication, a separate password may be configured for each network contained in the area. Authentication types 0 and 1 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 24. AuType Description _______________________________________________________________ 0 No authentication 1 Simple password All others Reserved for assignment by the IANA (iana@ISI.EDU) Table 24: OSPF authentication types. E.1 Autype 0 -- No authentication Use of this authentication type means that routing exchanges in the area are not authenticated. The 64-bit field in the OSPF header can contain anything; it is not examined on packet reception. E.2 Autype 1 -- Simple password 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. This guards against routers inadvertently coming up in the area. They must first be configured with their attached networks' passwords before they can join the routing domain.
F. Version 1 differences This section documents the changes between OSPF version 1 and OSPF version 2. The impetus for these changes derives from comments received on RFC 1131 and recent field experience with the OSPF protocol. Unfortunately, the changes are not backward-compatible. For that reason, OSPF version 1 will not interoperate with OSPF version 2. However, the changes are small in scope and should not greatly affect any existing implementations. In addition, some of the proposed changes should enable future protocol additions to be made in a backward- compatible manner (see Section F.4). F.1 Protocol Enhancements The following enhancements were made to the OSPF protocol. F.1.1 Stub area support In many Autonomous Systems, the majority of the OSPF link state database consists of AS external advertisements. In these Autonomous Systems, some OSPF areas may be organized in such a way that external advertisements can be safely ignored, enabling a reduction of the area's database size. This applies to OSPF areas where there is only a single exit/entry that is used by all externally addressed packets, or to cases where some sub-optimality of external routing is acceptable. Therefore, an OSPF area configuration option has been added (see Sections 3.6 and C.2) allowing the import of external advertisements to be disabled for an area. When this option is enabled, no AS external advertisements will be flooded into the area (Sections 13, 13.3 and 10.3). Instead, within the area all data traffic to external destinations will follow a (per-area) default route. These areas are called "stub" areas. To implement this, all area border routers attached to stub areas will originate a default summary link advertisement for the area (Section 12.4.3). This will direct all internal routers to an area border router when forwarding externally addressed packets. In addition, to ensure that stub areas are configured consistently, an Options field has been added to OSPF Hello packets (Sections A.2 and A.3.2). A bit is reset in the Options field indicating that the attached area is a stub area (Section 9.5). A router will not accept a neighbor's hellos unless they both agree on the area's ability to process AS external advertisements (Section 10.5). In this way, a system administrator will be able to discover incorrectly configured routers, and data traffic will be routed around them (in order to avoid potential looping situations) until their
configuration can be repaired. F.1.2 Optional TOS support In OSPF there is conceptually a separate routing table for each TOS; the calculations detailed in steps 1-5 of Section 16 must be done separately for each TOS. (Note however that link and summary costs need not be specified separately for each TOS; costs for unspecified TOS values default to the cost of TOS 0). In version 1 of the OSPF specification, all OSPF routers were required to route based on TOS. However, producing a separate routing table for each TOS may prove costly, both in terms of memory and processor resources. For this reason, version 2 allows the system administrator to configure routers to calculate/use only a single routing table (the TOS 0 table). When this is done, some traffic may take non-optimal routes. But all packets will still be delivered, and routing will remain loop free (see Section 2.4). In order to avoid routing loops, a router (router X) using a single table must communicate this information to its peers. This is done by resetting the new TOS-capable bit in the router X's router links advertisement (Section 12.4.1). Then, when its peers perform the Dijkstra calculation (Section 16.1) for non-zero TOS values, they will omit router X from the calculation. In effect, an attempt will be made to bypass router X when forwarding non-zero TOS traffic. Summary link and AS external link advertisements can also indicate their non- availability for non-zero TOS traffic (Sections 12.4.3 and 12.4.4). The result may be that no route can be found for some non-zero value of TOS. When this happens, the packet is routed along the TOS 0 route instead (Section 11.1). It is still mandatory for all OSPF implementations to be able to construct separate routing tables for each TOS value, if desired by the system administrator. F.1.3 Preventing external extra-hops In some cases, version 1 of the OSPF specification will introduce extra-hops when calculating routes to external destinations. This is because it is implicit in the format of AS external advertisements that packets should be forwarded through the advertising router. However, consider the situation where multiple OSPF routers share a LAN with an external router (call it router Y) , and only one OSPF router (call it router X) exchanges routing information with Y. The OSPF routers on the
LAN other than X will forward packets destined for Y and beyond through X, generating an extra hop (see Section 2.2). To fix this, a new field has been added to AS external advertisements. This field (called the forwarding address) will indicate the router address to which packets should be forwarded (Section 12.4.4). In the above example, router X will put Y's IP address into this field. If the field is 0, packets are (as before) forwarded to the originator of the advertisement. A different forwarding address can be specified for each TOS value. Whenever possible, this new field should be set to 0. This is because setting it to an actual router address incurs additional cost during the routing table build process (Section 16.4). Besides preventing extra-hops, there are two other applications for this field. The first is for use by "route servers". Using the forwarding address, a router in the middle of the Autonomous System can gather external routing information and originate AS external advertisements that specify the correct exit route to use for each external destination (Section 2.2). The other application possibly enables the reduction of the number of AS external advertisements that need be imported. Suppose in the example at the beginning of this section that there are two routers (X and Z) exchanging EGP information with the non-OSPF router Y. It is then likely that both X and Z will originate the same set of external routes. Two AS external advertisements that specify the same (non-zero) forwarding address, destination and cost are obviously functionally equivalent, regardless of their originators (advertising routers). The OSPF specification dictates that the advertisement originated by the router with the largest Router ID will always be used. This allows the other router to flush its equivalent advertisement (Section 12.4.4). F.2 Corrected problems The following problems in OSPF version 1 have been corrected in version 2. F.2.1 LS sequence number space changes The LS sequence number space has been changed from version 1's lollipop shape to a linear sequence space (Section 12.1.6). Sequence numbers will now be compared as signed 32-bit integers. Link state advertisements having larger sequence numbers will be considered more recent. The sequence number space will still begin at (-N+1) (where N =
2**31). The value of -N remains reserved. The LS sequence number of successive instances of an advertisement will continue to be incremented until it reaches the maximum possible value: N-1. At this point, when a new instance of the advertisement must be originated (due either to topological change of the expiration of the LS refresh timer) the current instance must first be "prematurely aged". There will be a new section discussing premature aging (Section 14.1). This is a method for flushing a link state advertisement from the routing domain: the advertisement's age is set to MaxAge and advertisement is reflooded just as if it were a newly received advertisement. As soon as the new flooding is acknowledged by all of the router's adjacent neighbors, the advertisement is flushed from the database. Premature aging can also be used when, for example, a previously advertised external route is no longer reachable. In this circumstance, premature aging is preferable to the alternative, which is to originate a new advertisement for the destination specifying a metric of LSInfinity. A router may only prematurely age its own (self-originated) link state advertisements. These are the link state advertisements having the router's own OSPF router ID in the Advertising Router field. F.2.2 Flooding of unexpected MaxAge advertisements Version 1 of the OSPF omitted the handling of a special case in the flooding procedure: the reception of a MaxAge advertisement that has no database instance. A paragraph has been added to Section 13 to deal with this occurrence. Without this paragraph, retransmissions of MaxAge advertisements could possibly delay their being flushed from the routing domain. F.2.3 Virtual links and address ranges When summarizing information into a virtual link's transit area, version 2 of the OSPF specification prohibits the collapsing of multiple backbone IP networks/subnets into a single summary link. This restriction has been added to deal with certain anomalous OSPF area configurations. See Sections 15 and 12.4.3 for more information.
F.2.4 Routing table lookup explained When forwarding an IP data packet, a router looks up the packet's IP destination in the routing table. This determines the packet's next hop. A new section (Section 11.1) has been added describing the routing table lookup (instead of just specifying a "best match"). This section clarifies OSPF's four level routing hierarchy (i.e., intra-area, inter- area, external type 1 and external type 2 routes). It also specifies the effect of TOS on routing. F.2.5 Sending Link State Request packets OSPF Version 2 eases the restrictions on the sending of Link State Request packets. Link State Request packets can now be sent to a neighboring router before a complete set of Database Description packets have been exchanged. This enables a more efficient use of a router's memory resources; an OSPF version 2 implementation may limit the size of the neighbor Link state request lists. See Sections 10.9, 10.7 and 10.3 for more details. F.2.6 Changes to the Database description process The specification has been modified to ensure that, when two routers are synchronizing their databases during the Database Description process, none of the component link state advertisements can have their sequence numbers decrease. A link state advertisement's sequence number decreases when it is flushed from the routing domain via premature- aging, and then reoriginated with the smallest sequence number 0x80000001 (see Section 14.1). So the specification now dictates that an advertisement cannot be flushed from a router's database until both a) it no longer appears on any neighbor Link State Retransmission lists and b) none of the router's neighbors are in states Exchange or Loading. See Sections 13 (step 4c) and 14.1 for more details. In addition, a new step has been added to the flooding procedure (Section 13) in order to make the Database Description process more robust. This step detects when a neighbor lists one instance of an advertisement in its Database Description packets, but responds to Link State Request packets by sending another (earlier) instance. This behavior now causes the event BadLSReq to be generated, which restarts the Database Description process with the neighbor. In OSPF version 1, the neighbor event BadLSReq erroneously did not restart the Database Description process.
F.2.7 Receiving OSPF Hello packets The section detailing the receive processing of OSPF Hello packets (Section 10.5) has been modified to include the generation of the neighbor Backup Seen event. In addition, the section detailing the Designated Router election algorithm (Section 9.4) has been modified to include the algorithm's initial state. F.2.8 Network mask defined for default route The network mask for the default route, when it appears as the destination in either an AS external link advertisement or in a summary link advertisement, has been set to 0.0.0.0. See Sections A.4.4 and A.4.5 for more details. F.2.9 Rate limit imposed on flooding When an advertisement is installed in the link state database, it is timestamped. The flooding procedure is then not allowed to install a new instance of the advertisement until MinLSInterval seconds have elapsed. This enforces a rate limit on the flooding procedure; a new instance can be flooded only once every MinLSInterval seconds. This guards against routers that disregard the limit on self-originated advertisements (already present in OSPF version 1) of one origination every MinLSInterval seconds. For more information, see Section 13. F.3 Packet format changes The following changes have been made to the format of OSPF packets and link state advertisements. Some of these changes were required to support the added functionality listed above. Other changes were made to further simplify the parsing of OSPF packets. F.3.1 Adding a Capability bitfield To support the new "stub area" and "optional TOS" features, a bitfield listing protocol capabilities has been added to the Hello packet, Database Description packet and all link state advertisements. When used in Hello packets, this 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 link state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to route traffic around reduced
functionality router, by excluding them from parts of the routing table calculation. See Section A.2 for more details. F.3.2 Packet simplification To simplify the format of Database Description packets and Link State Acknowledgment packets, their description of link state advertisements has been modified. Each advertisement is now be described by its 20- byte link state header (see Section A.4). This does not consume any additional space in the packets. The one additional piece of information that will be present is the LS length. However, this field need not be used when processing the Database Description and Link State Acknowledgment packets. F.3.3 Adding forwarding addresses to AS external advertisements As discussed in Section F.1.3, a forwarding address field has been added to the AS external advertisement. F.3.4 Labelling of virtual links Virtual links will be labelled as such in router links advertisements. This separates virtual links from unnumbered point-to-point links, allowing all backbone routers to discover whether any virtual links are in use. See Section 12.4.1 for more details. F.3.5 TOS costs ordered When a link state advertisement specifies a separate cost depending on TOS, these costs must be ordered by increasing TOS value. For example, the cost for TOS 16 must always follow the cost for TOS 8. F.3.6 OSPF's TOS encoding redefined The way that OSPF encodes TOS in its link state advertisements has been redefined in version 2. OSPF's encoding of the Delay (D), Throughput (T) and Reliability (R) TOS flags defined by [RFC 791] is described in Section 12.3.
F.4 Backward-compatibility provisions Additional functionality will probably be added to OSPF in the future. One example of this is a multicast routing capability, which is currently under development. In order to be able to add such features in a backward-compatible manner, the following provisions have been made in the OSPF specification. New capabilities will probably involve the introduction of new link state advertisements. If a router receives a link state advertisement of unknown type during the flooding procedure, the advertisement is simply ignored (Section 13. The router should not attempt to further flood the advertisement, nor acknowledge it. The advertisement should not be installed into the link state database. If the router receives an advertisement of unknown type during the Database Description process, this is an error (see Sections 10.6 and 10.3). The Database Description process is then restarted. There is also an Options field in both the Hello packets, Database Description packets and the link state advertisement headers. Unrecognized capabilities found in these places should be ignored, and should not affect the normal processing of protocol packets/link state advertisements (see Sections 10.5 and 10.6). Routers will originate their Hello packets, Database Description packets and link state advertisements with unrecognized capabilities set to 0 (see Sections 9.5, 10.8 and 12.1.2).
Security Considerations All OSPF protocol exchanges are authenticated. This is accomplished through authentication fields contained in the OSPF packet header. For more information, see Sections 8.1, 8.2, and Appendix E. Author's Address John Moy Proteon, Inc. 2 Technology Drive Westborough, MA 01581 Phone: (508) 898-2800 EMail: jmoy@proteon.com