Cisco Blogs

Cisco Blog > Mobility

Cisco Mobility Services APIs go RESTful

As a product manager, I am happy and excited to tell you that Cisco Mobility Services Engine (MSE) now supports REST based APIs. Why am I happy and excited you ask? MSE’s REST based APIs allow web app developers to rapidly develop location aware apps with ease.  Let me walk you through this new feature at a high level, and my colleague will take you through a closer look feature blog next week.

Mobility Services Engine and API support

For readers who are not familiar with the Cisco Mobility Service Engine and the APIs, here’s the gist:

-          Cisco Mobility Services Engine (MSE) works in conjunction with Cisco Wireless LAN Controller (WLC) and Cisco Aironet Access Points (APs) and computes real time location for all Wi-Fi end-points using RSSI based triangulation algorithms.

-          MSE stores real time and historical location of Wi-Fi clients in its database making it a gold mine of data for indoor location. (Remember that GPS technology is not effective for indoor location)

-          This rich store of indoor location data is now available to app developers to query through a REST based API over a secure HTTPS connection.

What can I do with MSE REST APIs?

MSE REST APIs allow web developers to query MSE location database using the HTTP(S) GET method. HTTP response payload can be received in XML or JSON format. Here is a list of resources that are accessible over the REST API. Read More »

Tags: , , , , , , , , , , , , , , ,

Moving to IPv6: Rebuilding the Heart of the Internet Without Missing a Beat

Within the coming decade, Internet Protocol version 6 (IPv6) will be key to enabling 50 billion connections among people, processes, data, and things in the Internet of Everything (IoE)But how we get there from here is not a simple matter.

I’m very pleased to invite Mark Townsley, Cisco Fellow and recognized industry expert on IP, to discuss this important transition in the second of our three-part blog series on IPv6. The first blog in Mark’s series was “Demystifying IPv6”.


Three years ago, I organized a conference in Paris where I thought it would be fascinating to bring together the original designers of IPv6 alongside the engineers who were finally deploying it at scale more than a decade later. During this discussion, Steve Deering, one of the “fathers” of IPv6 in the 1990s, was asked one of the most common questions about IPv6: Why wasn’t it designed for backward compatibility with IPv4? After all, wouldn’t it be easier to make the transition if the two versions could transparently coexist? Steve answered that the problem is not that IPv6 wasn’t designed to be backward-compatible—the real problem is that IPv4 wasn’t designed to be forward-compatible.

Steve was making the point that IPv4 was designed with a fixed address space. Given the number of computers connected to the Arpanet throughout the 1970s, this fixed-length address field seemed to be sufficient—at least for that version of IP. IP had been replaced before, and it seemed perfectly reasonable at the time that it might be replaced again. Read More »

Tags: , , , , , , , , , , , ,

Ignore the Mouse – Get Your IPv6 Learn On at Cisco Live Orlando 2013

simloBy Steve Simlo, IPv6 Product Manager, Cisco Network Operating Systems Technology Group

As IPv6 gains more and more ground within the Internet we are starting to see recognition amongst the wider community that technologies such as Carrier Grade NAT (CGNAT) have some significant drawbacks from a service and scalability standpoint. Some of the issues were recently highlighted by a major carrier which actually issued a public “opt out” option to their customers if needed.

However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN. For our customers utilizing these types of applications, we provide the ability to “opt out” of CGN Read More »

Tags: , , , , , , , , ,

Cisco Fellow Mark Townsley: A Better Way to Deploy IPv6

We first talked about the Mapping of Address and Port (MAP) method to handle IPv4 exhaust and the transition to IPv6 last week. MAP is based on two IETF drafts currently in the process of standardization in draft-ietf-softwire-map (MAP-E) and draft-ietf-softwire-map-t (MAP-T). The real advantage with MAP is that it’s stateless and doesn’t require additional hardware as traffic grows.   Read More »

Tags: , , , , , , , , , ,

A MAP to Easier, More Scalable IPv6 Deployments

There are a number of ways to deal with IPv4 exhaust and  IPv6 transition, including Carrier Grade NAT and stateful Dual Stack Lite. Cisco has added another method called Mapping of Address and Port (MAP) based on two IETF drafts currently in the process of standardization in draft-ietf-softwire-map (MAP-E) and draft-ietf-softwire-map-t (MAP-T). The real advantage with MAP is that it’s stateless and doesn’t require additional hardware as traffic grows. In fact, the MAP implementation on the Cisco ASR 1000 or ASR 9000 is just a software feature that can be enabled as needed. Read More »

Tags: , , , , , , , , ,