NFV 常见问题解答

NFV FAQ

Q1：SDN 和 NFV 的作用是什么？

术语 NFV 和 SDN 经常被联合使用，这可能给人一种印象，即 SDN 是 NFV 体系结构中的一个基本要素。 SDN 是一个重要的概念和衍生技术，极大地提高了 NFV 基础网络的控制和管理。 相反，SDN 架构的功能模块可以以 NFV 基础架构中承载的虚拟化网络功能的形式进行部署。 但是，SDN 并不是实现 NFV 的强制性技术。

2012年10月的第一届NFV白皮书：

“NFV 与软件定义网络（SDN）高度互补，但不依赖于它（反之亦然）。 NFV 可以在不需要 SDN 的情况下实现，尽管这两个概念和解决方案可以结合起来并可能获得更大的价值“

更多内容可以参考十张图看懂 SDN 与 NFV 的区别与联系

Q2：NFVO 与 VNFM 有什么区别？

NFVO 和 VNFM 都是 NFV-MANO 中管理和编排架构框架的功能块。

VNFM 负责 VNF（s） 的生命周期管理 （LCM） 。这包括支持界面操作和工作流程的执行：

• 实例化 VNF 。
• 扩缩容 VNF（增加或减少 VNF 的容量）。
• 修复 VNF（修复有故障的 VNF 和/或其 VNFC 实例和内部 VNF 虚拟链路的纠正措施）
• 更改 VNF 风格（更改已部署的 VNF 的风格，即部署选项）
• 操作 VNF（更改 VNF 实例的状态）
• 修改 VNF 信息（支持 VNF 配置和信息更改）。
• 更改外部 VNF 连接（更改 VNF 实例的外部连接）
• 终止 VNF （释放与 VNF 相关联的 NFVI 资源并将其返回给 NFVI 资源池）。

VNFM 还负责 VNF 性能，故障和配置管理。

另一方面，NFVO 负责管理网络服务（NS）生命周期，并结合 VNF 生命周期（由 VNFM 支持）和协调NFIM资源（由 VIM 支持）来确保优化分配必要的资源和连接。 因此，NFVO 功能可以分为两大类：端到端资源编排和网络服务编排。 NFVO 还负责 NS 性能和故障管理以及VNF包管理。 与 VNF LCM 类似，NS 生命周期与许多受支持的操作和执行工作流相关，例如用于实例化，缩放，修复和终止 NS 的工作流，以及不同类型的更新，例如添加/删除 VNF 来自/来自 NS 的实例等等。

Q3：VNF 部署的最佳做法是基于虚拟机还是容器？

目前大多数电信公司的 NFV 部署都是基于虚拟机，目前适合市场上提供的大部分 VNF 实施。

然而，最近的实现开始引入基于容器的 VNF 。 由于云原生 VNF 的诉求引入了行业，因此需要更多地考虑使用基于容器的虚拟化了。

Q4：VNFM 和 EM 有什么区别？

一方面，从资源的角度来看，VNFM 负责 VNF 的生命周期管理，如实例化，缩放等（同样参考 Q2）。 另一方面，EM 负责驻留在 VNF 中的实际网络应用的 FCAPS （故障，配置，计费，性能和安全）管理。

Q5: 水平和垂直缩放有什么区别？

缩放可以分为两类：水平缩放和垂直缩放。

以 VNF 为例，水平缩放可以分为两类

• Scale out: 涉及增加容量，它是指将一个或多个 VNFC 实例添加到现有应用程序的过程。
• Scale in: 涉及容量的减少，它指的是从现有应用程序中删除一个或多个 VNFC 实例的过程。

以 VNF 为例，垂直缩放可以分为两类

• Scale up: 涉及增加容量，它是指将资源（例如 CPU /内存）添加到现有 VNFC 实例的过程。
• Scale down: 涉及容量的减少，它是指从现有的 VNFC 实例释放资源（例如 CPU /内存）的过程。

每当某个预先配置的策略（例如关于 CPU 利用率）被激活时，或者通过例如由操作员的明确请求，自动触发缩放。

例如，NFV 生态系统中的自动扩展策略可能意味着，如果 CPU 利用率超过70％，系统应该扩容，如果 CPU 利用率低于 20％，系统应缩容。

VNF缩放可以从几个来源触发：

• NFVO
• VNFM
• VNF / EM（元素管理器）
• OSS / BSS
• 由操作员手动

Q6: 包处理解决方案在 NFV 中的实施

许多包处理解决方案（如 DPDK 功能）在专门的硬件中工作。 VNF 实施者如何确保商品硬件的性能也同样出色？

DPDK 需要兼容的硬件，即兼容的网络接口卡 （NIC） 和 CPU 型号。但是，与其他一些加速技术不同，DPDK 不需要专门的处理器。在后一种情况下，可以将专用处理器添加到商品服务器（例如，带有嵌入式处理器的 SmartNIC ），以便将来自主通用处理器的流量处理的一部分卸载到这些专用处理器。

此外，尽管最初是为 x86 生态系统设计的，但 DPDK 并不是特定于供应商的功能，而最近的版本与特定的硬件无关。如今，DPDK 是一个开源社区驱动的软件解决方案（软件库），用于增强数据包处理。 DPDK 已经发展成为一个庞大的生态系统，支持许多不同的 NIC 卡和处理器，因此不受特定硬件或供应商解决方案的约束。 尽管 DPDK 可用于各种平台，但要保证性能，还需要 VNF 实施人员和基础设施提供商联合实验室/测试工作。

Q7: 我们可以在一个单一的实体中有 EM 和 VNFM 吗？

EM 和 VNFM 是提供 NFV 体系结构框架中指定的不同功能的功能块。 然而，与许多功能体系结构一样，实际的实现可以将两个功能包含在一个单独的实体中。

Q8: 如何评估运营商在NFV和开源计划中的贡献？

2012年10月发布的第一份 NFV 白皮书是一级运营商（参考网络功能虚拟化 - 介绍性白皮书）合作的结果。

从那时起，生态系统已经扩展到 ETSI NFV ISG 中的300多家公司/组织，包括39家网络运营商。

NFV ISG 是运营商主导的行业倡议，旨在提高认识，并培养所有行业利益相关者在 NFV 愿景之下提供可互操作的解决方案。 运营商的贡献已经扩展到直接参与 OpenStack 等上游社区和 OPNFV 等中游社区。 除了所有 ETSI NFV 和其他 SDO 所做的标准化工作外，运营商还开发了其他市场领先的开放源码举措，如 OSM 和 ONAP。

Q9: Hypervisors 在 NFV 中的确切作用是什么？

Hypervisors 是一种软件，它将底层的硬件物理资源（CPU，内存，存储，网卡）进行分区，生成虚拟机，并将分配的资源分配给它们。

另一方面，虚拟机通常作为具有物理服务器（CPU，内存，存储，NIC）所需要的所有要素。

当虚拟化计算资源以虚拟机的形式交付时，Hypervisors 在 NFV 中的角色是 NFVI 的“虚拟化层”实现者。

Q10: 旧的硬件/基础设施如何重复使用？

运营商是否可以重新使用即将结束的现有硬件/基础设施作为NFVI的一部分，例如即将退役的2G基础设施？

大多数旧的电信平台是专用硬件，不能与其应用软件分离使用，这实际上是 NFV 背后的主要概念和驱动力之一。

具体的硬件是否可以重复使用可能取决于具体情况，需要经过运营商和设备供应商的分析。

Q11: NFV 引入的时机有什么考量？

为什么现在才引入 NFV for Mobile Core（LTE / EPC），而不是在 CDMA PS 核心（PDSN）和其他 NF BSC / RAN 之前就引入？

要进行虚拟化的网络功能的选择取决于运营商或供应商的许多标准。 影响网络功能虚拟化的因素包括：虚拟化平台上运行的网络功能软件的准备情况，市场需求，现有硬件的使用寿命等。 其他因素之一是网络功能目标本身。 例如，如果这是一个繁重的代码转换工作量，这种功能的虚拟化可能会影响网络功能的性能，从而延迟其虚拟化，直到虚拟化基础架构能够提供所需的性能。

Q12: Ve-Vnfm-em 和 Ve-Vnfm-vnf 是否具有相同类型的功能？

在标准中，有两个参考点，一个在 VNFM 和 VNF 之间，另一个在 VNFM 和 EM 之间。 两个参考点是否具有相同类型的功能？

Ve-Vnfm-em 参考点用于 EM 和 VNF Manager 之间的交换。 Ve-Vnfm-vnf 参考点用于 VNF 和 VNF Manager 之间的交换。 它们共享一些共同的功能，例如 VNF Indicator 接口，这是由 VNF 或 EM 提供的用于标识 VNF 行为的一些指示的信息。 VNFM 可以将这些指标与虚拟资源数据结合使用来执行自动缩放决策。 此外，两个参考点都共享由 VNFM 生成并由 EM 和/或 VNF 使用的 VNF 生命周期管理界面的大部分操作。

其中一个不同之处就是仅在 Ve-Vnfm-vnf 上可用的VNF配置界面。 Ve-Vnfm-vnf 参考点上的 VNF Configuration 界面支持设置或更新 VNF / VNFC 实例的虚拟化相关配置参数。

Q13: 多供应商？

我们是否可以在真正的部署中拥有独立的多供应商 VIM，VNF Manager 和 NFV Orchestrator？

是的，这样的多厂商设置是可能的。 在这种情况下，系统集成工作需要考虑 VIM，VNFM 和 NFVO 之间的所有三个参考点。 ETSI NFV 指定的 REST API 旨在实现多供应商解决方案。 见：One more step towards NFV MANO interoperability

Q14: VNF Manager 是一种云管理平台吗？

VNF Manager 是主要负责 VNF 生命周期管理以及某些配置管理功能的实体。

在 NFV 的背景下，云管理平台由 VIM （虚拟化基础架构管理）来表示。

Q15: NFVO 和 VNFM 可以组合在同一个实体中吗？

NFVO 和 VNFM 是提供 NFV 体系结构框架中指定的不同功能的功能模块。 然而，与许多功能体系结构一样，实际的实现可以将两个功能包含在一个单独的实体中。

Q16: NFV 是否只专注于虚拟化电信网络功能？

任何具有相同特征和 NFV 要求的企业或环境（例如电信级性能，高可用性，类似电信公司的工作负载）都可以利用 NFV 的潜力和 ETSI NFV 所定义的框架。

Q17:为什么我们需要使用 SDN，如果 NFVO 可以执行其功能？

这是不正确的。 这两个实体有不同的角色。 NFVO 主要负责资源编排和网络服务编排，而 NFVI PoP（又名 DC SDN）中的 SDN 通常负责 DC 网络。

说到网络服务的网络部分， VNF 间路径或链路被定义为网络服务描述符的一部分并由 NFVO 处理。 这些信息用于派生发送给 VIM 的请求的内容，而这些请求又可以将基础设施路由器和交换机的配置委托给 SDN。

所以，我们可以说这个定义来自于 NFVO，配置代理/主机是由 VIM / SDN 完成的。

Q18: 从性能角度来看，除了监控应用层 KPI 还必须监控云层的性能吗？

从 FM / PM 的角度来看，运营商需要对整个 NFV 的垂直堆栈进行 E2E 监测。 因此，从 EM 获取应用计数器和告警是不够的。 软/硬件故障和计数器需要通过引入相关的基础设施监控工具进行监控。

拥有正确的工具集将使运营商能够为网络服务和VNF提供高效的根源分析（RCA）引擎。 与虚拟资源有关的故障和性能报告应由 NFVI 报告给 VIM，由 VNFM 和 NFVO 传播/关联到 OSS 和/或 EM 或 VNF 本身。 NFVO 和 VNFM 也可能会对某些事件立即采取行动。

Q19: NFV-MANO 是否真的不考虑物理网络功能？

是的。NFVO 可以管理 VNF 和 PNF 结合的混合网络服务。 但是，NFV-MANO 不管理 PNF 资源的生命周期。 从 NFVO 的角度来看，PNF 是暴露多个连接点的黑盒实体。

Q20: NS 是否可以嵌套，但只允许一层嵌套呢？

不是的。嵌套层数没有理论上的限制。 尽管实际上这个数字预计很低。

Q21: 异体系结构使用 NFV API？

ETSI 在 NFV 架构框架的某些参考点指定了 REST API，实现了多供应商互操作性。 如果我的体系结构不同于 NFV 体系结构框架，我可以使用这些 API 吗？

这一切都取决于差异有多重要。 例如，如果 NFVO 和 VNFM 之间的功能划分不符合 ETSI 标准，或者如果两个功能块被包含在一个单一的内容中，则很难使用 ETSI NFV-SOL 003 中为 or-Vnfm 参考点指定的 API 实体。 但是，这并不妨碍使用 ETSI GS NFV-SOL 002 中指定的 Ve-Vnfm 参考点的 API。 此外，ETSI GS 中指定的 API 是彼此独立的。 例如，ETSI GS NFV-SOL 005 中指定的不同 API 可以由不同的 OSS 组件使用。

Q22: PNF 的可靠性与 VNF 的弹性不同吗？

这两个术语涵盖了相同的概念，即在故障，中断正常操作的事件的情况下，能够限制中断并恢复到正常或在可接受的最低服务交付水平。

参考资料

1. ETSI_NFV_FAQ