Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) is also an intradomain routing protocol like RIP, but it is based
on the link-state routing protocol.

Metric

In OSPF, like RIP, the cost of reaching a destination from the host is calculated from the source
router to the destination network. However, each link (network) can be assigned a weight based
on the throughput, round-trip time, reliability, and so on.

An administration can also decide to use the hop count as the cost. An interesting point
about the cost in OSPF is that different service types (TOSs) can have different weights
as the cost.

Figure 1 Metric in OSPF

Forwarding Tables
Each OSPF router can create a forwarding table after finding the shortest-path tree between
itself and the destination using Dijkstra’s algorithm. Figure 2 shows the forwarding tables for the
simple AS in Figure 1. Comparing the forwarding tables for the OSPF and RIP in the same AS,
we find that the only difference is the cost values. In other words, if we use the hop count for
OSPF, the tables will be exactly the same. The reason for this consistency is that both proto-
cols use the shortest-path trees to define the best route from a source to a destination.

Areas
Compared with RIP, which is normally used in small ASs, OSPF was designed to be able to
handle routing in a small or large autonomous system. However, the formation of shortest-path
trees in OSPF requires that all routers flood the whole AS with their LSPs to create the global
LSDB. Although this may not create a problem in a small AS, it may have created a huge
volume of traffic in a large AS. To prevent this, the AS needs to be divided into small sections
called areas. Each area acts as a small independent domain for flooding LSPs. In other words,
OSPF uses another level of hierarchy in routing: the first level is the autonomous system, the
second is the area
Figure 2 Forwarding tables in OSPF

However, each router in an area needs to know the information about the link states not only in
its area but also in other areas. For this reason, one of the areas in the AS is designated as the
backbone area, responsible for gluing the areas together. The routers in the backbone area are
responsible for passing the information collected by each area to all other areas. In this way, a
router in an area can receive all LSPs generated in other areas. For the purpose of
communication, each area has an area identification. The area identification of the backbone is
zero. Figure 3 shows an autonomous system and its areas.

Figure 3 Areas in an autonomous system

Link-State Advertisement

OSPF is based on the link-state routing algorithm, which requires that a router advertise the
state of each link to all neighbors for the formation of the LSDB. When we discussed the link-
state algorithm, we used the graph theory and assumed that each router is a node and each
network between two routers is an edge. The situation is different in the real world, in which we
need to advertise the existence of different entities as nodes, the different types of links that
connect each node to its neighbors, and the different types of cost associated with each link.
This means we need different types of advertisements, each capable of advertising different
situations. We can have five types of link-state advertisements: router link, network link,
summary link to network, summary link to AS border router, and external link. Figure 4 shows
these five advertisements and their uses.
Figure 4 Five different LSPs

● Router link: A router link advertises the existence of a router as a node. In addition to
giving the address of the announcing router, this type of advertisement can define one or
more types of links that connect the advertising router to other entities. A transient link
announces a link to a transient network, a network that is connected to the rest of the
networks by one or more routers. This type of advertisement should define the address
of the transient network and the cost of the link. A stub link advertises a link to a stub
network, a network that is not a through network. Again, the advertisement should define
the address of the network and the cost. A point-to-point link should define the address
of the router at the end of the point-to-point line and the cost to get there.
● Network link. A network link advertises the network as a node. However, since a network
cannot do announcements itself (it is a passive entity), one of the routers is assigned as
the designated router and does the advertising. In addition to the address of the
designated router, this type of LSP announces the IP address of all routers (including the
designated router as a router and not as speaker of the network), but no cost is
advertised because each router announces the cost to the network when it sends a
router link advertisement.
● Summary link to network. This is done by an area border router; it advertises the
summary of links collected by the backbone to an area or the summary of links collected
by the area to the backbone. As we discussed earlier, this type of information exchange
is needed to glue the areas together.
 ● Summary link to AS. This is done by an AS router that advertises the summary links
from other ASs to the backbone area of the current AS, information which later can be
disseminated to the areas so that they will know about the networks in other ASs. The
need for this type of information exchange is better understood when we discuss inter-
AS routing (BGP).
● External link. This is also done by an AS router to announce the existence of a single
network outside the AS to the backbone area to be disseminated into the areas.

OSPF Implementation

OSPF is implemented as a program in the network layer, using the service of the IP for
propagation. An IP datagram that carries a message from OSPF sets the value of the protocol
field to 89. This means that, although OSPF is a routing protocol to help IP to route its
datagrams inside an AS, the OSPF messages are encapsulated inside datagrams. OSPF has
gone through two versions: version 1 and version 2. Most implementations use version 2.

OSPF Messages
OSPF is a very complex protocol; it uses five different types of messages. In Figure 5, we first
show the format of the OSPF common header (which is used in all messages) and the link-state
general header (which is used in some messages). We then give the outlines of five message
types used in OSPF.
● The hello message (type 1) is used by a router to introduce itself to the neighbors and
announce all neighbors that it already knows.
● The database description message (type 2) is normally sent in response to the hello
message to allow a newly joined router to acquire the full LSDB.
● The link state request message (type 3) is sent by a router that needs information about
a specific LS.
● The link-state update message (type 4) is the main OSPF message used for building the
LSDB. This message, in fact, has five different versions (router link, network link,
summary link to network, summary link to AS border router, and external link), as we
discussed before.
● The link-state acknowledgment message (type 5) is used to create reliability in OSPF;
each router that receives a link-state update message needs to acknowledge it.

Authentication
As Figure 5 shows, the OSPF common header has the provision for authentication
of the message sender. This prevents a malicious entity from sending OSPF messages to a
router and causing the router to become part of the routing system to which it actually does not
belong.
Figure 5 OSPF message formats

Border Gateway Protocol Version 4 (BGP4)

The Border Gateway Protocol version 4 (BGP4) is the only interdomain routing protocol used in
the Internet today. BGP4 is based on the path-vector algorithm we described before, but it is
tailored to provide information about the reachability of networks in the Internet.

Introduction
BGP, and in particular BGP4, is a complex protocol. In this section, we introduce the basics of
BGP and its relationship with intradomain routing protocols (RIP or OSPF). Figure 6 shows an
example of an internet with four autonomous systems. AS2, AS3, and AS4 are stub
autonomous systems; AS1 is a transient one. In our example, data exchange between AS2,
AS3, and AS4 should pass through AS1.
Figure 6 A sample internet with four ASs

Each autonomous system in this figure uses one of the two common intradomain protocols, RIP
or OSPF. Each router in each AS knows how to reach a network that is in its own AS, but it
does not know how to reach a network in another AS. To enable each router to route a packet
to any network in the internet, we first install a variation of BGP4, called external BGP (eBGP),
on each border router (the one at the edge of each AS which is connected to a router at another
AS). We then install the second variation of BGP, called internal BGP (iBGP), on all routers.
This means that the border routers will be running three routing protocols (intradomain,
eBGP, and iBGP), but other routers are running two protocols (intradomain and iBGP). We
discuss the effect of each BGP variation separately.

Operation of External BGP (eBGP)

We can say that BGP is a kind of point-to-point protocol. When the software is installed on two
routers, they try to create a TCP connection using the well-known port 179. In other words, a
pair of client and server processes continuously communicate with each other to exchange
messages. The two routers that run the BGP processes are called BGP peers or BGP
speakers. We discuss different types of messages exchanged between two peers, but for the
moment we are interested in only the update messages (discussed later) that announce
reachability of networks in each AS. The eBGP variation of BGP allows two physically
connected border routers in two different ASs to form pairs of eBGP speakers and exchange
messages. The routers that are eligible in our example in Figure 20.24 form three pairs: R1-R5,
R2-R6, and R4-R9. The connection between these pairs is established over three physical
WANs (N5, N6, and N7). However, there is a need for a logical TCP connection to be created
over the physical connection to make the exchange of information possible. Each logical
connection in BGP parlance is referred to as a session. This means that we need three
sessions in our example, as shown in Figure 7.
Figure 7 eBGP operation

The figure also shows the simplified update messages sent by routers involved in the eBGP
sessions. The circled number defines the sending router in each case. For example, message
number 1 is sent by router R1 and tells router R5 that N1, N2, N3, and N4 can be reached
through router R1 (R1 gets this information from the corre- sponding intradomain forwarding
table). Router R5 can now add these pieces of information at the end of its forwarding table.
When R5 receives any packet destined for these four networks, it can use its forwarding table
and find that the next router is R1. The reader may have noticed that the messages exchanged
during three eBGP sessions help some routers know how to route packets to some networks in
the internet, but the reachability information is not complete. There are two problems that need
to be addressed:
1. Some border routers do not know how to route a packet destined for non neighbor ASs. For
example, R5 does not know how to route packets destined for networks in AS3 and AS4.
Routers R6 and R9 are in the same situation as R5: R6 does not know about networks in AS2
and AS4; R9 does not know about networks in AS2 and AS3.
2. None of the nonborder routers know how to route a packet destined for any net-
works in other ASs. To address the above two problems, we need to allow all pairs of routers
(border or nonborder) to run the second variation of the BGP protocol, iBGP.

Operation of Internal BGP (iBGP)

The iBGP protocol is similar to the eBGP protocol in that it uses the service of TCP on the well-
known port 179, but it creates a session between any possible pair of routers inside an
autonomous system. However, some points should be made clear. First, if an AS has only one
router, there cannot be an iBGP session. For example, we cannot create an iBGP session
inside AS2 or AS4 in our internet. Second, if there are n routers in an auton- omous system,
there should be [n × (n − 1) / 2] iBGP sessions in that autonomous system (a fully connected
mesh) to prevent loops in the system. In other words, each router needs to advertise its own
reachability to the peer in the session instead of flooding what it receives from another peer in
another session. Figure 8 shows the combination of eBGP and iBGP sessions in our internet.

Figure 8 Combination of eBGP and iBGP sessions in our internet

The first message (numbered 1) is sent by R1 announcing that networks N8 and N9 are
reachable through the path AS1-AS2, but the next router is R1. This message is sent, through
separate sessions, to R2, R3, and R4. Routers R2, R4, and R6 do the same thing but send
different messages to different destinations. The interesting point is that, at this stage, R3, R7,
and R8 create sessions with their peers, but they actually have no message to send.

The updating process does not stop here. For example, after R1 receives the update message
from R2, it combines the reachability information about AS3 with the reachability information it
already knows about AS1 and sends a new update message to R5. Now R5 knows how to
reach networks in AS1 and AS3. The process continues when R1 receives the update message
from R4. The point is that we need to make certain that at a point in time there are no changes
in the previous updates and that all information is propagated through all ASs. At this time, each
router combines the information received from eBGP and iBGP and creates what we may call a
path table after applying the criteria for finding the best path, including routing policies that we
discuss later. To demonstrate, we show the path tables in Figure 20.27 for the routers in Figure
20.24. For example, router R1 now knows that any packet destined for networks N8 or N9
should go through AS1 and AS2 and the next router to deliver the packet to is router R5.
Similarly, router R4 knows that any packet destined for networks N10, N11, or N12 should go
through AS1 and AS3 and the next router to deliver this packet to is router R1, and so on.

Injection of Information into Intradomain Routing

The role of an interdomain routing protocol such as BGP is to help the routers inside the AS to
augment their routing information. In other words, the path tables collected and organized by
BPG are not used, per se, for routing packets; they are injected into intradomain forwarding
tables (RIP or OSPF) for routing packets. This can be done in several ways depending on the
type of AS. In the case of a stub AS, the only area border router adds a default entry at the end
of its forwarding table and defines the next router to be the speaker router at the end of the
eBGP connection. In Figure 6, R5 in AS2 defines R1 as the default router for all networks other
than N8 and N9. The situation is the same for router R9 in AS4 with the default router to be R4.
In AS3, R6 set its default router to be R2, but R7 and R8 set their default router to be R6. These
settings are in accordance with the path tables we describe in Figure 9 for these routers. In
other words, the path tables are injected into intradomain forwarding tables by adding only one
default entry. In the case of a transient AS, the situation is more complicated. R1 in AS1 needs
to inject the whole contents of the path table for R1 in Figure 9 into its intradomain forwarding
table. The situation is the same for R2, R3, and R4.
One issue to be resolved is the cost value. We know that RIP and OSPF use different metrics.
One solution, which is very common, is to set the cost to the foreign networks at the same cost
value as to reach the first AS in the path. For example, the cost for R5 to reach all networks in
other ASs is the cost to reach N5. The cost for R1 to reach networks N10 to N12 is the cost to
reach N6, and so on. The cost is taken from the intradomain forwarding tables (RIP or OSPF).
Figure 10 shows the interdomain forwarding tables. For simplicity, we assume that all ASs are
using RIP as the intradomain routing protocol. The shaded areas are the augmentation injected
by the BGP protocol; the default destinations are indicated as zero.

Figure 6 Finalized BGP path tables

Figure 10 Forwarding tables after injection from BGP