Interdomain Internet Routing

Interdomain routing is concerned with connecting ISPs, or Autonomous Systems, of different sizes together to allow maximum connectivity on the internet. The protocol that allows these ASes to communicate is BGP. Connections between ASes come in two types: transit, basically paying for connectivity to another AS, or peer, where two ASes agree to forward connections destined for one another because there is roughly equal traffic both ways. ASes want to prioritize connecting their own transit customers who pay them, but want to avoid having to pay to connect them. BGP was designed with scalability in mind, with the idea that multiple competetors would be running the internet, so it allows them to enforce their own routing policies, but to enforce cooperation to ensure connectivity.

An AS is composed of edge routers that are connected to other ASes, and routers which are only connected within the same AS. Edge routers speak to other edge routers through eBGP sessions, and all routers in an AS communicate to each other using iBGP sessions. When eBGP routes are distributed to all the routers, the two main goals are to avoid loops, and to make sure all routers have a complete view of all routes. BGP uses attributes to decide which route to take. The first priority is LOCAL PREF, wihch ensures transit customers are given priority. Then by ASPATH length which is how many ASes are traversed on the route. Next MED is comared if there is a financial agreement, essentially this allows a paying AS to rank certain routes to avoid extra cost. If these attributes cannot alone decide a path, external routes are preferred, if not then pick the shortest internal hop, and finally a choice based on the IPs of the routers.

This paper was a lot of information, but it was quite interesting, particularly the fact that this system was designed with competing corporations in mind. The 'hot potato' principle is a bit bothersome, because it essentially means that in these peer situations, the route from A to B and the route from B to A are likely not to be the same. Are there situations where having these different routes could cause problems with different latency times etc?

Multi-homing was another interesting topic of the paper. Essentially the paper said that multi-homing is infeasible for smaller customers since routers typically don't keep records for anything less than ip/19. Also it is hard to specify a route as a 'backup' since each AS will do its own route computations and might ignore MEDs. The main hack to get around this is to pad the ASPATH with the same AS so that the main route is always preferred unless it goes down.