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 RFC 1583 ([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. 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
contains a new field called the "cryptographic sequence number".
This field is initialized to zero, and is also set to zero
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Usage of the Authentication field
in the OSPF packet header when Cryptographic
Authentication is employed
whenever the neighbor's state transitions to "Down". Whenever an
OSPF packet is accepted as authentic, the cryptographic sequence
number is set to the received packet's sequence number.
This specification does not provide a rollover procedure for the
cryptographic sequence number. When the cryptographic sequence
number that the router is sending hits the maximum value, the
router should reset the cryptographic sequence number that it is
sending back to 0. After this is done, the router's neighbors
will reject the router's OSPF packets for a period of
RouterDeadInterval, and then the router will be forced to
reestablish all adjacencies over the interface. However, it is
expected that many implementations will use "seconds since
reboot" (or "seconds since 1960", etc.) as the cryptographic
sequence number. Such a choice will essentially prevent
rollover, since the cryptographic sequence number field is 32
bits in length.
The OSPF Cryptographic authentication option does not provide
confidentiality.
When cryptographic authentication is used, the 64-bit
Authentication field in the standard OSPF packet header is
redefined as shown in Figure 18. The new field definitions are
as follows:
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:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in Step 6
of Section D.4.3.
(c) The calculated and received digests are compared. If
they do not match, the OSPF packet is discarded. If
they do match, the OSPF protocol packet is accepted
as authentic, and the "cryptographic sequence
number" in the neighbor's data structure is set to
the sequence number found in the packet's OSPF
header.
E. An algorithm for assigning Link State IDs
The Link State ID in AS-external-LSAs and summary-LSAs is usually
set to the described network's IP address. However, if necessary one
or more of the network's host bits may be set in the Link State ID.
This allows the router to originate separate LSAs for networks
having the same address, yet different masks. Such networks can
occur in the presence of supernetting and subnet 0s (see [Ref10]).
This appendix gives one possible algorithm for setting the host bits
in Link State IDs. The choice of such an algorithm is a local
decision. Separate routers are free to use different algorithms,
since the only LSAs affected are the ones that the router itself
originates. The only requirement on the algorithms used is that the
network's IP address should be used as the Link State ID whenever
possible; this maximizes interoperability with OSPF implementations
predating RFC 1583.
The algorithm below is stated for AS-external-LSAs. This is only
for clarity; the exact same algorithm can be used for summary-LSAs.
Suppose that the router wishes to originate an AS-external-LSA for a
network having address NA and mask NM1. The following steps are then
used to determine the LSA's Link State ID:
(1) Determine whether the router is already originating an AS-
external-LSA with Link State ID equal to NA (in such an LSA the
router itself will be listed as the LSA's Advertising Router).
If not, the Link State ID is set equal to NA and the algorithm
terminates. Otherwise,
(2) Obtain the network mask from the body of the already existing
AS-external-LSA. Call this mask NM2. There are then two cases:
o NM1 is longer (i.e., more specific) than NM2. In this case,
set the Link State ID in the new LSA to be the network
[NA,NM1] with all the host bits set (i.e., equal to NA or'ed
together with all the bits that are not set in NM1, which is
network [NA,NM1]'s broadcast address).
o NM2 is longer than NM1. In this case, change the existing
LSA (having Link State ID of NA) to reference the new
network [NA,NM1] by incrementing the sequence number,
changing the mask in the body to NM1 and inserting the cost
of the new network. Then originate a new LSA for the old
network [NA,NM2], with Link State ID equal to NA or'ed
together with the bits that are not set in NM2 (i.e.,
network [NA,NM2]'s broadcast address).
The above algorithm assumes that all masks are contiguous; this
ensures that when two networks have the same address, one mask is
more specific than the other. The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address. Given these two assumptions, the above algorithm
always produces unique Link State IDs. The above algorithm can also
be reworded as follows: When originating an AS-external-LSA, try to
use the network number as the Link State ID. If that produces a
conflict, examine the two networks in conflict. One will be a subset
of the other. For the less specific network, use the network number
as the Link State ID and for the more specific use the network's
broadcast address instead (i.e., flip all the "host" bits to 1). If
the most specific network was originated first, this will cause you
to originate two LSAs at once.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
F. Multiple interfaces to the same network/subnet
There are at least two ways to support multiple physical interfaces
to the same IP subnet. Both methods will interoperate with
implementations of RFC 1583 (and of course this memo). The two
methods are sketched briefly below. An assumption has been made that
each interface has been assigned a separate IP address (otherwise,
support for multiple interfaces is more of a link-level or ARP issue
than an OSPF issue).
Method 1:
Run the entire OSPF functionality over both interfaces, sending
and receiving hellos, flooding, supporting separate interface
and neighbor FSMs for each interface, etc. When doing this all
other routers on the subnet will treat the two interfaces as
separate neighbors, since neighbors are identified (on broadcast
and NBMA networks) by their IP address.
Method 1 has the following disadvantages:
(1) You increase the total number of neighbors and adjacencies.
(2) You lose the bidirectionality test on both interfaces, since
bidirectionality is based on Router ID.
(3) You have to consider both interfaces together during the
Designated Router election, since if you declare both to be
DR simultaneously you can confuse the tie-breaker (which is
Router ID).
Method 2:
Run OSPF over only one interface (call it the primary
interface), but include both the primary and secondary
interfaces in your Router-LSA.
Method 2 has the following disadvantages:
(1) You lose the bidirectionality test on the secondary
interface.
(2) When the primary interface fails, you need to promote the
secondary interface to primary status.
G. Differences from RFC 2178
This section documents the differences between this memo and RFC
2178. All differences are backward-compatible. Implementations of
this memo and of RFCs 2178, 1583, and 1247 will interoperate.
G.1 Flooding modifications
Three changes have been made to the flooding procedure in
Section 13.
The first change is to step 4 in Section 13. Now MaxAge LSAs are
acknowledged and then discarded only when both a) there is no
database copy of the LSA and b) none of router's neighbors are
in states Exchange or Loading. In all other cases, the MaxAge
LSA is processed like any other LSA, installing the LSA in the
database and flooding it out the appropriate interfaces when the
LSA is more recent than the database copy (Step 5 of Section
13). This change also affects the contents of Table 19.
The second change is to step 5a in Section 13. The MinLSArrival
check is meant only for LSAs received during flooding, and
should not be performed on those LSAs that the router itself
originates.
The third change is to step 8 in Section 13. Confusion between
routers as to which LSA instance is more recent can cause a
disastrous amount of flooding in a link-state protocol (see
[Ref26]). OSPF guards against this problem in two ways: a) the
LS age field is used like a TTL field in flooding, to eventually
remove looping LSAs from the network (see Section 13.3), and b)
routers refuse to accept LSA updates more frequently than once
every MinLSArrival seconds (see Section 13). However, there is
still one case in RFC 2178 where disagreements regarding which
LSA is more recent can cause a lot of flooding traffic:
responding to old LSAs by reflooding the database copy. For
this reason, Step 8 of Section 13 has been amended to only
respond with the database copy when that copy has not been sent
in any Link State Update within the last MinLSArrival seconds.
G.2 Changes to external path preferences
There is still the possibility of a routing loop in RFC 2178
when both a) virtual links are in use and b) the same external
route is being imported by multiple ASBRs, each of which is in a
separate area. To fix this problem, Section 16.4.1 has been
revised. To choose the correct ASBR/forwarding address, intra-
area paths through non-backbone areas are always preferred.
However, intra-area paths through the backbone area (Area 0) and
inter-area paths are now of equal preference, and must be
compared solely based on cost.
The reasoning behind this change is as follows. When virtual
links are in use, an intra-area backbone path for one router can
turn into an inter-area path in a router several hops closer to
the destination. Hence, intra-area backbone paths and inter-area
paths must be of equal preference. We can safely compare their
costs, preferring the path with the smallest cost, due to the
calculations in Section 16.3.
Thanks to Michael Briggs and Jeremy McCooey of the UNH
InterOperability Lab for pointing out this problem.
G.3 Incomplete resolution of virtual next hops
One of the functions of the calculation in Section 16.3 is to
determine the actual next hop(s) for those destinations whose
next hop was calculated as a virtual link in Sections 16.1 and
16.2. After completion of the calculation in Section 16.3, any
paths calculated in Sections 16.1 and 16.2 that still have
unresolved virtual next hops should be discarded.
G.4 Routing table lookup
The routing table lookup algorithm in Section 11.1 has been
modified to reflect current practice. The "best match" routing
table entry is now always selected to be the one providing the
most specific (longest) match. Suppose for example a router is
forwarding packets to the destination 192.9.1.1. A routing table
entry for 192.9.1/24 will always be a better match than the
routing table entry for 192.9/16, regardless of the routing
table entries' path-types. Note however that when multiple paths
are available for a given routing table entry, the calculations
in Sections 16.1, 16.2, and 16.4 always yield the paths having
the most preferential path-type. (Intra-area paths are the most
preferred, followed in order by inter-area, type 1 external and
type 2 external paths; see Section 11).
Security Considerations
All OSPF protocol exchanges are authenticated. OSPF supports
multiple types of authentication; the type of authentication in use
can be configured on a per network segment basis. One of OSPF's
authentication types, namely the Cryptographic authentication
option, is believed to be secure against passive attacks and provide
significant protection against active attacks. When using the
Cryptographic authentication option, each router appends a "message
digest" to its transmitted OSPF packets. Receivers then use the
shared secret key and received digest to verify that each received
OSPF packet is authentic.
The quality of the security provided by the Cryptographic
authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all
communicating OSPF implementations. It also requires that all
parties maintain the secrecy of the shared secret key.
None of the OSPF authentication types provide confidentiality. Nor
do they protect against traffic analysis. Key management is also not
addressed by this memo.
For more information, see Sections 8.1, 8.2, and Appendix D.
Author's Address
John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: 978-952-1367
Fax: 978-392-2075
EMail: jmoy@casc.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
