Download Chapter 13

Routing: Cores, Peers,
and Algorithms
Chapter 13
Have looked at:


TCP/IP network level services
Details of protocols in hosts and routers
Assumed routers contain correct routes
This chapter asks:


What values should routing tables contain?
How can those values be obtained?
Origin of Routing Tables
Router Review – Chap 3

Routers attach to 2 or more physical networks
Forward IP datagrams among them

Hosts pass all IP traffic to routers
Except for destinations on attached networks


Datagrams travel from router to router
Router system forms internet architectural
basis
Router Review – Chap 7

IP routing algorithm
Uses table to make forwarding decisions
Each entry specifies:



Network portion of destination address
Address of next machine to use to get there
Direct delivery
Like hosts, routers deliver datagrams directly to
destinations on networks to which they are attached
Still not said how hosts/routers get the
information for their routing tables


What values should be there
How the values are obtained
Establishing routes


Generally involves initialization and update
Initialization
Depends on OS
May read an initial table from secondary storage
May start empty and use commands (startup script)
May deduce some and ask for others

Update
Must accommodate changes
Small and slowly changing internets:

Establish and modify by hand
Large systems:

Must use automated methods
Will look at automatic routing table update
protocols

First look at some underlying ideas
Forwarding With Partial Information
Hosts usually know little about the network


Rely on routers
Some only have two routes:
Route for local network
Default route for nearby router
Can routers route with partial information?


Yes, but only under certain circumstances
Routing tables must be consistent and complete
Cannot have central router with all routes

A central intersection (star-shaped topology)
Cannot have all routes at every router

All intersections list all routes to everywhere
Third topology

Divide space in half
Some destinations in west; other destinations in east



Single bridge connecting the two halves
In east, list local destinations and point to bridge
In west, do opposite
Original Internet Architecture
Initially, ARPANET was Internet backbone


Tables installed and managed by hand
As it grew, this became unmanageable
Original automated architecture:

Small, central set of routers
Kept information about all possible destinations

Larger set of outlying routers
Kept partial information and route to a central router

Advantage:
Local administrators manage change without affecting
other parts of the Internet

Disadvantage:
Potential for inconsistency

Error in outlying router makes some destinations unreachable
Get inconsistencies from




Errors in the algorithms computing routing tables
Incorrect data given to the algorithms
Errors from transmissions to other routers
Want protocols to
Detect and correct errors quickly
Constrain the effect of errors
Core Routers
Had two groups: core and noncore routers



Noncore had to advertise address to core
Cores communicated among themselves
Evolved due to building on top of ARPANET
Did not lend itself to routing with partial
information
Figure 13.1 The early Internet core router system viewed as a set of routers
that connect local area networks to the ARPANET. Hosts on the
local networks pass all nonlocal traffic to the closest core router.
Needed to avoid default route inefficiencies



Arranged for core routers to exchange info
All have complete, optimal routes
Core routers did not have default routes
“Destination unreachable” if destination not in table
Easy to do because all connected to single
backbone network
This picture illustrates why the early system of core routers did not allow
default routes. With default routes, a local router would check for an explicit
route and if it did not have one, it would use the default route. To ensure
global consistency, the chain of default routes must reach every router in a
giant cycle. The sites had to coordinate the default routes, and forwarding
could be extremely inefficient.
Beyond the Core Architecture
NSFNET backbone added new complexity

Initially, connection was like any site
NSFNET attached to ARPANET via 1 core router
Core had explicit routes to all destinations in NSFNET
NSFNET routers knew about local destinations
Had default route to non-NSFNET traffic via core

NSFNET grew
Multiple connections between the two were added
Became peers
Figure 13.2 An example of two peer backbones interconnected by multiple
routers. The Internet had such an architecture in 1989.
Difficult to route among peer backbones

Consider route from Host 3 to Host 2
3 on West Coast; 2 on East Coast
Go thru R1and then over ARPANET backbone, or
Go thru R2 and then to ARPANET, or
Go thru R3 and then to ARPANET, or
Up R1, down R2, back up R3 to host!!

Usually try to take shortest path
Easy to say; hard to implement


Optimal forwarding in a peer backbone requires individual
routes for individual hosts
Managers must agree to consistent routes or get loops
Automatic Route Propagation
Core routers exchanged information

Propagated complete route information
Many corporate internets do that


Look at two types of algorithms that compute &
propagate routing information
Later – discuss protocols that use them
Routing protocols serve two functions


Compute set of shortest paths
Respond to failures or topology changes by
updating the routing information (dynamic)
Distance Vector Routing
Also called Bellman-Ford routing
Class of algorithms that propagate
routing info
Simple


Router keeps list of all known routes
On boot, initializes to entry for each directly
connected network
Figure 13.3

Periodically, exchange routing tables
Sends to routers it can reach directly
Updates information



If other router knows shorter route
If other router lists destination not have an entry for
If other router has longer destination for routes used thru it
Figure 13.4


Routes thru J will be N+1
Message contains list of pairs (V, D)
V identifies destination (called the vector)
D is the distance to the destination
Ok in completely static environment

Poor when routes change rapidly
New connections appear; old ones fail
Information propagates slowly
Discuss further later; ignore problems for now
Reliability and Routing
Protocols
Routing protocols use IP or (mostly) UDP


Can lose, delay, duplicate, etc. messages
Routing protocol must compensate for failures
Several ways



Checksums for corruption
Loss by soft state or positive ACK with retrans
Sequence numbers for out of order delivery
Link-State (SPF) Routing
Distance-Vector algorithm does not scale


Update size proportional to total # of networks
Lots of volume due to all routers participation
Primary alternative

Class of algorithms called Shortest Path First
Each participating router must have complete topology
information
Graph: routers are nodes; networks are edges
Edge between nodes only if routers communicate

SPF routers perform two tasks (vs sending msgs)
Actively tests status of neighbor routers

Sends short msg to see if link is up
Propagates the link status info to all other routers



Not report routes
Says if communication possible between pairs of routers
Routers update with the link status messages
Recompute paths if status changes
Use Dijkstra’s shortest path algorithm

Each router computes routes independently
Use same original link status information
Easy to debug
Guaranteed to converge (since done locally)
Scale better; message size not depend on number of
networks
Summary
Internet must provide globally consistent
routing


Hosts and most routers have partial info
Depend on default routes
Originally, used core routers


Cores traded information
No default routes to prevent loops
Core system not work well for peer backbones
To exchange info, routers use either:

Distance-vector algorithms
Perform distributed shortest-path computations

May not converge in continually changing environment
Update messages grow as number of nets increases

SPF
Converges due to local computations
Scales better since message size not dependent on the
number of networks