RFC8172：Considerations for Benchmarking Virtual Network Functions and Their Infrastructure，July 2017
基准方法工作组传统上对网络互联功能的专用物理实现进行实验室表征。本备忘录研究了在通用硬件中虚拟化和执行网络功能时的其他注意事项。
本文档不是 Internet Standards Track 规范；它是为了提供信息而发布的。
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已获互联网工程指导小组 (IESG) 批准出版。并非 IESG 批准的所有文件都适用于任何级别的互联网标准；请参阅 RFC 7841 的第 2 节。
有关本文档当前状态、勘误表以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8172。
版权所有 (c) 2017 IETF Trust 和文件作者。版权所有。
本文件受 BCP 78 和 IETF 信托关于 IETF 文件的法律规定 (http://trustee.ietf.org/license-info) 的约束，该条款在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且按照简化 BSD 许可中的说明在不保证的情况下提供。
基准方法工作组 (Benchmarking Methodology Working Group，BMWG) 传统上对互联网络功能（或物理网络功能，physical network functions，PNF）的专用物理实现进行实验室表征。吞吐量、延迟、转发率等黑盒基准已经为我们的行业服务多年。[RFC1242] 和 [RFC2544] 是这项工作的基石。
已经出现了一组服务提供商和供应商的发展目标：降低成本，同时提高网络设备的灵活性，并大幅缩短部署时间。网络功能虚拟化 (Network Function Virtualization，NFV) 有望实现这些目标，因此备受关注。现在看来，随着云计算和虚拟桌面的成功，在足够的网络路径容量、性能和广泛部署的支持下，一些网络功能将被虚拟化；许多相同的技术将有助于实现 NFV。
在虚拟网络功能 (Virtual Network Functions，VNF) 的上下文中，支持基础设施需要通用计算系统、存储系统、网络系统、虚拟化支持系统（例如管理程序）以及虚拟和物理资源的管理系统。将有许多潜在的基础设施系统供应商，并且在配置系统以获得最佳性能方面具有很大的灵活性。还有许多潜在的 VNF 供应商，在这种环境中增加了可能的组合。硬件和软件供应商的分离对基准测试活动产生了深远的影响：现在必须指定更多黑盒被测设备 (Device Under Test，DUT) 的内部配置并与结果一起报告，以促进以后可重复性和对比测试。
考虑以下用户故事作为进一步的背景和动机：
我正在设计和构建我的 NFV 基础架构平台。第一步很简单，因为我需要支持少量的 VNF 类别，而且 VNF 供应商提供了我遵循的硬件建议。现在我需要部署更多来自新供应商的 VNF，并且有不同的硬件建议。新 VNF 在我现有硬件上的性能如何？在给定类别中的几个新 VNF 中，哪一个在它们提供的容量方面效率最高？而且，当我在一个硬件平台上*同时*运行多个类别的 VNF（和 PNF）以便它们共享资源时，新的性能限制是什么，以及我可以做出哪些软件设计选择来优化我选择的硬件平台？相反，我应该进行哪些硬件平台升级来增加这些并发运行的 VNF 的容量？
有关更多背景信息，请参见 <http://www.etsi.org/technologies-clusters/technologies/nfv>；那里的白皮书可能是一个有用的起点。“NFV 性能和可移植性最佳实践”文档 [NFV.PER001] 与 BMWG 尤其相关。批准的 ETSI NFV 规范 [Approved_ETSI_NFV] 中也有可用的文档，包括描述基础设施性能方面和服务质量指标的文档，以及 ETSI NFV 开放区域 [Draft_ETSI_NFV] 中的草案，它们也可能与基准测试相关。
关键词“必须”、“不得”、“要求”、“应”、“不得”、“应该”、“不应”、“推荐”、“不推荐”、“可以”和“可选”当且仅当它们以全部大写字母出现时，本文档中的 ” 将按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，如此处所示。
在撰写本文时，BMWG 正在考虑虚拟网络功能和相关基础架构的新主题，以确保从一开始就识别常见问题；正在使用来自各自标准开发组织和开源开发项目（例如 IETF、ETSI NFV 和网络功能虚拟化开放平台 (Open Platform for Network Function Virtualization，OPNFV)）的背景材料。
本备忘录研究了使用裸金属虚拟机管理程序 [BareMetal] 或其他隔离环境（如 Linux 容器）对在通用硬件中实例化和托管的 VNF 进行基准测试时所需的其他方法考虑因素。一个重要的考虑因素是尽可能以相同的方式对物理和虚拟网络功能进行基准测试，从而允许直接比较。在被测系统 (System Under Test，SUT) 中对物理和虚拟设备和功能的组合进行基准测试是另一个非常感兴趣的话题。
一个明显相关的目标是调查通用平台承载多个 VNF 实例的能力的基准。现有的网络技术基准也将被考虑适应 NFV 和密切相关的技术。
非目标是与传统计算机基准测试开发及其特定指标（例如 SPECmark 套件，如 SPEC CPU）的任何重叠。
一个持续的非目标是任何形式的与 NFV 和 BMWG 相关技术相关的架构开发，这与自 1989 年 BMWG 开始以来的所有特许工作一致。
本节列出了对 VNF 及其支持基础架构进行基准测试时必须考虑的新注意事项。SUT 由硬件平台组件、安装的 VNF 和许多其他支持系统组成。记录 SUT 的所有方面以促进可重复性至关重要。
以下新硬件组件将成为测试设置的一部分：
1. 大容量服务器平台（通用，可能带有虚拟技术增强）
2. 大容量、高速度、高可靠性的存储系统
3. 专为高效服务许多虚拟网络接口卡（Network Interface Cards，NIC）而设计的网络接口端口
4. 大容量以太网交换机
上述组件是针对网络功能部署的特殊需求开发专门基准测试的主题。
对不同 VNF 进行比较的实验室可能能够在许多研究中使用相同的硬件平台，直到创新的稳步推进超过了他们的能力（就像今天实验室的流量生成和测试设备一样）。
有必要配置和记录整个通用平台的设置，以确保可重复性并促进未来的比较，包括但显然不限于以下内容：
*刀片服务器数量（机架占用）
*CPU
*缓存
*内存
*存储系统
*输入/输出
以及支持托管 VNF 本身的设备的配置：
*Hypervisor（或其他形式的虚拟功能托管）
*虚拟机 (Virtual Machine，VM)
*基础架构虚拟网络（例如，将虚拟机与物理网络接口或通过虚拟交换机相互连接）
最后是 VNF 本身，包括以下项目：
*在 VNF 中实现的特定功能
*为每个功能保留的资源（例如，CPU pinning 和非统一内存访问 (Non-Uniform Memory Access，NUMA) 节点分配）
*服务功能链中 VNF（或子 VNF 组件，每个都有自己的 VM）的数量（参见 [RFC7498] 的第 1.1 节，了解服务功能链的定义）
*服务功能链中经过的物理接口和链路数量
在物理设备基准测试环境中，大多数相应的基础设施配置选择由供应商确定。尽管平台本身现在是配置变量之一，但重要的是要保持对网络基准的重视并将平台变量作为输入因素。
在容量限制下表征性能的概念可能会改变。例如：
1. 描述托管 VNF 的 VM 以 50% 的利用率运行并因此在许多 VM 之间共享“真实”处理能力的情况可能更能代表系统容量。
2. 另一个重要的测试用例源于对网络功能进行分区（或隔离）的需要。理想情况下，嘈杂的邻居（在无限循环中托管 VNF 的虚拟机）将被隔离；其他 VM 的性能将根据其规范继续运行，并且测试将评估隔离程度。
3. 系统错误可能会以瞬态的形式出现，这意味着性能特征的分布具有长尾（如延迟），并导致需要对每组配置和测试参数进行长期测试。
4. 对网络功能之间的弹性和灵活性的需求将包括在 VM 实例数量、VM 所需资源以及支持 VM 连接的网络路径的设置/拆除等方面不断变化的测试。新 VM 的请求和实例化，以及托管不再需要的 VNF 的 VM 的发布，将是正常的操作条件。换句话说，基准测试应包括对 VM 及其 VNF 和正在进行的网络连接进行生产生命周期管理的场景，包括 VNF 扩展/缩减操作以及静态配置。
5. 所有物理事物都可能发生故障，基准测试工作还可以通过不同的弹性方法来检查虚拟架构辅助的恢复。
6. 大量的测试条件和配置组合鼓励提高效率，包括自动化测试安排、通过了解相互关系进行组合子采样以及机器可读的测试结果。
由于新的 NFV 基础架构的许多组件都是虚拟的，因此测试设置设计必须事先了解 SUT 中各种资源域内的交互/依赖关系。例如，执行传统测试器功能（例如生成和/或接收流量）的虚拟机应避免与 DUT 共享任何 SUT 资源。否则，结果将具有物理设备基准测试中未遇到的意外依赖关系。
请注意，术语“测试仪”传统上指的是 BMWG 文献中专门用于测试的设备。在这个新的上下文中，“测试器”还指专门用于测试的功能，可以是虚拟的或物理的。“测试者”从未指代执行测试的个人。
在测试设计中使用共享资源同时产生有用结果的可能性仍然是需要克服的关键挑战之一。基准测试设置可以将 DUT 和其他关键支持组件（例如主机/内核）的隔离资源指定为第一个基线步骤，并添加其他加载过程。每个设置增加的复杂性导致共享资源测试场景，其中竞争负载的特征（在内存、存储和 CPU 利用率方面）将直接影响基准测试结果（和结果的可变性），但结果应与基线一致。
物理测试设备仍然是与使用物理和虚拟测试功能组合的结果或在需要评估虚拟接口和其他虚拟功能时仅使用虚拟测试仪的结果进行比较的坚实基础。
本节讨论与适用于 VNF 及其相关技术的基准相关的注意事项。
为了将 VNF 和系统实现的性能与其物理对应物进行比较，必须使用相同的基准。由于 BMWG 已经为许多网络功能制定了规范，因此将通过参考重用现有基准，同时允许在开发新方法时进行基准管理。应考虑量化与给定物理设备实现可比规模/容量所需的并行 VNF 数量，或者在 VNF 达到可比水平之前是否达到某种规模限制。同样，基于不同管理程序或其他虚拟功能托管的实施仍然是性能评估的关键因素。
当被测网络功能基于开源代码时，在一定程度上可能存在依赖内部测量的趋势，尤其是当外部可观察到的现象仅支持对内部事件的推断时（例如在数据平面）。示例包括 CPU/核心利用率、网络利用率、存储利用率和已提交/已使用的内存。这些“白盒”指标提供了 VNF 资源占用量的一种视图。请注意，资源利用率指标不容易匹配 4.4 节中描述的 3×4 矩阵。
然而，作为基准的基础，外部观察仍然是必不可少的。例如，可以同时提供具有固定规范和解释的内部观察（作为辅助指标），以在部署技术时帮助开发操作程序。来自开源实现的内部度量和测量可能是所需维度中性能结果的唯一直接来源，但仍需要确证的外部观察来确保所有报告结果都保持测量规则的完整性。
基准开发的一个相关方面是范围包括在同一基准下实现公共功能的多种方法。例如，有许多方法可以安排接口点之间的网络路径的激活，如果启动到停止的激活间隔具有通用且明确的定义，则可以比较激活时间。因此，在可能的情况下，通用基准定义优于技术/协议特定定义。
在开发运营实践（可能是部署规模的自动化管理和编排）时，网络设计和协助将需要新的基准类别。以下段落中的示例如下，其中许多是出于增加网络功能的弹性和灵活性以及减少部署时间的目标。
*部署 VNF 的时间：在通用硬件已经部署并准备好服务的情况下，了解管理系统负责“启动”100 台虚拟机及其将托管的 VNF 时的响应时间是很有价值的。
*迁移 VNF 的时间：在必须从活动服务中移除硬件机架或机柜的情况下，了解管理系统负责“迁移”一些虚拟机及其 VNF 时的响应时间是很有价值的当前托管将继续使用的备用硬件。
*在通用基础架构中创建虚拟网络的时间：这是现有收敛时间基准的简化版本，因为该过程由（集中式或分布式）控制的请求启动，而不是从网络推断事件（链接失败）。成功的响应时间仍将取决于数据平面观察，以确认网络已准备好执行。
*验证测量对性能的影响：实现了完整的 VNF，或者像在 VNF 中实施的新策略这样简单的东西。验证 VNF 或策略实例化的操作可能会影响正常操作期间的性能。
此外，在评估传统和新基准时测量传统数据包传输性能指标似乎很有价值，包括可用于支持服务工程的指标，例如 [RFC6049] 中的空间组合指标。示例包括 [RFC6049] 第 4.1 节中的平均单向延迟、[RFC5481] 中的数据包延迟变化 (Packet Delay Variation，PDV) 和数据包重新排序 [RFC4737] [RFC4689]。
根据其适用的生命周期阶段和设计用于评估的性能标准来组织基准是很有用的。下表（源自 [X3.102]）提供了一种组织基准的方法，以便明确指示生命周期阶段和性能标准的交叉点的覆盖范围。
例如，上面描述的“部署VNF的时间”基准将放在激活和速度的交叉点上，这表明还有其他潜在的性能标准需要基准测试，例如100次尝试中的“失败VM/启动VNF的百分比”。该示例强调，激活和去激活生命周期阶段是NFV和相关基础设施的关键领域，并鼓励在正常运行的传统基准之外进行扩展。因此，在BMWG中，使用该表（有时称为3×3矩阵）审查基准覆盖率可能是一项有价值的工作。
在 BMWG [SDN-BENCHMARK] 中 3×3 矩阵的第一个应用中，我们发现测量大小、容量或规模的指标不容易匹配上述三列之一。经过讨论，通过两种方式解决了这个问题：
**添加一列Scale，用于对基准的覆盖范围进行分类和评估（没有测量结果）。在 [OPNFV-BENCHMARK] 中可以找到这种用法的示例（并且可以在 [SDN-BENCHMARK] 中找到变体）。这是 3×4 矩阵。
**如果使用矩阵以有组织的方式报告结果，请将大小、容量和规模指标与 3×3 矩阵分开，并将它们与结果的其他限定条件合并到报告中。
请注意，资源利用率（例如 CPU）指标不适合矩阵。它们不是基准，省略它们可这种方法鼓励使用3×3矩阵来组织结果报告，在该矩阵的标题中可以包括测量各种指标的能力（如果有足够的测量/结果以这种方式组织，多个能力的结果将产生单独的3×3矩阵）。
例如，每个 VM 和 VNF 的结果可能出现在 3×3 矩阵中，组织起来以说明特定物理计算系统中的资源占用（CPU 内核），如下所示。
上述表格的组合可以增量构建，从 VNF#1 和一个核心开始，然后根据支持的核心分配添加 VNF。关键基准的 X-Y 图也将提供对提高硬件利用率的影响的洞察力。所有 VNF 可能属于同一类型，或者为了匹配生产环境，可能存在多种类型和类别的 VNF。在该图中，假设 VNF #3-#5 需要较少的 CPU 资源，而 VNF#2 需要四个内核来执行其功能。
尽管以有意义的方式对物理网络功能功耗进行基准测试的工作并不完整，但测量支持虚拟功能的物理基础设施的愿望只会增加需求。最大功耗和动态功耗（负载变化）都是有用的。智能平台管理接口 (Intelligent Platform Management Interface，IPMI) 标准 [IPMI2.0] 已被许多制造商实施，并支持瞬时能耗测量。
根据 [NFVIaas-FRAMEWORK]，为了评估虚拟资源的瞬时能耗，可以使用基于利用率读数的整体指标来估计值。
本备忘录中描述的基准测试活动仅限于在实验室环境中使用受控刺激对 DUT/SUT 进行技术表征，具有专用地址空间和上述部分中指定的约束。
基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。
此外，基准测试是在“黑盒”基础上执行的，仅依赖于 DUT/SUT 外部可观察到的测量值。
DUT/SUT 中不应存在专门用于基准测试的特殊功能。DUT/SUT 对网络安全的任何影响在实验室和生产网络中应该是相同的。
本文档不需要任何 IANA 操作。
[]ETSI, "Network Function Virtualization: Performance & Portability Best Practices", ETSI GS NFV-PER 001, V1.1.2, December 2014.[] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.[] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc-editor.org/info/rfc2544>.[] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689, DOI 10.17487/RFC4689, October 2006, <http://www.rfc-editor.org/info/rfc4689>.[] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <http://www.rfc-editor.org/info/rfc4737>.[] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <http://www.rfc-editor.org/info/rfc7498>.[] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[Approved_ETSI_NFV] ETSI, Network Functions Virtualisation Technical Committee, "ETSI NFV", <http://www.etsi.org/standards-search>.[BareMetal] Popek, G. and R. Goldberg, "Formal requirements for virtualizable third generation architectures", Communications of the ACM, Volume 17, Issue 7, Pages 412-421, DOI 10.1145/361011.361073, July 1974.[Draft_ETSI_NFV] ETSI, "Network Functions Virtualisation: Specifications", <http://www.etsi.org/technologies-clusters/technologies/nfv>.[IPMI2.0] Intel Corporation, Hewlett-Packard Company, NEC Corporation, and Dell Inc., "Intelligent Platform Management Interface Specification v2.0 (with latest errata)", April 2015, <http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/ipmi-intelligent-platform-mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf>.[NFVIaas-FRAMEWORK] Krishnan, R., Figueira, N., Krishnaswamy, D., Lopez, D., Wright, S., Hinrichs, T., Krishnaswamy, R., and A. Yerra, "NFVIaaS Architectural Framework for Policy Based Resource Placement and Scheduling", Work in Progress, draft-krishnan-nfvrg-policy-based-rm-nfviaas-06, March 2016.[OPNFV-BENCHMARK] Tahhan, M., O'Mahony, B., and A. Morton, "Benchmarking Virtual Switches in OPNFV", Work in Progress, draft-ietf-bmwg-vswitch-opnfv-04, June 2017.[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, March 2009, <http://www.rfc-editor.org/info/rfc5481>.[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <http://www.rfc-editor.org/info/rfc6049>.[SDN-BENCHMARK] Vengainathan, B., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Terminology for Benchmarking SDN Controller Performance", Work in Progress, draft-ietf-bmwg-sdn-controller-benchmark-term-04, June 2017.[X3.102] ANSI, "Information Systems - Data Communication Systems and Services - User-Oriented Performance Parameters Communications Framework", ANSI X3.102, 1983.
感谢 2013 年 11 月与 Mukhtiar Shaikh 和 Ramki Krishnan 就该主题进行的令人鼓舞的对话。Bhavani Parise 和 Ilya Varlashkin 为扩展这些考虑提供了有用的建议。Bhuvaneswaran Vengainathan 已经在 SDN 控制器文档中尝试了 3×3 矩阵，并参与了许多讨论。Scott Bradner 在早期的 vSwitch 测量提案中迅速指出了共享资源依赖关系，并且该主题作为关键考虑因素包含在此处。在 IETF 92 的 BMWG 会议之后，Barry Constantine 的评论鼓励了进一步的发展：会议本身就是对这份备忘录的肯定。Maryam Tahhan、Marius Georgescu、Jacob Rapp、Saurabh Chattopadhyay 等人做出了许多有趣的贡献。