Spring 2008CS 3321 Intradomain Routing Outline Algorithms Scalability

Spring 2008CS 3322 Give Credit: Some of the figures I’ve used in this set of slides are from the Prentice-Hall text “Computer Networks” (3 rd Edition), by Andrew Tanenbaum.

Spring 2008CS 3323 Overview Forwarding vs Routing –forwarding: to select an output port based on destination address and forwarding table –routing: process by which routing table is built –Forwarding table (based on routing table) optimized for next hop lookup –Routing table optimized for tracking changes in topology and calculating “best” routes. Problem: Find lowest cost path between two nodes Key question (as always): Will our solution scale? –Answer: No! (At least not the first things we examine)

Spring 2008CS 3324 Overview Network as a Graph Nodes represent networks Edges represent costs Factors –static: topology – what links exist –dynamic: load – how busy is a link D G A F E B C

Spring 2008CS 3325 Terminology Routing domain: internetwork in which all routers are under the same administrative control –Small to midsized networks, e.g. university campus –Use intradomain routing protocols (interior gateway protocols (IGP)) Internet uses interdomain routing protocols

Spring 2008CS 3326 Distributed Algorithms Centralized control can kill scalability, reliability Nodes can only compute routing tables based on local info (i.e. information they possess) –Who needs to know what? When? –Who knows what? When? Convergence: process of getting consistent routing information to all nodes

Spring 2008CS 3327 Distance Vector (RIP, Bellman-Ford) Each node maintains a set of triples –(Destination, Cost, NextHop) Exchange updates with directly connected neighbors –periodically (on the order of several seconds to several minutes) –whenever its table changes (triggered update) Each update is a list of pairs: –( Destination, Cost) Update local table if receive a “better” route –smaller cost –came from next-hop

Spring 2008CS 3328 Example Destination Cost NextHop A 1 A C 1 C D 2 C E 2 A F 2 A G 3 A Sample routing table for node B Assume all link costs = 1

Spring 2008CS 3329 Example of Update F detects that link to G has failed F sets distance to G to infinity and sends update to A A sets distance to G to infinity since it uses F to reach G A receives periodic update from C with 2-hop path to G A sets distance to G to 3 and sends update to F F decides it can reach G in 4 hops via A

Spring 2008CS Note “distances” need not be hop counts

Spring 2008CS Calculate new route to G: Via A: = 26 Via I: = 41 Via H: = 18 Via K: = 37

Spring 2008CS Calculate new route to G: Via A: = 26 Via I: = 41 Via H: = 18 Via K: = 37

Spring 2008CS Complete updated table

Spring 2008CS Convergence Issues Distance vector schemes can converge slowly A is down initially, then comes back up. Assume all routers update simultaneously via common clock

Spring 2008CS Routing Loops Can happen because several nodes are updating routing tables concurrently Ex: The “count to infinity” problem Initially all lines are up, then either A goes down or the link between A and B is cut (same thing to B) Numbers indicate estimated distance to node A

Spring 2008CS Loop- Breaking Heuristics Set infinity to 16 Split horizon –Don’t send routes learned from a given neighbor back to that neighbor Split horizon with poison reverse –Reply to neighbor but give negative info (such as infinite cost) These are Hacks! –Delay convergence –Only work for loops involving 2 hosts

Spring 2008CS Distance Vector Summary Good –Only need communicate with neighbors (so little bandwidth is wasted on protocol overhead) –Relatively little processing of info Bad –Count to infinity problem –Slow convergence (the real issue) Despite this, RIP is popular –Because included in original BSD implementation

Spring 2008CS Link-State (OSPF – RFC 2328) Strategy –send to all nodes (not just neighbors) information about directly connected links (not entire routing table) Link State Packet (LSP) –id of the node that created the LSP –cost of the link to each directly connected neighbor –sequence number (SEQNO) –time-to-live (TTL) for this packet

Spring 2008CS Link-State (cont) Reliable flooding –store most recent LSP from each node –If new, forward LSP to all nodes but one that sent it –generate new LSP periodically increment SEQNO –start SEQNO at 0 when reboot –decrement TTL of each stored LSP discard when TTL=0

Spring 2008CS Route Calculation Dijkstra’s shortest path algorithm Let –N denotes set of nodes in the graph –l (i, j) denotes non-negative cost (weight) for edge (i, j) –s denotes this node –M denotes the set of nodes incorporated so far –C(n) denotes cost of the path from s to node n M = {s} for each n in N - {s} C(n) = l(s, n) while (N != M) M = M union {w} such that C(w) is the minimum for all w in (N - M) for each n in (N - M) C(n) = MIN(C(n), C (w) + l(w, n )) If you don’t know Dijkstra’s algorithm, please see me!

Spring 2008CS Example LSPs provide all the info a particular router needs to calculate DSP to all other routers

Spring 2008CS Link-State Summary Good –Converges relatively quickly Bad –Lots of information stored at each node because LSP for each node in network must be stored at each node (scalability problem) –Flooding of LSPs uses bandwidth –Potential security issue (if false LSP propogates)

Spring 2008CS Open Shortest Path First (OSPF) Typical link-state but with enhancements –Authentication of routing messages –Additional hierarchy (to help with scalability) –Load balancing

Spring 2008CS Distance Vector vs Link-state Key philosophical difference –Distance vector talks only to directly connected neighbors and tells them what is has learned –Link-state talks to everybody, but only tells them what it knows

Spring 2008CS Metrics Original ARPANET metric –measures number of packets enqueued on each link –took neither latency or bandwidth into consideration New ARPANET metric –stamp each incoming packet with its arrival time ( AT ) –record departure time ( DT ) –when link-level ACK arrives, compute Delay = (DT - AT) + Transmit + Latency –if timeout, reset DT to departure time for retransmission –link cost = average delay over some time period Fine Tuning (revised ARPANET metric) –compressed dynamic range –replaced delay with link utilization

Spring 2008CS What is actually done Metrics are changed infrequently, and by hand Experience with metrics showed they were not acceptably stable Link speeds aren't as varied as they were in ARPANET's heyday.