[要約] RFC 8172は、仮想ネットワーク機能（VNF）とそのインフラストラクチャのベンチマークに関する考慮事項を提供する。このRFCの目的は、VNFとそのインフラストラクチャのパフォーマンス評価を向上させるためのガイドラインを提供することである。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 8172 AT&T Labs
Category: Informational July 2017
ISSN: 2070-1721
Considerations for Benchmarking Virtual Network Functions and Their Infrastructure
仮想ネットワーク機能とそのインフラストラクチャのベンチマークに関する考慮事項
Abstract
概要
The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware.
ベンチマーキング手法ワーキンググループは、伝統的に、インターネットワーキング機能の専用の物理的実装の実験室特性評価を実施してきました。このメモは、ネットワーク機能が仮想化され、汎用ハードウェアで実行される場合の追加の考慮事項を調査します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8172.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8172で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Considerations for Hardware and Testing . . . . . . . . . . . 4
3.1. Hardware Components . . . . . . . . . . . . . . . . . . . 4
3.2. Configuration Parameters . . . . . . . . . . . . . . . . 5
3.3. Testing Strategies . . . . . . . . . . . . . . . . . . . 6
3.4. Attention to Shared Resources . . . . . . . . . . . . . . 7
4. Benchmarking Considerations . . . . . . . . . . . . . . . . . 8
4.1. Comparison with Physical Network Functions . . . . . . . 8
4.2. Continued Emphasis on Black-Box Benchmarks . . . . . . . 8
4.3. New Benchmarks and Related Metrics . . . . . . . . . . . 9
4.4. Assessment of Benchmark Coverage . . . . . . . . . . . . 10
4.5. Power Consumption . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The Benchmarking Methodology Working Group (BMWG) has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions (or physical network functions (PNFs)). The black-box benchmarks of throughput, latency, forwarding rates, and others have served our industry for many years. [RFC1242] and [RFC2544] are the cornerstones of the work.
Benchmarking Methodology Working Group（BMWG）は伝統的に、インターネットワーキング機能（または物理ネットワーク機能（PNF））の専用物理実装の実験室特性評価を実施してきました。スループット、レイテンシ、転送速度などのブラックボックスベンチマークは、長年にわたって私たちの業界に貢献してきました。 [RFC1242]と[RFC2544]はこの作品の基礎です。
A set of service provider and vendor development goals has emerged: reduce costs while increasing flexibility of network devices and drastically reduce deployment time. Network Function Virtualization (NFV) has the promise to achieve these goals and therefore has garnered much attention. It now seems certain that some network functions will be virtualized following the success of cloud computing and virtual desktops supported by sufficient network path capacity, performance, and widespread deployment; many of the same techniques will help achieve NFV.
サービスプロバイダーとベンダーの一連の開発目標が明らかになりました。ネットワークデバイスの柔軟性を高めながらコストを削減し、展開時間を大幅に削減します。ネットワーク機能仮想化（NFV）は、これらの目標を達成することを約束しているため、多くの注目を集めています。十分なネットワークパスキャパシティ、パフォーマンス、および広範な展開によってサポートされるクラウドコンピューティングおよび仮想デスクトップの成功に続いて、一部のネットワーク機能が仮想化されることが今や確実になっています。同じ手法の多くは、NFVの達成に役立ちます。
In the context of Virtual Network Functions (VNFs), the supporting Infrastructure requires general-purpose computing systems, storage systems, networking systems, virtualization support systems (such as hypervisors), and management systems for the virtual and physical resources. There will be many potential suppliers of Infrastructure systems and significant flexibility in configuring the systems for best performance. There are also many potential suppliers of VNFs, adding to the combinations possible in this environment. The separation of hardware and software suppliers has a profound implication on benchmarking activities: much more of the internal configuration of the black-box Device Under Test (DUT) must now be specified and reported with the results, to foster both repeatability and comparison testing at a later time.
仮想ネットワーク機能（VNF）のコンテキストでは、サポートするインフラストラクチャには、汎用コンピューティングシステム、ストレージシステム、ネットワークシステム、仮想化サポートシステム（ハイパーバイザーなど）、および仮想リソースと物理リソースの管理システムが必要です。インフラストラクチャシステムの潜在的なサプライヤが多数存在し、最高のパフォーマンスを得るためにシステムを構成する際に大きな柔軟性がもたらされます。この環境で可能な組み合わせに加えて、VNFの潜在的なサプライヤーも多数あります。ハードウェアサプライヤーとソフトウェアサプライヤーの分離は、ベンチマークアクティビティに大きな影響を与えます。ブラックボックステスト対象デバイス（DUT）の内部構成の多くを指定し、結果とともに報告する必要があります。後で。
Consider the following user story as further background and motivation:
さらなる背景と動機として、次のユーザーストーリーを検討してください。
I'm designing and building my NFV Infrastructure platform. The first steps were easy because I had a small number of categories of VNFs to support and the VNF vendor gave hardware recommendations that I followed. Now I need to deploy more VNFs from new vendors, and there are different hardware recommendations. How well will the new VNFs perform on my existing hardware? Which among several new VNFs in a given category are most efficient in terms of capacity they deliver? And, when I operate multiple categories of VNFs (and PNFs) *concurrently* on a hardware platform such that they share resources, what are the new performance limits, and what are the software design choices I can make to optimize my chosen hardware platform? Conversely, what hardware platform upgrades should I pursue to increase the capacity of these concurrently operating VNFs?
私はNFVインフラストラクチャプラットフォームを設計および構築しています。サポートするVNFのカテゴリが少数であり、VNFベンダーが私が従ったハードウェアの推奨事項を提供していたので、最初のステップは簡単でした。今、私は新しいベンダーからより多くのVNFを展開する必要があり、さまざまなハードウェアの推奨事項があります。新しいVNFは既存のハードウェアでどの程度うまく機能しますか？特定のカテゴリのいくつかの新しいVNFのうち、提供する容量の点で最も効率的なのはどれですか。また、ハードウェアプラットフォームで複数のカテゴリのVNF（およびPNF）を*同時に*操作して、リソースを共有する場合、新しいパフォーマンスの制限は何か、選択したハードウェアプラットフォームを最適化するためにソフトウェア設計でどのような選択ができるか？逆に、これらの同時に動作するVNFの容量を増やすには、どのようなハードウェアプラットフォームのアップグレードを行う必要がありますか？
See <http://www.etsi.org/technologies-clusters/technologies/nfv> for more background; the white papers there may be a useful starting place. The "NFV Performance & Portability Best Practices" document [NFV.PER001] is particularly relevant to BMWG. There are also documents available among the Approved ETSI NFV Specifications [Approved_ETSI_NFV], including documents describing Infrastructure performance aspects and service quality metrics, and drafts in the ETSI NFV Open Area [Draft_ETSI_NFV], which may also have relevance to benchmarking.
詳細については、<http://www.etsi.org/technologies-clusters/technologies/nfv>を参照してください。そこにあるホワイトペーパーは、有用な出発点になるかもしれません。 「NFVパフォーマンスと移植性のベストプラクティス」ドキュメント[NFV.PER001]は特にBMWGに関連しています。承認されたETSI NFV仕様[Approved_ETSI_NFV]には、インフラストラクチャのパフォーマンスの側面とサービス品質の指標を説明するドキュメント、およびETSI NFVオープンエリア[Draft_ETSI_NFV]のドラフトも含まれます。これらもベンチマークと関連がある場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
At the time of this writing, BMWG is considering the new topic of Virtual Network Functions and related Infrastructure to ensure that common issues are recognized from the start; background materials from respective standards development organizations and Open Source development projects (e.g., IETF, ETSI NFV, and the Open Platform for Network Function Virtualization (OPNFV)) are being used.
この記事の執筆時点では、BMWGは仮想ネットワーク機能と関連インフラストラクチャの新しいトピックを検討しており、共通の問題が最初から認識されるようにしています。それぞれの標準開発組織およびオープンソース開発プロジェクト（IETF、ETSI NFV、ネットワーク機能仮想化（OPNFV）などのオープンプラットフォーム）からの背景資料が使用されています。
This memo investigates additional methodological considerations necessary when benchmarking VNFs instantiated and hosted in general-purpose hardware, using bare metal hypervisors [BareMetal] or other isolation environments such as Linux containers. An essential consideration is benchmarking physical and Virtual Network Functions in the same way when possible, thereby allowing direct comparison. Benchmarking combinations of physical and virtual devices and functions in a System Under Test (SUT) is another topic of keen interest.
このメモは、ベアメタルハイパーバイザー[BareMetal]またはLinuxコンテナーなどの他の分離環境を使用して、インスタンス化され、汎用ハードウェアでホストされているVNFをベンチマークする際に必要な追加の方法論的な考慮事項を調査します。重要な考慮事項は、物理ネットワーク機能と仮想ネットワーク機能を可能な限り同じ方法でベンチマークすることにより、直接比較できるようにすることです。テスト対象システム（SUT）での物理デバイスと仮想デバイスおよび機能の組み合わせのベンチマークは、非常に興味深いトピックです。
A clearly related goal is investigating benchmarks for the capacity of a general-purpose platform to host a plurality of VNF instances. Existing networking technology benchmarks will also be considered for adaptation to NFV and closely associated technologies.
明確に関連する目標は、複数のVNFインスタンスをホストする汎用プラットフォームの容量のベンチマークを調査することです。既存のネットワーキングテクノロジーベンチマークも、NFVおよび密接に関連するテクノロジーへの適応について検討されます。
A non-goal is any overlap with traditional computer benchmark development and their specific metrics (e.g., SPECmark suites such as SPEC CPU).
非目標とは、従来のコンピューターベンチマークの開発とその特定のメトリック（SPEC CPUなどのSPECmarkスイート）との重複です。
A continued non-goal is any form of architecture development related to NFV and associated technologies in BMWG, consistent with all chartered work since BMWG began in 1989.
継続的な非目標とは、BMWGにおけるNFVおよび関連技術に関連するアーキテクチャ開発のあらゆる形態であり、BMWGが1989年に開始して以来のすべてのチャーターされた作業と一致しています。
This section lists the new considerations that must be addressed to benchmark VNF(s) and their supporting Infrastructure. The SUT is composed of the hardware platform components, the VNFs installed, and many other supporting systems. It is critical to document all aspects of the SUT to foster repeatability.
このセクションでは、VNFとそれらをサポートするインフラストラクチャをベンチマークするために対処する必要がある新しい考慮事項を示します。 SUTは、ハードウェアプラットフォームコンポーネント、インストールされているVNF、およびその他の多くのサポートシステムで構成されています。再現性を高めるには、SUTのすべての側面を文書化することが重要です。
The following new hardware components will become part of the test setup:
次の新しいハードウェアコンポーネントがテストセットアップの一部になります。
1. High-volume server platforms (general-purpose, possibly with virtual technology enhancements)
1. 大量のサーバープラットフォーム（汎用、場合によっては仮想テクノロジが強化されたもの）
2. Storage systems with large capacity, high speed, and high reliability
2. 大容量、高速、高信頼性のストレージシステム
3. Network interface ports specially designed for efficient service of many virtual Network Interface Cards (NICs)
3. 多くの仮想ネットワークインターフェイスカード（NIC）の効率的なサービスのために特別に設計されたネットワークインターフェイスポート
4. High-capacity Ethernet switches
4. 大容量イーサネットスイッチ
The components above are subjects for development of specialized benchmarks that focus on the special demands of network function deployment.
上記のコンポーネントは、ネットワーク機能の展開の特別な要求に焦点を当てた特別なベンチマークの開発の対象です。
Labs conducting comparisons of different VNFs may be able to use the same hardware platform over many studies, until the steady march of innovations overtakes their capabilities (as happens with the lab's traffic generation and testing devices today).
さまざまなVNFの比較を行うラボは、イノベーションの着実な進歩が機能を追い抜くまで、今日のラボのトラフィック生成およびテストデバイスで発生するように、多くの研究にわたって同じハードウェアプラットフォームを使用できる場合があります。
It will be necessary to configure and document the settings for the entire general-purpose platform to ensure repeatability and foster future comparisons, including, but clearly not limited to, the following:
汎用プラットフォーム全体の設定を構成および文書化して、再現性を確保し、以下を含むがこれに限定されない将来の比較を促進する必要があります。
o number of server blades (shelf occupation)
o サーバーブレードの数（シェルフ占有）
o CPUs
o CPU
o caches
o キャッシュ
o memory
o 記憶
o storage system
o ストレージシステム
o I/O
o Η/Ο
as well as configurations that support the devices that host the VNF itself:
また、VNF自体をホストするデバイスをサポートする構成：
o Hypervisor (or other forms of virtual function hosting)
o ハイパーバイザー（または他の形式の仮想機能ホスティング）
o Virtual Machine (VM)
o 仮想マシン（VM）
o Infrastructure virtual network (which interconnects virtual machines with physical network interfaces or with each other through virtual switches, for example)
o インフラストラクチャ仮想ネットワーク（たとえば、仮想マシンを物理ネットワークインターフェイスと相互接続するか、仮想スイッチを介して相互に接続します）
and finally, the VNF itself, with items such as:
そして最後に、VNF自体には次のような項目があります。
o specific function being implemented in VNF
o VNFに実装されている特定の機能
o reserved resources for each function (e.g., CPU pinning and Non-Uniform Memory Access (NUMA) node assignment)
o 各機能用に予約されたリソース（CPUピニング、Non-Uniform Memory Access（NUMA）ノードの割り当てなど）
o number of VNFs (or sub-VNF components, each with its own VM) in the service function chain (see Section 1.1 of [RFC7498] for a definition of service function chain)
o サービス機能チェーン内のVNF（またはそれぞれが独自のVMを持つサブVNFコンポーネント）の数（サービス機能チェーンの定義については、[RFC7498]のセクション1.1を参照してください）
o number of physical interfaces and links transited in the service function chain
o サービス機能チェーンで通過した物理インターフェースとリンクの数
In the physical device benchmarking context, most of the corresponding Infrastructure configuration choices were determined by the vendor. Although the platform itself is now one of the configuration variables, it is important to maintain emphasis on the networking benchmarks and capture the platform variables as input factors.
物理デバイスのベンチマークのコンテキストでは、対応するインフラストラクチャ構成の選択のほとんどはベンダーによって決定されました。現在、プラットフォーム自体が構成変数の1つになっていますが、ネットワーキングベンチマークに重点を置き、プラットフォーム変数を入力要素として取り込むことが重要です。
The concept of characterizing performance at capacity limits may change. For example:
容量制限でのパフォーマンスの特徴付けの概念は変更される場合があります。例えば：
1. It may be more representative of system capacity to characterize the case where the VMs hosting the VNFs are operating at 50% utilization and therefore sharing the "real" processing power across many VMs.
1. VNFをホストしているVMが50％の使用率で動作しているため、多くのVM間で「実際の」処理能力を共有している場合を特徴づけると、システム容量をより表すことができます。
2. Another important test case stems from the need to partition (or isolate) network functions. A noisy neighbor (VM hosting a VNF in an infinite loop) would ideally be isolated; the performance of other VMs would continue according to their specifications, and tests would evaluate the degree of isolation.
2. もう1つの重要なテストケースは、ネットワーク機能を分割（または分離）する必要から生じます。ノイズの多いネイバー（無限ループでVNFをホストするVM）は分離するのが理想的です。他のVMのパフォーマンスはそれらの仕様に従って続行され、テストでは分離の程度が評価されます。
3. System errors will likely occur as transients, implying a distribution of performance characteristics with a long tail (like latency) and leading to the need for longer-term tests of each set of configuration and test parameters.
3. システムエラーは一時的なものとして発生する可能性が高く、長いテール（レイテンシなど）のあるパフォーマンス特性の分布を意味し、構成とテストパラメーターの各セットの長期テストが必要になります。
4. The desire for elasticity and flexibility among network functions will include tests where there is constant flux in the number of VM instances, the resources the VMs require, and the setup/ teardown of network paths that support VM connectivity. Requests for and instantiation of new VMs, along with releases for VMs hosting VNFs that are no longer needed, would be a normal operational condition. In other words, benchmarking should include scenarios with production life-cycle management of VMs and their VNFs and network connectivity in progress, including VNF scaling up/down operations, as well as static configurations.
4.ネットワーク機能間の弾力性と柔軟性に対する要望には、VMインスタンスの数、VMが必要とするリソース、およびVM接続をサポートするネットワークパスのセットアップ/ティアダウンに一定のフラックスがあるテストが含まれます。新しいVMの要求とインスタンス化、および不要になったVNFをホストしているVMのリリースは、通常の運用条件です。つまり、ベンチマークには、VMとそのVNFの運用ライフサイクル管理、および進行中のネットワーク接続（VNFのスケールアップ/ダウン操作や静的構成など）のシナリオを含める必要があります。
5. All physical things can fail, and benchmarking efforts can also examine recovery aided by the virtual architecture with different approaches to resiliency.
5. すべての物理的な障害が発生する可能性があり、ベンチマークの取り組みでは、復元力に対するさまざまなアプローチを使用して、仮想アーキテクチャによって支援されるリカバリを調査することもできます。
6. The sheer number of test conditions and configuration combinations encourage increased efficiency, including automated testing arrangements, combination sub-sampling through an understanding of inter-relationships, and machine-readable test results.
6. 膨大な数のテスト条件と構成の組み合わせにより、自動テスト配置、相互関係の理解によるサブサンプリングの組み合わせ、機械可読テスト結果など、効率の向上が促進されます。
Since many components of the new NFV Infrastructure are virtual, test setup design must have prior knowledge of interactions/dependencies within the various resource domains in the SUT. For example, a virtual machine performing the role of a traditional tester function, such as generating and/or receiving traffic, should avoid sharing any SUT resources with the DUT. Otherwise, the results will have unexpected dependencies not encountered in physical device benchmarking.
新しいNFVインフラストラクチャの多くのコンポーネントは仮想であるため、テストセットアップの設計には、SUTのさまざまなリソースドメイン内の相互作用/依存関係に関する事前の知識が必要です。たとえば、トラフィックの生成や受信など、従来のテスター機能の役割を実行する仮想マシンは、SUTリソースをDUTと共有しないでください。そうしないと、物理デバイスのベンチマークで発生しない予期しない依存関係が結果に生じます。
Note that the term "tester" has traditionally referred to devices dedicated to testing in BMWG literature. In this new context, "tester" additionally refers to functions dedicated to testing, which may be either virtual or physical. "Tester" has never referred to the individuals performing the tests.
「テスター」という用語は、伝統的にBMWGの文献でテスト専用のデバイスを指していることに注意してください。この新しいコンテキストでは、「テスター」はさらに、仮想または物理的なテスト専用の機能を指します。 「テスター」は、テストを実行する個人に言及したことがありません。
The possibility to use shared resources in test design while producing useful results remains one of the critical challenges to overcome. Benchmarking setups may designate isolated resources for the DUT and other critical support components (such as the host/ kernel) as the first baseline step and add other loading processes. The added complexity of each setup leads to shared-resource testing scenarios, where the characteristics of the competing load (in terms of memory, storage, and CPU utilization) will directly affect the benchmarking results (and variability of the results), but the results should reconcile with the baseline.
テスト設計で共有リソースを使用しながら、有用な結果を生成する可能性は、克服すべき重要な課題の1つのままです。ベンチマークセットアップでは、DUTおよびその他の重要なサポートコンポーネント（ホスト/カーネルなど）の分離されたリソースを最初のベースラインステップとして指定し、他の読み込みプロセスを追加できます。各セットアップの複雑さが増すと、共有リソースのテストシナリオが発生します。このシナリオでは、競合する負荷の特性（メモリ、ストレージ、およびCPU使用率に関する）がベンチマーク結果（および結果の変動性）に直接影響しますが、結果はベースラインと一致するはずです。
The physical test device remains a solid foundation to compare with results using combinations of physical and virtual test functions or results using only virtual testers when necessary to assess virtual interfaces and other virtual functions.
物理テストデバイスは、物理インターフェイスと他の仮想機能を評価する必要がある場合に、物理テスト機能と仮想テスト機能の組み合わせを使用した結果、または仮想テスターのみを使用した結果と比較するための強固な基盤です。
This section discusses considerations related to benchmarks applicable to VNFs and their associated technologies.
このセクションでは、VNFとその関連テクノロジに適用可能なベンチマークに関連する考慮事項について説明します。
In order to compare the performance of VNFs and system implementations with their physical counterparts, identical benchmarks must be used. Since BMWG has already developed specifications for many network functions, there will be re-use of existing benchmarks through references, while allowing for the possibility of benchmark curation during development of new methodologies. Consideration should be given to quantifying the number of parallel VNFs required to achieve comparable scale/capacity with a given physical device or whether some limit of scale was reached before the VNFs could achieve the comparable level. Again, implementation based on different hypervisors or other virtual function hosting remain as critical factors in performance assessment.
VNFとシステム実装のパフォーマンスを対応する物理モデルと比較するには、同一のベンチマークを使用する必要があります。 BMWGはすでに多くのネットワーク機能の仕様を開発しているため、新しい方法論の開発中にベンチマークのキュレーションの可能性を考慮しながら、リファレンスを通じて既存のベンチマークを再利用します。特定の物理デバイスで同等のスケール/容量を実現するために必要な並列VNFの数を定量化するか、またはVNFが同等のレベルを達成する前にスケールの制限に達したかどうかを考慮する必要があります。この場合も、さまざまなハイパーバイザーまたは他の仮想機能ホスティングに基づく実装は、パフォーマンス評価の重要な要素として残っています。
When the network functions under test are based on open-source code, there may be a tendency to rely on internal measurements to some extent, especially when the externally observable phenomena only support an inference of internal events (such as routing protocol convergence observed in the data plane). Examples include CPU/Core utilization, network utilization, storage utilization, and memory committed/used. These "white-box" metrics provide one view of the resource footprint of a VNF. Note that the resource utilization metrics do not easily match the 3x4 Matrix, described in Section 4.4.
テスト対象のネットワーク機能がオープンソースコードに基づいている場合、特に外部で観測可能な現象が内部イベントの推論のみをサポートする場合（ルーティングプロトコルの収束など）データプレーン）。例には、CPU /コア使用率、ネットワーク使用率、ストレージ使用率、およびコミット/使用されたメモリが含まれます。これらの「ホワイトボックス」メトリックは、VNFのリソースフットプリントの1つのビューを提供します。セクション4.4で説明されているように、リソース使用率メトリックは3x4マトリックスと簡単には一致しません。
However, external observations remain essential as the basis for benchmarks. Internal observations with fixed specification and interpretation may be provided in parallel (as auxiliary metrics), to assist the development of operations procedures when the technology is deployed, for example. Internal metrics and measurements from open-source implementations may be the only direct source of performance results in a desired dimension, but corroborating external observations are still required to assure the integrity of measurement discipline was maintained for all reported results.
ただし、ベンチマークの基礎として外部からの観察は依然として重要です。たとえば、技術が展開されている場合の運用手順の開発を支援するために、固定された仕様と解釈を伴う内部観察を（補助メトリックとして）並行して提供できます。オープンソース実装からの内部メトリックスと測定値が、目的のディメンションにおけるパフォーマンス結果の直接の唯一のソースである場合がありますが、報告されたすべての結果について測定分野の整合性が維持されていることを保証するために、確固たる外部観察が依然として必要です。
A related aspect of benchmark development is where the scope includes multiple approaches to a common function under the same benchmark. For example, there are many ways to arrange for activation of a network path between interface points, and the activation times can be compared if the start-to-stop activation interval has a generic and unambiguous definition. Thus, generic benchmark definitions are preferred over technology/protocol-specific definitions where possible.
ベンチマーク開発の関連する側面は、スコープに同じベンチマークでの共通機能への複数のアプローチが含まれる場合です。たとえば、インターフェイスポイント間のネットワークパスのアクティブ化を調整する多くの方法があり、開始と停止のアクティブ化間隔に一般的で明確な定義がある場合、アクティブ化時間を比較できます。したがって、可能であれば、テクノロジー/プロトコル固有の定義よりも一般的なベンチマーク定義が優先されます。
There will be new classes of benchmarks needed for network design and assistance when developing operational practices (possibly automated management and orchestration of deployment scale). Examples follow in the paragraphs below, many of which are prompted by the goals of increased elasticity and flexibility of the network functions, along with reduced deployment times.
ネットワークの設計と運用プラクティスの開発時の支援（おそらく自動管理と展開規模の調整）に必要な新しいクラスのベンチマークが存在します。以下の段落で例を示します。その多くは、ネットワーク機能の弾力性と柔軟性の向上と、展開時間の短縮という目標によって促進されます。
o Time to deploy VNFs: In cases where the general-purpose hardware is already deployed and ready for service, it is valuable to know the response time when a management system is tasked with "standing up" 100s of virtual machines and the VNFs they will host.
o VNFを展開する時間：汎用ハードウェアがすでに展開されており、サービスの準備ができている場合、管理システムが数百の仮想マシンとそれらがホストするVNFを「立ち上げる」という任務を課されたときの応答時間を知ることは貴重です。 。
o Time to migrate VNFs: In cases where a rack or shelf of hardware must be removed from active service, it is valuable to know the response time when a management system is tasked with "migrating" some number of virtual machines and the VNFs they currently host to alternate hardware that will remain in service.
o VNFを移行する時間：ハードウェアのラックまたはシェルフをアクティブなサービスから削除する必要がある場合、管理システムがいくつかの仮想マシンとそれらが現在ホストしているVNFの「移行」を課せられたときの応答時間を知ることは貴重です。サービスを継続する代替ハードウェアに。
o Time to create a virtual network in the general-purpose Infrastructure: This is a somewhat simplified version of existing benchmarks for convergence time, in that the process is initiated by a request from (centralized or distributed) control, rather than inferred from network events (link failure). The successful response time would remain dependent on data-plane observations to confirm that the network is ready to perform.
o 汎用インフラストラクチャで仮想ネットワークを作成する時間：これは収束時間の既存のベンチマークのやや簡略化されたバージョンであり、プロセスはネットワークイベントから推論されるのではなく（集中または分散）制御からの要求によって開始されます（リンク障害）。正常な応答時間は、ネットワークが実行する準備ができていることを確認するためのデータプレーンの観測に依存したままになります。
o Effect of verification measurements on performance: A complete VNF, or something as simple as a new policy to implement in a VNF, is implemented. The action to verify instantiation of the VNF or policy could affect performance during normal operation.
o パフォーマンスに対する検証測定の影響：完全なVNF、またはVNFに実装する新しいポリシーのような単純なものが実装されます。 VNFまたはポリシーのインスタンス化を検証するアクションは、通常の動作中のパフォーマンスに影響を与える可能性があります。
Also, it appears to be valuable to measure traditional packet transfer performance metrics during the assessment of traditional and new benchmarks, including metrics that may be used to support service engineering such as the spatial composition metrics found in [RFC6049]. Examples include mean one-way delay in Section 4.1 of [RFC6049], Packet Delay Variation (PDV) in [RFC5481], and Packet Reordering [RFC4737] [RFC4689].
また、[RFC6049]にある空間構成メトリックなどのサービスエンジニアリングをサポートするために使用できるメトリックを含む、従来のベンチマークと新しいベンチマークの評価中に、従来のパケット転送パフォーマンスメトリックを測定することは価値があるようです。例には、[RFC6049]のセクション4.1の平均一方向遅延、[RFC5481]のパケット遅延変動（PDV）、パケットの並べ替え[RFC4737] [RFC4689]が含まれます。
It can be useful to organize benchmarks according to their applicable life-cycle stage and the performance criteria they were designed to assess. The table below (derived from [X3.102]) provides a way to organize benchmarks such that there is a clear indication of coverage for the intersection of life-cycle stages and performance criteria.
適用可能なライフサイクルの段階と評価のために設計されたパフォーマンス基準に従ってベンチマークを整理すると便利です。以下の表（[X3.102]から派生）は、ライフサイクルステージとパフォーマンス基準の共通部分のカバレッジを明確に示すようにベンチマークを整理する方法を提供します。
|----------------------------------------------------------|
| | | | |
| | SPEED | ACCURACY | RELIABILITY |
| | | | |
|----------------------------------------------------------|
| | | | |
| Activation | | | |
| | | | |
|----------------------------------------------------------|
| | | | |
| Operation | | | |
| | | | |
|----------------------------------------------------------|
| | | | |
| De-activation | | | |
| | | | |
|----------------------------------------------------------|
For example, the "Time to deploy VNFs" benchmark described above would be placed in the intersection of Activation and Speed, making it clear that there are other potential performance criteria to benchmark, such as the "percentage of unsuccessful VM/VNF stand-ups" in a set of 100 attempts. This example emphasizes that the Activation and De-activation life-cycle stages are key areas for NFV and related Infrastructure and encourages expansion beyond traditional benchmarks for normal operation. Thus, reviewing the benchmark coverage using this table (sometimes called the 3x3 Matrix) can be a worthwhile exercise in BMWG.
たとえば、上記の「VNFをデプロイする時間」のベンチマークは、アクティベーションと速度の交差点に配置され、「失敗したVM / VNFスタンドアップのパーセンテージ"100回の試行のセット。この例では、アクティブ化と非アクティブ化のライフサイクルステージがNFVと関連するインフラストラクチャの主要な領域であることを強調し、通常の操作の従来のベンチマークを超えた拡張を促進します。したがって、このテーブル（3x3マトリックスと呼ばれることもあります）を使用してベンチマークカバレッジを確認することは、BMWGで価値のある練習になる可能性があります。
In one of the first applications of the 3x3 Matrix in BMWG [SDN-BENCHMARK], we discovered that metrics on measured size, capacity, or scale do not easily match one of the three columns above. Following discussion, this was resolved in two ways:
BMWGの3x3マトリックスの最初のアプリケーションの1つ[SDN-BENCHMARK]で、測定されたサイズ、容量、またはスケールのメトリックが、上記の3つの列の1つと簡単には一致しないことを発見しました。議論の結果、これは2つの方法で解決されました。
o Add a column, Scale, for use when categorizing and assessing the coverage of benchmarks (without measured results). An example of this use is found in [OPNFV-BENCHMARK] (and a variation may be found in [SDN-BENCHMARK]). This is the 3x4 Matrix.
o （測定結果なしで）ベンチマークのカバレッジを分類および評価するときに使用する列、Scaleを追加します。この使用例は[OPNFV-BENCHMARK]にあります（バリエーションは[SDN-BENCHMARK]にあります）。これは3x4マトリックスです。
o If using the matrix to report results in an organized way, keep size, capacity, and scale metrics separate from the 3x3 Matrix and incorporate them in the report with other qualifications of the results.
o マトリックスを使用して整理された方法で結果を報告する場合は、サイズ、容量、およびスケールメトリックを3x3マトリックスから分離し、結果の他の修飾と一緒にレポートに組み込みます。
Note that the resource utilization (e.g., CPU) metrics do not fit in the matrix. They are not benchmarks, and omitting them confirms their status as auxiliary metrics. Resource assignments are configuration parameters, and these are reported separately.
リソース使用率（CPUなど）の指標がマトリックスに収まらないことに注意してください。それらはベンチマークではなく、それらを省略すると、それらのステータスが補助的なメトリックとして確認されます。リソース割り当ては構成パラメーターであり、これらは個別に報告されます。
This approach encourages use of the 3x3 Matrix to organize reports of results, where the capacity at which the various metrics were measured could be included in the title of the matrix (and results for multiple capacities would result in separate 3x3 Matrices, if there were sufficient measurements/results to organize in that way).
このアプローチでは、3x3マトリックスを使用して結果のレポートを整理し、さまざまなメトリックが測定された容量をマトリックスのタイトルに含めることができます（十分な場合、複数の容量の結果は別々の3x3マトリックスになります）そのように整理するための測定/結果）。
For example, results for each VM and VNF could appear in the 3x3 Matrix, organized to illustrate resource occupation (CPU Cores) in a particular physical computing system, as shown below.
たとえば、以下に示すように、各VMおよびVNFの結果は、特定の物理コンピューティングシステムでのリソース占有（CPUコア）を示すために編成された3x3マトリックスに表示されます。
VNF#1
.-----------.
|__|__|__|__|
Core 1 |__|__|__|__|
|__|__|__|__|
| | | | |
'-----------'
VNF#2
.-----------.
|__|__|__|__|
Cores 2-5 |__|__|__|__|
|__|__|__|__|
| | | | |
'-----------'
VNF#3 VNF#4 VNF#5
.-----------. .-----------. .-----------.
|__|__|__|__| |__|__|__|__| |__|__|__|__|
Core 6 |__|__|__|__| |__|__|__|__| |__|__|__|__|
|__|__|__|__| |__|__|__|__| |__|__|__|__|
| | | | | | | | | | | | | | |
'-----------' '-----------' '-----------'
VNF#6
.-----------.
|__|__|__|__|
Core 7 |__|__|__|__|
|__|__|__|__|
| | | | |
'-----------'
The combination of tables above could be built incrementally, beginning with VNF#1 and one Core, then adding VNFs according to their supporting Core assignments. X-Y plots of critical benchmarks would also provide insight to the effect of increased hardware utilization. All VNFs might be of the same type, or to match a production environment, there could be VNFs of multiple types and categories. In this figure, VNFs #3-#5 are assumed to require small CPU resources, while VNF#2 requires four Cores to perform its function.
上記の表の組み合わせは、VNF＃1と1つのコアから始めて、サポートするコアの割り当てに従ってVNFを追加して、段階的に構築することができます。重要なベンチマークのX-Yプロットも、ハードウェア使用率の増加の影響を洞察します。すべてのVNFが同じタイプである場合や、実稼働環境と一致させるために、複数のタイプおよびカテゴリのVNFが存在する場合があります。この図では、VNF＃3〜＃5は小さなCPUリソースを必要とすると想定されていますが、VNF＃2はその機能を実行するために4つのコアを必要とします。
Although there is incomplete work to benchmark physical network function power consumption in a meaningful way, the desire to measure the physical Infrastructure supporting the virtual functions only adds to the need. Both maximum power consumption and dynamic power consumption (with varying load) would be useful. The Intelligent Platform Management Interface (IPMI) standard [IPMI2.0] has been implemented by many manufacturers and supports measurement of instantaneous energy consumption.
物理ネットワーク機能の消費電力を意味のある方法でベンチマークする作業は不完全ですが、仮想機能をサポートする物理インフラストラクチャを測定したいという欲求は、ニーズに追加するだけです。最大電力消費と動的負荷（負荷が変動する）の両方が役立ちます。 Intelligent Platform Management Interface（IPMI）標準[IPMI2.0]は多くのメーカーによって実装されており、瞬間的なエネルギー消費の測定をサポートしています。
To assess the instantaneous energy consumption of virtual resources, it may be possible to estimate the value using an overall metric based on utilization readings, according to [NFVIaas-FRAMEWORK].
[NFVIaas-FRAMEWORK]によれば、仮想リソースの瞬間的なエネルギー消費を評価するために、使用率の測定値に基づいて全体的なメトリックを使用して値を推定することが可能な場合があります。
Benchmarking activities as described in this memo are limited to technology characterization of a DUT/SUT using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモで説明されているベンチマーク活動は、専用のアドレス空間と上記のセクションで指定された制約を使用して、実験環境で制御された刺激を使用したDUT / SUTの技術特性評価に限定されます。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUT / SUTの外部で観測可能な測定のみに依存します。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
特別な機能は、特にベンチマークの目的でDUT / SUTに存在すべきではありません。 DUT / SUTから生じるネットワークセキュリティへの影響は、ラボと本番ネットワークで同じである必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[NFV.PER001] ETSI, "Network Function Virtualization: Performance & Portability Best Practices", ETSI GS NFV-PER 001, V1.1.2, December 2014.
[NFV.PER001] ETSI、「ネットワーク機能の仮想化：パフォーマンスと移植性のベストプラクティス」、ETSI GS NFV-PER 001、V1.1.2、2014年12月。
[RFC2119] 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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2544] 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>.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク手法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<http://www.rfc-editor.org/info/rfc2544>。
[RFC4689] 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>.
[RFC4689] Poretsky、S.、Perser、J.、Erramilli、S。、およびS. Khurana、「ネットワーク層トラフィック制御メカニズムのベンチマークに関する用語」、RFC 4689、DOI 10.17487 / RFC4689、2006年10月、<http：/ /www.rfc-editor.org/info/rfc4689>。
[RFC4737] 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>.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<http：// www.rfc-editor.org/info/rfc4737>。
[RFC7498] 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>.
[RFC7498]クイン、P。、エド。 T.ナドー編、「サービス機能連鎖の問題ステートメント」、RFC 7498、DOI 10.17487 / RFC7498、2015年4月、<http://www.rfc-editor.org/info/rfc7498>。
[RFC8174] 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>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[Approved_ETSI_NFV] ETSI, Network Functions Virtualisation Technical Committee, "ETSI NFV", <http://www.etsi.org/standards-search>.
[Approved_ETSI_NFV] ETSI、ネットワーク機能仮想化技術委員会、「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.
[ベアメタル] Popek、G。およびR. Goldberg、「仮想化可能な第3世代アーキテクチャの正式な要件」、ACMの通信、第17巻、第7号、第412〜421ページ、DOI 10.1145 / 361011.361073、1974年7月。
[Draft_ETSI_NFV] ETSI, "Network Functions Virtualisation: Specifications", <http://www.etsi.org/technologies-clusters/technologies/ nfv>.
[Draft_ETSI_NFV] ETSI、「ネットワーク機能の仮想化：仕様」、<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>.
[IPMI2.0] Intel Corporation、Hewlett-Packard Company、NEC Corporation、およびDell Inc。、「Intelligent Platform Management Interface Specification v2.0（with latest errata）」、2015年4月、<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.
[NFVIaas-FRAMEWORK]クリシュナン、R。、フィゲイラ、N。、クリシュナスワミー、D。、ロペス、D。、ライト、S。、ヒンリヒス、T。、クリシュナスワミー、R。、およびA.イエラ、「NFVIaaS Architectural Framework forポリシーベースのリソースの配置とスケジュール」、進行中の作業、draft-krishnan-nfvrg-policy-based-rm-nfviaas-06、2016年3月。
[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.
[OPNFV-BENCHMARK] Tahhan、M.、O'Mahony、B。、およびA. Morton、「OPNFVでの仮想スイッチのベンチマーク」、作業中、draft-ietf-bmwg-vswitch-opnfv-04、2017年6月。
[RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, <http://www.rfc-editor.org/info/rfc1242>.
[RFC1242] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、DOI 10.17487 / RFC1242、1991年7月、<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>.
[RFC5481] Morton、A。およびB. Claise、「Packet Delay Variation Applicability Statement」、RFC 5481、DOI 10.17487 / RFC5481、2009年3月、<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>.
[RFC6049] Morton、A。およびE. Stephan、「メトリックの空間構成」、RFC 6049、DOI 10.17487 / RFC6049、2011年1月、<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.
[SDN-BENCHMARK] Vengainathan、B.、Basil、A.、Tassinari、M.、Manral、V。、およびS. Banks、「ベンチマークSDNコントローラーのパフォーマンスに関する用語」、進行中の作業、draft-ietf-bmwg-sdn -controller-benchmark-term-04、2017年6月。
[X3.102] ANSI, "Information Systems - Data Communication Systems and Services - User-Oriented Performance Parameters Communications Framework", ANSI X3.102, 1983.
[X3.102] ANSI、「情報システム-データ通信システムとサービス-ユーザー指向のパフォーマンスパラメータ通信フレームワーク」、ANSI X3.102、1983。
Acknowledgements
謝辞
The author acknowledges an encouraging conversation on this topic with Mukhtiar Shaikh and Ramki Krishnan in November 2013. Bhavani Parise and Ilya Varlashkin have provided useful suggestions to expand these considerations. Bhuvaneswaran Vengainathan has already tried the 3x3 Matrix with the SDN controller document and contributed to many discussions. Scott Bradner quickly pointed out shared resource dependencies in an early vSwitch measurement proposal, and the topic was included here as a key consideration. Further development was encouraged by Barry Constantine's comments following the BMWG session at IETF 92: the session itself was an affirmation for this memo. There have been many interesting contributions from Maryam Tahhan, Marius Georgescu, Jacob Rapp, Saurabh Chattopadhyay, and others.
著者は、2013年11月にこのトピックに関するMukhtiar ShaikhとRamki Krishnanとの励ましの会話を認めています。BhavaniPariseとIlya Varlashkinは、これらの考慮事項を拡張するための有用な提案を提供しました。 Bhuvaneswaran Vengainathanは、SDNコントローラーのドキュメントを含む3x3マトリックスを既に試し、多くの議論に貢献しています。 Scott Bradnerは、初期のvSwitch測定提案で共有リソースの依存関係をすぐに指摘し、このトピックは重要な考慮事項としてここに含まれていました。 IETF 92でのBMWGセッションに続くバリーコンスタンティンのコメントによって、さらなる発展が促されました。セッション自体がこのメモの肯定でした。 Maryam Tahhan、Marius Georgescu、Jacob Rapp、Saurabh Chattopadhyayなどから多くの興味深い貢献がありました。
Author's Address
著者のアドレス
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com