Transcript
Page 1: Routing: Cores, Peers and Algorithms

Routing: Cores, Peers and Algorithms

Chapter 14

Page 2: Routing: Cores, Peers and Algorithms

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

Page 3: Routing: Cores, Peers and Algorithms

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

Page 4: Routing: Cores, Peers and Algorithms

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

Page 5: Routing: Cores, Peers and Algorithms

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

Page 6: Routing: Cores, Peers and Algorithms

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,:

– a small 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

Page 7: Routing: Cores, Peers and Algorithms

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

Page 8: Routing: Cores, Peers and Algorithms

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

Page 9: Routing: Cores, Peers and Algorithms

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

Page 10: Routing: Cores, Peers and Algorithms

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

Page 11: Routing: Cores, Peers and Algorithms

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

Page 12: Routing: Cores, Peers and Algorithms

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

Page 13: Routing: Cores, Peers and Algorithms

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

Page 14: Routing: Cores, Peers and Algorithms

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

Page 15: Routing: Cores, Peers and Algorithms

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

Page 16: Routing: Cores, Peers and Algorithms

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

Page 17: Routing: Cores, Peers and Algorithms

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

Page 18: Routing: Cores, Peers and Algorithms

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

Page 19: Routing: Cores, Peers and Algorithms

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

Page 20: Routing: Cores, Peers and Algorithms

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

Page 21: Routing: Cores, Peers and Algorithms

For Next Time

• Read Chapter 15


Top Related