< Back

How IP transit works on the Internet

We all know that when we browse the web, our laptops or other ‘web-enabled’ devices are part of a local IP network. Many people understand that their local network itself connects to a much larger network we call the Internet and that from there, we are able to reach almost anywhere in the world. But how does this happen?

How does the Internet, the network of networks, keep track of itself and what kind of control do we have over how it operates? In this blog, I will take look at the structure of the Internet with a focus on one of the key technologies that binds Internet Service Provider (ISP) networks together to create the world wide web.

Firstly, we need to be clear, if I would like to connect to other clients within the ConnetU network, my data packers are routed directly there. But connecting outside the ConnetU network is a different matter; ConnetU routers will need to pass-off my web-page requests to another ISP. So, how does this work?

ISP networks exist on their own but are interconnected. Within each network, certain key ‘edge’ routers are selected to connect outside to other ISPs. These routers share information about different networks using the ubiquitous Border Gateway protocol (BGP).

BGP is the main routing protocol for connections between ISPs and other large network operators. The latest version is BGP4

First of all, let’s imagine a common scenario. Working in the office on the ConnetU network, I decide to open my web browser and do a little shopping on Amazon (it’s lunchtime). In doing so, I’ve initiated a Internet-session with Amazon’s American site. But how exactly did this just happen? Let’s take a look at some steps along the way.

I type in amazon.com into the address field of my browser and press return. My browser queries a DNS server which resolves the domain name (amazon.com) to a destination IP (72.21.194.1). My browser in turn sends a request to that IP destination, an Amazon web-server, asking for the relevant web page. Before it can arrive at its destination, however, the request packet enters into the ConnetU network and is received by one of the internal routers who recognises the IP does not belong to the ConnetU network and sends it to a BGP router that can forward the packet. This BGP router selects the best path to the destination and the IP is forwarded once again.

The best path here is an important concept to understand. My ISP has more than one option in sending the web-page request to the Amazon network, meaning it can choose more that one path. It could go through either the network of NTT Communications or through the network of Telia Sonera, both major international ISPs

Here we see some of the power of the BGP protocol in finding the shortest path do it’s destination. My packet is forwarded into the NTT network and makes its way out again to hook up with Amazon.

The ConnetU – NTT – Amazon path is set for packets going towards Amazon servers. However, the return path is uncontrollable as my ISP Administrator has far less influence over paths from which it receives data.

Amazon, on the other hand, can control how it returns the packet and may well choose the Telia Sonera path for various reasons, one of which may be the fact that it could cost them less money to use Telia Sonera. The truth is, the cost often dictates the way a traffic paths are chosen on the Internet.

Data Centre complex, East London, including Telehouse, home of LINX and LONAP Internet exchanges

Global carriers such as NTT and Telia Sonera provide connectivity to the entire world, making them expensive and complex: a single packet crossing London needs to traverse many devices before reaching the desired egress point, increasing latency. Therefore, having the ability to avoid global carriers if possible is desirable, giving lower cost and lower latency routes for traffic. To this end, Internet exchanges such as LINX (London Internet Exchange) and LONAP (London Access Point) have been formed which offer a way for ISPs to connect directly to each other.

My packet returned and my web-page displayed, I can now place my Amazon order. A session is created between my computer and the Amazon servers and traffic continues to go back and forth as described above. During payment, servers at Amazon begin communication with my bank’s network either directly, through ISP intermediaries or over an exchange, and so it continues.