网络功能虚拟化（NFV）技术的目标是在标准服务器上提供网络功能，而不是在定制设备上。虽然供应商和网络运营商都急于部署NFV，但欧洲电信标准协会（ETSI）要到2015年1月才会发布规范。因此，早期NFV部署将不得不利用更广泛的原则，随着更多细节信息浮出水面，这些原则将会逐渐被部署。

为了在短期内实现NFV部署，供应商需要作出四个关键决策：部署云托管模式，选择网络优化的平台，基于TM论坛的原则构建服务和资源以促进操作整合，以及部署灵活且松耦合的数据/流程架构。

为NFV寻找通用管理框架：选择OpenStack？

从理论上讲，NFV可以存在于专用物理服务器上，也可以运行在云计算中的虚拟服务器中。但在实践中，由于没有涵盖所有这些选项的统一管理框架，因此很难提供如此广泛的部署选择。

为了解决这个问题，我们可以将虚拟功能放在云中，并使用OpenStack作为云软件平台。OpenStack有着广泛的行业支持，并且它有一个网络即服务框架，Neutron（以前被称为Quantum），其插件能够支持大部分主流SDN技术，甚至还能支持一些专有网络管理系统（NMS）。然而，Neutron正在逐渐发展为满足云计算的需求，而不是满足网络运营商更广泛的需求，因此，早期NFV部署将需要为运营商网络扩展Neutron，以涵盖云计算中不存在的传统的端到端连接等功能。在这种情况下，开发人员需要增强Neutron，或者绕过它不支持的模型。

为NFV部署优化商用服务器

NFV和托管虚拟功能的成功取决于这些功能是否可用以及是否能根据需要来执行。ETSI NFV行业规范组（ISG）的目标就是在商用服务器上实现这些功能，但这需要通过硬件和软件进行网络优化。在从网络接口到虚拟机的数据路径连接的情况下，这种优化尤其重要。毕竟，根据网络设备预期处理的流量以及它们提供的可靠性的不同，网络设备各有不同。NFV主机也是相同的情况，所以相同的优化是必要的。

寻找NFV管理模式：看看TM论坛

部署NFV的第三个问题是管理过程。这需要基于数据模型来描述服务和资源。在NFV出现之前，TM论坛（TMF）就提供了一个合适的（也许是理想的）数据模型：（SID）GB 922。虽然这种模型可能需要进行扩展，才能支持虚拟功能和云资源，但这种扩展将是很小范围的，并且，GB922提供了丰富的模型用于描述服务（包含虚拟功能）以及（承载这些功能的）资源。

这个TMF模型极大地简化了资源和服务的构建和管理，同时，NFV自身的虚拟功能管理理念也可能融入这个较大的TMF模型。

此外，TMF模型可以很容易地部署，不仅能管理从虚拟功能新组成的服务，而且可以管理传统配置的服务，甚至合作伙伴提供的那些服务。通过一个共同的架构来管理所有这些服务，当很多传统网络设备仍然继续使用时，这种模型将允许运营商管理到NFV的过渡。

NFV部署需要非传统数据模型

管理集成和服务建模代表着最大和最后的NFV部署决策（数据模型）。NFV触及现有网络OSS/BSS，以及NMS，云管理系统以及虚拟功能本身的管理。它将需要管理所有用于托管NFV的设备以及所有周围的网络设备。

在确定托管功能的最佳位置以及最佳连接方式时，我们需要考虑虚拟化、虚拟功能的机器映像、虚拟网络SDN连接和流量模式。这种优化任务很巨大，但真正的挑战在于简单地传达这些政策来指导部署，以及收集所需要的管理数据。对于这一点，NFV部署需要站在传统数据模型之外来思考。

现代数据驱动的过程模型将数据存储从数据/信息模型分离出来，并且，它们使用语义层来描述解译和关系。这些可以很容易地适应收集器接口来从设备和功能收集遥测信息，以及分布接口来以管理系统需要的形式可视化数据。IETF已经提出使用数据仓库来收集资源信息，用以分布到虚拟功能或者其基础架构到应用程序的信息传输（i2aex）架构内的管理流程。这种语义建模方法还可以让我们很容易地对NFV ISG指定的接口进行准标准部署。

在NFV部署中，我们是否需要现成的云应用？

除了这些基本部署点，我们还需要考虑一些基本问题，例如虚拟功能实际来自哪里。

如果虚拟功能必须被定制开发为在NFV部署中运行，那么，在功能可用性方面可能存在潜在的延迟。毕竟，开发人员必须致力于新环境，这可能导致多个平台具有不同的需求集。而在NFV托管云应用或网络组件的能力将帮助解决这个功能可用性问题，但现成的云应用或网络功能组件不能利用任何特殊管理、可用性或性能工具（这些可能被构建到NFV规范中）。正确的答案可能是同时支持现成的应用以及具有NFV优化行为的定制化应用。然后，市场可以自己作出选择。

在规范出现之前，我们肯定会看到很多NFV部署。事实上，ISG的工作目标并不是描述或者限制部署过程和供应商，NFV用户将在不同的功能和特性上放置不同的价值。随着部署逐渐展开，我们将看到NFV可以做什么，到时候，我们将能够判断这会是怎样的一场革命。