| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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.
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.
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):
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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.
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.
# 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.
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.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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].
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.
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.
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 RFC1583 ([Ref9]). When set to "disabled", the
preference rules are those stated in Section 16.4.1, which
prevent routing loops when AS- external-LSAs for the same
destination have been originated from different areas (see
Section G.7). 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.
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:
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 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
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.
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]).
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.
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.
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
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
contains a new field called the "cryptographic sequence number".
This field is initialized to zero, and is also set to zero 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:
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.
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
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.
(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 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.
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: