SDN and NFV Era
Latest Articles
Network Requirements for Telco (NFV) Clouds

Network Requirements for Telco (NFV) Clouds

The network fabric is an integral element of the NFV Infrastructure (NFVI), as defined by the ETSI architectural framework for building NFV clouds. In my previous blog in this series, I mentioned that the architectural blocks required for building the network fabric for an NFV cloud are similar to those used by cloud providers for building their cloud offerings. Let’s examine what these are:


A Resilient, Scaled-Out, Open IP Fabric for underlay:


While Layer 2 technologies can certainly be leveraged to build small clouds, cloud providers have settled on Layer 3 designs to build scaled-out leaf-spine data center fabrics. IP based fabrics offer better scalability, often scaling to 1000’s of racks. NFV solutions offer the promise of elasticity, which is the ability to turn up services (VNF’s) on demand. Service Providers building Telco Clouds may start with a small footprint, but need to ensure that the underlay design allows for future growth and IP fabrics are better suited to build scaled out clouds. The QFX portfolio provides rich suite of standard based protocols with ECMP based load balancing to build a scaled out underlay.


Service providers currently provide network functions on dedicated hardware appliances which offer carrier grade reliability. As these services migrate to a virtualized delivery model, the demands for 5 9’s reliability from customers is not relaxed. Service providers who do not place enough importance to the need for always-on service risk customer attrition and loss of revenue. While carrier grade reliability places demands on the VNF’s themselves and requires a holistic approach to delivery, the network plays a crucial role in offering an always-on service.


Tenant Isolation with Network Virtualization:


The NFV service delivery models allow for multiple tenants to be hosted on the same NFVI (NFV Infrastructure). For example with NFVIaaS, multiple service providers may be hosted on the same cloud infrastructure, each providing their NFV services. On the other hand, even in a single tenant environment, individual VNF’s may need to be isolated. For example network slicing is a key tenet of the emerging 5G radio access standard. In all of these scenarios it is paramount that the physical network is capable of hosting virtualized network slices and that the traffic in each slice is 100% isolated.


Another important thing to keep in mind is that while it is true that the full agility of NFV can be exploited if the VNF’s are hosted on virtualized compute, we certainly see VNF’s being hosted on bare metal compute. In this scenario the edge of the network slice will originate and terminate on the ToR switch connected to the bare metal compute and not on the vSwitch or vRouter residing on the hypervisor. A key requirement for the network fabric in a NFV deployment is to provide seamless interconnectivity between VNF’s hosted on virtualized and bare metal compute.


Finally, the network should also be able to support service chaining of VNF’s to build a customizable service.


Enabler for VNF Migration:


Telco Clouds needs to support the live migration of VNF’s within a data center and across data centers. Workload migration may be initiated to balance the load on the compute resources, in response to failure of a compute resource or during maintenance windows. While a big onus, to provide the capability, resides on the VNF and the management and orchestration layers of the Telco Cloud, the network fabric comprising of the leaf, spine and edge routers needs to be an enabler for supporting this flexibility.




SDN and NFV are complementary technologies. The full potential of NFV relies on the ability to turn up and turn down services at the velocity of a few clicks on a web portal. Business intent or customer intent must translate into action in the network in an automated way and not rely on an army of network staff to provision the network. To achieve this the network layer must


  • Provide a comprehensive programmable interface: Every action (configuration or operation) that can be undertaken via a CLI should be available via a programmatic interface that facilitates automation. Moreover these programmable interfaces should be standards based where standards exist. For example in order to enable vendor neutral automation of the network, the network gear must support the YANG models published by OpenConfig and IETF.
  • Be Open: The network layer should be built on open standard based technologies that allow for easy integration with any open SDN controllers that the service provides chooses. Any proprietary solution that locks in the service provider to a closed solution will prevent them from best of breed selections and likely be more expensive in the long run.
  • Easily Integrate with Automation Platforms: There are many open source efforts (and certainly a few startups) that have spawned in recent years that provide platforms for automation of networking resources – Ansible and SaltStack being few of them. The network should integrate easily with the best of breed automation regime of choice that service providers decide to deploy.

Hardened for the COLO:


Telco clouds require customer proximity and would be hosted in the 100’s of COLO locations, rather than a few national or regional data centers. The network switches should be GR-63-CORE and GR-1089-Core compliant and built to meet the stringent physical and electrical demands for deployment in Telco clouds.


We would love to have a dialogue on how Juniper can help you with your NFV deployment needs. In my next blog, I will detail how the QFX portfolio of switches from Juniper can help you build scalable, open, elastic and programmable Telco clouds. 


For more information on Juniper QFX Series Switches, click here.

For more information on ETSI requirements for Network Infrastructure, click here.

For more information on NFV use cases defined by ETSI, click here.

Juniper Employee
Accelerate Revenue Growth with Telco (NFV) Clouds

Accelerate Revenue Growth with Telco (NFV) Clouds

The march towards Network Functions Virtualization (NFV) is well underway, with a majority of service providers in some stage of evaluating or deploying virtualized network functions which were traditionally delivered with dedicated hardware appliances. The full potential for NFV will take many years to materialize, but service providers have certainly warmed up to the virtues of delivering network functions on general purpose hardware infrastructure. While the initial chatter promoting NFV promised cost savings as the primary benefit, service providers now believe that topline revenue growth is the key driver for NFV deployments. NFV offers service providers AGILITY that traditional deployments models which relied on deploying dedicated hardware for specific functions did not. Service Providers can roll out new services at the pace of software development cycles, unhinged by the pace of evolution of the underlying hardware, thus speeding up customer acquisition. NFV based services offer the agility to turn up (and turn down if needed) services with a few clicks and make the service available in new locations quickly, without having to deploy new hardware in remote sites.


The agility offered by NFV enables Service Providers to accelerate revenue recognition for existing network service offerings and also opens the door wide open for monetizing with new business models. These are outlined below:


Virtualization of existing network functions:  Probably the foremost driver for Telco Cloud today is the virtualization of network services that Service Providers are offering their customers today. These include network services like vPE, vBNG, vOLT, vEPC (MME etc.), vIMS and many others. Virtualization lowers the total cost of ownership by allowing the flexible usage of network functions on a general purpose hardware pool. For example a service provider providing mobility services can take advantage of the fact that individual mobility functions (MME, PGW etc.) do not require peak services at the same time and does not have to lay out special purpose network infrastructure to handle the peak for each function. Moreover the elastic nature of a virtualized service allows service providers to turn up services instantly as new customers get acquired, thus accelerating the book to bill cycle.


NFV Infrastructure as a Service (NFVIaaS): Service Providers can offer their infrastructure comprising of compute, networking and storage resources as a service to other service providers delivering NFV services to their customers. Only a few service providers have a global footprint of physical infrastructure residing close to the customer and NFVIaaS offers them the opportunity to monetize this footprint. Certain NFV applications demand proximity to the customer. For example certain mobility functions require customer proximity to operate within latency boundaries and to maintain the customer experience. Another example – CDN’s offer cached content close to the customer to improve the customer experience.  Service Providers who consume NFVIaas would see this as an enticing alternative to building their own infrastructure and quickly launching services in new areas – essentially being able to provide services where their customers demand it.


Virtual Network Function as a Service (VNFaaS): Enterprises deploy network functions like DPI, Firewall, and WAN Optimization etc. on dedicated hardware appliances in their branch locations. The deployment and operation of special purpose hardware is both CAPEX and OPEX intensive. NFV enables these services delivered via Virtual Network Functions (VNF’s) to be deployed on general purpose computing infrastructure, enabling enterprises to quickly turn up services while lowering costs. While this general purpose compute can be deployed on the customer premise itself (Example - NFX250), Service Providers can offer to host these network functions in the cloud offering a virtual CPE (Customer Premise Equipment). 


Virtual Network Platform as a Service (VNPaaS): In this model, service providers provide enterprises with the physical infrastructure plus a software toolkit that enables enterprises to innovate and deliver network services on top of the platform. This model is similar to the VNFaaS model but offers a greater level of flexibility to enterprises to customize the service.


These models of service delivery described above are analogous to the IaaS, SaaS and PaaS delivery models that cloud providers have been providing customers for years. While delivery of NFV services in a Telco Cloud places certain new demands from the network (proximity to customer, MEF services etc.), the basic building blocks required of the network infrastructure to deliver NFV based services are identical to the building blocks used by cloud providers to deliver their cloud services.


Deploying a Telco Cloud requires a 360 degree consideration of the service which encompasses the following:


  • Virtual Network Functions – The VNF’s actually providing the service.
  • NFV Infrastructure (NFVI) – The layer that provides the compute resources, storage resources and the cloud network fabric that provides connectivity between the VNF and the customers and between the VNF’s themselves (for service chaining).
  • Orchestration and Controller Layer – The layer responsible for managing and orchestrating the end to end service. This layer captures customer intent (via a self-serve portal), launches the VNF’s (service chain them where needed) and configures the network.


While each layer plays a critical role; in my subsequent series of blogs I will focus on the network infrastructure layer for the Telco Cloud. The QFX portfolio of data center switches, comprising of the QFX10K family of spine switches and the QFX5K family of leaf switches, provides the network fabric that powers 100’s of cloud data centers worldwide and is ideally suited to provide the network fabric for Telco clouds


In my subsequent blogs, I will dive into the building blocks for the network layer (here) and detail the capabilities of the QFX portfolio that make it a perfect fit for building a Telco Cloud.


For more information on Juniper QFX Series Switches, click here.

For more information on ETSI requirements for Network Infrastructure, click here.

For more information on NFV use cases defined by ETSI, click here.

Juniper Employee
Developing a business strategy that’s grounded on NFV realities, not promises

Developing a business strategy that’s grounded on NFV realities, not promises

Embracing the opportunities of disruption


What is the big promise of NFV for Service Providers? All too often I hear people talking about cost reductions. But the reality is that most organizations won’t achieve the full potential from this approach alone. Why is that?


Juniper Employee
Top Kudoed Authors
Latest Comments
SDNCentral | 06-28-2017
Re: Introduction to the E2 Controller
SDNCentral | 06-14-2017
Re: Juniper demonstrates a complete end-to-end NFV solution in NIA Interop Testing
By  rmachat
SDNCentral | 04-30-2017
Re: A Blueprint for Building the OpenContrail Community