RFC 1247
OSPF Version 2
4. Functional Summary A separate copy of OSPF's basic routing algorithm runs in each area. Routers having interfaces to multiple areas run multiple copies of the algorithm. A brief summary of the routing algorithm follows. When a router starts, it first initializes the routing protocol data structures. The router then waits for indications from the lower-level protocols that its interfaces are functional. A router then uses the OSPF's Hello Protocol to acquire neighbors. The router sends Hello packets to its neighbors, and in turn receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters. On non-broadcast networks, some configuration information is necessary in order to discover neighbors. On all multi-access networks (broadcast or non-broadcast), the Hello Protocol also elects a Designated router for the network. The router will attempt to form adjacencies with some of its newly acquired neighbors. Topological databases are synchronized between pairs of adjacent routers. On multi-access networks, the Designated Router determines which routers should become adjacent. Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies. In particular, distribution of topological database updates proceeds along adjacencies. A router periodically advertises its state, which is also called link state. Link state is also advertised when a router's state changes. A router's adjacencies are reflected in the contents of its link state advertisements. This relationship between adjacencies and link state allows the protocol to detect dead routers in a timely fashion. Link state advertisements are flooded throughout the area. The flooding algorithm is reliable, ensuring that all routers in an area have exactly 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 [RFC 791]).
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. Interface Up Lower-level protocols have indicated that the network interface is operational. This enables the interface to transition out of Down state. On virtual links, the interface operational indication is actually a result of the shortest path calculation (see Section 16.7). Wait Timer The Wait timer has fired, indicating the end of the waiting period that is required before electing a (Backup) Designated Router. Backup seen The router has detected the existence or non-existence of a Backup Designated Router for the network. This is done in one of two ways. First, a Hello Packet may be received from a neighbor claiming to be itself the Backup Designated Router. Alternatively, a Hello Packet may be received from a neighbor claiming to be itself the Designated Router, and indicating that there is no Backup. In either case there must be bidirectional communication with the neighbor, i.e., the router must also appear in the neighbor's Hello Packet. This event signals an end to the Waiting state. Neighbor Change There has been a change in the set of bidirectional neighbors associated with the interface. The (Backup) Designated Router needs to be recalculated. The following neighbor changes lead to the Neighbor Change event. For an explanation of neighbor states, see Section 10.1. o Bidirectional communication has been established to a neighbor. In other words, the state of the neighbor has transitioned to 2-Way or higher. o There is no longer bidirectional communication with a neighbor. In other words, the state of the neighbor has transitioned to Init or lower. o One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This is detected through examination of that neighbor's Hello Packets.
o One of the bidirectional neighbors is no longer declaring itself
as Designated Router, or is no longer declaring itself as Backup
Designated Router. This is again detected through examination
of that neighbor's Hello Packets.
o The advertised Router Priority for a bidirectional neighbor has
changed. This is again detected through examination of that
neighbor's Hello Packets.
Loop Ind
An indication has been received that the interface is now looped
back to itself. This indication can be received either from network
management or from the lower level protocols.
Unloop Ind
An indication has been received that the interface is no longer
looped back. As with the Loop Ind event, this indication can be
received either from network management or from the lower level
protocols.
Interface Down
Lower-level protocols indicate that this interface is no longer
functional. No matter what the current interface state is, the new
interface state will be Down.
9.3 The Interface state machine
A detailed description of the interface state changes follows. Each
state change is invoked by an event (Section 9.2). This event may
produce different effects, depending on the current state of the
interface. For this reason, the state machine below is organized by
current interface state and received event. Each entry in the state
machine describes the resulting new interface state and the required set
of additional actions.
When an interface's state changes, it may be necessary to originate a
new router links advertisement. See Section 12.4 for more details.
Some of the required actions below involve generating events for the
neighbor state machine. For example, when an interface becomes
inoperative, all neighbor connections associated with the interface must
be destroyed. For more information on the neighbor state machine, see
Section 10.3.
State(s): Down
Event: Interface Up
New state: Depends on action routine
Action: Start the interval Hello Timer, enabling the periodic
sending of Hello packets out the interface. If the attached
network is a physical point-to-point network or virtual
link, the interface state transitions to Point-to-Point.
Else, if the router is not eligible to become Designated
Router the interface state transitions to DR other.
Otherwise, the attached network is multi-access and the
router is eligible to become Designated Router. In this
case, in an attempt to discover the attached network's
Designated Router the interface state is set to Waiting and
the single shot Wait Timer is started. If in addition the
attached network is non-broadcast, examine the configured
list of neighbors for this interface and generate the
neighbor event Start for each neighbor that is also eligible
to become Designated Router.
State(s): Waiting
Event: Backup Seen
New state: Depends upon action routine.
Action: Calculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
State(s): Waiting
Event: Wait Timer
New state: Depends upon action routine.
Action: Calculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
State(s): DR Other, Backup or DR
Event: Neighbor Change
New state: Depends upon action routine.
Action: Recalculate the attached network's Backup Designated Router
and Designated Router, as shown in Section 9.4. As a result
of this calculation, the new state of the interface will be
either DR other, Backup or DR.
State(s): Any State
Event: Interface Down
New state: Down
Action: All interface variables are reset, and interface timers
disabled. Also, all neighbor connections associated with
the interface are destroyed. This is done by generating the
event KillNbr on all associated neighbors (see Section
10.2).
State(s): Any State
Event: Loop Ind
New state: Loopback
Action: Since this interface is no longer connected to the attached
network the actions associated with the above Interface Down
event are executed.
State(s): Loopback
Event: Unloop Ind
New state: Down
Action: No actions are necessary. For example, the interface
variables have already been reset upon entering the Loopback
state. Note that reception of an Interface Up event is
necessary before the interface again becomes fully
functional.
9.4 Electing the Designated Router This section describes the algorithm used for calculating a network's Designated Router and Backup Designated Router. This algorithm is invoked by the Interface state machine. The initial time a router runs the election algorithm for a network, the network's Designated Router and Backup Designated Router are initialized to 0.0.0.0. This indicates the lack of both a Designated Router and a Backup Designated Router. The Designated Router election algorithm proceeds as follows: Call the router doing the calculation Router X. The list of neighbors attached to the network and having established bidirectional communication with Router X is examined. This list is precisely the collection of Router X's neighbors (on this network) whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself is also considered to be on the list. Discard all routers from the list that are ineligible to become Designated Router. (Routers having Router Priority of 0 are ineligible to become Designated Router.) The following steps are then executed, considering only those routers that remain on the list: (1) Note the current values for the network's Designated Router and Backup Designated Router. This is used later for comparison purposes. (2) Calculate the new Backup Designated Router for the network as follows. Only those routers on the list that have not declared themselves to be Designated Router are eligible to become Backup Designated Router. If one or more of these routers have declared themselves Backup Designated Router (i.e., they are currently listing themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets) the one having highest Router Priority is declared to be Backup Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Backup Designated Router, choose the router having highest Router Priority, (again excluding those routers who have declared themselves Designated Router), and again use the Router ID to break ties. (3) Calculate the new Designated Router for the network as follows. If one or more of the routers have declared themselves Designated Router (i.e., they are currently listing themselves as Designated Router in their Hello Packets) the one having highest Router Priority is declared to be Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Designated Router, promote the new Backup Designated Router to Designated Router.
(4) If Router X is now newly the Designated Router or newly the Backup
Designated Router, or is now no longer the Designated Router or no
longer the Backup Designated Router, repeat steps 2 and 3, and then
proceed to step 5. For example, if Router X is now the Designated
Router, when step 2 is repeated X will no longer be eligible for
Backup Designated Router election. Among other things, this will
ensure that no router will declare itself both Backup Designated
Router and Designated Router.[5]
(5) As a result of these calculations, the router itself may now be
Designated Router or Backup Designated Router. See Sections 7.3 and
7.4 for the additional duties this would entail. The router's
interface state should be set accordingly. If the router itself is
now Designated Router, the new interface state is DR. If the router
itself is now Backup Designated Router, the new interface state is
Backup. Otherwise, the new interface state is DR Other.
(6) If the attached network is non-broadcast, and the router itself has
just become either Designated Router or Backup Designated Router, it
must start sending hellos to those neighbors that are not eligible
to become Designated Router (see Section 9.5.1). This is done by
invoking the neighbor event Start for each neighbor having a Router
Priority of 0.
(7) If the above calculations have caused the identity of either the
Designated Router or Backup Designated Router to change, the set of
adjacencies associated with this interface will need to be modified.
Some adjacencies may need to be formed, and others may need to be
broken. To accomplish this, invoke the event AdjOK? on all
neighbors whose state is at least 2-Way. This will cause their
eligibility for adjacency to be reexamined (see Sections 10.3 and
10.4).
The reason behind the election algorithm's complexity is the desire for
an orderly transition from Backup Designated Router to Designated
Router, when the current Designated Router fails. This orderly
transition is ensured through the introduction of hysteresis: no new
Backup router can be chosen until the old Backup accepts its new
Designated Router responsibilities.
If Router X is not itself eligible to become Designated Router, it is
possible that neither a Backup Designated Router nor a Designated Router
will be selected in the above procedure. Note also that if Router X is
the only attached router that is eligible to become Designated Router,
it will select itself as Designated Router and there will be no Backup
Designated Router for the network.
9.5 Sending Hello packets Hello packets are sent out each functioning router interface. They are used to discover and maintain neighbor relationships.[6] On multi-access networks, hellos are also used to elect the Designated Router and Backup Designated Router, and in that way determine what adjacencies should be formed. The format of a Hello packet is detailed in Section A.3.2. The Hello Packet contains the router's Router Priority (used in choosing the Designated Router), and the interval between Hello broadcasts (HelloInterval). The Hello Packet also indicates how often a neighbor must be heard from to remain active (RouterDeadInterval). Both HelloInterval and RouterDeadInterval must be the same for all routers attached to a common network. The Hello packet also contains the IP address mask of the attached network (Network Mask). On unnumbered point-to-point networks and on virtual links this field should be set to 0. The Hello packet's Options field describes the router's optional OSPF capabilities. There are currently two optional capabilities defined (see Sections 4.5 and A.2). The T-bit of the Options field should be set if the router is capable of calculating separate routes for each IP TOS. The E-bit should be set if and only if the attached area is capable of processing AS external advertisements (i.e., it is not a stub area). If the E-bit is set incorrectly the neighboring routers will refuse to accept the Hello Packet (see Section 10.5). The rest of the Hello Packet's Options field should be set to zero. In order to ensure two-way communication between adjacent routers, the Hello packet contains the list of all routers from which hellos have been seen recently. The Hello packet also contains the router's current choice for Designated Router and Backup Designated Router. A value of 0 in these fields means that one has not yet been selected. On broadcast networks and physical point-to-point networks, Hello packets are sent every HelloInterval seconds to the IP multicast address AllSPFRouters. On virtual links, Hello packets are sent as unicasts (addressed directly to the other end of the virtual link) every HelloInterval seconds. On non-broadcast networks, the sending of Hello packets is more complicated. This will be covered in the next section. 9.5.1 Sending Hello packets on non-broadcast networks Static configuration information is necessary in order for the Hello Protocol to function on non-broadcast networks (see Section C.5). Every attached router which is eligible to become Designated Router has a
configured list of all of its neighbors on the network. Each listed neighbor is labelled with its Designated Router eligibility. The interface state must be at least Waiting for any hellos to be sent. Hellos are then sent directly (as unicasts) to some subset of a router's neighbors. Sometimes an hello is sent periodically on a timer; at other times it is sent as a response to a received hello. A router's hello- sending behavior varies depending on whether the router itself is eligible to become Designated Router. If the router is eligible to become Designated Router, it must periodically send hellos to all neighbors that are also eligible. In addition, if the router is itself the Designated Router or Backup Designated Router, it must also send periodic hellos to all other neighbors. This means that any two eligible routers are always exchanging hellos, which is necessary for the correct operation of the Designated Router election algorithm. To minimize the number of hellos sent, the number of eligible routers on a non-broadcast network should be kept small. If the router is not eligible to become Designated Router, it must periodically send hellos to both the Designated Router and the Backup Designated Router (if they exist). It must also send an hello in reply to an hello received from any eligible neighbor (other than the current Designated Router and Backup Designated Router). This is needed to establish an initial bidirectional relationship with any potential Designated Router. When sending Hello packets periodically to any neighbor, the interval between hellos is determined by the neighbor's state. If the neighbor is in state Down, hellos are sent every PollInterval seconds. Otherwise, hellos are sent every HelloInterval seconds.
(page 54 continued on part 3)
