1 / 21

Routing: Cores, Peers and Algorithms

Routing: Cores, Peers and Algorithms. Chapter 14. The Origin of Routing Tables. Routers form the base of an internet and handle all traffic except for direct delivery from one host to another We have two questions: What should be in routing tables?

shamus
Download Presentation

Routing: Cores, Peers and Algorithms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Routing: Cores, Peers and Algorithms Chapter 14

  2. The Origin of Routing Tables • Routers form the base of an internet and handle all traffic except for direct delivery from one host to another • We have two questions: • What should be in routing tables? • How do routers get the information for the tables? • Initial routes may be determined: • from secondary storage into main memory at startup • from a set of addresses of connecting networks

  3. The Origin of Routing Tables • In small internets, the routing tables may be established and modified by hand • In large internets, automated approaches are necessary

  4. Routing with Partial Information • Hosts usually have two routes in their routing table • A route for the local network • A default route for nonlocal datagrams • Example of road signs with partial information, page 255 • Extreme Architectural Approaches • Star shaped topology with one road to each town, one central point • Arbitrary roads with signs for all towns at each intersection

  5. Routing with Partial Information • The two extreme architectural approaches fail • Star - one machine would have to work as switch between all • Arbitrary - to keep all routing information at all sites is cumbersome and difficult to change • A third approach • Half of the cities lie in the east and half in the west • A bridge spans a river that separates the east and west • Road signs in the east list all destinations in the east, and only points to the west, and so on

  6. Original Internet Architecture and Cores • When TCP/IP was developed, research sites were connected to the ARPANET (Internet backbone) • Routing tables were initialized and modified by hand • To begin automation for routing,: • asmall central set of routers kept complete information about all possible destinations • a larger set of outlying routers kept partial information • allows local administrators to make local changes • default routes at the outlying routers could indicate a central intersection

  7. Core Routers • Those early routers were either: • Core routers controlled by Internet Network Operations Center • or Noncore routers controlled by inividual groups • Core routers communicated among themselves • information was consistent and the system was reliable • Sites assigned an Internet network address agreed to advertise that address to the core system

  8. Core Routers • The early Internet core routing system consisted of routers connecting local area networks to the ARPANET • See Figure 14.1 • Hosts on the local networks passed nonlocal traffic to the core router • Routing information was exchanged between core routers • Default routes were not used; would be inefficient

  9. Core Routers • This approach became impractical because: • the Internet outgrew a single, centrally managed long-haul backbone • protocols needed to maintain consistency among core routers became nontrivial • maintaining correct routing information became difficult

  10. Peer Backbones • NSFNET attached to ARPANET through a single router in Pittsburgh • The core had explicit routes to all destinations in NSFNET • Routers inside NSFNET knew local destinations and used a default route (the Pittsburgh router) to send all non-NSFNET traffic to the core • Multiple connections were added between NSFNET and ARPANET as shown in Figure 14.4 and the two became peer backbone networks, or peers

  11. Peer Backbones • With such an architecture, how do we route with peer backbones? • Routing loops are possible as in Figure 14.5 • Core systems work best for internets with a single, centrally managed backbone • Expanding the topology to multiple backbones makes routing complex

  12. Automatic Route Propagation • The original Internet core system propagated complete routing information to all core routers • Today, many routers continue to communicate routing information • We need ways to automatically determine routes, and to continually update the information needed to determine the routes

  13. Distance Vector Routing(aka Bellman-Ford) • A router keeps a list of all known routes in a table • When it boots, the routing table is initialized with an entry for each directly connected network • Each entry identifies a network and the distance to it, usually in hops - See Figure 14.6 • Periodically, all routers send a copy of their routing table to any other router it can reach directly • If a shorter path is found in one of these, the current path is replaced with the shorter one

  14. Distance Vector Routing • See Figure 14.7 which shows an existing table for router K, and an update from router J • Is this a good choice? • Easy to implement • If routes change rapidly, routes may not stabilize • Some routers may have incorrect information • Message size is proportional to the number of networks in an internet

  15. Gateway to Gateway Protocol • GGP was used by original core routers to exchange routing information - no longer used • Designed to travel in IP datagrams like TCP and UDP • Messages had a fixed format header identifying message type

  16. Distance Factoring • Distance values were small, and the same values tended to be repeated often • To reduce the message size, avoid sending copies of the same distance number • The list of pairs (Network, Distance) is sorted by distance • each distance is represented once and all networks at that distance follow

  17. Reliability • Most routing protocols use connectionless transport • Routing protocols that use UDP or IP must compensate for failures • by using checksums • sequence numbers for out of order delivery

  18. Link-State Routing • Primary alternative to distance vector routing • Tests the status of all neighbor routers • Short message asking if neighbor is alive • If the neighbor responds, the link is up, else down • Routers periodically broadcast a message with the status of each of its links • Indicates whether communication is possible between pairs of routers • When link status information arrives at a router, it modifies its view of the internet

  19. Shortest Path First • When link status changes, the router recomputes routes by applying Dijkstra’s Shortest Path algorithm • SPF computes the shortest paths to all destinations from a single source • Advantages • each router computes routes independently • messages are propagated unchanged • size does not depend on number of networks in internet

  20. Summary • Hosts and routers usually contain partial routing information • The Internet used a core routing architecture in which cores had complete network information • Routing information is exchanged periodically • using distance-vector or link state algorithms

  21. For Next Time • Read Chapter 15

More Related