NFV Q&A with HP
Author: Vinay Saxena, Chief Architect at HP NFV
The NFV conversation has been heating up for some time now. Thanks to the efforts of standards organizations, intrigued CSPs, solution providers, and industry publications, the market is becoming more informed about what NFV offers, where to start, and how to select the right partners. There are still a lot of questions however. What are some of the questions which are hot on the minds of the CSPs, ISVs, and OEMs in the NFV space? The following is Q&A based on a recent webinar (available on demand), “NFV Use Cases – succeeding the transformation,” presented by TM Forum and HP.
Which use cases should be the focus for someone starting out in the NFV journey?
Look for targets in your network that can be instantiated easily, will have minimal impact to the customer base if a problem should occur and will have minimal disruption to the OSS. Find functions that are CPU-intensive but not bandwidth-intensive and are already implemented in software. And look at solutions that are new to the network or on a capital refresh cycle.
Good initial targets for high ROI look to be things like virtual Customer Premise Equipment for Enterprise, virtualization of processes such as service provisioning and activation, virtualization of data mediation, and virtualized CDN. All of these can produce reasonable ROI while providing a safe place for CSPs to get started in NFV.
Find a more detailed answer to this question here.
For the virtualization infrastructure in the NFV architecture, is it sufficient to pull together Linux, KVM and OpenStack and just use them?
Yes, in general these are sufficient, but certain capabilities in each of these layers are critical to success for NFV deployment:
- Linux layer: The hard part is getting Real Time Capabilities in the Linux layer to reduce the impact of latency in the Linux Kernel
- KVM layer: High performance vSwitch and capabilities for NUMA awareness are critical in the KVM layer.
- OpenStack: Smart schedulers, scalability of the OpenStack control plane, high availability and reliability aspects are critical in NFV Deployment.
What do you mean by carrier grade, and what is missing to make carrier-grade a reality?
For NFV to be successful, it must meet carrier grade requirements in the following areas:
- Availability: The network must allow continued operation in the event of a natural disaster, such as a hurricane or earthquake. When faults occur, the virtual machine (VM) infrastructure must recover instantly. The network should not drop calls or lose data during failovers. This is a much more stringent requirement than in the enterprise/data center space.
- High performance: The carrier network must handle a very large number of transactions. In the enterprise space, an e-commerce transaction might take a few seconds, while in the CSP network, transactions — such as a phone system contacting an HLR to verify its location –may be sub seconds in duration. The carrier network must achieve both high throughput and very low latency for critical real-time applications.
- Security: The network must give the CSPs’ customers the peace of mind that the data they are transmitting is secure. All observable traffic in the carrier network must be encrypted, and visible user data cannot be stored in the system. Among other things, the network must fully implement AAA (authentication, authorization, accounting) security protocols to prevent unauthorized access, hacking, or attacks.
What are the key requirements for a next gen OSS to be able to support the needs of an NFV-ready infrastructure?
The abstractions introduced by network functions virtualization present a number of new components and systems that need monitoring. Correlation capabilities are required when the embedded VNF manager functionality is being used for rules-based autonomous actions. Key requirements include:
- VNF Fault & Performance management
- Network service fault and performance management
- Monitoring alerts received from Openstack and Virtualized infrastructure
- Provide Audit Reports for the entire lifecycle of a VNF Instance
- Ability to monitor VIM
What is the difference between NFV and SDN?
SDN and NFV are highly complementary and mutually benefit each other. NFV brings virtualization techniques to network equipment, which helps:
- Decrease unit costs of network functions:
- Move from bespoke hardware and software (physical network functions) to software running on commercial-off-the-shelf (COTS) hardware
- Increase utilization of the infrastructure through virtualization (i.e., multiple instances, software-based redundancies)
- Reduce the management costs of network functions because they are now “IT based” with more standardization and more centralization
SDN is about dynamic programmability in the network to:
- Introduce new services faster, because SDN allows flexible (re)configuration and more automation
- Reduce the management costs of end-to end networks, because SDN can create an abstraction on which automated (orchestration) management processes can be applied (vs. bespoke, per box, proprietary scripts)
- Enable virtualization and mobility by defining networks that dynamically follow virtual and physical devices even when they move and connect to the network at varying locations
- Eventually lower the unit cost of network devices (commoditization) because they become “COTS based”
Read this for more information on why SDN matters to NFV.
How is the NFV infrastructure like the Openstack one? Is there any specific link between NFV and cloud?
There’s a very close tie-in between OpenStack and network functions virtualization (NFV), because with NFV, CSPs are really trying to “cloudify” the network. If they have a router or various functions in the network, they’re trying to cloudify those functions and move them away from expensive, proprietary hardware over to a cloud infrastructure. To accomplish this, they need a cloud platform. And that’s where OpenStack comes into play, because OpenStack, as an open source platform, is the cloud platform of choice for CSPs.
Does HP NFV Director directly control the hypervisor?
HP NFV Director today uses OpenStack APIs to manage a virtual data center. Openstack has built-in scripts to talk to the hypervisor.
How will Network Protocols and advanced Network protocol MPLS, OSPF ,etc. work with NFV?
NFV is agnostic to network protocols, whether these protocols are used in the WAN or in the DC LAN. They will be transported to the appropriate VNFs in the DC/PoP/MSC using an overlay network based on VLANs, VXLANs or GRE.
How can an HP partner gain, align and participate with HP NFV solutions?
The HP OpenNFV Partner program consists of three partner categories:
- Technology partners—Select technology companies and vendors, including NEPs, original equipment providers (OEMs) and CSPs that collaborate on technology innovation, integration and support for the HP OpenNFV infrastructure stack.
- Application partners—ISVs that conduct testing, characterization and validation on the HP OpenNFV infrastructure stack.
- Service partners—Systems integrators using the HP OpenNFV infrastructure stack as a platform for their offerings.
If you are interested in participating as an Application partner, please visit our AllianceOne website. If you would like to participate as a Technology or Service partner, please contact us at email@example.com
What kind of templates did you use for SKT Multi Vendor Implementation? Were they based on TOSCA or native HOT based on Openstack for Network models?
The HP NFV Director descriptor is based on the ETSI descriptor model, where the descriptors are split into 3 parts: Definitions, Templates and Instances. Each VNF or Network service you are provisioning and/or monitoring would have to define descriptors. There is a lightweight tool included with HP NFV Director to define descriptors.
In addition there is thin client browser-based tool which helps partners to define their requirements and for generic descriptors to be generated for their VNFs.
Currently the descriptors are not based on TOSCA.
How are service providers moving from existing platforms for existing services into NFV? They should obviously go through a hybrid platform where both existing platform/services and NFV platforms are supported. How do you see this happening?
New NFV deployments will have to co-exist with existing vertically integrated HW platforms. Most initial NFV deployments will deploy the new NFV Cloud as an active-active pairing with existing platforms or carve out specialized use cases / users / applications to be serviced by the NFV Cloud environment while traditional customers / use cases will continue to be serviced by the existing platforms.
What should we change in BSS/OSS to adopt SDN and NFV and monetize their value?
As part of the orchestration workflow and assurance workflow, add a custom workflow to integrate with BSS/OSS systems. Also in the service assurance, define related monitors and monitor handlers.
What are the pain points in the level of physical network that should be considered before implementing the SDN/NFV?
- Provide separate network channels: Management, data and monitoring network.
- Integration with vSwtich where the host network integration with the NFV / SDN might need admin access for routing or IP table configuration
- The need to model the relation between an abstract, logical (virtual) infrastructure and the physical infrastructure. This can be further complicated by hybrid environments—those with some network functions virtualized and some still physical. A network function may correspond to a device in one part of the network and to a virtualized service in another.
- The need to monitor network functions at both physical and virtual levels. This will require mapping between the two
- Complications that arise from distribution of virtual network functions. Since these can consist of multiple components, each independently deployed, some VNFs may span across multiple data centers. Capacity management and disaster recovery will require entirely new tools and strategies in the dynamic world of NFV.
- With the increase in mobile data and new technologies like M2M, IoT etc, it will be very difficult for carriers to have good amount bandwidth available for NFV/SDN.
HP’s OpenNFV team invites you to join the discussion on this topic. Share your thoughts with us on twitter @HPCMS, #OpenNFV, and our blog.