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: API, Cisco, cmx, connected mobile experiences, HTTP(S) GET, location, location based services, map, mobility services, mobility services engine, mse, real time location, REST, rtls, web developer, XML
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: 6rd, Cisco, Internet of Everything, internet of things, internet protocol, IoE, IoT, ip, ipv4, IPv6, IPv6 rapid deployment, map, mapping of address and port
By 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: cgv6, Cisco, Internet of Everything, internet of things, IoT, IPv6, map, Service Provider, Steve Simlo, World IPv6 Congress
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: cgv6, Cisco, DSLite, IPv6, map, MAP-E, MAP-T, Mark Townsley, Service Provider, stateful, stateless
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: cgv6, Cisco, DSLite, IPv6, map, MAP-E, MAP-T, Service Provider, stateful, stateless