Transcript 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