Blog: The First STEP in Rethinking Routing Protocols

By Patrick MeLampy
| May 2, 2017

We all use Google Maps, Waze, or some kind of mapping software to understand the topology of the road system, and what an optimal route might be given traffic conditions. Routing protocols have the same mission: to understand topology and help find optimal routes given current conditions.

Modern mapping software products have an amazing ability to find virtually any and all roads – from the smallest to the largest – in any specific area. By zooming in, more detail emerges and more roads/paths appear. In fact, in the United States alone there are over three million mapped road segments, as defined by the US Postal Service. Each of these segments have various static (or at least slowly changing) attributes: a speed limit, a capacity (number of lanes), one way vs. two way, etc. One would assume that updates to this topology database are infrequent.

Each of these road segments also have a set of dynamic attributes; think congestion, construction, accidents, etc. The dynamic attributes supply information that may be extremely relevant in providing optimal paths, and therefore must be current – within several minutes – to be effective.

When seeking directions, a user supplies two pieces of information: their starting location and desired destination. From these, the different route possibilities are computed using the topology information – then a second step of reviewing the dynamic attributes of those pathways is performed to derive the optimal route. It would be computationally impossible to distribute the traffic information for all routes to all users. Only traffic nearby – or on pathways of interest – are shared.

The advanced state of Google Maps or Waze may lead a user to believe that routing protocols in the Internet are equally advanced and high performing. Nothing could be further from the truth.

Let’s compare mapping software path determination to data networking protocols. The topology in our road mapping software includes all navigable roads. A user can zoom out and see only the major highways and byways, or zoom in to see avenues and side roads. The topology is “complete.”

With IP networking protocols, there are literally only two views – and neither is adequate. The totally “zoomed out” view is called the autonomous system view. The fully “zoomed in” view is called the “link state topology.” Imagine how frustrating it would be to have the view of your local neighborhood, but when you wanted to get a map to New York City, the zoomed out view only showed state borders, and all the roads (links) were removed. You might realize that you must drive from Massachusetts, through Connecticut, to get to New York, and have a general direction of southwest. But which link, which path, and what distances you need to travel would be missing from your view. In fact, when you cross a boundary – for example, a state line – you would lose all the topology you just traversed. This is how IP networking works.

When you route a packet through the Internet, each autonomous system shares no topology information, other than what they are adjacent to. You have no idea what the actual topology is, or what it might support. When you zoom in, you receive all the information, but this information is shared in a brute force method. Each user simply tells all other users about a change they received, and this process continues until everybody knows every change. This flooding scheme has proven not to scale well or be effective in providing end-to-end topology for services. It has limited the number of networks that use link state routing schemes.

What’s Missing? [Hint: Traffic Reports]

Most of the current mapping software programs receive traffic updates from users’ devices. On roads where there are a lot of participating users, they can get extraordinarily accurate real-time traffic data. This information is selectively made available, and can augment the topology data, to provide insight into how to achieve the best travel times between any two points on the map. IP networking protocols do not share capacity, traffic, or congestion. The only information shared is whether a road is open or closed.

What about Route Alternatives?

Currently, Google Maps can provide users with the shortest route, as well as other options. One may involve a longer, scenic view. Another may be a longer, highway drive. But IP networking protocols provide just one set of routes that are costed equally. Since IP network owners know that routes that cost more will be removed from the routing tables, current practices suggest methods to make every route equal.

Let’s finish with this example – assume that mapping software was just as primitive as our current IP networking protocols. A user knows that taking Interstate 93 (which is an eight lane highway) is the best route, but when I-93 is closed, the backup is Route 1 (which is a four lane roadway with frequent traffic signals). Network protocols require that for these two paths to be available at all times, their costs would need to be equal. Now imagine that 50% of the traffic is on I-93, and 50% is on Route 1. As a result, I-93 is underutilized and Route 1 is perpetually congested. This is exactly how primitive IP networking protocols work, and how best current practices make people lie about which pathways are best.

For decades, routed and overlay networks have been designed around an increasing amount of protocols that are only significant to the networks and their topology. The 128 Technology approach is to segment traffic differently by introducing a whole new set of tools intended to build the network around the services it is meant to deliver, rather than around the network itself. Check out our Hypersegmentation White Paper to learn more.

Blog: The First STEP in Rethinking Routing Protocols2017-05-022017-06-28https://www.128technology.com/wp-content/uploads/2017/05/128-technology-logo-menu-light-01.png128 Technologyhttps://www.128technology.com/wp-content/uploads/2017/05/pexels-photo-116222.jpeg200px200px