area's parameters, and all routers attached to a network must agree
on that network's HelloInterval and RouterDeadInterval.
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. 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 of [Ref1]), or they will persist
for up to MaxAge minutes.
Because the size of the Router ID is smaller than an IPv6 address,
it cannot be set to one of the router's IPv6 addresses (as is
commonly done for IPv4). Possible Router ID assignment procedures
for IPv6 include: a) assign the IPv6 Router ID as one of the
router's IPv4 addresses or b) assign IPv6 Router IDs through some
local administrative procedure (similar to procedures used by
manufacturers to assign product serial numbers).
The Router ID of 0.0.0.0 is reserved, and should not be used.
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 is reserved for the backbone.
List of address ranges
Address ranges control the advertisement of routes across
area boundaries. Each address range consists of the
following items:
[IPv6 prefix, prefix length]
Describes the collection of IPv6 addresses contained in
the address range.
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
inter-area-prefix-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.
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 inter-area 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 of [Ref1].
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 inter-area-prefix-LSA that the
router should advertise into the area. See Section 12.4.3.1 of
[Ref1] for more information.
C.3 Router interface parameters
Some of the configurable router interface parameters (such as Area
ID, HelloInterval and RouterDeadInterval) actually imply properties
of the attached links, and therefore must be consistent across all
the routers attached to that link. The parameters that must be
configured for a router interface are:
IPv6 link-local address
The IPv6 link-local address associated with this interface. May
be learned through auto-configuration.
Area ID
The OSPF area to which the attached link belongs.
Instance ID
The OSPF protocol instance associated with this OSPF interface.
Defaults to 0.
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([Ref3]).
IPv6 prefixes
The list of IPv6 prefixes to associate with the link. These will
be advertised in intra-area-prefix-LSAs.
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-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 link. 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 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 link. 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 link. 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:
30 seconds. Sample value for a local area network (LAN): 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 link.
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
most of the parameters associated with a router interface (see
Section C.3). Virtual links do not have link-local addresses, but
instead use one of the router's global-scope or site-local IPv6
addresses as the IP source in OSPF protocol packets it sends along
the virtual link. Router Priority is not used on virtual links.
Interface output cost is not configured on virtual links, but is
dynamically set to be the cost of the intra-area path between the two
endpoint 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.
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.
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 configured with its Router ID and IPv6 link-local
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 configured with its Router ID
and IPv6 link-local address on the network. Designated Routers are
not elected on Point-to-MultiPoint networks, so the Designated Router
eligibility of configured neighbors is undefined.
C.7 Host route parameters
Host prefixes are advertised in intra-area-prefix-LSAs. They
indicate either internal router addresses, router interfaces to
point-to-point networks, looped router interfaces, or IPv6 hosts that
are directly connected to the router (e.g., via a PPP connection).
For each host directly connected to the router, the following items
must be configured:
Host IPv6 prefix
The IPv6 prefix belonging to 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(s) in many
cases is unimportant (i.e., will have no effect on routing).
Area ID
The OSPF area to which the host's prefix belongs.
Security Considerations
When running over IPv6, OSPF relies on the IP Authentication Header
(see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20])
to ensure integrity and authentication/confidentiality of routing
exchanges.
Most OSPF implementations will be running on systems that support
multiple protocols, many of them having independent security
assumptions and domains. When IPSEC is used to protect OSPF packets,
it is important for the implementation to check the IPSEC SA, and
local SA database to make sure that the packet originates from a
source THAT IS TRUSTED FOR OSPF PURPOSES.
Authors' Addresses
Rob Coltun
Siara Systems
300 Ferguson Drive
Mountain View, CA 94043
Phone: (650) 390-9030
EMail: rcoltun@siara.com
Dennis Ferguson
Juniper Networks
385 Ravendale Drive
Mountain View, CA 94043
Phone: +1 650 526 8004
EMail: dennis@juniper.com
John Moy
Sycamore Networks, Inc.
10 Elizabeth Drive
Chelmsford, MA 01824
Phone: (978) 367-2161
Fax: (978) 250-3350
EMail: jmoy@sycamorenet.com
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.