Architectures for Networks

and Services
Arhitecturi pentru retele si servicii (ARS)

Intra-domain Routing
(Review & Extensions)

Managementul serviciilor si retelelor (MSR)

 Routing in the Internet
Routing and administrative boundaries
The Internet is a federation of autonomous IP networks, owned
and operated by different organizations.
Each organization manages autonomously:
the connectivity and routing within its own network;
the policies for interconnection with other networks.

Autonomous System (AS)

An AS is a connected group of networks under a single
technical administration, with consistent interior routing, and
unified exterior routing policy (RFC 1786,1930).
An AS is also called (autonomous) routing domain.
An AS is treated as a single entity by the rest of the Internet.

Internet routing must take into account these

administrative boundaries
Octavian Catrina 2
 Intra-domain vs. inter-domain routing
IGP
Intra-domain routing
Based on IP network topology
and performance metrics.
All routers in the AS participate
in route finding and selection.
Focus on efficiency and
performance (QoS).
Interior routing (or gateway)
protocols (IGP): RIP, OSPF, ...
Octavian Catrina
EGP
Inter-domain routing
Based on AS interconnection
topology and routing policies.
Designated pairs of AS border
routers exchange routing info.
Focus on scalability, route
stability, convergence.
Exterior routing (or gateway)
protocols (EGP): BGP4.
3
 Intra-domain: Main routing algorithms
Distance-vector routing (DVR)
What routing Costs of the best paths known
information does by the router to all (known)
a router send? destinations.
Only to neighbor (directly
To what routers?
connected) routers.
Every router learns the costs of
the paths to all destinations,
via each of its neighbors.
How is it used to
For each destination, the next
build the routing
hop is the neighbor offering the
table?
best path to that destination
(distributed Bellman-Ford
shortest path algorithm).
RIP: Routing Information
Example
Protocol
Octavian Catrina
Link-state routing (LSR)
Costs of the links to the
networks directly connected to
the router.
To all other routers in the
routing domain.
Every router builds a complete
map of the routing domain, as
a labeled graph.
Every router runs a shortest
path algorithm (Dijkstra) on this
graph and finds the tree of best
paths from itself to all
destinations.
OSPF: Open Shortest Path
First
4
Distance Vector
Routing (DVR)
Review
RIP
 DVR: Basic algorithm (1)
Each router:
(1) Maintains a table with all known routes (routing table)
Route = { network prefix, path metric, next hop, interface }
Network prefix identifies a set of destinations with the same path.
No next hop for directly connected networks.

(2) Advertises known routes to all neighbors (periodic/triggered)

List of { network prefix, path metric } = Distance Vector (DV).

Router B: routing table

B All DVR examples assume:
Network M NH IF
DVB
DVB Link metric (cost) = 1
10.1.0.0/16 1 d.c. e Path metric = link-count.
10.2.0.0/16
10.1.0.0/16
10.2.0.0/16 1 d.c. w
10.3.0.0/16 2 C w
Metric = 1 10.5.0.0/16 10.6.0.0/16
10.4.0.0/16 2 A e
C
10.5.0.0/16 2 A e 10.3.0.0/16 A E
10.6.0.0/16 3 A e
10.4.0.0/16
D RIP metric is slightly different!
M = route metric
Distance vector Path metric = hop-count
NH = next hop
(DVB)
IF = interface
Octavian Catrina 6
 DVR: Basic algorithm (2)
(3) Updates its own routing table based on DVs from neighbors
For each destination (network) not directly connected:
Next hop = Neighbor that offers best path.
Path metric = neighbors metric + shared network metric.
Best path metric = Min all neighbors { Path metric }.

Router B: routing table Router B: DV from neighbors Router B: Dir. con.

Network M NH Network C A Network M
10.1.0.0/16 1 d.c. 10.1.0.0/16 2 +1=3 10.1.0.0/16 1
10.2.0.0/16 1 d.c. 10.2.0.0/16 2 +1=3 10.2.0.0/16 1
10.3.0.0/16 2 C 10.3.0.0/16 1 +1=2 2 +1=3
10.4.0.0/16 2 A 10.4.0.0/16 2 +1=3 1 +1=2
10.5.0.0/16 2 A B 10.5.0.0/16 3 +1=4 1 +1=2
10.6.0.0/16 3 A 10.6.0.0/16 4 +1=5 2 +1=3

Distance vector
(DVB) 10.2.0.0/16
10.1.0.0/16
DVC DVA
Metric = 1 10.5.0.0/16 10.6.0.0/16
C
10.3.0.0/16 A E
10.4.0.0/16
D
Octavian Catrina 7
 Example: network startup
Router B Router A Router E
Route M NH Route M NH Route M NH
10.1.0.0/16 1 dir.con. 10.1.0.0/16 1 dir.con.
10.2.0.0/16 1 dir.con.
10.4.0.0/16 2
10.5.0.0/16 2 10.4.0.0/16 1 dir.con.
10.5.0.0/16 1 dir.con. 10.5.0.0/16 1 dir.con.
B 10.6.0.0/16 1 dir.con.

10.2.0.0
10.1.0.0
C Metric = 1 10.5.0.0 10.6.0.0
10.3.0.0 A E
10.4.0.0

Router C D Router D Assume a sequence:

Route M NH Route M NH A B, D, E;
10.1.0.0/16 2
10.2.0.0/16 1 dir.con. B, D C, A; etc.
10.3.0.0/16 1 dir.con. 10.3.0.0/16 1 dir.con.
10.4.0.0/16 3 10.4.0.0/16 1 dir.con.
10.5.0.0/16 3

Octavian Catrina 8
 Example: state after convergence
Router B Via Router A Via Router E Via
Route M NH C A Route M NH B D E R M NH A
10.1.0.0/16 1 dc 3 - 10.1.0.0/16 1 dc. - 3 3 10.1.0.0/16 2 A 2
10.2.0.0/16 1 dc - 3 10.2.0.0/16 2 B 2 3 4 10.2.0.0/16 3 A 3
10.3.0.0/16 2 C 2 3 10.3.0.0/16 2 D 3 2 4 10.3.0.0/16 3 A 3
10.4.0.0/16 2 A 3 2 10.4.0.0/16 1 dc 3 - 3 10.4.0.0/16 2 A 2
10.5.0.0/16 2 A 4 2 10.5.0.0/16 1 dc. 3 3 - 10.5.0.0/16 1 dc -
10.6.0.0/16 3 A 5 3 10.6.0.0/16 2 E 4 4 2 10.6.0.0/16 1 dc. 3

10.2.0.0 B 10.1.0.0
For the basic DVR algorithm

C Metric = 1 10.5.0.0 10.6.0.0

10.3.0.0 A E
10.4.0.0

Router C Via D Router D Via

Convergence time:
Route M NH B D Route M NH C A
10.1.0.0/16 2 B 2 3 10.1.0.0/16 2 A 3 2 - Very slow for
10.2.0.0/16 1 dc. - 3 10.2.0.0/16 2 C 2 3 periodic updates.
10.3.0.0/16 1 dc 3 - 10.3.0.0/16 1 dc. - 3 - Much faster for
10.4.0.0/16 2 D 3 2 10.4.0.0/16 1 dc. 3 - triggered updates
10.5.0.0/16 3 B 3 3 10.5.0.0/16 2 A 4 2 (request, change).
10.6.0.0/16 4 B 4 4 10.6.0.0/16 3 A 5 3
Octavian Catrina 9
 Towards real DVR protocols
Incremental update of the routing table
Routers incrementally update their routing table for each
received DV, instead of storing the DVs for all neighbors.
For each entry in a received DV:
If the received path metric is smaller than own metric, update the
route: metric = received metric, next hop = neighbor.
If the received path metric is larger than own metric, but comes
from the same neighbor, update the route: metric = received metric.
Otherwise ignore the received DV entry.

How to handle infeasible routes?

Different cases: link/interface, path, or router failures.
Route timeout: Delete a route if not advertised for a long time.
A basic mechanism applicable in all cases, but rather slow. Example:
Periodic updates every 30 sec. Declare a route invalid if not advertised
for 180 sec. Delete the route after other 180 sec.
Notification of infeasible routes? (We'll discuss this later.)
Octavian Catrina 10
 Routing loops
Router B Via Router A Via Router E Via
Route M NH C A Route M NH B D E R M NH A
10.1/16 1 dc 3 - 10.1/16 1 dc. - 3 3 10.1/16 2 A 2
10.2/16 1 dc. - 3 10.2/16 2 B 2 3 4 10.2/16 3 A 3
10.3/16 2 C 2 3 10.3/16 2 D 3 2 4 10.3/16 3 A 3
10.4/16 2 A 3 2 10.4/16 1 dc 3 - 3 10.4/16 2 A 2
10.5/16 2 A 4 2 10.5/16 1 dc. 3 3 - 10.5/16 1 dc -
10.6/16 3 A 5 3 B 10.6/16 2 E 4 4 2 10.6/16 1 dc. 3

10.2.0.0
10.1.0.0 For the basic DVR algorithm
C Metric = 1 10.5.0.0 10.6.0.0
10.3.0.0 A E
10.4.0.0
1. A-B loop.
Router C Via D Router D Via
Assume E, A mark
Route M NH B D Route M NH C A 10.6.0.0/16 as invalid
10.1/16 2 B 2 3 10.1/16 2 A 3 2 and an update BA.
10.2/16 1 dc. - 3 10.2/16 2 C 2 3 2. A-B-C-D loop.
10.3/16 1 dc 3 - 10.3/16 1 dc. - 3 Assume E, A, D mark
10.4/16 2 D 3 2 10.4/16 1 dc. 3 - 10.6.0.0/16 as invalid
10.5/16 3 B 3 3 10.5/16 2 A 4 2 and the updates:
10.6/16 4 B 4 4 10.6/16 3 A 5 3 C D A B.
Octavian Catrina 11
 Counting to infinity
Router B Via Router A Via Router E Via
Route M NH C A Route M NH B D E R M NH A
10.1/16 1 dc 3 - 10.1/16 1 dc. - 3 3 10.1/16 2 A 2
10.2/16 1 dc. - 3 10.2/16 2 B 2 3 4 10.2/16 3 A 3
10.3/16 2 C 2 3 10.3/16 2 D 3 2 4 10.3/16 3 A 3
10.4/16 2 A 3 2 10.4/16 1 dc 3 - 3 10.4/16 2 A 2
10.5/16 2 A 4 2 10.5/16 1 dc. 3 3 - 10.5/16 1 dc -
10.6/16 3 A 5 3 B 10.6/16 2 E 4 4 2 10.6/16 1 dc. 3

10.2.0.0
10.1.0.0 For the basic DVR algorithm
C Metric = 1 10.5.0.0 10.6.0.0
10.3.0.0 A E
10.4.0.0

Router C Via D Router D Via Routers cannot detect

Route M NH B D Route M NH C A that a destination has
10.1/16 2 B 2 3 10.1/16 2 A 3 2 become unreachable.
10.2/16 1 dc. - 3 10.2/16 2 C 2 3 Path metric increases
10.3/16 1 dc 3 - 10.3/16 1 dc. - 3 indefinitely.
10.4/16 2 D 3 2 10.4/16 1 dc. 3 -
10.5/16 3 B 3 3 10.5/16 2 A 4 2
10.6/16 4 B 4 4 10.6/16 3 A 5 3

Octavian Catrina 12
 DVR enhancements (1)
Cause of troubles
Routers ignore the actual topology. They rely on each others
routing updates. Basic algorithm permits mutual deception!
What can we do?
Simple enhancements can ensure convergence and avoid
most routing loops. Complete elimination is difficult/inefficient.
Ensuring convergence: Maximum path metric
The path metric is limited to a maximum value (infinity).
Destinations with a larger value are considered unreachable.
What value? Conflicting requirements:
Small value for fast convergence. Larger than any path metric.
Example: RIP infinity = 16!
Inefficient solution for routing loops.
Useful for announcing unreachable destinations.

Octavian Catrina 13
 DVR enhancements (2)
Split horizon (simple)
Never advertise a route to the neighbor it was learned from.
RA builds a DV sent to RB by removing from the set of all the routes it
knows those for which RB is next hop (and the link between them).
Motivation
It is not useful: the neighbor knows it already.
It is harmful: the neighbor believes it is a different path.
Effects
Eliminates 2-router loops. Does not eliminate larger loops.
Speeds up convergence. Reduces routing update traffic.
Split horizon with poisoned reverse
Advertise infeasible routes with infinite metric (rather than
omitting them from the DV).
Increases the update size. In practice, it is used for limited time when
a (previously feasible) route becomes infeasible. Needed to speed up
convergence for the incremental update algorithm.
Octavian Catrina 14
 Example: state after convergence
Router B Via Router A Via Router E Via
Route M NH C A Route M NH B D E R M NH A
10.1/16 1 dc - - 10.1/16 1 dc. - - - 10.1/16 2 A 2
10.2/16 1 dc. - - 10.2/16 2 B 2 3 - 10.2/16 3 A 3
10.3/16 2 C 2 3 10.3/16 2 D 3 2 - 10.3/16 3 A 3
10.4/16 2 A 3 2 10.4/16 1 dc - - - 10.4/16 2 A 2
10.5/16 2 A - 2 10.5/16 1 dc. - - - 10.5/16 1 dc -
10.6/16 3 A - 3 10.6/16 2 E - - 2 10.6/16 1 dc. -

10.2.0.0 B 10.1.0.0
For DVR with split-horizon

C Metric = 1 10.5.0.0 10.6.0.0

10.3.0.0 A E
10.4.0.0

Router C Via D Router D Via Split-horizon:

Route M NH B D Route M NH C A Eliminates trivial loops,
10.1/16 2 B 2 3 10.1/16 2 A 3 2
10.2/16 1 dc. - - 10.2/16 2 C 2 3
faster convergence.
10.3/16 1 dc - - 10.3/16 1 dc. - - Example:
10.4/16 2 D 3 2 10.4/16 1 dc. - -
10.5/16 3 B 3 3 10.5/16 2 A 4 2
What happens if the link
10.6/16 4 B 4 4 10.6/16 3 A 5 3 from E to10.6.0.0/16 fails?
Octavian Catrina 15
 DVR enhancements (3)
Triggered updates
Send an update whenever the metric of a route changes,
besides the periodic updates.
Much faster convergence (than for periodic updates), but we
have to avoid update "storms".
Related enhancement: Allow a router to request an update
(e.g., after booting up, to build up its routing table).
Hold-down
When a route becomes infeasible, wait for a certain time (hold-
down timer) before accepting worse routes to that destination.
Wait until information about the incident propagates to all routers.
The route is marked and advertised as unreachable.
Even if it was not advertised earlier due to split horizon.
The route may still be used to forward packets (no alternative).
Less routing anomalies during convergence. For triggered
updates, less control traffic but longer convergence duration.
Octavian Catrina 16
 RIP timers (Cisco RIP)
Timer Description Default value
Update timer Time interval between the transmission of periodic 30 sec.
update messages.
Invalid timer Time interval until a route is considered invalid 180 sec.
because no updates confirming it have been
received. When it expires, the route is marked and
advertised as unreachable. Also, it is hold down
for the duration of the hold-down timer.
Hold-down timer Time interval during which a route is hold down. 180 sec.
This occurs when a neighbor indicates a network
as unreachable or the invalid timer expires. The
route is advertised as unreachable.
Flush timer Time interval until the route is removed from the 240 sec.
routing table if not confirmed by updates.
Sleep timer Optional delay before sending a triggered update

Octavian Catrina 17
 RIP packets
RIP version 1 packet format
Encapsulation
Req/Resp (1) Version (1) must be zero (2)
UDP header Header
RIP Port = 520 Address family id (2) must be zero (2)
Route IPv4 address (4)
RIP header
must be zero (4)
Route entry
must be zero (4)

Up to 25 RIP Route metric (4)

route entries (DV) (other route entries)

RIP version 2 packet format

Req/Resp (1) Version (1) Route Tag (2)
Header
Main RIPv2 improvements: Address family id (2) must be zero (2)
- Full support for subnetting, Route IPv4 address (4)
including VLSM. Route Subnet Mask (4)
Route entry
- Authentication. Next Hop (4)
Route metric (4)
- Packets are multicast not
broadcast.
(other route entries)
Octavian Catrina 18
 Link State
Routing (LSR)
Review
OSPF
 OSPF overview
OSPF: Open Shortest Path First Area 0
IGP based on Link State Routing (LSR). Backbone area

OSPF version 2: RFC 2328 (1998). ABR ABR ABR

Area 1 Area 3
OSPF version 3: RFC 5340 (2008). Area 2

Hierarchical network structure

The routing domain is divided into several areas interconnected
by a backbone area scalability, efficiency.
The topology of an area is hidden to the rest of the AS.
LSR within each area. Route summarization between areas.
Lower routing information traffic (flooding) and path computation
overhead. Smaller routing tables.
Link State Routing enhancements
Optimizations of the topological database and the routing info
exchange (e.g., for multi-access networks with many routers).
Octavian Catrina 20
 Link State Routing (LSR) (1)
Build the topological database
Each router distributes the state of its own links to all routers in
the domain (using reliable hop-by-hop flooding).
All routers collect the advertised link states and build identical
copies of a database describing the topology of the domain.

Graph model of the network topology

Physical network topology
determined by each router and stored
and link costs
in its local topological database
1 2 2
1 2 2 2
N1 N2 N1 R1 R2 N2
R1 R2 2
2 3 4
Link State
2 2 4
Advertisements 3
3 3 3 3
2 2 1 2 1
N3 N4 N3 N4
R3 R4 R3 R4
0 0
1 1 1 1
1 N7 1 1
N7
2 2 1
2 0 0 2
N5 N6 N5 R5 R6 N6
R5 R6

Directed labeled graph (edges are

labeled with the link metrics)
Octavian Catrina 21
 LSR (2)
Find the shortest paths
All routers independently run the same algorithm (Dijkstra) to find
the shortest paths from the topological database.
Each router computes a tree of shortest paths, with itself as root,
to all destinations.
The shortest paths are recomputed when the topology changes.
Run shortest-paths algorithm
Add the shortest paths
Network topology graph on the sub-graph containing
to non-transit (stub) nodes
only the transit nodes
2 2 2
1 2 1 2
N1 R1 R2 N2 R1 2
R2 N1 R1 R2 N2
2 2
2 2 2 4 2
2 4 2 4
3 3 3 3 3
3 3 3 3
2 1 2 1
N3 R3 R4 N4 R3 R4 N3 R3 R4 N4
0 0 0 0 0 0
1 1 1 1
1 N7 1
N7 1 N7
1 1 1 1 1
2 0 0 2 0 0 2 0 0 2
N5 R5 R6 N6 R5 R6 N5 R5 R6 N6

Example: shortest paths for R1

Octavian Catrina 22
 LSR (3)
Derive the local routing table
A router derives the entries in the routing table from the
computed shortest paths.
Shortest paths for R1 Routing table for R1
1 2 2 Router R1
N1 R1 2 R2 N2 Route Next hop Metric
2 2 4 N1 dir.con. 1
3 3 3 N2 R2 4
2 1
N3 R3 R4 N4 N3 R3 4
0 0
1 N4 R4 3
1
1
N7 N5 R3 5
1
2 0 0 2 N6 R3 5
N5 R5 R6 N6
N7 R3 3

Each router runs the same shortest path algorithm on the same
graph (hopefully), but with a different root node - itself.
Hence each router computes a different set of paths: from itself
to all destinations. However, the shortest path algorithm
guarantees that the resulting routing tables are consistent.
Octavian Catrina 23
 OSPF areas (1)
R1 External routes: External routes:
Area 1 N12, N13, N14 N12, N15 Area 2
N1
R4 R5 R7 R8
N3 N6 N7
R2 Backbone
N2 R3 area (0) R10
N4 N8
R6
Virtual link
belongs to R11
backbone
R9
Two-level network hierarchy N11

The AS is structured into multiple areas

N9
interconnected by a backbone area R12
(using physical or virtual links). N10

An area is a contiguous collection of Area 3

networks, delimited by routers.
The backbone area also connects the
AS to other ASes.
Octavian Catrina 24
 OSPF areas (2)
R1 External routes: External routes:
Area 1 N12, N13, N14 N12, N15 Area 2
N1
R4 R5 R7 R8
N3 N6 N7
R2 Backbone
N2 R3 area (0) R10
N4 N8
R6
Virtual link
R11

Types of routers R9
N11
Area internal routers:
R1, R2, R5, R6, R8, R9, R12. N9
R12
Area border routers (ABR):
N10
R3, R4, R7, R10, R11.
Area 3
Backbone routers:
All ABR + backbone internal routers (R5, R6).
AS border routers (ASBR):
R5, R7. Provide links to other AS.
Octavian Catrina 25
 Intra-area vs. Inter-area routing
R1 External routes: External routes:
Area 1 N12, N13, N14 N12, N15 Area 2
N1
R4 R5 R7 R8
N3 N6 N7
R2 Backbone
N2 R3 area (0) R10
N4 N8
R6
Virtual link
R11
Routing information exchange R9
N11
Intra-area: Each router floods throughout
an area the state of its own links that N9
belong to the area. R12

Inter-area: A separate topological DB is N10

maintained per area. The topology of an Area 3

area is invisible outside the area.
The backbone redistributes routing info
between areas.
Octavian Catrina 26
 Inter-area routing info exchange
R1 External routes: External routes:
Area 1 N12, N13, N14 N12, N15 Area 2
N1
R4 R5 R7 R8
N3 N6 N7
R2 Backbone
N2 R3 area (0) R10
N4 N8
R6
Virtual link
R11
Inter-area routing information exchange
R9
An ABR has a separate database for each area N11
it belongs to. It reports on the backbone topology
summaries (routes) for its non-backbone areas. N9
R12
It injects into its non-backbone areas summaries
N10
about other areas learned on the backbone. It
also injects external routes learned from ASBRs. Area 3

Redistribution of routes via the backbone is similar to route advertisements

in DVR. Similar way of computing route metrics.
Redistribution can be limited for stub networks (replaced by default route).
Octavian Catrina 27
 IP packet forwarding
R1 External routes: External routes:
Area 1 N12, N13, N14 N12, N15 Area 2
N1
Inter-area R4 R5 R7 R8
N3 N6 N7
R2 Backbone
Intra-area
N2 R3 area (0) R10
N4 N8
R6
Virtual link
R11
R9
N11
Packet forwarding
Intra-area traffic is independently N9
handled by each area (based on its R12

own routing info, links). N10

Inter-area traffic is forwarded via the Area 3

backbone.

Octavian Catrina 28
 OSPF topological database
Stub multi-access network
R1 From R1 N1
c1 c1
N1 To R1 N1
R1
N1 c1

Point-to-point network From R1 R2

c1
R1 R2 To R1 c2 R1 R2
c1 c2 c2
R2 c1
Unnumbered

From R1 R2
c1
R1 R2 To R1 c2 R1 R2
c1 c2 c2
R2 c1 c1 c2
A1 A2
A1 c2
A2 A1
A2 c1
Multi-access network
R1
c1 From R1 R2 R3 N1 c1
R1
R3 To R1 0
c3 0 c3
N1 R2 0 N1 R3
0 0
R2 R3 0
N1 c1 c2 c3 R2 c2
c2
Octavian Catrina 29
 Link state advertisements (LSA)
LSA Advertisement Advertisement description
Type name
1 Router (links) Originated by all routers. Describes the collected states of the
advertisement router's interfaces to an area. Flooded throughout a single area
only.
2 Network (links) Originated for multi-access networks by the Designated Router.
advertisement Contains the list of routers connected to the network. Flooded
throughout a single area only.
3, 4 Summary (link) Originated by area border routers, and flooded throughout the
advertisement advertisement's associated area. Describes a route to a
destination inside the AS, but outside the area (inter-area route).
- Type 3 describes routes to networks.
- Type 4 describes routes to AS boundary routers.

5 AS external link Originated by AS boundary routers, and flooded throughout the

advertisement AS. Each AS external link advertisement describes a route to a
destination in another AS. Default routes for the AS can also be
described by AS external link advertisements.

Octavian Catrina 30
 LSA examples
R1 External routes: External routes:
3 Area 1 N12, N13, N14 N12, N15 Area 2
N1 8
1 R4 R5 R7 R8
1 8 8 6 6 2 1 1
N3 N6 N7
R2 1 Backbone 7
3
N2 1 R3 area (0) 6 R10 2
2 8 6 7 5
N4 N8
2
R6 2
Virtual link
R1 Router LSA (Type 1) R3 Summary LSA for Aria 1 (Type R11
From R1 N1 N3 3, flooded in the backbone area) 1 R9
From R3 N1 N2 N3 N4 3
To R1 N11
1
N1 3 To R3

N3 1 N1 4
N9
N2 4 1 R12
N3 Network LSA (Type 2) 2
N3 1 N10
From R1 R2 R3 R4 N3
N4 2
To R1 0 Area 3
R2 0
R3 0
Networks in an area are assigned IP address blocks
R4 0 with certain prefixes. Routes to sets of blocks with a
N3 common prefix can be summarized ...
Octavian Catrina 31
 Topological DBs for areas 1 and 0
R1 Area 1
3 R4 R5 R7 R8
N1 1 8 1
1 8 6 6 2 1
N3 N6 N7
R2 1 Backbone 7
3 1 R3 area (0) 6 R10 2
N2 7 5
2 8 6 Area 2
N4 N8
2
Area 0 DB R6 2
Virtual
From R3 R4 R5 R6 R7 R10 R11 link
Area 1 DB R11
To R3 6
From R1 R2 R3 R4 N3 R4 8 1 R9
To R1 0 R5 8 6 6 3
1 N11
R2 0 R6 8 7 5
R3 0 R7 6
R4 0 R10 7 2 N9
N1 3 1 R12
R11 2
2
N2 3 N1 4 4 N10
N3 1 1 1 1 N2 4 4
N4 2 N3 1 1 Area 3
N6 17 16 N4 2 3
N7 18 17 N6 2 2 4
Notes:
N8 17 18 N7 3 3 5 R11 is connected to areas 2, 3, and 0
N9 18 19 N8 4 2 2 (virtual). For simplicity, point-to-point links
N10 20 21 N9 1 are assumed unnumbered (but this is
N11 21 22 N10 4 problematic for R5, R6).
N11 3
Octavian Catrina 32
 Setup & maintenance of the topological DB
Objectives
Consistent routing tables maintain synchronized topological
DBs in all routers, with fast update in case of topology changes.
Low control traffic and processing overhead use efficient
mechanisms for distributing the routing information (especially
for multi-access networks).

Mechanisms for creating/maintaining the topological DB

Neighbor discovery: Directly connected OSPF routers discover
each-other (Hello protocol).
Adjacency setup: Neighbor routers set up an efficient topology
for routing information exchange (adjacency relations).
DB synchronization: During adjacency setup, routers perform
an initial synchronization of their topological DBs.
DB update: Routers maintain/update their topological DB by
reliable flooding of LSAs following adjacency relations.
Octavian Catrina 33
 Neighbor discovery
Neighbor relation
Routing information travels hop-by-hop OSPF routers
attached to the same link (physical or virtual) must discover and
identify each-other, i.e., establish a "neighbor relation".
R1
OSPF Hello protocol N1
Hello! R4
The Hello protocol is used to establish Area 1 N3
and maintain neighbor relationships. R2
R3
Hello packets are sent periodically out all N2
N4
router interfaces (multicast, if supported).

A Hello packet includes the sender's identity and the list of all the
known neighbors (on that link).
A neighbor is considered "dead" if it stops sending periodic Hello
packets (according to timer values in Hello packets).
On multi-access networks the Hello protocol also elects a
designated router and a backup designated router (next slides).
Octavian Catrina 34
 Adjacency relation (1)
Adjacency relation
Two neighbor routers that directly exchange routing information
and synchronize their topological DBs are called adjacent.
To improve efficiency, only a subset of neighbor routers
establish adjacency relations.
Area 0
Point-to-point links R4
Always adjacent
R5

Routers connected by a point-to-

point link are always adjacent.
R1
Multi-access networks N1 What
adjacencies? R4
Any-to-any adjacencies would be Area 1 N3
R2
inefficient (e.g., imagine the initial
N2 R3
exchange of the topological DBs N4
and flooding of the LSA updates).

Octavian Catrina 35
 Adjacency relation (2)
Adjacencies on multi-access networks
Adjacencies on multi-
OSPF routers use the Hello protocol R1 access network N3
R4, elected
to elect: N1
DR for N3
- a Designated Router (DR) and Area 1 N3
R2
- a Backup Designated Router (BDR).
N2 R3
Adjacencies are only set up between N4
the DR/BDR and the other routers. All routers also set up
adjacencies with the BDR.
DR responsibilities
Routers on a multi-access network synchronize their topological
DB with the DR: DB exchange with the DR at adjacency setup
(not any-to-any), followed by LSA updates afterwards.
DR floods a Network-LSA which lists the routers connected to
the multi-access network.
DR disseminates the LSAs from the rest of the AS to the routers
on its multi-access network.
Octavian Catrina 36
 OSPF packets
Type Packet name Protocol function

1 Hello Used to discover and maintain neighbor relationships between

routers, and elect the DR/BDR on multi-access networks.
2 Database Contains a summary of the topological database contents.
Description (DD) Used to synchronize databases during adjacency setup.
3 Link State (LS) Request to download specified entries in the topological
Request database.
4 Link State (LS) Contains updates for the topological database.
Update
5 Link State (LS) Acknowledges the receipt of a Link State Update (OSPF
Ack provides a reliable transfer of routing information updates).

OSPF runs directly over IP (protocol id=89).

OSPF packets are exchanged only between adjacent routers.
Except for the packets used in the process of discovering neighbors and
setting-up adjacencies.

Octavian Catrina 37
 OSPF packet formats (1)
OSPF packet header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuthType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link State Advertisement (LSA) header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Five LSA types.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An LSA consists
| LS age | Options | LS type | of a header with
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ common format
| Link State (LS) ID | followed by link
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ description data
| Advertising Router |
specific for each
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | LSA type.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Octavian Catrina 38
 OSPF packet formats (2)
Hello packet: OSPF Header +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options |Router Priority|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbors |
+- +-+
| ... |

Database Description (DD) packet: OSPF Header +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I = Init bit = 1 in
| Interface MTU | Options |0|0|0|0|0|I|M|MS| first packet in DB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ synchronization.
| DD sequence number | M = More bit = 1 if
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ more DD packets
| | follow.
| LSA Headers | MS = Master (1)
| | or Slave (0) bit.
+- +-+
| ... |

Octavian Catrina 39
 OSPF packet formats (3)
Link State (LS) Request packet: OSPF Header +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |

Link State (LS) Update packet: OSPF Header +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |

Link State (LS) Ack packet: OSPF Header +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSA Headers |
+- +-+
| ... |

Octavian Catrina 40
 Adjacency setup (1)
Router ID: R3
Router ID: R1 172.16.1.3 Router ID: R2
172.16.1.1 172.16.1.2
172.16.1.0/24

Adjacency Adjacency
Scenario: OSPF on router R1 has just started.
state state
Router R2 is currently DR. R1 will accept R2 as DR.
Down Down
Hello (RouterID = R1; Neighbors = none; DR = none; ...)
Init Init
Hello (RouterID = R2; Neighbors = R1, R3, ...; DR = R2; ...)
ExStart ExStart
Initialize topology DB exchange

Database Description (Seq = x , I = 1, M = 1, MS = 1) We assume that

R2>R1, hence R2
Database Description (Seq = y, I = 1, M = 1, MS = 1) becomes master

Database Description (Seq = y , I = 0, M = 1, MS = 0)

Exchange Exchange
Exchange DB: Database description

Database Description (Seq = y+1, I = 0, M = 1, MS = 1)

Database Description (Seq = y+1 , I = 0, M = 1, MS = 0)

...

Octavian Catrina 41
 Adjacency setup (2)
Router ID: R3

Router ID: R1 172.16.1.3 Router ID: R2

172.16.1.1 172.16.1.2
172.16.1.0/24

Adjacency Adjacency
state Exchange of topology DB continued state
...
Exchange Exchange
Database Description (Seq = y+1, I = 0, M = 0, MS = 1)

Database Description (Seq = y+1 , I = 0, M = 0, MS = 0)

Exchange DB: LSA loading
(can be interleaved with DD exchange)

LS Request (IDs of requested LSAs)

Loading LS Update (requested LSAs)
Loading
LS Ack (acked LSA headers)

LS Request (IDs of requested LSAs)

LS Update (requested LSAs)
LS Ack (acked LSA headers)
Full Full
...
DBs are now synchronized.
Adjacency setup is finished
Octavian Catrina 42
 Topology update - examples (1)
Adjacencies on multi-access network N3 New network N5 attached to R2
R1 R1
N1 R4, elected N1 R4, elected
DR for N3 DR for N3
Area 1 N3 Area 1 N3
R2 R2
LS Update
N2 R3 N2 R3
N4 N4
LS Update N5
All routers also set up DR delivers the LS Update (LSU)
adjacencies with the BDR. LS Ack using multicast, if available

New LS Update received by R4 from another router New LS Update received by R3 from another router
R1 R1
N1 R4, elected N1 R4, elected
DR for N3 LS Update DR for N3
Area 1 N3 Area 1 N3
R2 R2
N2 R3 N2 R3 LS Update
N4 N4

N5 N5
DR uses multicast, DR uses multicast,
if available if available
Octavian Catrina 43
 Topology update - examples (2)
Scenario: New network N1 attached to R1:
R1 sends LS Update with Router LSA announcing link to N1 (to R4 = DR, and to BDR).
LS Update is flooded all over the area, hop-by-hop, reliably (LS Ack, retransmission).
LSA sequence number allows routers to distinguish duplicates and discard them.
Each router runs SPF algorithm and updates its routing table.
Also, the area's ABRs send in the other areas LS Update containing a Summary LSA
announcing the route to N1.

R1 Area 1
3
N1 LS Update DR for N3
1 R4 R5
1 8 6 N5
N3
R2 1 7
3
N2 1 R3 6
6 7
N4 N6
2
R6
After receiving LS Update
from R3, R6 suppresses
LS Update
the copy from R5
LS Ack (same sequence #)

Octavian Catrina 44
 LS Update processing

Received Yes Yes

Is LSA in Is seq.
LS Update
DB? the same?
(LSA)
No Ignore LSA
No

Yes Is seq.
Add to DB Send LS Ack
higher?
to source

Send LS Ack No
End
to source
Send LS Update
with newer LSA
Flood the LSA to source
within the area
Implicit Ack

Run SPF to build Simplified!

End
new routing table

End
Octavian Catrina 45