Solving the Network Location Problem with LISP

Your Location Has Changed, Carry On!

Solving the Network Location Problem with LISP (Locator/Identifier Separation Protocol)

The first thing that comes to mind when someone mentions location is our GPS location. Our ability to roam around the earth with our mobile devices is something many of us take for granted. However, at the packet level on the Internet of Everything (IOE), trying to map the network location of a trillion new things may require some new thinking.

Where we as users of applications are worried about our GPS location, the network is concerned about how to deliver information to our device. As we move from place to place, the network needs to figure out how to deliver that next packet of music or other information to us. In concept, this seems very simple, but the real world presents some challenges to make this experience seamless.

Phoning home used to be easier

Let’s back up a little with a simple comparison. Locating a telephone used to be as easy as knowing the country code, area code, and exchange ( 1-NPA-NXX-XXXX in the USA ). This was tied to a physical pair of wires to a home or office. Mobile phones changed this by giving us the ability to roam well outside our exchange and area code.

Number portability made this even more complicated by giving us the ability to move a phone number to another provider. Today, each phone call requires network lookups to discover the provider and then within the provider a lookup to find where that phone number currently is connected to the network.

Numbering on the Internet

In the current IPv4 packet world, this sort of mobility is more complicated for several reasons. The most important is that there just are not enough IPv4 addresses. The most popular solution has been to assign each location a set of private addresses ( see RFC 1918 ) which in most cases give users enough addresses to connect internally. External connections are shared through a smaller pool of public IP addresses ( see NAT / PAT ). This system works well to solve the shortage problem, but means many people are using duplicate addresses. This means we can’t move from network to network without changing our address.

So let us solve that problem by migrating to IPv6, which gives us more than enough addresses to assign each device a permanent address for the foreseeable future which gives us 340 billion billion billion billion addresses. More than enough to assign each device a permanent address for the foreseeable future.

Assuming every device and network was ready to do this, there is another problem ( oh great ).

The public Internet DFZ ( default-free zone ) is designed around the idea of being able to summarize addresses the way we used to think of area codes in order to keep the routing tables small and save memory. Even though IPv4 is only 4 billionaddresses, most providers summarize these addresses down to smaller tables of around 32,000 blocks.

If we allow devices and addresses to start roaming, we can no longer summarize the addresses because we must know how to get to individual addresses. There are 900 million Android devices alone. Imagine tracking 900 million devices in a table designed for 30-50 thousand!

Fortunately, there is an emerging method to help facilitate this transition to truly mobile network locations called LISP (Locator/ID Separation Protocol).

Omar Sultan, Cisco’s Senior Manager, Emerging Technologies talks about the importance of LISP. “…if you are looking at deploying clouds, supporting mobility of end-points or VMs or are managing a routing architecture or any meaningful size or complexity, I think it will be worth your while to check out LISP.”

The beauty of the LISP solution is that it borrows from existing methods to help us dynamically look up device/address locations on the Internet and reliably deliver packets while we roam.

Next : how it works.