Why Network Functions Virtualization sdn?
- 1. Author Rajeev Tiwari PUBLICATION DATE Dec 30, 2012 Principal Embedded Software Engineer Technicolor Why Network Functions Virtualization?? Network Functions Virtualization (NFV) explicitly targets the two biggest problems facing network operators: bringing costs in line with revenue growth expectations and improving service velocity. NFV's premise is that industry standard IT virtualization technology (servers, switches, and storage) located in data centers, network nodes, or end-users' premises can be used to reduce the cost and increase the speed of service delivery for fixed and mobile networking functions. We believe Network Functions Virtualization is applicable to any data plane packet processing and control plane function in fixed and mobile network infrastructures. What Makes NFV Different While PC-based network devices have been available since the '80s, they were generally used by small companies and networking enthusiasts who didn't or couldn't afford to buy a commercial-based solution. In the last few years many drivers have brought PC-based networking devices back into the limelight, including: Ethernet as the last mile, better network interface cards, and Intel's focus on networking processing in its last few generation of chips. Today many vendors are producing PC-based network devices. Advancements in packet handling within Intel's processors, allowing processor cores to be re-programmed into network processors, allow PC- based network devices to push 10's or even 100's of Gbp/s. Values of NFV Some of the values to the NFV concept are speed, agility, and cost reduction. By centralizing designs around commodity server hardware, network operators can: • Do a single PoP/Site design based on commodity compute hardware; • Avoiding designs involving one-off installs of appliances that have different power, cooling and space needs simplifies planning. • Utilize resources more effectively; • Virtualization allows providers to allocate only the necessary resources needed by each feature/function. • Deploy network functions without having to send engineers to each site; o “Truck Rolls” are costly both from a time and money standpoint. • Achieve Reductions in OpEX and CapEX; and, • Achieve Reduction of system complexity i.e Deliver Agility and Flexibility: quickly scale up or down services to address changing demands; support innovation by enabling services to be delivered via software on any industry-standard server hardware • Accelerate Time-to-Market: reducing the time to deploy new networking services to support changing business requirements, seize new market opportunities and improve return on investment of new services. Also lowers the risks associated with rolling out new services, allowing providers to easily trial and evolve services to determine what best meets the needs of customers. • Error resilience : Ensuring the appropriate level of resilience to hardware and software failures. • Scale: Network Functions Virtualization will only scale if all of the functions can be automated.
- 2. Overview of the ETSI NFV ISG The ETSI Board approved foundation of the NFV ISG in time for publication of our first white paper last October. ETSI is a global organisation and has proved to be an excellent environment in which to Network Functions virtualization progress our work and we extend our thanks to the Director General and the ETSI Board for their accommodation and support. Although ETSI is a Standards Development Organisation (SDO), the objective of the NFV ISG is not to produce standards. The key objectives are to achieve industry consensus on business and technical requirements for NFV, and to agree common approaches to meeting these requirements. The outputs are openly published and shared with relevant standards bodies, industry fora and consortia to encourage a wider collaborative effort. The NFV ISG will collaborate with other SDOs if any standardization is necessary to meet the requirements. The NFV ISG also provides an environment for the industry to collaborate on Proof of Concept (PoC) platforms to demonstrate solutions which address the technical challenges for NFV implementation and to encourage growth of an open ecosystem NFV: Vision NFV architecture Model • Network operators have proven NFV feasibility via proof of concept test platforms • Network operators and vendors have identified numerous “fields of application” spanning all domains (fixed and mobile network infrastructures) • Significant CAPEX/OPEX benefits, leveraging also the economies of scale • Emerging virtual network appliance market • Novel ways to architect and operate networks, spawning a new wave of industry wide innovation • Network Functions Virtualization can dramatically change the telecom landscape and industry over the next 2-5 years
- 3. NFV Relationship with Software Defined Networks (SDN) Whereas SDN was created by researchers and data center architects, NFV was created by a consortium of service providers. The original NFV white paper1 describes the problems that they are facing, along with their proposed solution, Link1 to white paper has complete information about this. SDN and NFV – Working Together? Let’s look at an example of how SDN and NFV could work together. Figure shows how a managed router service is implemented today, using a router at the customer site. Network Functions virtualizations goals can be achieved using non-SDN mechanisms, relying on the techniques currently in use in many datacenters. But approaches relying on the separation of the control and data forwarding planes as proposed by SDN can enhance performance, simplify compatibility with existing deployments, and facilitate operation and maintenance procedures. Network Functions Virtualization is able to support SDN by providing the infrastructure upon which the SDN software can be run. Furthermore, Network Functions Virtualization aligns closely with the SDN objectives to use commodity servers and switches. 1 1 http://portal.etsi.org/portal/server.pt/community/NFV
- 4. Managed Router Service Today NFV would be applied to this situation by virtualizing the router function, as shown in Figure. All that is left at the customer site is a Network Interface Device (NID) for providing a point of demarcation as well as for measuring performance.
- 5. Managed Router Service Using NFV Finally, SDN is introduced to separate the control and data, as shown in Figure. Now, the data packets are forwarded by an optimized data plane, while the routing (control plane) function is running in a virtual machine running in a rack mount server. Managed Router Service Using NFV and SDN The combination of SDN and NFV shown in Figure provides an optimum solution: • An expensive and dedicated appliance is replaced by generic hardware and advanced software. • The software control plane is moved from an expensive location (in dedicated platform) to an optimized location (server in a data center or POP). • The control of the data plane has been abstracted and standardized, allowing for network and application evolution without the need for upgrades of network devices. How NFV will push SDN beyond the data center NFV's use of virtual network overlays could also drive an expansion of this SDN model beyond the data center where it's focused most often today. If NFV allows services to be composed of virtual functions hosted in different data centers, that would require virtual networks to stretch across data centers and become end-to-end. An end-to-end virtual network would be far more interesting to enterprises than one limited to the data center. Building application-specific networks that extend to the branch locations might usher in a new model for application access control, application performance management and even application security. Will NFV unify differing SDN models?
- 6. With the use of network overlays, NFV could also unify the two models of SDN infrastructure -- centralized and distributed. If connectivity control and application component or user isolation are managed by the network overlay, then the physical-network mission of SDN can be more constrained to traffic management. If SDN manages aggregated routes more than individual application flows, it could be more scalable. Remember that the most commonly referenced SDN applications today -- data center LANs and Google's SDN IP core network -- are more route-driven than flow-driven. Unification of the SDN model might also make it easier to sort out SDN implementations. The lower physical network SDN in this two-layer model might easily be created using revisions to existing protocols, which has already been proposed. While it doesn't offer the kind of application connectivity control some would like, that requirement would be met by the higher software virtual network layer or overlay. Why NFV is the future? • Recent tests by network operators and vendors have demonstrated that network functions can operate at the level of several millions of packets per sec, per CPU core • Demonstrates that standard high volume servers have sufficient processing performance to cost- effectively virtualized network appliances o The hypervisor need not be a bottleneck o The OS need not be a bottleneck • Total Cost of Ownership advantages are a huge driver – could be scenario specific but expect significant benefits, e.g., energy savings • Advances in virtualization & server technologies have propelled the importance and use of software in many applications and fields • A concerted industry effort is underway to accelerate this vision by encouraging common approaches which address the challenges for NFV Fields of Application (examples) • Application-level optimisation: CDNs, Cache Servers, Load Balancers, Application Accelerators • Mobile networks: HLR/HSS, MME, SGSN, GGSN/PDN-GW, Base Station, EPC • Home environment: home router, set-top-box • Security functions: Firewalls, intrusion detection/protection systems, virus scanners, spam protection • Tunnelling gateway elements: IPSec/SSL VPN gateways • Traffic analysis/forensics: DPI, QoE measurement • Traffic Monitoring, Service Assurance, SLA monitoring, Test and Diagnostics • NGN signalling: SBCs, IMS • Converged and network-wide functions: AAA servers, policy control and charging platforms • Switching elements: BNG, CG-NAT, routers Summary The table below provides a brief comparison of some of the key points of SDN and NFV. Category SDN NFV Reason for Being Separation of control and data, centralization of control and programmability of network Relocation of network functions from dedicated appliances to generic servers
- 7. Target Location Campus, data center / cloud Service provider network Target Devices Commodity servers and switches Commodity servers and switches Initial Applications Cloud orchestration and networking Routers, firewalls, gateways, CDN, WAN accelerators, SLA assurance New Protocols OpenFlow None yet Formalization Open Networking Forum (ONF) ETSI NFV Working Group