SDN and NFV Era
Showing results for 
Search instead for 
Do you mean 

As NFV gains mainstream production status across carriers and service providers worldwide, important facts about the realities of a software-defined network world are coming to light.


Service levels for network functions—more commonly referred to as “service assurance”—is a concept created in the days when network functions were anything but virtual. These network services were tied to physical devices, and that hardware was “assured” to deliver its assigned “services” at a specified up-time.


In NFV, those now-virtualized network functions—or VNFs—must still meet desired service targets in order for the network to support its assigned applications at expected levels.


SDWAN-infographic.jpg In the next 18 months, 65% of enterprises are planning to migrate to SD-WAN services according to a recent IDC survey in Western Europe and North America. Enterprises are looking to achieve massive cost savings by moving traffic from MPLS to the Internet, but not only that, they are also interested in providing better support for high bandwidth applications, simplifying traffic management and accelerating the deployment of new branch locations.


With enterprise applications moving to the cloud, SD-WAN is well positioned to facilitate this transition – driving a predicted decline in IP VPN revenues in developed markets.


How will you [Service Providers] make money in this environment? 


Continue reading and get the full Juniper SD-WAN infographic 


OpenStack Summit 2017 Boston – Vote for Juniper and Customer Talks

by Juniper Employee ‎02-21-2017 11:50 AM - edited ‎02-21-2017 05:45 PM

OpenStack Summit is coming to Boston in May 2017 and we at Juniper Networks are excited and proud to be a co-sponsor for the event. If you are planning to attend the event we will be located in the expo hall at booth # A1. We are also participating in the Open Source Days at the Summit where we will be featuring use cases, product features, and progress related to OpenContrail.


Network Requirements for Telco (NFV) Clouds

by Juniper Employee ‎02-20-2017 01:02 PM - edited ‎02-25-2017 11:43 AM

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.

Accelerate Revenue Growth with Telco (NFV) Clouds

by Juniper Employee ‎02-14-2017 02:56 PM - edited ‎02-25-2017 11:44 AM

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.

Digital Disruption in Banks and Telcos

by Juniper Employee on ‎01-31-2017 12:59 AM

What do a Bank and a Telecom Operator have in common?


I’m not an expert in banking or the FinTech industry, but simply as an observer, and I notice a lot of similarities with the Telco industry. We can already see a large number of FinTech startups around, but just a few next-gen telecom operators, it might just be a matter of time.


Can Telcos innovate fast enough?


A Game of Letters and Acronyms with SD-WAN

by Juniper Employee ‎11-18-2016 08:00 AM - edited ‎01-12-2017 12:59 AM



Do you like games? I sure do!

How about a game of Scrabble? Who could turn that down!

When given a letter, do you let your imagination run wild? Sure you do!

Well, let’s start with the letters of “S” and “D” and combine that with WAN – What does that spell?


Hmm… Let your imaginative mind think for a moment. Okay, Ready Set GO!


Enterprise SD-WAN Adoption

by Juniper Employee ‎10-29-2016 12:48 AM - edited ‎01-12-2017 01:17 AM

According to a recent Kable Global ICT Customer Insight study, 58.5% of Enterprises globally plan to adopt SD-WAN within the next two years. And IDC, estimates that worldwide SD-WAN revenues will exceed $6 billion in 2020 with a compound annual growth rate (CAGR) of more than 90% over the 2015-2020 forecast period.


But, how are enterprises going to adopt SD-WAN?


From Bring-your-Own-Bottle to Bring-your-own-Broadband

by Juniper Employee ‎10-21-2016 01:38 AM - edited ‎11-08-2016 09:23 PM

Have you heard about the corkage fee in some restaurants? In the same way restaurants provide a table and the service but have a corkage fee to serve your bottle, Service Providers can provide a CPE and charge you for the SD-WAN service over your own broadband connections.





SD-WAN: Expectations vs Reality

by Juniper Employee ‎10-17-2016 02:26 AM - edited ‎11-08-2016 09:25 PM

Many enterprises are attracted by the promise of huge cost savings by SD WAN compared to MPLS. A recent qualitative survey among enterprises showed interesting results: Expectations vs Reality of SD-WAN


Juniper Networks Technical Books