Tải bản đầy đủ
13 OSPF ( open shortest path first)

13 OSPF ( open shortest path first)

Tải bản đầy đủ


Routing tables and protocols

• OSPF uses a link cost parameter as the basis for shortest path calculations. The parameter
may be weighted to accommodate other metrics including link bandwidth, delay, load,
reliability, etc.
• by using a link state routing protocol and by limiting routing information messages to
‘real’ update information, the network traffic load created by OSPF routing messages is
much lower than that of RIP;
• the subdivision of the OSPF routing domain into separate routing areas (as in Figure 6.7)
provides for hierarchical routing and a further reduction in routing protocol traffic. It also
allows OSPF to cope with large, very complex networks;
• OSPF allows for the use of equal cost multipaths to the same destination by load sharing
traffic between alternative paths if desired;
• OSPF is a fast converging protocol requiring minimum routing message traffic: but, as a
result, is much more demanding of router processing power and memory capacity; and
• OSPF traffic is always authenticated — so only trusted routers may take part in the routing process.

How does a link state routing protocol work?
Routers which employ link state routing protocols maintain a link state database. This is a
database containing information about the network as a whole and the state (i.e. link cost)
of each of the links. Using the database, each router separately calculates a shortest path tree
with itself as the root. This enables the router to determine its routing table by working out the
shortest path route (i.e. the lowest cost route) to every reachable destination on the branches
of the tree. We shall use the example network of Figure 6.11 to explain in detail how the
method works.
The network of Figure 6.11 comprises 7 routers (R1 to R7), 8 networks (N1 to N8: these
might be ethernet LANs, ATM or Frame Relay networks, etc.) and one point-to-point (PP)
link (from router R3 to router R6).

Figure 6.11 Example of network topology.

OSPF (open shortest path first)


Figure 6.12 Link states (i.e. link costs) for the network example of Figure 6.11.

There are also a number of different hosts connected to the different networks and routers.
For our example we only illustrate one of these (H1), which is connected directly to router R3.
The first stage in the creation of the link state database which will represent this network
is the assignment of states (i.e. link costs) to each of the links in the network. This step is
illustrated in Figure 6.12. The diagram uses the normal convention, that a hop or link from
one router to another has a given link cost. The cost for the link traversed in one direction
may be different from the cost of the same link when traversed in the opposite direction. The
cost of a link is assigned by the associated router for each relevant outgoing interface. Thus, if
we study the costs to the routers (R1, R2 and R3) of using their respective outgoing interfaces
to network N2 these are values 2, 6 and 8. The cost value is a dimensionless parameter (i.e.
a simple integer value) as far as the routing protocol is concerned. The lower the value, the
‘shorter’ (and thus more preferable) the route.
The values assigned as link costs to the relevant router outgoing interfaces are assigned by
the individual routers themselves. The assignment may take place automatically (e.g. as the
result of a calculation based on other bandwidth, delay, load or reliability metrics) or alternatively the value may be set as an administrative distance — assigned manually by a human
operator when configuring the router. Automatically calculated values may vary over time (as
the link delay, load and reliability change). Typically the default cost value of 1000 million
divided by the link bit rate is assigned. (Thus a Gigabit ethernet network would have a link
cost of 1, while a 64 kbit/s point-to-point line would have a value of 15 625.) It is important
to note (as in Figure 6.12) that there is no cost for exiting a network to enter a router. Thus
the total cost of the route from router R1 to router R2 is 2.
Using Figure 6.12 we are now in a position to create a ‘database’ to represent the network
and the link states illustrated. This appears in Table 6.3. The table illustrates a matrix of
the individual links in the network which interconnect all the various routers, networks and
hosts. The numerical values which appear within the table are the link costs according to the
direction of packets across the link, and all the network components (routers, networks hosts)
are represented.
As an example, Table 6.3 shows the link from router R1 to router R2 broken down into two
separate sub-links: FROM router R1 TO network N2 (with a cost of 2) and a second sub-link



Routing tables and protocols
Table 6.3

Typical OSPF link state database corresponding to the example of Figure 6.12



































FROM network N2 TO router R2 (with a cost of 0). The empty positions in Table 6.3 indicate
non-existent links.
In its completed form, Table 6.3 contains as much information as Figure 6.12, and we can
use it alone to calculate all available routes through the network. It is this link state database
which serves as the basis for each router to calculate its routing table.7
Having received all relevant routing information updates (by collecting the routing protocol
broadcasts of all other routers in the network), each router is able to collate a complete link state
database like Table 6.3. Using it, each router applies an OSPF process using the Dijkstra algorithm to calculate the shortest path tree with itself at the root. Two examples of shortest path
trees, respectively with routers R1 and R2 as their roots are shown in Figures 6.13 and 6.14.
It is perhaps surprising to discover that the shortest path routes from the two routers R1
and R2 appear to follow totally different ‘spinal’ paths. Router R1 tends to reach destinations
in the lower portion via routers R3 and R6 (Figure 6.13), while router R2 instead accesses the
same destinations by way of network N3 and router R5 (Figure 6.14). The fact that the shortest
routes for the two routers should follow such different paths may not have been obvious at
first (i.e. from Figure 6.12)! This illustrates the major strength of link state algorithms — they
always find optimal routes through the network — no matter how complex the network is.
There is no chance of selecting a circular route, and routes of equal shortest path cost will
both be used — by employing traffic load sharing across all relevant paths.
Once the shortest path tree has been calculated from the link state database (using the
shortest path first, SPF, algorithm), the router can create its own routing table, which is
stored separately.
The need to store the routing table as well as the entire link state database demands
that routers using OSPF have much more data storage capacity than is needed for distance
You might like to use Table 6.3 to work out the possible alternative routes (and their costs) when traversing
the network from router R1 to network N7. Having done so, you will appreciate that the ‘database’ of Table 6.3
is not as easy to use as the ‘map’ of Figure 6.12. But the database form is all that the routers have to work with.
Being in a numerical form, it is easy to transfer the information in the database from one router to another by
means of a routing protocol, but the calculation of the possible routes requires a special mathematical routing
algorithm. The algorithm used is the Dijkstra or shortest path first (SPF) algorithm.

OSPF (open shortest path first)


Figure 6.13 Shortest path tree from router R1 as the root.

Figure 6.14 Shortest path tree from router R2 as the root.

vector routing protocols such as RIP. Furthermore, the complexity of the calculations necessary to determine the shortest path tree demands not only that a powerful router processing
capability be available but also that the routing table calculation should not be repeated
too often.
The big benefit of link state protocols is that the level of network topology detail held in
the link state database means that only ‘real’ topology changes need normally be notified by
the routing protocol — rather than having to keep on re-broadcasting the entire routing table
(as undertaken by RIP). This means much larger and more complex networks can be handled
efficiently by OSPF than by RIP.


Routing tables and protocols

Information content of routing updates (link state advertisements — LSAs)
The routing updates of link state routing protocols take the form of link state advertisements
(LSAs). Each router restricts the origination of routing information which it floods to all other
OSPF routers to its router link state advertisement (router-LSA). This contains only information
about outgoing access possibilities from the router (e.g. directly connected routers, networks
and hosts). Thus the information which the router R6 of Figure 6.12 would advertise in its
router-LSA is as listed in Table 6.4.
Using the same logic as we used to create the router link state advertisement (routerLSA) of Table 6.4 we could create a network link state advertisement (network-LSA) table for
each of the networks of Figure 6.12. Table 6.5, for example, shows the network link state
advertisement (network-LSA) of the ‘multipoint’ network N3. The only problem is that the
network is unable to create and advertise the network-LSA, since the network does not take an
active part in the OSPF protocol or OSPF process. To get around this problem, we designate
one of the routers to undertake the task on behalf of the network. In the case of network N3
of Figure 6.12 we could designate any of the routers R2, R3, R4 or R5 to perform the task.
The router chosen for the task is termed the designated router (DR) and its backup (which
ensures continued operation of OSPF in the case of failure of the DR) is called the back-up
designated router (BDR). The designated router creates and advertises the network-LSA for
the network (e.g. Table 6.5 for network 3 of Figure 6.12).
Collect all the router link state advertisements (router-LSAs) and network-link state advertisements (network-LSAs) together, and you are in a position to create the complete link state
database of Table 6.3! (All the routers in an OSPF collect this identical link state database).
In principle, this is exactly the type of information contained in routing updates and exactly
the manner in which the OSPF protocol works. But before we go on to explain the OSPF
protocol in detail, we should explain network-LSAs more thoroughly.

Network link state advertisements (network-LSA)
To ensure the creation of network-LSAs, both a designated router (DR) and a back-up designated router (BDR) are elected from the routers connected to a given broadcast (i.e.
Table 6.4

Router R6’s router-link state
advertisement (LSA)


Table 6.5



Network N3’s network-link state
advertisement (network-LSA)




OSPF (open shortest path first)


shared medium network such as an ethernet LAN) or non-broadcast multiple access (NBMA)
Rather than making all the routers separately issue the (same) network-LSA, the task is left
to the designated router, which also takes on the task of coordinating incoming and outgoing
link state advertisements. Thus, for example, neighbouring routers within the broadcast- or
NBMA-network need not exchange LSAs with each other and all possible other routers on
a bilateral basis. Instead, each router within the local network simply updates the designated
router (DR) which then broadcasts the consolidated updates to all the other local and remote
routers on their behalf.
Both a designated router (DR) and a back-up designated router (BDR) are elected for each
broadcast- and NBMA-network. This ensures smooth continued operation of the OSPF network
in the case of failure of the DR. But smooth operation does not extend to immediate adoption
by the BDR of the DR’s duties. First the BDR will have to create a new version of the DR’s
router-LSAs and network-LSAs as well as re-collecting the details of neighbouring routers.
A hot standby copy (i.e. mirror copy) of the various DR databases is not maintained by the
BDR, as this is considered an undue effort during normal operation of the protocol. As soon
as the BDR takes over the role of the DR, a new BDR is elected.
Both the DR and BDR elections are undertaken as part of the hello procedure (which we
shall discuss later). The router with the highest router priority is elected to become the DR.
The router with the second highest router priority becomes the BDR. Where more than one
router has the same router priority (which is set during configuration of the router or left at the
factory default value), the router with the higher router identifier (RID) is elected. The router
identifier is a 32-bit value used to identify uniquely the source of link state advertisements
and router-relevant entries in the link state database.

OSPF operation — the detailed protocol functions and their chronology
We have seen how the OSPF protocol is designed to work by advertising link state advertisements (LSAs) which describe the link topology of the network surrounding a particular
router. LSAs are flooded by all OSPF routers to all other routers within the relevant routing
domain or area (Figure 6.7), and enable each router to create and maintain a full copy of
the link state database (network topology database) from which the shortest path tree and
ultimately, the routing table are calculated. But this is only a small part of the story. There is
a lot more complex detail involved in initialising the protocol, conducting the hello procedure,
discovering neighbours and synchronising data, as we shall discover next.
Figure 6.15 illustrates the functions which must be undertaken and the chronological order
of the steps, as a new OSPF router is introduced into, and subsequently maintained in, operation. As with other Internet devices, OSPF routers are designed to find out as much as they
can about the network for themselves — thereby minimising as far as possible the need for
human operators to configure them. This minimises initial human installation effort, but also
maximises the capability of the OSPF routing process to cope with network failures. As we
shall see, this means there are a number of complicated functions all taking place at the
same time.
Before a router can be introduced to a network using the OSPF routing protocol, it must
first be configured by the human operator for OSPF. This involves:
An NBMA (non-broadcast multiple access) network is a data network based on a technology like X.25, ATM
(asynchronous transfer mode) or frame relay which has multipoint access but does not have a simple, single
address method for multicasting. The designated router in an NBMA network provides functionality which
makes the network act like a broadcast or multicast network.


Routing tables and protocols

Figure 6.15

Functions and chronology of the OSPF protocol [LSD = link state database].

• defining the OSPF process in the router and identifying it with a process ID (one process
is required for each network area of Figure 6.7 in which the router is to take part in the
routing process);
• defining the network area (area-ID) to which each OSPF process is to be assigned;
• defining the router priority and router-ID;
• defining the network interfaces which are to be subject to the OSPF routing process:
associating the IP address-ranges and setting up the metrics which are to be used to
define the link costs associated with OSPF-controlled interface (otherwise the default is
1000 million divided by the interface bit rate); and
• defining the default route (gateway of last resort for the address if required.
When first introduced to the network, the router will be in the down (i.e. non-active) state. The
first function it must perform is to discover who its neighbours are. Neighbours are routers
which can be reached by means of a single IP forwarding hop. In other words, neighbours
are all those other routers ‘directly connected’ to the router, by means of a point-to-point link
or single network (e.g. LAN) connection. The process of neighbour discovery of other OSPF
routers is carried out in the OSPF protocol by means of the hello procedure.

The OSPF Hello Procedure (hello protocol)
Straight after a router is first switched on, configured for OSPF and introduced to a network, it is said to be in a down state. It is down because it is not yet participating fully in
either the OSPF routing process or in the forwarding of IP traffic. To come ‘on line’, the
first thing an OSPF router does, is to discover its neighbours. It does so by multicasting a

OSPF (open shortest path first)


Figure 6.16 OSPF common packet header and hello packet format.

hello packet (Figure 6.16) on all its outgoing interfaces which have been configured to be
controlled by OSPF.
The first hello packet sent by a new router will let the neighbouring routers know its
details — its IP address will be in the IP packet header, its router-ID and routing area-ID will
be identified in the corresponding hello packet fields (Figure 6.15), as will other parameters
locally configured within it (authentication type, hello options, router priority, router dead
interval, etc.). Although the hello packet is addressed to the all OSPF routers multicast address
(, this first hello packet will only reach directly connected neighbour routers by virtue
of the fact that the number of allowed IP forwarding hops is limited to one by setting the IP
packet header field time-to-live (TTL) to one.
All the routers in an OSPF network are obliged to continue sending hello packets to their
neighbours at regular intervals. By so doing, the routers continually re-confirm that they are
still available and ‘alive’ — that their routes and links are still valid and should not be aged
and deleted. So . . . sometime after the receipt of the hello packet from the new router, it will
be the turn of each of the neighbouring routers to broadcast their own hello packets back.
In these hello packets, the ‘new router’ will be identified as being one of the neighbouring
routers (since a hello packet contains the information: ‘my neighbours are. . .’). Following the
receipt of all the hello packets of neighbouring routers, the ‘new router’ will thus be able to
determine who all the neighbours are, to which link (i.e. interface) they are connected and
other IP address details.
Next, the router has to decide with which of the neighbours an adjacency relationship will
be established. We shall discuss this shortly, but before we do, we describe the information
fields in the common OSPF packet header and OSPF hello packet fields, as used for the OSPF
process described so far.

Common OSPF packet header
All OSPF routing protocol messages are preceded by the common OSPF packet header of
20 octets (Figure 6.16). The first four octets of the header identify the OSPF version number


Routing tables and protocols
Table 6.6

OSPF common packet types

OSPF packet type value



Hello packet
Database Description (DD)
Link State Request (LSR)
Link State Update (LSU)
Link State Acknowledgement (LSAck)

Table 6.7

OSPF authentication types

OSPF packet authentication type value
3- 65 535

Authentication method in use
Null authentication
Simple password
Cryptographic authentication
Reserved values

(either version 1 or version 2), the type of the OSPF message (Table 6.6) and the packet length
(the total length of the packet including the common header fields).
The 32-bit router-ID uniquely identifies the router which generated the OSPF message. This
value is manually configured into the router. The area-ID is also a 32-bit value, identifying
an area within the overall OSPF routing domain (as shown in Figure 6.7).
The checksum applies to the entire OSPF-packet (excluding the 64-bit authentication field).
The authentication fields reveal the type of authentication in use (Table 6.7) and the authentication codeword and algorithm.
The entire OSPF packet is carried directly by the Internet protocol, with the IP packet
header protocol field value set to protocol number 89 (OSPF).

Hello packet format
The hello packet format is as illustrated in Figure 6.16. It carries the common OSPF packet
header, with the OSPF packet type field set to value ‘1’.
The network mask field is the subnet mask of the link interface across which the hello packet
is being sent. The hello interval indicates the time between transmission of successive hello
packets in seconds. The router dead interval is the period of time for which a neighbouring
router will still be considered to be ‘alive’ even if it does not send a hello packet. After expiry
of the router dead interval without receipt of a hello packet, the router is assumed to be ‘dead’
and relevant database entries are amended accordingly. The options field we discuss later.
Designated routers (DR) and back-up designated routers (BDR) are identified by their
router-ID if the interface on which the hello packet is being sent is either a broadcast- or
a NBMA (non-broadcast multiple access)-network.
The neighbours field comprises a list of the various 32-bit router IDs of all neighbouring
routers, who have sent a hello packet within a period of time equal to the router dead interval.

Turning a neighbour relationship into an adjacency relationship
A neighbour relationship has been created with a given neighbour router as soon as a hello
packet has been received from that neighbour with the first router listed as one of its neighbours.
This is the first step towards full OSPF operation. The next step (as Figure 6.15 shows) is the

OSPF (open shortest path first)


selection of neighbouring routers with which an adjacency relationship will be created. Not
all neighbour relationships are turned into adjacency relationships, but only adjacency relationships take part in the main OSPF process. An OSPF router forms adjacency relationships
with the following routers:
• all neighbour routers at the opposite end of point-to-point links;
• each of the neighbour routers at the opposite end of point-to-multipoint network interfaces
(each neighbour in this case is treated as if it were a separate point-to-point neighbour);
• all designated routers (DRs) and back-up designated routers (BDR) of broadcast or nonbroadcast multiple access (NBMA) networks to which the router is directly attached; and
• to any backbone (i.e. area 0 ) neighbour router to which the router may be connected by
a real or virtual link (more about virtual links later).
Routers only exchange routing information in adjacency relationships (i.e. only with particular
neighbours). Any information which needs to be propagated to all other routers in the OSPF
network is cascaded through the network across one adjacency relationship to the next in a
process known as flooding. Thus OSPF routing information received on one interface will be
flooded by advertising it to all other adjacent OSPF interfaces of the router.
An adjacency relationship first exists when adjacent routers have synchronised their link
state databases (i.e. network topology databases). But before the synchronisation can commence, it is necessary to elect the designated router (DR) and back-up designated router
(BDR) for any broadcast or non-broadcast multiple access (NBMA) networks to which the
‘new router’ is connected. The designated router (DR) saves the routers in broadcast and
NBMA networks from having to create adjacency relationships with all other routers in the
network. Instead each router has an adjacency relationship with the designated router (DR),
which acts to broadcast all the relevant link state advertisements (LSAs) to all routers. In the
case of an NBMA, there is no actual broadcast capability for messages provided by the normal network technology, but the designated router is configured in such a manner to simulate
broadcasting or multicasting. This might involve, for example, being pre-configured with the
IP unicast addresses of all the routers in the network and progressively sending the same LSAs
to each one in turn.
The process of automatic neighbour discovery is critical to the operation of OSPF, if there is
not to be a heavy load placed upon the human network operator to configure OSPF routers by
hand (and keep them up-to-date) so that they always ‘know’ their neighbours. While neighbour
discovery in most ‘pure IP’ networks is covered by the provisions of the hello protocol, there
are occasions when this alone is not sufficient. For example, when a number of routers are
all connected to a non-broadcast multiple access (NBMA) network such as frame relay, they
may not be capable of undertaking either neighbour discovery or the election of a designated
router (DR) without further assistance (either manual configuration or help from a further
protocol). For this reason, the development of protocols for neighbour discovery continues.
RFC 2461 defines a specific procedure for neighbour discovery in IPv6 while the inverse
address resolution protocol (inARP — RFC 2390) defines a process for neighbour discovery
in NBMA networks (specifically designed for frame relay).

Data synchronisation
Once all the neighbouring routers which are to enter adjacency relationships have been selected,
the process of data synchronization can commence. This is triggered by a request made in
a hello packet, and involves comparing the entries in the link state databases (i.e. network


Routing tables and protocols

Figure 6.17 Format of the OSPF data description (DD) packet.

topology databases) of the two adjacent routers and making sure that the two are identical and
as up-to-date as possible. The synchronisation process takes place by means of OSPF database
description (DD) packets. A DD packet contains a list of all the link state advertisements (LSAs)
(identified by their LSA-headers) making up the link state database (Figure 6.17).
One or more DD packets may necessary to list all the LSA-headers making up the link
state database of a given router. When more than one packet is necessary, this is indicated by
the M-bit (More DD-packets to follow).
OSPF database description (DD) packets are transmitted using the unicast IP-address
(learned during neighbour discovery) of the selected neighbour router. The data synchronisation process (also called the data exchange process) is controlled by one of the routers as
the master (the router which acts as master first is the one with the highest router priority).
The master is the router allowed to send DD packets. It sends DD packets repeatedly until
they are acknowledged. Meanwhile, the other ‘soon-to-be-adjacent’ router acts as a slave: it
acknowledges the receipt of each DD packet (by returning an empty DD packet with the same
sequence number) and checks the list of the LSAs contained in the master’s link state database
against the list of LSAs in its own.
Should the database description (DD) packet indicate to the slave router that the master has
a link state advertisement (LSA) not previously known to the slave or more up-to-date than
the LSA-version held by the slave, then the slave is obliged to generate a link state request
(LSR). The link state request (LSR) demands that the master provide the full LSA (link state
advertisement). This may, in turn lead the slave to flood the same LSA to other routers.
Of course, there is bound to be some new topology information for newly connected adjacent routers to share between themselves. The link state databases cannot possibly have been
the same beforehand! Consider the example of Figure 6.18. The network comprising routers A
and B is being newly-connected to the existing network consisting of routers C, D and E. Let
us assume that router B acts as master first during the process of data synchronisation — then
router E is the slave — and receives database description (DD) packets. While router E acts
as the slave it will generate LSRs for the LSAs pertaining to the network comprising routers
A and B. The LSAs (link state advertisements) describe each of the links in the A/B part of