Network customers have always bought networks for one and only one reason: to run their applications over them. Yet for most of that time, those networks have been largely oblivious to the composition of the network traffic they carried. Traditional network tools could tell you whether your network was having a lot of errors, or whether a given link or interface was congested, but they couldn’t tell you what was congesting your network, beyond the limited granularity of a few well-known ports. Finding out that you’ve got a lot of HTTP or HTTPS is not very helpful in finding out whether you’re swamped by personal traffic that needs to be controlled, or by legitimate business traffic that requires an increase in effective bandwidth.
At CiscoLive Cancun we are introducing a new addition to the 800 ISR family, the new 800M Series. What does the “M” stand for? The “M” stands for modular, as this is the first 800 series platform with pluggable modules that give flexibility in the field. Why do you need flexibility? The 800M is designed to operate in environments where 3G wireless is the primary mode of connectivity. For those of you with a cellphone, you are no doubt familiar with the large number of different service providers and 3G technologies. When designing the 800M we wanted to give our customers the ability to connect to any service provider in order to avoid lock-in, lower costs and improve redundancy. The modular platform enables customers to choose from serial and cellular connectivity without having to replace the chassis, which can be a challenge with fixed platforms. Read More »
Tighter Planning Cycles for Greater Efficiency with the Evolved Services Platform
In the global geography of telecom, wide-area networks (WAN) are oceans of uncertainty. Resource-constrained and multivendor, WANs produce delays and outages in far-flung and sometimes remote areas, posing a special set of issues that are distinct from those we see in data centers and access networks.
WAN bandwidth is the most expensive bandwidth in the network and failure impacts are large. WANs bear the brunt of traffic growth with a very tricky calculus: underbuild your WAN and jeopardize your brand, but overbuild it and spend your way into oblivion.
Greater Predictability through Ever-Shortening Planning Cycles
To keep pace with these conundrums, you need sophisticated modeling and planning tools, which naturally evolved—in the case of the WAN Automation Engine (WAE)—into an ever-tightening loop of planning, building, and measuring, eventually encompassing SDN.
Longer planning cycles inevitably means over-engineering, over-building and over-hiring. With the Evolved Services Platform’s (ESP) Orchestration Engine, Cisco is shrinking these cycles, and thus reducing the uncertainties that lead to inefficiencies.
Last week I discussed the Orchestration Engine of the ESP in terms of how different components fit in individual domains. Let’s see how to use this framework to plan, engineer, and ultimately automate the WAN to make it cloud-ready.
As the Process Becomes More Automated, a Shrinking Planning Cycle Brings Huge Efficiencies.
The cycle progressively shortens, from years to months, and eventually (with automated, programmable networking) to continuous changes. As this process moves from manual to automated, the network becomes more predictable.
But Why is this Happening Now? Read More »
Cisco IT is preparing our global WAN for employees’ growing use of third-party cloud services. Already we use more than 400 cloud services. The most popular are Cisco WebEx, Salesforce, SAP, and Office365. Read More »
We created the Evolved Services Platform (ESP) to help our customers increase service revenue while driving down costs. In doing so, we needed to make it expansive to include the breadth of technologies and solutions that would apply to many domains (such as access, Wide Area Network (WAN), and data center) and technologies (such as cloud, security, and video).
And we addressed the fact that a virtualized network function (VNF) is only as good as the automation of orchestration capabilities that are used spin it up and expand it to fit the required job. Given all the VNFs (greater than 40, just counting our own) that we could conceivably be orchestrating, we had to ensure that the Cisco ESP was sufficiently broad and inclusive of multivendor technologies.
The following diagram shows the big picture—the applications and network services made possible by an open, elastic, and application-centric architecture. Read More »