Tagged: OpenStack

Is OpenStack Enough to Support NFV?

“One area receiving a lot of focus this cycle is NFV (Network Functions Virtualization). We’ve started an upstream NFV sub-team for OpenStack that is tracking and helping to drive requirements and development efforts in support of NFV use cases […] The main consumers of NFV are Service providers (telecommunication providers and the like) who are looking to accelerate the deployment of new network services, and to do that, need to eliminate the constraint of slow renewal cycle of hardware appliances, which do not autoscale and limit their innovation. […] The opportunities for OpenStack in the NFV space appear to be huge.”

“Juno Preview for OpenStack Compute (Nova)” by Russell Bryant, reposted on Red Hat Stack.


Left: with CloudBand’s Guy Shemesh at Alcatel-Lucent’s Tech Symposium’s demo station.

Right: Bell Labs “Networked Cloud” demonstration presented at Tech Symposium – Silicon Valley.

I just finished listening to Red Hat’s Nicolas Lemieux and CloudBand’s Idan Green who delivered a 30 minute webinar on OpenStack for NFV. This is worth watching. Here is the link to CloudBand’s NFV Mashup Series, which is hosted by Valerie Noto. On that webpage you will find this and 9 other presentations at the time of posting this article.

imageToday’s webinar reminded me of a Bell Labs project that we unveiled at Mobile World Congress in 2012 and further developed for Alcatel-Lucent’s Tech Symposium Silicon Valley. Bell Labs’ “Networked Cloud” PoC (Proof of Concept) helped illustrate benefits behind distributed “cloud-and-network” systems while taking full advantage of CloudBand’s management system and cloud nodes.

I ended up conducting quite a few demonstrations of this project for network operators, industry and financial analysts because predictive analytics fueled with smart algorithms cleverly figured out where to best place a given load anytime. This exercise factored both cloud nodes and network capacity, resource optimization practices, and the actual application requirements and load impact, coupled with deterministic behaviors subject to SLA (Service Level Agreements).

There were several use cases worth considering. Demonstration wise, it made sense to first focus our conversation on the one that could be best visualized and experienced. As an example, sudden demand growth led to the automatic spinning of VM (Virtual Machines), onboarding the right applications, instantiating and deploying a given service (enterprise productivity and collaboration applications for that one demo), and scaling in the process.

  • This scenario’s narrative talked to taking down silos and gaining visibility to improve both server utilization levels and network capacity, all under a centralized management system such as CloudBand. This assumed dramatically shorter lead times, more efficient power consumption and subsequent higher ROA (Return on Assets). Though, the wow factor was delivered by operating under QoS (Quality of Service) parameters, such as latency constrains with a SLA in place, being the result of intelligently placing loads at the edge of the network, closer to the end user for performance sake.

  • Concepts such as monitoring, data correlation, predictive analytics and service continuity would come to the surface under a second use case. Worth emphasizing that both use cases take advantage of the distributed nature of the networked cloud paradigm, which the above map (right screen) helped visualize as the demo progressed.

  • This second use case showed what specific node-and-link combination would be best performing at the time of re-instantiating an application. The objective was to prevent service degradation when network traffic worsens for any reason. There were A/B comparison scenarios facing the same issues, such as a network link being compromised.

  • “A” showed the known behavior of a conventional architecture where the user experience would either be negatively impacted or, alternatively, addressed by means of costly and lengthy over engineering and, therefore, extremely poor and self-defeating ROA. 

  • “B” presented the benefits of distributed systems under the “networked cloud” paradigm, where performance was sustained in an unparalleled cost efficient fashion with loads dynamically placed and relocated as needed; all being back-end stuff that is completely transparent to the end user.

More recently, our EPC (Evolved Packet Core) team conducted a similar NFV demonstration at Mobile World Congress 2014 where the end user’s mobile experience featured video streaming instead. NFV’s distributed architecture is key to also managing not just service continuity and self-healing, but also: resource isolation in multi-tenant environments, security, RAS (Reliability, Availability and Serviceability) and overall service delivery and lifecycle assurance under SLA.

Some other use cases are related to regulatory compliance, which can involve: lawful intercept, local data protection mandates, as well as regional coverage requirements and engineering for no-single-point-of-failure.


Source: courtesy of Alcatel-Lucent and Red Hat. CloudBand’s NFV Mashup Series #10.

FOSS (Free Open Source Software) is becoming a de-facto standard in the telecommunications industry. Some years ago, my team used Euclyptus to deploy and manage cloud computing infrastructure. We needed to create a number of virtual machines and that initiative helped with working on a hybrid AWS-compatible (Amazon Web Services) environment. When projects became more focused on communication networks we then took advantage of CloudStack, which is also positioned as turnkey IaaS (Infrastructure as a Service). Here is a link to a presentation discussing CloudStack in the context of NFV.

More recently, OpenStack has made significant inroads in this nascent space and is part of trials for virtual: CPE (Customer Premises Equipment), CDN (Content Delivery Network), DNS (Domain Name System), AAA (Authentication, Authorization, Accounting), SBC (Session Border Controller), EPC (Evolved Packet Core), and IMS (IP Multimedia Subsystem). In many cases NFV’s MANO (Management and Orchestration) interfaces directly with OpenStack and in some others that is the application’s EMS (Element Management System, or virtual equivalent) job, depending on the workflow.

So, is OpenStack enough to support NFV? I addressed Bell Lab’s “Networked Cloud” research demo as an example where “OpenStack-as-is” does not happen to be yet equipped to address NFV’s own challenges. To be more specific, we are talking about those presented by distributed carrier cloud systems, sophisticated networking, more complex transactions, CPU intensive packet processing and high availability in multi-tenant environments.

As discussed by Nicolas in today’s webinar, NFV injects workload dependencies spanning: control and data planes, signal processing, storage; and more strict requirements for performance, determinism and RAS. These items impact projects shown in the upper part of the above graphic and there are OpenStack Foundation teams looking into these:


Table source: OpenStack NFV Use Cases. 

Note that Red Hat is also addressing KVM (Kernel Based Virtual Machine) as the open source hypervisor, which creates and runs the VMs; supports libvirt for node management APIs beyond what’s provided by hypervisors; and works with DPDK, Intel’s Data Plane Development Kit with the drivers to accelerate packet processing on x86 platforms.

What follows is the architecture of our integrated joint solution aiming to bring together the best of carrier and IT (Information Technologies) worlds with NFV in mind. This also takes SDN (Software Defined Networking) into consideration.


Picture source: courtesy of Alcatel-Lucent and Red Hat. See CloudBand’s NFV Mashup Series #10.

“Both companies are creating the basic building blocks of a distributed cloud based on OpenStack and the foundational infrastructure for a best of breed open NFV Platform. Red Hat and CloudBand are set to help accelerate NFV for service provider networks.”

Demystifying the fast emerging carrier cloud (3)

Related posts:

Here is the presentation that I delivered at IIT’s Real Time Communications Conference back in October. For those of you who might not yet be familiar with what’s going on with cloud computing in the telecommunications industry, what follows outlines key terms driving that discussion:

Carrier cloud – most typically, this refers to cloud infrastructure (data center environments) owned and operated by wide area network operators, who are also known as “carriers” in the telecommunications industry. These are utilities whose “carrier systems” handle a number of communication channels with network traffic for services such as digital voice, video and data. Phone and cable tv companies being well known examples. What differentiates the carrier cloud from other, let’s say conventional clouds, is:

  1. the need for addressing “carrier grade” requirements meeting five nines high availability standards to meet both market expectations and regulatory compliance
  2. the context of wide area networks in metropolitan, regional, national and global geographies which, architecturally speaking, are comprised of a mix of centralized and distributed assets.

Bottom line: carriers operate sophisticated end-to-end systems that support real-time digital communications that can be subject to high demand and be bandwidth intensive.

Network functions virtualization – NFV is a fairly recent development in a telecommunications industry where conventional gear is typically sold as dedicated hardware and can come with tightly integrated software stacks. NFV calls for decoupling control and data planes instead and deconstructing the stack in the process. Basically, what this actually means is that the bulk of a given network element’s intelligence (software) can run on a virtual machine (also software). This takes place in a data center that is equipped with:

  • more widely available hardware (commercially speaking) which is far less expensive than traditional telco gear
  • its general purpose design is leveraged as a shared resource serving multiple applications, and registering higher utilization levels as a result
  • the new “carrier cloud” is built on the COTS (Commercial Off-the-Shelf) supply chain model and calls for competing multi-vendor solutions.

The thinking is that software defined assets can better scale by automatically growing and degrowing to meet demand curves – spinning up more virtual machines, instantiating and provisioning services near-on-demand. This translates into lean operations and unprecedented business agility. As an example, new deployments that could take days, weeks and even months under conventional architectures would not be a match for carrier clouds taking just minutes or hours.

Virtual network functions – under NFV’s next gen model, conventional network elements would eventually be superseded by software defined versions, and they would then become virtual network functions themselves. These are applications supported by common NFV Management & Operation platforms. VNFs  get to leverage shared resource pools available from computing fabrics consisting of cloud nodes and network infrastructure.

There are significant gains that come with consolidating by centralizing, not just with regards to capital expenditures, but also when looking into operational costs and improved control. Though, trade-offs impacting overall performance and quality of service can implicate diminishing returns and hidden costs triggered by some loosely coupled systems that add latency, more complex flows and processing, and all of that ends up to be coupled with traffic overhead…the complete opposite of what cloud computing calls for.

Therefore, centralization also prompts a need for revisiting and better defining modularity, interoperability and openness. By the same token, there is growing interest in programmability, machine-learning, real-time monitoring and predictive analytics, streamlining flows and lean operations, load balancing, data acceleration, compression, lifecycle automation and understanding what packet and split processing as well as hybrid architectures comprised of centralized and distributed assets bring to the table.

Software Defined Networking – SDN is a bit better known term given its three year head start when compared to NFV. SDN first capitalized into the difference between managing and optimizing network traffic (control plane) vs. forwarding packets (data plane) and embraced programmable networking.

Control and data plane’s physical separation allows for a controller to live in the carrier cloud instead of cohabitating in the same hardware. OpenFlow is best known as an open source protocol addressing control and data plane communications in SDN frameworks. When thinking of fulfilling the promise behind application aware networks and service oriented architectures, it makes even more sense to look further into logical self-organizing networks that can be set to outperform conventional systems and greatly simplify operations.

By means of a quick example encompassing all of the above: AAA (Authentication, Authorization and Accounting) is a security architecture matching users with the services they have access to. Under the NFV model, this can be deployed as VNFs running on VMs in a carrier cloud. This application taps into a shared pool (compute, storage) to grow and degrow to meet demand’s ups & downs. SDN gets these VMs dynamically hooked to the network and works intelligently to address the needs of the VNFs around the clock. All automated, programmable and with extremely short lead times, self-service and dramatically lower costs.