Routing at the Network Layer
Relationship to switches
In an internetworking environment, switches are essentially routers
Switch receives packets, then forwards them to other switches based on routing information: store and forward.
It has buffer space to store packets received but not yet forwarded (busy output line). If switch is highly connected, this will prove essential.
Internetworking
internetworking goal: universal service across heterogeneous networks.
Internetworks are formed by connecting networks with routers and gateways.
Conceptually, internet consists of hosts and routers.
- Hosts run entire network protocol stack.
- Routers do not run entire protocol stack (esp. application layer)
Routing Table
Switch has routing table, which is consulted to determine which output line to send the packet out.
Route Determination Methods
Methods for determining routes in network fall into several categories. Consider the advantages and disadvantages of each:
- centralized
. A distinguished node has global knowledge of network and runs algorithm to determine shortest path, then distributes routing information to other nodes.
- distributed
. Each node dynamically builds its routing table using local information, usually obtained from backward learning, plus information it receives from its neighbors (and possibly from other nodes as well).
- isolated
. Each node determines routing tables using only local information obtained from backward learning. An extreme form of the distributed method.
Distance Vector Routing : A Distributed Approach
Essence:
- routers exchange routing information with neighbors.
- Information packet from each neighbor is called "vector"
- Vector contains "best known distance" to each destination from that neighbor.
- "Neighbor" means directly connected.
- router uses info from neighbors to update its routing table
Router receiving this vector:
a. Maintains routing table with entry for each destination. Entry has:
- destination
- estimated shortest distance (normally hop count)
- next hop on shortest path
b. knows "distance to neighbor" from which it receives vector (e.g. 1 hop)
Upon receipt of vector, router processes each destination included in vector:
- add "distance to neighbor" to "best known distance" (from vector)
- compare sum to routing table "estimated shortest distance" to that destination
- if less, store new sum and neighbor into routing table entry
- if more, but "next hop" is vector’s router, update "estimated shortest distance"
In practice, it was found that "good news traveled faster than bad" Network was quicker to record reduced distances than increased ones. Traffic would quickly flow to routers along the new path.
Link State Routing : another distributed approach
Essense is that each router:
- knows its neighbors
- knows "distance" to each neighbor. (#hops, bandwidth, congestion, etc.)
- broadcasts "distance to neighbor" to all other routers in the internet.
- uses received broadcasts to run Shortest Path algorithm locally
Dijkstra shortest path algorithm:
PreDefinitions:
- designate source node
- put all other nodes into set S
- array D[v] is weight from source to node v if known (else infinite)
- routing table R, where R[v] is next hop router for destination v.
Algorithm:
while S is not empty,
- chose node u from S s.t. D[u] is minimum
- remove u from S
- for each neighbor v (of u) which is still in S
- weight from source to v is calculated
- if it is less then D[v], update distance
- make it the new D[v]
- set next-hop in routing table R[v] to R[u] (e.g. same next-hop if dest is u or v)
Dijkstra's algorithm is attractive in that "weight" is defined to be whatever the network designers want: distance, bandwidth, delay,utilization, number of switches (each hop has weight of one), etc.
Note of Historical Interest
ARPANET (now Internet) originally used Distance Vector routing
In 1979, switched to Link State routing.
Reasons:
- Algorithm ran slow due to increased number of network nodes
- assumption of uniform bandwidth for all links was no longer true.
Related Home Pages:
notes | CSC 465 | Peter Sanderson | Computer Science | SMSU
Last reviewed: 10 April 2000
Peter Sanderson ( pete@csc.smsu.edu )