the same topological database. This database consists of the collection
of link state advertisements received from each router belonging to the
area. From this database each router calculates a shortest-path tree,
with itself as root. This shortest-path tree in turn yields a routing
table for the protocol.
4.1 Inter-area routing
The previous section described the operation of the protocol within a
single area. For intra-area routing, no other routing information is
pertinent. In order to be able to route to destinations outside of the
area, the area border routers inject additional routing information into
the area. This additional information is a distillation of the rest of
the Autonomous System's topology.
This distillation is accomplished as follows: Each area border router is
by definition connected to the backbone. Each area border router
summarizes the topology of its attached areas for transmission on the
backbone, and hence to all other area border routers. A area border
router then has complete topological information concerning the
backbone, and the area summaries from each of the other area border
routers. From this information, the router calculates paths to all
destinations not contained in its attached areas. The router then
advertises these paths to its attached areas. This enables the area's
internal routers to pick the best exit router when forwarding traffic to
destinations in other areas.
4.2 AS external routes
Routers that have information regarding other Autonomous Systems can
flood this information throughout the AS. This external routing
information is distributed verbatim to every participating router.
There is one exception: external routing information is not flooded into
"stub" areas (see Section 3.6).
To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of these AS
boundary routers are summarized by the (non-stub) area border routers.
4.3 Routing protocol packets
The OSPF protocol runs directly over IP, using IP protocol 89. OSPF
does not provide any explicit fragmentation/reassembly support. When
fragmentation is necessary, IP fragmentation/reassembly is used. OSPF
protocol packets have been designed so that large protocol packets can
generally be split into several smaller protocol packets. This practice
is recommended; IP fragmentation should be avoided whenever possible.
Routing protocol packets should always be sent with the IP TOS field set
to 0. If at all possible, routing protocol packets should be given
preference over regular IP data traffic, both when being sent and
received. As an aid to accomplishing this, OSPF protocol packets should
have their IP precedence field set to the value Internetwork Control
(see [RFC791]).
All OSPF protocol packets share a common protocol header that is
described in Appendix A. The OSPF packet types are listed below in
Table 8. Their formats are also described in Appendix A.
Type Packet name Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
Table 8: OSPF packet types.
OSPF's Hello protocol uses Hello packets to discover and maintain
neighbor relationships. The Database Description and Link State Request
packets are used in the forming of adjacencies. OSPF's reliable update
mechanism is implemented by the Link State Update and Link State
Acknowledgment packets.
Each Link State Update packet carries a set of new link state
advertisements one hop further away from their point of origination. A
single Link State Update packet may contain the link state
advertisements of several routers. Each advertisement is tagged with
the ID of the originating router and a checksum of its link state
contents. The five different types of OSPF link state advertisements
are listed below in Table 9.
LS Advertisement Advertisement description
type name
____________________________________________________________________________
1 Router links advs. Originated by all routers. This
advs. advertisement describes the collected
states of the router's interfaces to an
area. Flooded throughout a single area
only.
____________________________________________________________________________
2 Network links Originated for multi-access networks by
advs. the Designated Router. This
advertisement contains the list of
routers connected to the network.
Flooded throughout a single area only.
LS Advertisement Advertisement description
type name
____________________________________________________________________________
____________________________________________________________________________
3,4 Summary link Originated by area border routers, and
advs. flooded throughout their associated
area. Each summary link advertisement
describes a route to a destination
outside the area, yet still inside the
AS (i.e., an inter-area route). Type 3
advertisements describe routes to
networks. Type 4 advertisements
describe routes to AS boundary routers.
____________________________________________________________________________
5 AS external Originated by AS boundary routers, and
link advs. flooded throughout the AS. Each external
advertisement describes a route to a
destination in another Autonomous
System. Default routes for the AS can
also be described by AS external advertisements.
Table 9: OSPF link state advertisements.
As mentioned above, OSPF routing packets (with the exception of Hellos)
are sent only over adjacencies. Note that this means that all protocol
packets travel a single IP hop, except those that are sent over virtual
adjacencies. The IP source address of an OSPF protocol packet is one
end of a router adjacency, and the IP destination address is either the
other end of the adjacency or an IP multicast address.
4.4 Basic implementation requirements
An implementation of OSPF requires the following pieces of system
support:
Timers
Two different kind of timers are required. The first kind, called
single shot timers, fire once and cause a protocol event to be
processed. The second kind, called interval timers, fire at
continuous intervals. These are used for the sending of packets at
regular intervals. A good example of this is the regular broadcast
of Hello packets (on broadcast networks). The granularity of both
kinds of timers is one second.
Interval timers should be implemented to avoid drift. In some
router implementations, packet processing can affect timer
execution. When multiple routers are attached to a single network,
all doing broadcasts, this can lead to the synchronization of
routing packets (which should be avoided). If timers cannot be
implemented to avoid drift, small random amounts should be added
to/subtracted from the timer interval at each firing.
IP multicast
Certain OSPF packets use IP multicast. Support for receiving and
sending IP multicasts, along with the appropriate lower-level
protocol support, is required. These IP multicast packets never
travel more than one hop. For information on IP multicast, see [RFC
1112].
Lower-level protocol support
The lower level protocols referred to here are the network access
protocols, such as the Ethernet data link layer. Indications must
be passed from from these protocols to OSPF as the network interface
goes up and down. For example, on an ethernet it would be valuable
to know when the ethernet transceiver cable becomes unplugged.
Non-broadcast lower-level protocol support
Remember that non-broadcast networks are multi-access networks such
as a X.25 PDN. On these networks, the Hello Protocol can be aided
by providing an indication to OSPF when an attempt is made to send a
packet to a dead or non-existent router. For example, on a PDN a
dead router may be indicated by the reception of a X.25 clear with
an appropriate cause and diagnostic, and this information would be
passed to OSPF.
List manipulation primitives
Much of the OSPF functionality is described in terms of its
operation on lists of link state advertisements. For example, the
advertisements that will be retransmitted to an adjacent router
until acknowledged are described as a list. Any particular
advertisement may be on many such lists. An OSPF implementation
needs to be able to manipulate these lists, adding and deleting
constituent advertisements as necessary.
Tasking support
Certain procedures described in this specification invoke other
procedures. At times, these other procedures should be executed
in-line, that is, before the current procedure is finished. This is
indicated in the text by instructions to execute a procedure. At
other times, the other procedures are to be executed only when the
current procedure has finished. This is indicated by instructions
to schedule a task.
4.5 Optional OSPF capabilities
The OSPF protocol defines several optional capabilities. A router
indicates the optional capabilities that it supports in its OSPF Hello
packets, Database Description packets and in its link state
advertisements. This enables routers supporting a mix of optional
capabilities to coexist in a single Autonomous System.
Some capabilities must be supported by all routers attached to a
specific area. In this case, a router will not accept a neighbor's
Hello unless there is a match in reported capabilities (i.e., a
capability mismatch prevents a neighbor relationship from forming). An
example of this is the external routing capability (see below).
Other capabilities can be negotiated during the database synchronization
process. This is accomplished by specifying the optional capabilities
in Database Description packets. A capability mismatch with a neighbor
is this case will result in only a subset of link state advertisements
being exchanged between the two neighbors.
The routing table build process can also be affected by the
presence/absence of optional capabilities. For example, since the
optional capabilities are reported in link state advertisements, routers
incapable of certain functions can be avoided when building the shortest
path tree. An example of this is the TOS routing capability (see
below).
The current OSPF optional capabilities are listed below. See Section
A.2 for more information.
External routing capability
Entire OSPF areas can be configured as "stubs" (see Section 3.6).
AS external advertisements will not be flooded into stub areas.
This capability is represented by the E-bit in the OSPF options
field (see Section A.2). In order to ensure consistent
configuration of stub areas, all routers interfacing to such an area
must have the E-bit clear in their Hello packets (see Sections 9.5
and 10.5).
TOS capability
All OSPF implementations must be able to calculate separate routes
based on IP Type of Service. However, to save routing table space
and processing resources, an OSPF router can be configured to ignore
TOS when forwarding packets. In this case, the router calculates
routes for TOS 0 only. This capability is represented by the T-bit
in the OSPF options field (see Section A.2). TOS-capable routers
will attempt to avoid non-TOS-capable routers when calculating non-
zero TOS paths.
5. Protocol Data Structures
The OSPF protocol is described in this specification in terms of its
operation on various protocol data structures. The following list
comprises the top-level OSPF data structures. Any initialization that
needs to be done is noted. Areas, OSPF interfaces and neighbors also
have associated data structures that are described later in this
specification.
Router ID
a 32-bit number that uniquely identifies this router in the AS. One
possible implementation strategy would be to use the smallest IP
interface address belonging to the router.
Pointers to area structures
Each one of the areas to which the router is connected has its own
data structure. This data structure describes the working of the
basic algorithm. Remember that each area runs a separate copy of
the basic algorithm.
Pointer to the backbone structure
The basic algorithm operates on the backbone as if it were an area.
For this reason the backbone is represented as an area structure.
Virtual links configured
The virtual links configured with this router as one endpoint. In
order to have configured virtual links, the router itself must be an
area border router. Virtual links are identified by the Router ID
of the other endpoint -- which is another area border router. These
two endpoint routers must be attached to a common area, called the
virtual link's transit area. Virtual links are part of the
backbone, and behave as if they were unnumbered point-to-point
networks between the two routers. A virtual link uses the intra-
area routing of its transit area to forward packets. Virtual links
are brought up and down through the building of the shortest-path
trees for the transit area.
List of external routes
These are routes to destinations external to the Autonomous System,
that have been gained either through direct experience with another
routing protocol (such as EGP), or through configuration
information, or through a combination of the two (e.g., dynamic
external info. to be advertised by OSPF with configured metric).
Any router having these external routes is called an AS boundary
router. These routes are advertised by the router to the entire AS
through AS external link advertisements.
List of AS external link advertisements
Part of the topological database. These have have originated from
the AS boundary routers. They comprise routes to destinations
external to the Autonomous System. Note that, if the router is
itself an AS boundary router, some of these AS external link
advertisements have been self originated.
The routing table
Derived from the topological database. Each destination that the
router can forward to is represented by a cost and a set of paths.
A path is described by its type and next hop. For more information,
see Section 11.
TOS capability
This item indicates whether the router will calculate separate
routes based on TOS. This is a configurable parameter. For more
information, see Sections 4.5 and 16.9.
Figure 9 shows the collection of data structures present in a typical
router. The router pictured is RT10, from the map in Figure 6. Note
that router RT10 has a virtual link configured to router RT11, with Area
2 as the link's transit area. This is indicated by the dashed line in
Figure 9. When the virtual link becomes active, through the building of
the shortest path tree for Area 2, it becomes an interface to the
backbone (see the two backbone interfaces depicted in Figure 9).
6. The Area Data Structure
The area data structure contains all the information used to run the
basic routing algorithm. Remember that each area maintains its own
topological database. Router interfaces and adjacencies belong to a
_______________________________________
(Figure not included in text version.)
Figure 9: Router RT10's Data Structures
_______________________________________
single area.
The backbone has all the properties of an area. For that reason it is
also represented by an area data structure. Note that some items in the
structure apply differently to the backbone than to areas.
The area topological (or link state) database consists of the collection
of router links, network links and summary links advertisements that
have originated from the area's routers. This information is flooded
throughout a single area only. The list of AS external advertisements
is also considered to be part of each area's topological database.
Area ID
A 32-bit number identifying the area. 0 is reserved for the area ID
of the backbone. If assigning subnetted networks as separate areas,
the IP network number could be used as the Area ID.
List of component address ranges
The address ranges that define the area. Each address range is
specified by an [address,mask] pair. Each network is then assigned
to an area depending on the address range that it falls into
(specified address ranges are not allowed to overlap). As an
example, if an IP subnetted network is to be its own separate OSPF
area, the area is defined to consist of a single address range - an
IP network number with its natural (class A, B or C) mask.
Associated router interfaces
This router's interfaces connecting to the area. A router interface
belongs to one and only one area (or the backbone). For the
backbone structure this list includes all the virtual adjacencies.
A virtual adjacency is identified by the router ID of its other
endpoint; its cost is the cost of the shortest intra-area path that
exists between the two routers.
List of router links advertisements
A router links advertisement is generated by each router in the
area. It describes the state of the router's interfaces to the
area.
List of network links advertisements
One network links advertisement is generated for each transit
multi-access network in the area. It describes the set of routers
currently connected to the network.
List of summary links advertisements
Summary link advertisements originate from the area's area border
routers. They describe routes to destinations internal to the
Autonomous System, yet external to the area.
Shortest-path tree
The shortest-path tree for the area, with this router itself as
root. Derived from the collected router links and network links
advertisements by the Dijkstra algorithm.
Authentication type
The type of authentication used for this area. Authentication types
are defined in Appendix E. All OSPF packet exchanges are
authenticated. Different authentication schemes may be used in
different areas.
External routing capability
Whether AS external advertisements will be flooded into/throughout
the area. This is a configurable parameter. If AS external
advertisements are excluded from the area, the area is called a
"stub". Internal to stub areas, routing to external destinations
will be based solely on a default summary route. The backbone
cannot be configured as a stub area. Also, virtual links cannot be
configured through stub areas. For more information, see Section
3.6.
StubDefaultCost
If the area has been configured as a stub area, and the router
itself is an area border router, then the StubDefaultCost indicates
the cost of the default summary link that the router should
advertise into the area. There can be a separate cost configured
for each IP TOS. See Section 12.4.3 for more information.
Unless otherwise specified, the remaining sections of this document
refer to the operation of the protocol in a single area.
7. Bringing Up Adjacencies
OSPF creates adjacencies between neighboring routers for the purpose of
exchanging routing information. Not every two neighboring routers will
become adjacent. This section covers the generalities involved in
creating adjacencies. For further details consult Section 10.
7.1 The Hello Protocol
The Hello Protocol is responsible for establishing and maintaining
neighbor relationships. It also ensures that communication between
neighbors is bidirectional. Hello packets are sent periodically out all
router interfaces. Bidirectional communication is indicated when the
router sees itself listed in the neighbor's Hello Packet.
On multi-access networks, the Hello Protocol elects a Designated Router
for the network. Among other things, the Designated Router controls
what adjacencies will be formed over the network (see below).
The Hello Protocol works differently on broadcast networks, as compared
to non-broadcast networks. On broadcast networks, each router
advertises itself by periodically multicasting Hello Packets. This
allows neighbors to be discovered dynamically. These Hello Packets
contain the router's view of the Designated Router's identity, and the
list of routers whose Hellos have been seen recently.
On non-broadcast networks some configuration information is necessary
for the operation of the Hello Protocol. Each router that may
potentially become Designated Router has a list of all other routers
attached to the network. A router, having Designated Router potential,
sends hellos to all other potential Designated Routers when its
interface to the non-broadcast network first becomes operational. This
is an attempt to find the Designated Router for the network. If the
router itself is elected Designated Router, it begins sending hellos to
all other routers attached to the network.
After a neighbor has been discovered, bidirectional communication
ensured, and (if on a multi-access network) a Designated Router elected,
a decision is made regarding whether or not an adjacency should be
formed with the neighbor (see Section 10.4). An attempt is always made
to establish adjacencies over point-to-point networks and virtual links.
The first step in bringing up an adjacency is to synchronize the
neighbors' topological databases. This is covered in the next section.
7.2 The Synchronization of Databases
In an SPF-based routing algorithm, it is very important for all routers'
topological databases to stay synchronized. OSPF simplifies this by
requiring only adjacent routers to remain synchronized. The
synchronization process begins as soon as the routers attempt to bring
up the adjacency. Each router describes its database by sending a
sequence of Database Description packets to its neighbor. Each Database
Description Packet describes a set of link state advertisements
belonging to the database. When the neighbor sees a link state
advertisement that is more recent than its own database copy, it makes a
note that this newer advertisement should be requested.
This sending and receiving of Database Description packets is called the
"Database Exchange Process". During this process, the two routers form
a master/slave relationship. Each Database Description Packet has a
sequence number. Database Description Packets sent by the master
(polls) are acknowledged by the slave through echoing of the sequence
number. Both polls and their responses contain summaries of link state
data. The master is the only one allowed to retransmit Database
Description Packets. It does so only at fixed intervals, the length of
which is the configured constant RxmtInterval.
Each Database Description contains an indication that there are more
packets to follow --- the M-bit. The Database Exchange Process is over
when a router has received and sent Database Description Packets with
the M-bit off.
During and after the Database Exchange Process, each router has a list
of those link state advertisements for which the neighbor has more up-
to-date instances. These advertisements are requested in Link State
Request Packets. Link State Request packets that are not satisfied are
retransmitted at fixed intervals of time RxmtInterval. When the
Database Description Process has completed and all Link State Requests
have been satisfied, the databases are deemed synchronized and the
routers are marked fully adjacent. At this time the adjacency is fully
functional and is advertised in the two routers' link state
advertisements.
The adjacency is used by the flooding procedure as soon as the Database
Exchange Process begins. This simplifies database synchronization, and
guarantees that it finishes in a predictable period of time.
7.3 The Designated Router
Every multi-access network has a Designated Router. The Designated
Router performs two main functions for the routing protocol:
o The Designated Router originates a network links advertisement on
behalf of the network. This advertisement lists the set of routers
(including the Designated Router itself) currently attached to the
network. The Link State ID for this advertisement (see Section
12.1.4) is the IP interface address of the Designated Router. The
IP network number can then be obtained by using the subnet/network
mask.
o The Designated router becomes adjacent to all other routers on the
network. Since the link state databases are synchronized across
adjacencies (through adjacency bring-up and then the flooding
procedure), the Designated Router plays a central part in the
synchronization process.
The Designated Router is elected by the Hello Protocol. A router's
Hello Packet contains its Router Priority, which is configurable on a
per-interface basis. In general, when a router's interface to a network
first becomes functional, it checks to see whether there is currently a
Designated Router for the network. If there is, it accepts that
Designated Router, regardless of its Router Priority. (This makes it
harder to predict the identity of the Designated Router, but ensures
that the Designated Router changes less often. See below.) Otherwise,
the router itself becomes Designated Router if it has the highest Router
Priority on the network. A more detailed (and more accurate)
description of Designated Router election is presented in Section 9.4.
The Designated Router is the endpoint of many adjacencies. In order to
optimize the flooding procedure on broadcast networks, the Designated
Router multicasts its Link State Update Packets to the address
AllSPFRouters, rather than sending separate packets over each adjacency.
Section 2 of this document discusses the directed graph representation
of an area. Router nodes are labelled with their Router ID. Broadcast
network nodes are actually labelled with the IP address of their
Designated Router. It follows that when the Designated Router changes,
it appears as if the network node on the graph is replaced by an
entirely new node. This will cause the network and all its attached
routers to originate new link state advertisements. Until the
topological databases again converge, some temporary loss of
connectivity may result. This may result in ICMP unreachable messages
being sent in response to data traffic. For that reason, the Designated
Router should change only infrequently. Router Priorities should be
configured so that the most dependable router on a network eventually
becomes Designated Router.
7.4 The Backup Designated Router
In order to make the transition to a new Designated Router smoother,
there is a Backup Designated Router for each multi-access network. The
Backup Designated Router is also adjacent to all routers on the network,
and becomes Designated Router when the previous Designated Router fails.
If there were no Backup Designated Router, when a new Designated Router
became necessary, new adjacencies would have to be formed between the
router and all other routers attached to the network. Part of the
adjacency forming process is the synchronizing of topological databases,
which can potentially take quite a long time. During this time, the
network would not be available for transit data traffic. The Backup
Designated obviates the need to form these adjacencies, since they
already exist. This means the period of disruption in transit traffic
lasts only as long as it take to flood the new link state advertisements
(which announce the new Designated Router).
The Backup Designated Router does not generate a network links
advertisement for the network. (If it did, the transition to a new
Designated Router would be even faster. However, this is a tradeoff
between database size and speed of convergence when the Designated
Router disappears.)
The Backup Designated Router is also elected by the Hello Protocol.
Each Hello Packet has a field that specifies the Backup Designated
Router for the network.
In some steps of the flooding procedure, the Backup Designated Router
plays a passive role, letting the Designated Router do more of the work.
This cuts down on the amount of local routing traffic. See Section 13.3
for more information.
7.5 The graph of adjacencies
An adjacency is bound to the network that the two routers have in
common. If two routers have multiple networks in common, they may have
multiple adjacencies between them.
One can picture the collection of adjacencies on a network as forming an
undirected graph. The vertices consist of routers, with an edge joining
two routers if they are adjacent. The graph of adjacencies describes
the flow of routing protocol packets, and in particular Link State
Updates, through the Autonomous System.
Two graphs are possible, depending on whether the common network is
multi-access. On physical point-to-point networks (and virtual links),
the two routers joined by the network will be adjacent after their
databases have been synchronized. On multi-access networks, both the
Designated Router and the Backup Designated Router are adjacent to all
other routers attached to the network, and these account for all
adjacencies.
These graphs are shown in Figure 10. It is assumed that router RT7 has
become the Designated Router, and router RT3 the Backup Designated
Router, for the network N2. The Backup Designated Router performs a
lesser function during the flooding procedure than the Designated Router
(see Section 13.3). This is the reason for the dashed lines connecting
the Backup Designated Router RT3.
8. Protocol Packet Processing
This section discusses the general processing of routing protocol
packets. It is very important that the router topological databases
remain synchronized. For this reason, routing protocol packets should
get preferential treatment over ordinary data packets, both in sending
and receiving.
Routing protocol packets are sent along adjacencies only (with the
exception of Hello packets, which are used to discover the adjacencies).
This means that all protocol packets travel a single IP hop, except
those sent over virtual links.
All routing protocol packets begin with a standard header. The sections
below give the details on how to fill in and verify this standard
header. Then, for each packet type, the section is listed that gives
more details on that particular packet type's processing.
8.1 Sending protocol packets
When a router sends a routing protocol packet, it fills in the fields of
that standard header as follows. For more details on the header format
consult Section A.3.1:
Version #
Set to 2, the version number of the protocol as documented in this
specification.
Packet type
The type of OSPF packet, such as Link state Update or Hello Packet.
Packet length
The length of the entire OSPF packet in bytes, including the
standard header.
Router ID
The identity of the router itself (who is originating the packet).
______________________________________
(Figure not included in text version.)
Figure 10: The graph of adjacencies
Figure 11: Interface state changes
______________________________________
Area ID
The area that the packet is being sent into.
Checksum
The standard IP 16-bit one's complement checksum of the entire OSPF
packet, excluding the 64-bit authentication field. This checksum
should be calculated before handing the packet to the appropriate
authentication procedure.
Autype and Authentication
Each OSPF packet exchange is authenticated. Authentication types
are assigned by the protocol and documented in Appendix E. A
different authentication scheme can be used for each OSPF area. The
64-bit authentication field is set by the appropriate authentication
procedure (determined by Autype). This procedure should be the last
called when forming the packet to be sent. The setting of the
authentication field is determined by the packet contents and the
authentication key (which is configurable on a per-interface basis).
The IP destination address for the packet is selected as follows. On
physical point-to-point networks, the IP destination is always set to
the the address AllSPFRouters. On all other network types (including
virtual links), the majority of OSPF packets are sent as unicasts, i.e.,
sent directly to the other end of the adjacency. In this case, the IP
destination is just the neighbor IP address associated with the other
end of the adjacency (see Section 10). The only packets not sent as
unicasts are on broadcast networks; on these networks Hello packets are
sent to the multicast destination AllSPFRouters, the Designated Router
and its Backup send both Link State Update Packets and Link State
Acknowledgment Packets to the multicast address AllSPFRouters, while all
other routers send both their Link State Update and Link State
Acknowledgment Packets to the multicast address AllDRouters.
Retransmissions of Link State Update packets are ALWAYS sent as
unicasts.
The IP source address should be set to the IP address of the sending
interface. Interfaces to unnumbered point-to-point networks have no
associated IP address. On these interfaces, the IP source should be set
to any of the other IP addresses belonging to the router. For this
reason, there must be at least one IP address assigned to the router.[2]
Note that, for most purposes, virtual links act precisely the same as
unnumbered point-to-point networks. However, each virtual link does
have an interface IP address (discovered during the routing table build
process) which is used as the IP source when sending packets over the
virtual link.
For more information on the format of specific packet types, consult the
sections listed in Table 10.
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5
Table 10: Sections describing packet transmission.
8.2 Receiving protocol packets
Whenever a protocol packet is received by the router it is marked with
the interface it was received on. For routers that have virtual links
configured, it may not be immediately obvious which interface to
associate the packet with. For example, consider the router RT11
depicted in Figure 6. If RT11 receives an OSPF protocol packet on its
interface to network N8, it may want to associate the packet with the
interface to area 2, or with the virtual link to router RT10 (which is
part of the backbone). In the following, we assume that the packet is
initially associated with the non-virtual link.[3]
In order for the packet to be accepted at the IP level, it must pass a
number of tests, even before the packet is passed to OSPF for
processing:
o The IP checksum must be correct.
o The packet's IP destination address must be the IP address of the
receiving interface, or one of the IP multicast addresses
AllSPFRouters or AllDRouters.
o The IP protocol specified must be OSPF (89).
o Locally originated packets should not be passed on to OSPF. That
is, the source IP address should be examined to make sure this is
not a multicast packet that the router itself generated.
Next, the OSPF packet header is verified. The fields specified in the
header must match those configured for the receiving interface. If they
do not, the packet should be discarded:
o The version number field must specify protocol version 2.
o The 16-bit checksum of the OSPF packet's contents must be verified.
Remember that the 64-bit authentication field must be excluded from
the checksum calculation.
o The Area ID found in the OSPF header must be verified. If both of
the following cases fail, the packet should be discarded. The Area
ID specified in the header must either:
(1) Match the Area ID of the receiving interface. In this case, the
packet has been sent over a single hop. Therefore, the packet's
IP source address must be on the same network as the receiving
interface. This can be determined by comparing the packet's IP
source address to the interface's IP address, after masking both
addresses with the interface mask.
(2) Indicate the backbone. In this case, the packet has been sent
over a virtual link. The receiving router must be an area
border router, and the router ID specified in the packet (the
source router) must be the other end of a configured virtual
link. The receiving interface must also attach to the virtual
link's configured transit area. If all of these checks succeed,
the packet is accepted and is from now on associated with the
virtual link (and the backbone area).
o Packets whose IP destination is AllDRouters should only be accepted
if the state of the receiving interface is DR or Backup (see Section
9.1).
o The Authentication type specified must match the authentication type
specified for the associated area.
Next, the packet must be authenticated. This depends on the
authentication type specified (see Appendix E). The authentication
procedure may use an Authentication key, which can be configured on a
per-interface basis. If the authentication fails, the packet should be
discarded.
If the packet type is Hello, it should then be further processed by the
Hello Protocol (see Section 10.5). All other packet types are
sent/received only on adjacencies. This means that the packet must have
been sent by one of the router's active neighbors. If the receiving
interface is a multi-access network (either broadcast or non-broadcast)
the sender is identified by the IP source address found in the packet's
IP header. If the receiving interface is a point-to-point link or a
virtual link, the sender is identified by the Router ID (source router)
found in the packet's OSPF header. The data structure associated with
the receiving interface contains the list of active neighbors. Packets
not matching any active neighbor are discarded.
At this point all received protocol packets are associated with an
active neighbor. For the further input processing of specific packet
types, consult the sections listed in Table 11.
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7
Table 11: Sections describing packet reception.
9. The Interface Data Structure
An OSPF interface is the connection between a router and a network.
There is a single OSPF interface structure for each attached network;
each interface structure has at most one IP interface address (see
below). The support for multiple addresses on a single network is a
matter for future consideration.
An OSPF interface can be considered to belong to the area that contains
the attached network. All routing protocol packets originated by the
router over this interface are labelled with the interface's Area ID.
One or more router adjacencies may develop over an interface. A
router's link state advertisements reflect the state of its interfaces
and their associated adjacencies.
The following data items are associated with an interface. Note that a
number of these items are actually configuration for the attached
network; those items must be the same for all routers connected to the
network.
Type
The kind of network to which the interface attaches. Its value is
either broadcast, non-broadcast yet still multi-access, point-to-
point or virtual link.
State
The functional level of an interface. State determines whether or
not full adjacencies are allowed to form over the interface. State
is also reflected in the router's link state advertisements.
IP interface address
The IP address associated with the interface. This appears as the
IP source address in all routing protocol packets originated over
this interface. Interfaces to unnumbered point-to-point networks do
not have an associated IP address.
IP interface mask
This indicates the portion of the IP interface address that
identifies the attached network. This is often referred to as the
subnet mask. Masking the IP interface address with this value
yields the IP network number of the attached network.
Area ID
The Area ID to which the attached network belongs. All routing
protocol packets originating from the interface are labelled with
this Area ID.
HelloInterval
The length of time, in seconds, between the Hello packets that the
router sends on the interface. Advertised in Hello packets sent out
this interface.
RouterDeadInterval
The number of seconds before the router's neighbors will declare it
down, when they stop hearing the router's hellos. Advertised in
Hello packets sent out this interface.
InfTransDelay
The estimated number of seconds it takes to transmit a Link State
Update Packet over this interface. Link state advertisements
contained in the update packet will have their age incremented by
this amount before transmission. This value should take into
account transmission and propagation delays; it must be greater than
zero.
Router Priority
An 8-bit unsigned integer. When two routers attached to a network
both attempt to become Designated Router, the one with the highest
Router Priority takes precedence. A router whose Router Priority is
set to 0 is ineligible to become Designated Router on the attached
network. Advertised in Hello packets sent out this interface.
Hello Timer
An interval timer that causes the interface to send a Hello packet.
This timer fires every HelloInterval seconds. Note that on non-
broadcast networks a separate Hello packet is sent to each qualified
neighbor.
Wait Timer
A single shot timer that causes the interface to exit the Waiting
state, and as a consequence select a Designated Router on the
network. The length of the timer is RouterDeadInterval seconds.
List of neighboring routers
The other routers attached to this network. On multi-access
networks, this list is formed by the Hello Protocol. Adjacencies
will be formed to some of these neighbors. The set of adjacent
neighbors can be determined by an examination of all of the
neighbors' states.
Designated Router
The Designated Router selected for the attached network. The
Designated Router is selected on all multi-access networks by the
Hello Protocol. Two pieces of identification are kept for the
Designated Router: its Router ID and its interface IP address on the
network. The Designated Router advertises link state for the
network. The network link state advertisement is labelled with the
Designated Router's IP address. This item is initialized to 0,
which indicates the lack of a Designated Router.
Backup Designated Router
The Backup Designated Router is also selected on all multi-access
networks by the Hello Protocol. All routers on the attached network
become adjacent to both the Designated Router and the Backup
Designated Router. The Backup Designated Router becomes Designated
Router when the current Designated Router fails. Initialized to 0
indicating the lack of a Backup Designated Router.
Interface output cost(s)
The cost of sending a packet on the interface, expressed in the link
state metric. This is advertised as the link cost for this
interface in the router links advertisement. There may be a
separate cost for each IP Type of Service. The cost of an interface
must be greater than zero.
RxmtInterval
The number of seconds between link state advertisement
retransmissions, for adjacencies belonging to this interface. Also
used when retransmitting Database Description and Link State Request
Packets.
Authentication key
This configured data allows the authentication procedure to generate
and/or verify the authentication field in the OSPF header. The
authentication key can be configured on a per-interface basis. For
example, if the authentication type indicates simple password, the
authentication key would be a 64-bit password. This key would be
inserted directly into the OSPF header when originating routing
protocol packets, and there could be a separate password for each
network.
9.1 Interface states
The various states that router interface may attain is documented in
this section. The states are listed in order of progressing
functionality. For example, the inoperative state is listed first,
followed by a list of intermediate states before the final, fully
functional state is achieved. The specification makes use of this
ordering by sometimes making references such as "those interfaces in
state greater than X".
Figure 11 shows the graph of interface state changes. The arcs of the
graph are labelled with the event causing the state change. These
events are documented in Section 9.2. The interface state machine is
described in more detail in Section 9.3.
Down
This is the initial interface state. In this state, the lower-level
protocols have indicated that the interface is unusable. No
protocol traffic at all will be sent or received on such a
interface. In this state, interface parameters should be set to
their initial values. All interface timers should be disabled, and
there should be no adjacencies associated with the interface.
Loopback
In this state, the router's interface to the network is looped back.
The interface may be looped back in hardware or software. The
interface will be unavailable for regular data traffic. However, it
may still be desirable to gain information on the quality of this
interface, either through sending ICMP pings to the interface or
through something like a bit error test. For this reason, IP
packets may still be addressed to an interface in Loopback state.
To facilitate this, such interfaces are advertised in router links
advertisements as single host routes, whose destination is the IP
interface address.[4]
Waiting
In this state, the router is trying to determine the identity of the
Backup Designated Router for the network. To do this, the router
monitors the Hellos it receives. The router is not allowed to elect
a Backup Designated Router nor Designated Router until it
transitions out of Waiting state. This prevents unnecessary changes
of (Backup) Designated Router.
Point-to-point
In this state, the interface is operational, and connects either to
a physical point-to-point network or to a virtual link. Upon
entering this state, the router attempts to form an adjacency with
the neighboring router. Hellos are sent to the neighbor every
HelloInterval seconds.
DR Other
The interface is to a multi-access network on which another router
has been selected to be the Designated Router. In this state, the
router itself has not been selected Backup Designated Router either.
The router forms adjacencies to both the Designated Router and the
Backup Designated Router (if they exist).
Backup
In this state, the router itself is the Backup Designated Router on
the attached network. It will be promoted to Designated Router when
the present Designated Router fails. The router establishes
adjacencies to all other routers attached to the network. The
Backup Designated Router performs slightly different functions
during the Flooding Procedure, as compared to the Designated Router
(see Section 13.3). See Section 7.4 for more details on the
functions performed by the Backup Designated Router.
DR In this state, this router itself is the Designated Router on the
attached network. Adjacencies are established to all other routers
attached to the network. The router must also originate a network
links advertisement for the network node. The advertisement will
contain links to all routers (including the Designated Router
itself) attached to the network. See Section 7.3 for more details
on the functions performed by the Designated Router.
9.2 Events causing interface state changes
State changes can be effected by a number of events. These events are
pictured as the labelled arcs in Figure 11. The label definitions are
listed below. For a detailed explanation of the effect of these events
on OSPF protocol operation, consult Section 9.3.