The Carrier Cloud Needs a New Fabric, Not a Patched Cloth

Over the past two decades, carriers have built massive global networking platforms that are faithfully serving many enterprises. At a premium cost. MPLS-based services are under pressure from emerging Internet-based solutions. With MPLS revenue streams at risk, the carriers are pursuing a two-prong strategy: augmenting MPLS with Software-Defined Wide Area Networking (SD-WAN) and adding value-add services to the core network with Network Function Virtualization (NFV).

This strategy is attempting to “patch” the carrier MPLS cash cow and slow its decline. In reality, what the carriers could use, is a whole new fabric built for the cloud-centric enterprise and driven by cloud economics to reduce costs and maximize customer value delivery.

SD-WAN for the Carrier Network Edge

SD-WANs are driven by the explosive growth of Internet traffic and the changes in traffic flows. There is less demand for MPLS-to-the-datacenter and more demand for accelerating and securing traffic to internet destinations, such as cloud infrastructure and public cloud applications. SD-WAN offers a good way for carriers to augment their MPLS services. It allows their customers to boost the capacity, manageability and agility of MPLS by adding Internet-links into a hybrid WAN.

But alone, SD-WAN will be insufficient for enterprises to transform their WANs and for carriers to stay competitive. SD-WAN relies on the Internet, which makes delivering a consistent user experience for voice, video and other latency-sensitive applications difficult, if not impossible, particularly when routes span long-distance, internet regions, and carrier backbones.  Customers remain forever locked into MPLS with all of its high costs and lack of agility, leaving carriers exposed to churn as customers look for more effective approaches.

NFV for the Carrier Core Network

The challenges of maintaining and deploying rigid, hardware-based MPLS infrastructure is leading carriers to look for new service delivery models. A successful on-demand infrastructure model exists with Amazon AWS and has thoroughly changed how we purchase servers and build datacenters. But how can carriers deliver an Amazon-like offering for networking and security services?

The initial thinking was that the virtualization of physical appliances and network functions virtualization (NFV) would make carriers more agile. They could run a fully managed orchestration platform, spinning up virtual network functions (VNFs) in a generic customer premise equipment (CPE) device. Carriers would gain the efficient use of software licenses, centralized management, and upfront saving they’ve long sought and enterprises achieve the branch office operational cost reductions they’ve long wanted.

But operationally, VNFs are still multi-sourced virtual appliances. Each has to go through a complete lifecycle of sizing, deployment, configuration, and upgrades. Each must have its own redundancy scheme built per customer. Each must be run through its own management interface and policy engine. Can you imagine Amazon offering AWS where virtual machines are deployed per host, run a vendor-specific operating system, and managed by vendor-specific tools? What a headache. If that was the case, AWS would be far less compelling.

And the more VNFs running in the CPE, the more features activated, or the more business traffic grows the more processing that’s required from the finite resources of the CPE. At some point, it will underperform or force an upgrade.

Moving VNFs  into the carrier core isn’t much help even with the telco’s plentiful compute and storage resources. VNFs from multiple customers running side-by-side may impact one another as customer activity bursts or new capabilities are deployed. For example, adding deep packet inspection of SSL content to stateful firewalls can increase loads on firewalls by 10x.  Carriers and service providers also need to develop the management and OSS systems to accommodate for those sudden shifts.

And that’s not all. VNFs, like virtual appliances, must still be maintained, patched and configured, increasing operational costs. Creating multi-tenant VNFs is complicated for VNF providers, forcing carriers to deploy individual instances for their customers. The result: inefficient use of compute and storage resources.

From a business standpoint, VNFs have always posed a problem for the VNF suppliers. Evolving VNFs to be more standardized, reducing lock-in and brand value. VNF providers can’t allow a situation of easy swap outs with other offerings. They’ve become somewhat reluctant partners in the architecture, sort of like trying to dance when your feet are controlled by two brains. Coordination becomes very difficult indeed.

Network Functions Built for the Cloud

Rather than trying to adapt a legacy, appliance-based architecture to the cloud, carriers should embrace a new architecture for a network and security cloud-based service. Don’t run discrete appliances (i.e VNFs) in the cloud. Create a distributed multitenant software stack for networking and security services and overlay them on a carrier-grade backbone. The software would provide policy based routing, optimization, encryption and full network security stack – governed by a unified networking and security policy.

We call this the Network Function Cloudification (NFCL) fabric. It is comprised of NFCL nodes, each running the same integrated software stack.

As a cloud-based service, NFCL is multi-tenant by design, and fully distributed as PoPs, each with multiple NFCL nodes. There is no proprietary hardware to complicate geographic expansion of a service offering. And without the hardware, there is no need for massive capital expenditures. NFCL nodes are accessible from any location, data center, cloud resource and mobile user that can connect to the Internet.

Figure 1: NFCL Fabric and Nodes

As traffic flows through the NFCL node routing, path selection, and multiple security engines are applied to the traffic.

Figure 2: NFCL PoP Integrated Network and Security Services

The unique advantage of NFCL is that it is built for the cloud. It breaks the notion that every network function must be locked into a proprietary appliance. Instead, the network function is delivered without a 1:1 bond with any specific appliance. Customer resources simply connect to the NFCL fabric using a secure tunnel and are attached ad-hoc to an available NFCL node.

NFCL brings significant operational and capital cost benefits to carriers.  

It provides built-in redundancy and scalability. New NFCL nodes can be spawned as needed to ensure capacity is available. Global coverage can be expanded easily by adding NFCL software nodes at a regional datacenter or a hosting service. If a node fails, the customer resource tunnel can reconnect to any nearby available NFCL node.  The NFCL fabric always maintains the overall context of the virtual customer network within the multi-tenant infrastructure.

Finally, the NFCL software seamlessly upgrades in the background, so neither the carrier nor the customer have to own that responsibility.

The Way Forward for the Carrier Cloud  

The obvious advantage of legacy appliance-based approaches is choice. Customers can choose to work with specific vendor appliances and handle the resulting fragmentation and complexity. Fewer enterprises can afford it these days, as more and more solutions are introduced to the market and new business requirements emerge. Providing customer choice also means higher costs for carriers for the reasons we discussed above.

With NFCL, choice comes not from deploying standalone appliances but from seamlessly extending the NFCL fabric with third-party, cloud-delivered functions. In this way, NFCL can maintain its unique availability, scalability and functional attributes while delivering the capabilities customers require, anywhere they need it, whenever they want it. While technology purists may scowl at the lack of “do it yourself” options, business and IT leaders understand the tremendous benefits from the AWS-like approach of NFCL.

It is the past or the future. NFV vs. NFCL. What will be the right choice for the carrier cloud?

This article was originally published on the SDxCentral.