CS5480: Data Communication and Networks Lecture 15 Overall organization: - Basics of routing - Distance vector routing --------------------------------------------------------------------------- Topic: Basics of Routing Routing: process of building up `routing tables' used by switches Desirable attributes of a routing protocol: * efficiency or optimality - minimize network waste, overhead, cost, and latency - maximize bandwidth utilization * correctness - packet go where they are supposed to go * simplicity - decreases cost of algorithm and chance of errors * robustness - ability to maintain function even under failures * stability - over time, network congestion will vary at various spots - reaction time delay may cause network performance to be extremely unstable - need to minimize this effect * fairness - ideally want to give each customer their fair share of the resources - perhaps impossible to achieve efficiently --------------------------------------------------------------------------- Topics: Elements of Routing Techniques * Performance: - particularly difficult in a heterogeneous LAN/WAN environment - number of hops - influenced by topology and network health - several aspects: cost, delay, throughput * Decision time: - packet (datagram) - session setup (virtual circuit) * Decision place: - centralized (designated supervisory node) - distributed (each node decides) - source routing (each TX specifies route) * Routing strategy: - fixed - flooding - random - adaptive: if so, how? - continuous - periodic - how does it deal with major load or topology changes What makes the problem interesting (i.e., hard): - networks are DISTRIBUTED SYSTEMS: nodes are separated - networks are DYNAMIC SYSTEMS: - load, health, topology, configuration, use, ... change - notion `network state' is nebulous -- changes, unknown Routing basically boils down to GRAPH THEORY: - routing is form of dynamic `path selection' - good algorithms associate `costs' with links --------------------------------------------------------------------------- Topic: Example Network (we'll come back to this time and again) <-8 +-----------------------+ | 5-> | | | | <-3 3-> V 5-> | ---> B <-----------> C <--- | /2-> ^ <-6 /^ \<-8 |/ |^ / | \ v 2 || <-3 / |^ v A | |2 --------/ 1 || F ^ V | / 3-> | |1 ^ \1-> | / v | / \ v/ <-1 v <-4/ 2-> ---> D <-----------> E <--- <-7 1-> * Six machines (nodes A through F) * Twenty links (not always symmetric capacity) Weights between nodes: D E S T I N A T I O N A B C D E F --------------------------------------------------- S A 0 2 5 1 - - O B 3 0 3 2 - - U C 8 6 0 3 1 5 R D 7 2 3 0 1 - C E - - 1 1 0 2 E F - - 8 - 4 0 These values represent the `cost' of the DIRECT connections SPACE for you to draw network (since it is hard to read in ASCII): --------------------------------------------------------------------------- Topic: Routing algorithms Note: For most graph algorithms that you've seen, e.g., traveling salesman or depth-first-search, you are given the complete graph and the weights on each edge as inputs... ... unfortunately, in a real network: - the set of nodes change over time, - the set of edges change over time, - the weights on the edges change over time, and - nobody knows the full topology or set of weights! ==> EACH NODE ONLY SEES A PART OF THE PROBLEM ==> The challenge of routing algorithms is trying to come up with a good heuristic that works in the face of this utter lack of complete (and changing) information! --------------------------------------------------------------------------- Topic: Distance vector routing (simplest dynamic algorithm) Idea: Each node knows the current best DISTANCE from it to each other node, as well as the direction (or VECTOR) to take to get there. By distributing this information, each node can build an accurate DISTANCE-VECTOR table, which is what you want from your ROUTING TABLE. Algorithm: Data structures: ---------------- distance[*] = distance from current node to node * vector[*] = link to use to send to node * message.* = distance from sending node to node * foreach destination D such that distance[D] != infinite { Send(myid, distance); } Repeat { Receive(N:sending node, message: N's distance information); new_vector = false; /* Ddid we update our table?*/ foreach destination D { if (distance[D] > distance[N] + message.D) { distance[D] = distance[N] + message.D; vector[D] = N; new_vector = true; } } /* Do we have to send a TRIGGERED UPDATE? */ if (new_vector) Send(myid, distance); } Goal: each node wants to calculate distance[] and vector[] values that make up their routing table. From example above: INITIAL STATE: D E S T I N A T I O N A B C D E F --------------------------------------------------- S A 0 2 5 1 - - O B 3 0 3 2 - - U C 8 6 0 3 1 5 R D 7 2 3 0 1 - C E - - 1 1 0 2 E F - - 8 - 4 0 * D sends its vector to A, B, C, and E: D E S T I N A T I O N A B C D E F --------------------------------------------------- S A 0 2 4D (5) 1 2D (-) - O B 3 0 3 2 3D (-) - U C 8 5D (6) 0 3 1 5 R D 7 2 3 0 1 - C E 8D (-) 3D (-) 1 1 0 2 E F - - 8 - 4 0 * The `D' after the number means that this distance is via node `D'. * The numbers in parentheses are the previous best route. * Node E sends its vector to nodes C, D, and F D E S T I N A T I O N A B C D E F --------------------------------------------------- S A 0 2 4D 1 2D - O B 3 0 3 2 3D - U C 8 5D 0 2E (3) 1 3E (5) R D 7 2 2E (3) 0 1 3E (-) C E 8D 3D 1 1 0 2 E F 12E (-) 7E (-) 5E (8) 5E (-) 4 0 * Node A sends its vector to B, C, and D: NO CHANGE! * This process continues until no changes anywhere: - strong suggestion: finish this at home Result: each node will have built it's routing table * Node E (at the time above): Destination NextHop | Cost ----------- ------- | ---- A D | 8 B D | 3 C C | 1 D D | 1 F F | 2 - you can extract the routing table for each other node from the above `global perspective' in the same way --------------------------------------------------------------------------- Topic: Handling Failures * Even after the algorithm has stabilized, each node continues to send out routing messages `periodically' - rate of these is dependent on implementation - this lets system handle transient changes in system: - node failures - changes to `congestion' (weights change) * Failure detection: - active : polling - passive: assume dead if you miss N regular updates * Handing failures: - update your routing table to show `infinite' distance to failed node - similarly, mark as `infinite' distance any path that has failed node as NextHop - initiated `flooding' algorithm (above) - most of the time, new routing information will quickly be recreated without failed node --------------------------------------------------------------------------- Topic: Algorithmic instabilities Unfortunately, bad timing of updates can cause instability: Simple example network: A B C - - - <-1-> <-2-> A 0 1 3 A <---------> B <---------> C B 1 0 2 C 3 2 0 * suppose node C fails, and node B detects this... A B C - - - A 0 1 3 B 1 0 - * node C sends update to node A: (B->A = 1, B->C = infinite) * node A looks up in its table, and sees that it has a better route to C than B (or so it thinks), and send update to C: (A->B = 1, A->C = 3) * node B looks in its table and says, "Oh, node A has a way to get to `C', cool" and adds that path to its routing table. * ........counts to infinity --> consider case with a 3 node loop . Solutions: - split horizon: do not send routes back to another node that you think go through that node - node A would not tell B about its route to C - split horizon with poison reverse: even better -- node B could convince node A that its route to C is invalid Unfortunately, neither of these solutions work in really large systems. --------------------------------------------------------------------------- Topic: Link State Routing Idea: Flood STATE information about directly-connected LINKS to all other routers and nodes -- let them determine routes using semi-complete information collected from flooding. Flooding: * send all neighbors a link-state packet containing: - sender's node ID (S) - list of nodes directly connected to S, and current costs - sequence number of l-s packet - TTL for routing information * upon receipt of an LSP, decrement its TTL, and if non-zero, forward it to all neighbors except one that sent it to you - if current packet's seqno > seqno of last LSP from same node, save it Calculating routes: * collection of LSP's essentially lets each node see a subset of the connectivity graph (trying to `centralize' graph walk algorithm, without being complete `centralized') * once you have fairly complete graph info, use standard graph shortest-path algorithms (Djikstra, Bellman-Ford, ...) --------------------------------------------------------------------------- Next time: Link state routing, and comparison