Cisco’s NPS: The Cisco Network Positioning System (NPS) provides and manages virtual cloud-based services and other network applications from the network. It is built on advanced network features and the intelligence inside next generation networks (NGN), and further aggregates the data center resources and services to ease multi-tenant cloud provisioning.
Today’s virtualized cloud-based services require:
- New levels of automation, mobility, and scale from the network
- Control and speed to match the availability of virtual resources within the data center
To meet these requirements, Cisco has introduced the Network Positioning System. This system exposes the underlying intelligence in the network to cloud-based applications and management solutions.
Applications often have little knowledge of IP topology, and can be deployed into sub-optimal locations from a network point-of-view. This can result in:
- Excessive consumption of network resources
- Diminished application performance
- Added costs to the network provider
Cisco Network Positioning System locates and uses the best resources from the cloud. This system:
- Helps provision and manage virtual cloud-based services and other network applications
- Is built on advanced network features
- Uses the intelligence inside the Cisco Intelligent Network
- Further aggregates data center resources and services to simplify multi-tenant cloud provisioning
The Cisco Network Positioning System provides real-time information about the network, including:
- Proximity
- Performance
- Capabilities
The Cisco Network Positioning System understands which capabilities are available across the network and connected data centers. This real-time information, used in conjunction with a provisioning and orchestration solution, helps distribute workload and best use resources in the cloud.
NOTES: PDF file of Cisco NPS
When provided access to multiple data centers with the identical service, Cisco’s NPS correctly chose the best performing option for user traffic.
If cloud services are so important, than so too must be the availability of cloud services, which will require cloud providers to use multiple data centers to tackle issues involving scale, reduction in application latency based on geographical proximity, and resource distribution.
If the existence of multiple data centers is a given, resource distribution and customer experience optimization becomes a critical business concern: Will the data center operators distribute load across the data centers? Will they provide customers with the data center that will give them the best experience based on network proximity or performance?
Cisco says it can arm the network with the intelligence to make these decisions. This is the idea behind Cisco’s Network Positioning System (NPS). To see NPS in action we needed two data centers and, as luck would have it, our test setup came equipped with two data centers.
Our intention was to verify that when the same customer requests a service, NPS makes the decision as to where that request would go — Data Center 1, or Data Center 2. When we discussed this idea with Cisco, were prepared to have NPS work based on proximity, but they also explained that NPS was built as a customizable tool. We felt it would be more relevant to see NPS chose data centers based on performance — delay, for example. Cisco agreed with us and got to work.
The NPS system database was incorporated into our customer-facing CRS-1. Cisco then set up an ASR 1002 as a Customer Edge router (CE) to be the NPS client. The CRS-1’s central purpose in the NPS setup is to always know which data center is the optimal match for the defined metrics. The ASR 1002 polls the CRS-1 with the preferred metrics and uses the CRS-1’s response for the customer traffic. In our test case, Cisco set up their IP-SLA measurement probes between an ASR 9010 in each data center, and our customer edge NPS client to constantly measure and report the delay to the CRS-1.
Cisco installed two simple video servers in each data center. We connected a laptop client to our ASR 1002, and began requesting video through a Web portal Cisco had setup. In the beginning, the Web portal would almost randomly choose different data centers each time we refreshed. We found this was because the latency measurements were extremely close, and mildly fluctuating. No problem, this meant both video servers were working. Also, we came prepared. We connected Ixia’s new shiny ImpairNet impairment generator between the customer edge ASR 1002 and its upstream CRS-1. This was the customer’s link to both data centers, but, by using a filter on the impairment generator, we could add delay to all packets for a given destination. We toggled back and forth between adding 50 milliseconds on all the IP-SLA measurement packets to Data Center 1, and then disabling it and adding the delay to Data Center 2. Each time, we observed that when the video client was refreshed it was showing video from a different data center according to the path with the lowest latency.
Impairments Illustrated
In addition we verified that NPS would not include data center options that didn’t run a service all together. We used “CPU hog” on Data Center 1 to disrupt the video server. The ASR 9010 detected the failure for this virtual server to respond, and signaled the CRS-1 not to include Data Center 1 as a viable option for this video service. We refreshed our browser and were consistently directed to Data Center 2.
For service providers offering cloud services the ability to optimize the customer experience when accessing geo-redundant or distributed data centers could well be a competitive edge, especially when the cloud services begin to be commoditized. It is impressive to see that functions that required complicated traffic engineering knowledge in the past have been simplified and repackaged for general consumption.
—Original resource from lightreading.com-Carsten Rossenhövel
More News: CloudVerse: Cisco Storms into the Cloud Market
