Next hop.

And we look at the other speeds, things that packets of node a, well, there's no need
to do that because A is directly connected to B and C. So there's a list entry put in tentative list
B 5B based on this link information and C 10c based on this link information.

Next step would be extracting the minimum cost entry from tentative, which is B 5 B. So this
goes here. And then, we look at the links state packets of note B. There would be like the next
step. Well, from B, we can reach out to D, and we can reach C. All right, let's take a look at
reaching-- we can look at C3 B link state packet.

OK, so that means that this here could be revised. You can reach c going through B at a lower
cost, eight basically using this path. OK, so that's the meaning of this update right here. OK, and
then the next one from B we can reach D at a cost of 16. So it's a to B is 5 plus 11 where you
reach 16.

The next step, we get the minimum cost entry from tentative, which is this entry goes to
confirm. And then, we look at node c link state packets. So C can reach B and D and back to a,
but B and A are already on the Confirm list. The only one that's not is D. All right, so we realize
that we can reach D going through node c at a lesser cost of total being 10.

So we have this update going on right here. So from 16 to the next step is extracting the
minimum cost entry from tentative, put it back into confirm, and you end up with the empty
tentative list, and this is where your algorithm stops. So you end up with these-- of this
information that can be used to build directly the round table and the foreign table.

So from A, you can reach B through B, and then you can reach C also through B. So here's how
you can reach C through B at a cost of 8. And you can reach D going through B as the next hopp,
that's going to be-- that's going to include this Hopp and this hopp at a total cost of 10, 5 plus 3
plus 2, 10.

So that's the link state routing algorithm. It converges faster than distance vector because it has
global information. It doesn't generate excess or excessive traffic, responds quickly to topology
changes. Its main advantage is that all stations all routers operate normally on the same
information about the network topology. So it will generate loop free routes.

The problem with link state protocol is that there is a link state packet for each router, and so
that generates a little bit of traffic, and requires memory for storing, so for larger networks
again, you have the issue of network overhead.

Open shortest path first is a routing protocol that was built around link state routing. It was
originally created in the late 80s. It was standardized, and it became widely used in the early
90s. It has additional features that differentiates it from the routing information, protocol from
IP. It has authentication of routing messages to prevent malicious users from introducing errors
in the network.
It also has additional hierarchy. So that makes it a much more scalable. The idea is to partition
routing domain into areas and then to run OSPF inside areas, and that will basically limit the
scope of that reliable flooding algorithm, and it will also limit the number of LSPs used for
computing the shortest path.

So that also improve the complexity of the algorithm that runs on every router. But at the cost
of potentially producing suboptimal routes compared to the situation where there are no--,
there's no partitioning into areas. OSPF also is able to route packets on multiple routes. It's
called multi path routing if two routes are determined to have the same cost.

And this is a big deal. In larger networks, there may be additional paths available. And that
could improve performance by distributing traffic more uniformity in the network instead of
having just a bottleneck links that take a lot of usage, what other links in the network may not
be utilizing as much.

So here's an autonomous system, the big box running everything that could represent an ISP
network or could be a network of a larger organization. For instance, like FAU's campus
network, or could be Comcast network in South Florida. It may have thousands of router. So the
idea is to split it in areas, and adjacent areas are connected by area border routers like these
guys here, area border routers.

And then area 0 is always considered to be the backbone area, which connects all the other
border areas. OK, now, in this case, we have two backbone routers. This one here, this one
here, and another big router would be at the boundary of the autonomous system. This is
called the autonomous system boundary router.

Now you could do individual routing inside each area without having link state packets
spanning multiple areas. That's the whole point of creating this hierarchy. So by partitioning the
network like this, the number of routers in each area will go down significantly, basically, by a
factor proportional to the number of areas you have in your autonomous system.

So there's no flooding of link state packets between the areas, and you also have this backbone
area that is kind of shared whenever traffic goes from 1 area to another. So potentially, this
could become a bottleneck if it's not properly designed. So like this particular edge in the
network, this link may see a high utilization if there's a lot of traffic going on between areas like
this.

Anyway, so OSPF is capable of doing routing inside areas or in between areas as well. Area
border routers will summarize information about an area, and we'll send it to other areas.
Basically, an area border router like this one will tell all the other routers in the network and in
the backbone area that they can reach a subnet, or a set of subnets, basically, using the border
area as the next stop.
So that means summarizing instead of sending links state packets about individual routers like
that, it just sends an update saying that, hey, you can reach this particular subnets-- a little
subnets and this reduces the traffic that goes between adjacent areas too.

All right, so the main benefit of breaking down a larger network into areas is that this reliable
flooding is limited to 1 area. So that's a big gain in performance, reducing network overhead,
but it also reduces the number of nodes involved in computing the protocol. Now the Open
Shortest path first protocol uses a packet header that's represented here.

It starts with the version of the protocol and the type of message, the message length, the
source address, the area information that checks on for an entire header, and then
authentication information to make sure that there's no malicious packets flowing around
trying to subvert the routing tables.

And then the links state advertisement. Basically, that's the content of a link state packet. It
includes this age information about the link states, so after when this age reaches zero, link
state packet will be dropped from the network, additional options, the link state ID, then
advertising router, that is the one that generated the links state information and the links state
sequence number that's on the 32-bits of link state check some 16-bit over this advertisement.

The length of the link state advertisement, meaning how many links are included, number of
links, the link ID, link data, link tab. This is all for each individual link permalink information. This
could be repeated multiple times, once for every other link that this particular advertising
router has. There are a number of messages that can be sent part of this protocol. One is Hello.
This is like a heart beat type of packet to make sure that your neighbor router is still alive and
the link is on.

Then there's a database description, which includes four messages that include entire link state
packet database, and there is a type of packet for requesting information and one for returning
an update. Then there's an acknowledgment sent in that reliable flooding to make sure that link
state packets are not lost, and they are delivered reliably.

Now let's compare the state routing with distance vector routing. Now with link state routing, if
you have N nodes and e links in the network, there is going to be a number proportional to the
product of the number of nodes and the number of links messages sent in the network.

OK, so this reliable flooding involves a lot of messages, not a distance vector exchanges
messages only between neighbors, but because it doesn't rely on the global information,
convergence time for distance vector is longer.

OK, so for links state, the algorithm has the complexity of n, and it will take a number of
iterations for the topology to converge basically so that all the nodes calculate the same
shortest path. The distance vector has similar problems but, in addition, may experience the
count to infinity and may have routing loops.
In terms of robustness as to what happens if routers malfunctioning with link state and node
can advertise incorrect link costs. Basically, a node may report wrong information about the
cost to reach its neighbors. And then, each node will compute only its own table. So this will not
we-- will not have a large difference on the routes computed. Now with distance vector, the
situation may be wrong.

The distance vector node can advertise incorrect path information so that it's like the total cost
to reach a node. That's not a neighbor, but it's any other network, any other router in the
network. Now because each node in the network may use information from other nodes that
includes the path cost, it means that if one node makes a mistake or miscalculated the cost,
then this error will propagate through the network and eventually, all routes will be polluted by
errors.

So distance vector is less robust from this point of view compared to the links state protocol. All
right, now let's look in a little bit more detail at costs. We talk about link cost, path cost, but
what exactly is path cost? Now, the terminology networking for link cost actually is link metric,
OK, and routing protocols compute the minimum cost of routes. They will basically use distance
vector or link state protocol to come up with the shortest cost or the minimum cost route.

Now, the routing information protocol or RIP distance vector uses a cost of 1 for all links in the
network. This actually keeps the algorithm very simple. It computes roots that have the
minimum hopes. It's basically short routes, but that doesn't mean that it will calculate the
optimal roots in practical situation.

So, for instance, if one of the links is a slow modern link or a satellite link with the long delay,
then the distance vector protocol may include those links on a shortest path, and it will discard
maybe gigabit per second if not links that may be several involved, just because they are not on
the shortest path.

So that's one of the problems with distance vector, it treats all links identically, and that's not
very effective. Now at the beginning of the internet in the 70s and the 80s, a research project
funded by the Department of Defense looked at computing or coming up with the best routing
protocols and optimal metrics.

ARPANET was the early version of the internet managed by this data project. And they came up
with a variety of different metrics and experimented with those metrics to find those that work
the best. OK, one metric that was used was queue length. So at each router, there's going to be
transmission cues for each outgoing link.

And a line-- a link experiences congestion, packets will be delayed or when those queues
accumulate more packets. So queue length could be a good indicator for how busy a link is.
Obviously, if you have a high value for the link-- for the queue length, that means you have
more traffic queued up. So the waiting time the delay will go up.
OK, that means that if you calculate a minimum cost path, basically, you end up with a
minimum delay path, and this is-- it sounds very appealing, but it ignores transmission delays
and the data rate. So you could have a very fast link that has a long queue. And you could have
a slow link that has a short queue and the short queue will have a shorter-- smaller cost.

This sort of metric created another problem, which ended up being very difficult to solve.
Basically, traffic would be moved from one path to another path based on those queue lengths.
So if the network determines that one path is better, it will direct traffic over those links with
shorter queue lengths, leading up to queues in routers along those lightly utilized routes to
grow quickly.

So the network will determine afterwards based on updated metrics using OSPF, for instance,
that those routes are not good anymore because their costs went up, so traffic would be quickly
redirected to routes and links that are less utilized with shorter queues. And this can happen--
can happen rather frequently.

You end up with the network rerouting traffic, basically creating oscillations, or traffic moves
from very busy routes to less utilized routes that over time become a lot busier than the other
routes. So basically, you end up with a network where there is a lot of traffic changing
directions midstream, and this creates routes instability. OK, and that's not very good.

Another metric included-- try to do a better job in estimating or using delay as the metric. So
how do you calculate delay on a link while you put a time stamp for a packet and you measure
the time it spends inside a router. So a packet is received at a moment in time called arrival
time, and it leaves the routes at the time called departure time.

And so, you can estimate the delay on that link by subtracting the arrival time from the
departure time. So this would be-- this will include any processing overhead and curing delay,
and to that, you add transmission time and Link latency. Latency here means something like
medium access control delay.

For instance, if you use something like ethernet, this could be the average time of accessing the
medium, medium access delay. So this was an estimate of the delay on a link. If you do that,
then you will compute routes and have minimum delay. Now, this is-- it works well when the
network is likely loaded, but the moment the network becomes heavily loaded, then you have
the same issue as before with the queue length.

When a link becomes heavily utilized, its delay will go up, and then other rulers will take that
updated cost into configurator-- into consideration when they can recompute the roots, they
will avoid that particular link that was highly loaded. Quickly it will become idle, and the other
links will become highly loaded.

So you've got traffic that varies over time, and it will keep pretty much a large number of edges
idle or less utilized than necessary. Another issue is that there is a very high range of delay for
different links, and if you take, for instance, a slow modem link, 56 kilobits per second,
transmission timing could be very high. Could be in the order of dozens of milliseconds, for
instance.

And at the same time, if you take, for instance, a gigabit per second ethernet network, 100
megabits per second ethernet, that transmission time is in the order of maximum, a couple of
milliseconds. So there is a high dynamic range for this metric, and that makes this metric
impractical.

There you could have links that have a very high cost and then links with a very low cost, and
that could create again issues over time again, link routes instability when routes change
frequently, and traffic varies. Overall this will keep a lot of links of underutilized. So again, it's
inefficient.

A better approach was another ARPANET metric that intended to keep this dynamic range of
the metric under control. So a lightly loaded link will never have a cost more than 3 times, then
its cost when it's idle great, just to keep the difference between an idling cost and a heavily
linked cost under control.

The most expensive link is only 7 times the cost of the least expensive, that means you can have
a very slow link like a modem link and a very fast link like gigabit ethernet, and this metric will
basically keep the difference between those two less than 7 times right. A high speed satellite
link is more attractive than a low speed terrestrial link.

So they came up basically with functions that looked like these lines in this chart that computed
the link cost based on the type of link, if it's terrestrial or satellite link, but also on its utilization.
So, in other words is that the link kind of stays constant for a while for low utilization, and then
when utilization goes up, that means the load on the link goes up.

For instance, how long the queues are? Then the cost grows up gradually, and this encourages
the network to use links that are lightly loaded and avoid those links that are heavily loaded.
And again, by adjusting this constant value depending on the link type and speed, they achieve
the same performance.

Now obviously, technology change in the air is dramatically. So in the early 90s of 56 kilobit per
second, wide area network link was a good speed, but that became obsolete in just a few years.
So know you could come up with a scheme like this, and you basically, whenever new
technology comes in, you've got to update.

Now modern links are very different from what we've seen before. The metrics change rarely, if
at all, in the majority of real time network deployments these days. Most network operators
use pretty much a uniform and small set of different technologies. So they rely on SOLNET or
switch ethernet is running at 40 or 100 gigabits per second for their backbones.

And there's no-- the high disparity between metrics that it was in the 80s. So all of these
metrics are assigned by the network administrator, or they are assigned basically automatically,
and they don't change over time. Conventional wisdom holds that changing metrics dynamically
will lead up to route instability. It's causing links to become underutilized and other links to
become highly utilized.

So they would create-- will ultimately lead to inefficient use of resources. And the typical metric
that's used today is some constant divided by the link speed or did all ready. All right, so if you
have, for instance, a gigabit per second ethernet link that the cost will probably be around 400,
the metric would be 400. If you have a Wi-Fi link running at 600 megabits per second, the cost
would be bigger, around 1,000. All right, so there is a high disparity, and the cost doesn't
depend on utilization anymore.