Automating the WAN with SDN – Avoiding “Hurry Up and Wait”
“Hurry up and wait!” This is a phrase that expresses the exasperation when you’ve done everything you can to make things happen on time, only to have something outside your control cause the process to grind to a halt. Like filling out your travel visa paperwork at home, taking the express train to get to the embassy before it opens, yet still having to wait all day to be serviced.
Too often, this is how pioneers in NFV-based services must feel. They’ve established the cloud data center pods, on-boarded the VNFs, programmed the orchestrator and set up the self-serve portal – so that the desired VNFs can be spun up on-demand. Unfortunately, the Wide Area Network (WAN) connectivity between the enterprise locations, the data center, and the Internet, cloud or content providers still takes weeks to be provisioned. Essentially, it’s hurry up and wait.
The issue is that the WAN has been built up over several years through multiple technologies (e.g. optical, Ethernet, IP, MPLS) with multiple generations of proprietary equipment from several vendors. This complexity is often amplified by the merger of multiple providers. Network and service provisioning across this conglomeration requires interacting with multiple EMS/NMS within each technology or vendor domain, and manually stitching connectivity between domains. This process is time consuming, resource intensive, and error-prone. Before network operators can reap the rewards enabled by virtualization technologies, they first need to deploy a WAN automation solution to overcome these obstacles to agility.
Before network operators can reap the rewards enabled by virtualization technologies, they first need to deplay a WAN automation solution to overcome these obstacles to agility.- Mitch Auster, Senior Advisor of Product Marketing, Ciena
In fact, we are seeing a rapidly growing number of service providers prioritizing WAN automation for provisioning traditional connectivity services and the infrastructure underlying their other services (e.g. mobile, residential). Many times, this is even before broaching NFV, and next-generation virtualized services. This makes a ton of sense given the fact that it reduces opex, shortens time-to-revenue, and improves network utilization across the brownfield network that generates almost all of their current revenues – not to mention the fact that it paves the way to avoid the “hurry up and wait” scenario when they do deploy NFV-based services.
Now, I know what you must be thinking – haven’t we heard claims about end-to-end (E2E) provisioning ad nauseum? Well, yes – so the question is “why is this still a problem?” Here are a few reasons:
- When E2E provisioning has been done by a vendor NMS, it is only for their own network elements (NEs) and perhaps a handful of their strategic partners’ NEs
- Independent OSS vendors went about developing costly “activation packs” that were also vendor/product-specific and typically only for major vendors
- In both cases, typically only a single technology (e.g. MPLS or SONET/SDH) can be provisioned at a time, and WDM has been statically provisioned
- Any time you want to add a new device type or modify the service, you need the vendors to reprogram the interdependent hard-coded logic throughout the software stack all the way from the OSS to each affected EMS/NMS or device
So, operators have been teased with short-lived, quasi-E2E provisioning limited to what others have decided comprises the end-to-end. In today’s dynamic and competitive landscape, this approach doesn’t cut it.
Ciena’s Blue Planet offers a modern approach to WAN automation, using SDN orchestration. First, it has a multi-layer, model-based architecture, which provides an abstract representation of the network to the service layer as well as an abstract representation of heterogeneous devices to the network layer. This means that service logic can be developed independent of the specific technology, device or vendor that will be invoked to render the specifications of the service.
Next, workflows for end-to-end service provisioning aren’t hard-coded and compiled into a software release. Instead, service lifecycle logic is template-driven, with templates “compiled” by Blue Planet’s orchestration engine at run-time. Service templates (STs) can be added or modified independent of any release stream. Resource adapters (RAs) provide the mapping between the common network information model and each vendor/product-specific device (or domain controller) data model and interface protocol. Like STs, these RAs are not hard-coded into a release, but are independently developed.
Critical to our customers though is one important fact. These STs and RAs don’t need to be developed by Ciena. In fact, we’ve launched the Blue Planet DevOps Toolkit and an open developers community (Blue Planet DevOps Exchange) to encourage and assist network operators, 3rd-party NE suppliers, independent software vendors, systems integrators, and others to develop these on their own, or in collaboration, to meet their particular use cases on their own timelines. Of course, Ciena is ready, willing and able to do the development as well if asked.
Blue Planet’s technology-independent orchestration engine, model-based architecture, and DevOps-enabled service templates and resource adapters make it fast and practical to achieve end-to-end, multi-vendor WAN automation across multiple layers that is easily and continually maintained, enhanced and extended. This has been proven in several recent customer deployments including:
- CenturyLink, a Tier-1 service provider using Blue Planet to automate Carrier Ethernet service activation/provisioning and performance management, in addition to NFV and SD-WAN provisioning,
- a global Tier-1 service provider headquartered in Europe using Blue Planet to drive virtualized services on top of an automated WAN,
- a large Tier-2 service provider using Blue Planet to orchestrate a mixed Ciena and competitor’s optical services network (with plans to extend this to Ethernet and IP layers),
- and a large data center operator using Blue Planet to automate a global Juniper MX-based IP network.
These examples build upon Blue Planet’s long history of providing SDN-enabled WAN automation across multi-vendor networks.
As suggested earlier, using SDN for WAN automation is a critical initial step toward bigger and better things. While it reduces opex and shortens time-to-revenue for traditional services, it also provides a springboard to offering bandwidth-on-demand and bandwidth calendaring for applications like hybrid cloud connect, data center interconnect, scheduled backup services, disaster recovery and network-as-a-service. And it can be combined with NFV and SD-WAN orchestration to offer enhanced managed services, improved customer experience for cloud services, and much more. The beauty of Blue Planet is these additional functions are part of the platform ready and waiting for you to put them to use.
With WAN automation enabled by Blue Planet, the days of “hurry up and wait” will be replaced by “keep calm and orchestrate.”
