[要約] RFC 8568は、ネットワーク仮想化の研究課題に関する情報を提供するものであり、ネットワーク仮想化の現状と将来の課題を要約しています。目的は、ネットワーク仮想化の研究者や開発者に対して、課題を理解し、解決策を見つけるための指針を提供することです。
Internet Research Task Force (IRTF) CJ. Bernardos
Request for Comments: 8568 UC3M
Category: Informational A. Rahman
ISSN: 2070-1721 InterDigital
JC. Zuniga
SIGFOX
LM. Contreras
TID
P. Aranda
UC3M
P. Lynch
Keysight Technologies
April 2019
Network Virtualization Research Challenges
ネットワーク仮想化研究の課題
Abstract
概要
This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG).
このドキュメントでは、ネットワーク仮想化に関するオープンリサーチの課題について説明します。ネットワーク仮想化は、以前にクラウドコンピューティングが採用していたのと同様の方法で進んでいます。具体的には、クラウドコンピューティングは、ローカルの専用の物理リソースからインターネットを介してアクセス可能なリモートの仮想機能へのコンピューティング機能（アプリケーションなど）およびストレージの移行を普及させました。同様に、ネットワーク仮想化は、専用の物理ハードウェアノードから仮想化されたリソースプールへのネットワーク機能の移行を促進しています。ただし、ネットワーク仮想化は、コンピューティングおよびストレージ機能の仮想化だけでなく、ネットワーク自体の抽象化も含むため、クラウドコンピューティングよりも複雑な問題と見なすことができます。このドキュメントでは、サービス品質の保証、パフォーマンスの向上、複数ドメインのサポート、ネットワークスライシング、サービス構成、デバイス仮想化、プライバシーとセキュリティ、制御の懸念の分離、ネットワーク機能の配置など、ネットワーク仮想化における現在の研究とエンジニアリングの課題について説明します。テスト。さらに、IETFとIRTFでのこれらの課題のいくつかに対処できる新しい活動について、いくつかの提案がなされています。このドキュメントは、Network Function Virtualization Research Group（NFVRG）の製品です。
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 Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Network Function Virtualization Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネット研究タスクフォース（IRTF）のネットワーク機能仮想化研究グループの合意を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8568.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8568で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Network Function Virtualization . . . . . . . . . . . . . 6
3.2. Software-Defined Networking . . . . . . . . . . . . . . . 9
3.3. ITU-T Functional Architecture of SDN . . . . . . . . . . 13
3.4. Multi-Access Edge Computing . . . . . . . . . . . . . . . 15
3.5. IEEE 802.1CF (OmniRAN) . . . . . . . . . . . . . . . . . 15
3.6. Distributed Management Task Force (DMTF) . . . . . . . . 15
3.7. Open-Source Initiatives . . . . . . . . . . . . . . . . . 16
4. Network Virtualization Challenges . . . . . . . . . . . . . . 18
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Guaranteeing Quality of Service . . . . . . . . . . . . . 18
4.2.1. Virtualization Technologies . . . . . . . . . . . . . 18
4.2.2. Metrics for NFV Characterization . . . . . . . . . . 19
4.2.3. Predictive Analysis . . . . . . . . . . . . . . . . . 20
4.2.4. Portability . . . . . . . . . . . . . . . . . . . . . 20
4.3. Performance Improvement . . . . . . . . . . . . . . . . . 21
4.3.1. Energy Efficiency . . . . . . . . . . . . . . . . . . 21
4.3.2. Improved Link Usage . . . . . . . . . . . . . . . . . 21
4.4. Multiple Domains . . . . . . . . . . . . . . . . . . . . 22
4.5. 5G and Network Slicing . . . . . . . . . . . . . . . . . 22
4.5.1. Virtual Network Operators . . . . . . . . . . . . . . 23
4.5.2. Extending Virtual Networks and Systems to the
Internet of Things . . . . . . . . . . . . . . . . . 24
4.6. Service Composition . . . . . . . . . . . . . . . . . . . 25
4.7. Device Virtualization for End Users . . . . . . . . . . . 27
4.8. Security and Privacy . . . . . . . . . . . . . . . . . . 27
4.9. Separation of Control Concerns . . . . . . . . . . . . . 29
4.10. Network Function Placement . . . . . . . . . . . . . . . 29
4.11. Testing . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.11.1. Changes in Methodology . . . . . . . . . . . . . . . 30
4.11.2. New Functionality . . . . . . . . . . . . . . . . . 31
4.11.3. Opportunities . . . . . . . . . . . . . . . . . . . 32
5. Technology Gaps and Potential IETF Efforts . . . . . . . . . 33
6. NFVRG Focus Areas . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. Informative References . . . . . . . . . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
The telecommunications sector is experiencing a major revolution that will shape the way networks and services are designed and deployed for the next few decades. In order to cope with continuously increasing demand and cost, network operators are taking lessons from the IT paradigm of cloud computing. This new approach of virtualizing network functions will enable multi-fold advantages by moving communication services from bespoke hardware in the operator's core network to Commercial Off-The-Shelf (COTS) equipment distributed across data centers.
電気通信部門は、ネットワークとサービスが今後数十年にわたって設計および展開される方法を形作る大きな革命を経験しています。絶えず増大する需要とコストに対処するために、ネットワークオペレーターはクラウドコンピューティングのITパラダイムから教訓を取り入れています。ネットワーク機能を仮想化するこの新しいアプローチは、通信サービスをオペレーターのコアネットワーク内の特注のハードウェアからデータセンター全体に分散された市販の（COTS）機器に移動することにより、複数の利点を可能にします。
Some of the network virtualization mechanisms that are being considered include the following: sharing of network infrastructure to reduce costs, virtualization of core and edge servers/services running in data centers as a way of supporting their load-aware elastic dimensioning, and dynamic energy policies to reduce the electricity consumption.
検討されているネットワーク仮想化メカニズムには、次のものが含まれます。コストを削減するためのネットワークインフラストラクチャの共有、データセンターで実行されているコアサーバーとエッジサーバー/サービスの仮想化、それらの負荷を考慮した柔軟なディメンションと動的エネルギーポリシー消費電力を削減します。
This document presents research and engineering challenges in network virtualization that need to be addressed in order to achieve these goals, spanning from pure research and engineering/standards space. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research and standards work.
このドキュメントは、これらの目標を達成するために取り組む必要のある、ネットワーク仮想化における研究とエンジニアリングの課題を提示します。研究とエンジニアリング/標準の分野にまたがります。このメモの目的は、技術的な課題と対応する現在のアプローチを文書化し、将来の研究と標準化作業で対処する必要がある要件を明らかにすることです。
This document represents the consensus of the Network Function Virtualization Research Group (NFVRG). It has been reviewed by the RG members active in the specific areas of work covered by the document.
このドキュメントは、ネットワーク機能仮想化研究グループ（NFVRG）の合意を表します。それは、文書でカバーされている特定の作業分野で活動しているRGメンバーによってレビューされました。
The following terms used in this document are defined by the ETSI Network Function Virtualization (NFV) Industrial Study Group (ISG) [etsi_gs_nfv_003], the Open Networking Foundation (ONF) [onf_tr_521], and the IETF [RFC7426] [RFC7665]:
このドキュメントで使用される次の用語は、ETSIネットワーク機能仮想化（NFV）産業研究グループ（ISG）[etsi_gs_nfv_003]、Open Networking Foundation（ONF）[onf_tr_521]、およびIETF [RFC7426] [RFC7665]によって定義されています。
Application Plane: The collection of applications and services that program network behavior.
アプリケーションプレーン：ネットワークの動作をプログラムするアプリケーションとサービスのコレクション。
Control Plane (CP): The collection of functions responsible for controlling one or more network devices. The CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane.
コントロールプレーン（CP）：1つ以上のネットワークデバイスの制御を担当する機能の集まり。 CPは、パケットの処理方法と転送方法に関してネットワークデバイスに指示します。コントロールプレーンは、主にフォワーディングプレーンと相互作用しますが、それほどではありませんが、オペレーションプレーンと相互作用します。
Forwarding Plane (FP): The collection of resources across all network devices responsible for forwarding traffic.
Forwarding Plane（FP）：トラフィックの転送を担当するすべてのネットワークデバイスにわたるリソースのコレクション。
Management Plane (MP): The collection of functions responsible for monitoring, configuring, and maintaining one or more network devices or parts of network devices. The management plane is mostly related to the operational plane (it is related less to the forwarding plane).
管理プレーン（MP）：1つ以上のネットワークデバイスまたはネットワークデバイスの一部を監視、構成、および保守する機能の集合。管理プレーンは、主に運用プレーンに関連しています（転送プレーンにはあまり関連していません）。
NFV Infrastructure (NFVI): Totality of all hardware and software components that build up the environment in which VNFs are deployed.
NFVインフラストラクチャ（NFVI）：VNFが展開される環境を構築するすべてのハードウェアおよびソフトウェアコンポーネントの合計。
NFV Management and Orchestration (NFV-MANO): Functions collectively provided by NFVO, VNFM, and VIM.
NFV管理およびオーケストレーション（NFV-MANO）：NFVO、VNFM、およびVIMによって集合的に提供される機能。
NFV Orchestrator (NFVO): Functional block that manages the Network Service (NS) life cycle and coordinates the management of NS life cycle, VNF life cycle (supported by the VNFM) and NFVI resources (supported by the VIM) to ensure an optimized allocation of the necessary resources and connectivity.
NFV Orchestrator（NFVO）：ネットワークサービス（NS）ライフサイクルを管理し、NSライフサイクル、VNFライフサイクル（VNFMでサポート）、およびNFVIリソース（VIMでサポート）の管理を調整して、割り当てを最適化する機能ブロック必要なリソースと接続の。
Operational Plane (OP): The collection of resources responsible for managing the overall operation of individual network devices.
運用面（OP）：個々のネットワークデバイスの全体的な運用を管理するリソースの集合。
Physical Network Function (PNF): Physical implementation of a network function in a monolithic realization.
物理ネットワーク機能（PNF）：モノリシックな実現におけるネットワーク機能の物理的な実装。
Service Function Chain (SFC): For a given service, the abstracted view of the required service functions and the order in which they are to be applied. This is somehow equivalent to the Network Function Forwarding Graph (NF-FG) at ETSI.
サービス機能チェーン（SFC）：特定のサービスについて、必要なサービス機能の抽象化されたビューとそれらが適用される順序。これは、ETSIのネットワーク機能転送グラフ（NF-FG）と何とか同等です。
Service Function Path (SFP): The selection of specific service function instances on specific network nodes to form a service graph through which an SFC is instantiated.
サービス機能パス（SFP）：特定のネットワークノード上の特定のサービス機能インスタンスを選択して、SFCがインスタンス化されるサービスグラフを形成します。
Virtualized Infrastructure Manager (VIM): Functional block that is responsible for controlling and managing the NFVI compute, storage, and network resources, usually within one infrastructure operator's domain.
Virtualized Infrastructure Manager（VIM）：NFVIコンピューティング、ストレージ、およびネットワークリソースの制御と管理を担当する機能ブロック。通常、1つのインフラストラクチャオペレーターのドメイン内にあります。
Virtualized Network Function (VNF): Implementation of a Network Function that can be deployed on a Network Function Virtualization Infrastructure (NFVI).
仮想化ネットワーク機能（VNF）：ネットワーク機能仮想化インフラストラクチャ（NFVI）に展開できるネットワーク機能の実装。
Virtualized Network Function Manager (VNFM): Functional block that is responsible for the life-cycle management of VNF.
Virtualized Network Function Manager（VNFM）：VNFのライフサイクル管理を担当する機能ブロック。
This section briefly describes some basic background technologies as well as other Standards Developing Organizations (SDOs) and open-source initiatives working on network virtualization or related topics.
このセクションでは、いくつかの基本的な背景技術、その他の標準開発組織（SDO）、およびネットワーク仮想化または関連トピックに取り組んでいるオープンソースイニシアチブについて簡単に説明します。
The ETSI ISG Network Function Virtualization (NFV) is a working group that, since 2012, has aimed to evolve quasi-standard IT virtualization technology to consolidate many network equipment types into industry standard high-volume servers, switches, and storage. It enables implementing network functions in software that can run on a range of industry-standard server hardware and can be moved to, or loaded in, various locations in the network as required, without the need to install new equipment. The ETSI NFV is one of the predominant NFV reference framework and architectural footprints [nfv_sota_research_challenges]. The ETSI NFV framework architecture is composed of three domains (Figure 1):
ETSI ISGネットワーク機能仮想化（NFV）は、2012年以降、準標準IT仮想化テクノロジーを進化させて、多くのネットワーク機器タイプを業界標準の大容量サーバー、スイッチ、ストレージに統合することを目的としたワーキンググループです。さまざまな業界標準のサーバーハードウェアで実行でき、必要に応じてネットワーク内のさまざまな場所に移動またはロードできるソフトウェアにネットワーク機能を実装できます。新しい機器をインストールする必要はありません。 ETSI NFVは、主要なNFVリファレンスフレームワークの1つであり、アーキテクチャのフットプリント[nfv_sota_research_challenges]です。 ETSI NFVフレームワークアーキテクチャは、3つのドメインで構成されています（図1）。
o Virtualized Network Function, running over the NFVI.
o NFVIで実行される仮想ネットワーク機能。
o NFVI, including the diversity of physical resources and how these can be virtualized. NFVI supports the execution of the VNFs.
o 物理リソースの多様性とそれらを仮想化する方法を含むNFVI。 NFVIはVNFの実行をサポートします。
o NFV Management and Orchestration, which covers the orchestration and life-cycle management of physical and/or software resources that support the infrastructure virtualization, and the life-cycle management of VNFs. NFV Management and Orchestration focuses on all virtualization-specific management tasks necessary in the NFV framework.
o NFV管理とオーケストレーション。インフラストラクチャの仮想化をサポートする物理リソースやソフトウェアリソースのオーケストレーションとライフサイクル管理、およびVNFのライフサイクル管理について説明します。 NFV管理とオーケストレーションは、NFVフレームワークで必要なすべての仮想化固有の管理タスクに焦点を当てています。
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
Figure 1: ETSI NFV Framework
図1：ETSI NFVフレームワーク
The NFV architectural framework identifies functional blocks and the main reference points between such blocks. Some of these are already present in current deployments, whilst others might be necessary additions in order to support the virtualization process and consequent operation. The functional blocks are (Figure 2):
NFVアーキテクチャフレームワークは、機能ブロックとそのようなブロック間の主要な参照ポイントを識別します。これらの一部は現在の展開にすでに存在していますが、仮想化プロセスとその結果として生じる操作をサポートするために必要な追加もある場合があります。機能ブロックは次のとおりです（図2）。
o Virtualized Network Function (VNF)
o 仮想化ネットワーク機能（VNF）
o Element Management (EM)
o 要素管理（EM）
o NFV Infrastructure, including: Hardware and virtualized resources as well as the Virtualization Layer.
o NFVインフラストラクチャ。ハードウェアと仮想化リソース、および仮想化レイヤー。
o Virtualized Infrastructure Manager(s) (VIM)
o Virtualized Infrastructure Manager（s）（VIM）
o NFV Orchestrator
o NFVオーケストレーター
o VNF Manager(s)
o VNFマネージャー
o Service, VNF and Infrastructure Description o Operational Support Systems and Business Support Systems (OSS and BSS)
oサービス、VNF、インフラストラクチャの説明o運用サポートシステムおよびビジネスサポートシステム（OSSおよびBSS）
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
Figure 2: ETSI NFV Reference Architecture
図2：ETSI NFVリファレンスアーキテクチャ
The Software-Defined Networking (SDN) paradigm pushes the intelligence currently residing in the network elements to a central controller implementing the network functionality through software. In contrast to traditional approaches, in which the network's control plane is distributed throughout all network devices, with SDN, the control plane is logically centralized. In this way, the deployment of new characteristics in the network no longer requires complex and costly changes in equipment or firmware updates, but only a change in the software running in the controller. The main advantage of this approach is the flexibility it provides operators to manage their network, i.e., an operator can easily change its policies on how traffic is distributed throughout the network.
ソフトウェア定義ネットワーク（SDN）パラダイムは、ネットワーク要素に現在存在するインテリジェンスを、ソフトウェアを介してネットワーク機能を実装する中央コントローラーにプッシュします。ネットワークのコントロールプレーンがSDNを使用してすべてのネットワークデバイスに分散される従来のアプローチとは対照的に、コントロールプレーンは論理的に集中化されています。このようにして、ネットワークに新しい特性を導入する際に、機器やファームウェアの更新に複雑で費用のかかる変更を加える必要がなくなり、コントローラーで実行されているソフトウェアを変更するだけで済みます。このアプローチの主な利点は、ネットワークを管理するオペレーターに柔軟性を提供することです。つまり、オペレーターは、トラフィックがネットワーク全体に分散される方法に関するポリシーを簡単に変更できます。
One of the most well-known protocols for the SDN control plane between the central controller and the networking elements is the OpenFlow Protocol (OFP), which is maintained and extended by the Open Network Foundation (ONF) <https://www.opennetworking.org/>. Originally, this protocol was developed specifically for IEEE 802.1 switches conforming to the ONF OpenFlow Switch specification [OpenFlow]. As the benefits of the SDN paradigm have reached a wider audience, its application has been extended to more complex scenarios such as wireless and mobile networks. Within this area of work, the ONF is actively developing new OFP extensions addressing three key scenarios: (i) wireless backhaul, (ii) cellular Evolved Packet Core (EPC), and (iii) unified access and management across enterprise wireless and fixed networks.
中央コントローラーとネットワーク要素の間のSDNコントロールプレーンの最もよく知られているプロトコルの1つは、OpenFlow Protocol（OFP）です。これは、Open Network Foundation（ONF）<https：//www.opennetworkingによって維持および拡張されています。 .org />。もともと、このプロトコルは、ONF OpenFlowスイッチ仕様[OpenFlow]に準拠したIEEE 802.1スイッチ用に特別に開発されました。 SDNパラダイムの利点がより広い聴衆に届くように、そのアプリケーションはワイヤレスやモバイルネットワークなどのより複雑なシナリオに拡張されました。この作業領域内で、ONFは3つの主要なシナリオに対応する新しいOFP拡張機能を積極的に開発しています。 。
+----------+
| ------- |
| |Oper.| | O
| |Mgmt.| |<........> -+- Network Operator
| |Iface| | ^
| ------- | +----------------------------------------+
| | | +------------------------------------+ |
| | | | --------- --------- --------- | |
|--------- | | | | App 1 | | App 2 | ... | App n | | |
||Plugins| |<....>| | --------- --------- --------- | |
|--------- | | | Plugins | |
| | | +------------------------------------+ |
| | | Application Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +------------------------------------+ |
|--------- | | | ------------ ------------ | |
|| Netw. | | | | | Module 1 | | Module 2 | | |
||Engine | |<....>| | ------------ ------------ | |
|--------- | | | Network Engine | |
| | | +------------------------------------+ |
| | | Control Plane |
| | +----------------------------------------+
| | A
| | |
| | V
| | +----------------------------------------+
| | | +--------------+ +--------------+ |
| | | | ------------ | | ------------ | |
|----------| | | | OpenFlow | | | | OpenFlow | | |
||OpenFlow||<....>| | ------------ | | ------------ | |
|----------| | | NE | | NE | |
| | | +--------------+ +--------------+ |
| | | Data Plane |
|Management| +----------------------------------------+
+----------+
Figure 3: High-Level SDN ONF Architecture
図3：高レベルSDN ONFアーキテクチャ
Figure 3 shows the blocks and the functional interfaces of the ONF architecture, which comprises three planes: data, controller, and application. The data plane comprehends several Network Entities (NEs), which expose their capabilities toward the control plane via a Southbound API. The control plane includes several cooperating modules devoted to the creation and maintenance of an abstracted resource model of the underlying network. Such a model is exposed to the applications via a Northbound API where the application plane comprises several applications/services, each of which has exclusive control of a set of exposed resources.
図3は、データ、コントローラー、アプリケーションの3つのプレーンで構成されるONFアーキテクチャのブロックと機能インターフェイスを示しています。データプレーンには、サウスバウンドAPIを介してコントロールプレーンに向けて機能を公開するいくつかのネットワークエンティティ（NE）が含まれています。コントロールプレーンには、基盤となるネットワークの抽象化されたリソースモデルの作成と保守に特化したいくつかの協調モジュールが含まれています。このようなモデルは、Northbound APIを介してアプリケーションに公開されます。NorthboundAPIは、アプリケーションプレーンが複数のアプリケーション/サービスで構成され、それぞれが一連の公開リソースを排他的に制御します。
The management plane spans its functionality across all planes performing the initial configuration of the network elements in the data plane, the assignment of the SDN controller and the resources under its responsibility. In the control plane, the management needs to configure the policies defining the scope of the control given to the SDN applications, to monitor the performance of the system and to configure the parameters required by the SDN controller modules. In the application plane, the management plane configures the parameters of the applications and the service-level agreements. In addition to these interactions, the management plane exposes several functions to network operators that can easily and quickly configure and tune the network at each layer.
管理プレーンは、データプレーンのネットワーク要素の初期構成、SDNコントローラーの割り当て、およびリソースの責任の下でのリソースを実行するすべてのプレーンにわたって機能を拡張します。コントロールプレーンでは、管理者はSDNアプリケーションに与えられる制御の範囲を定義するポリシーを構成し、システムのパフォーマンスを監視し、SDNコントローラーモジュールに必要なパラメーターを構成する必要があります。アプリケーションプレーンでは、管理プレーンがアプリケーションのパラメーターとサービスレベルアグリーメントを構成します。これらの相互作用に加えて、管理プレーンはネットワークオペレーターにいくつかの機能を公開し、各レイヤーでネットワークを簡単かつ迅速に構成および調整できます。
In RFC 7426 [RFC7426], the IRTF Software-Defined Networking Research Group (SDNRG) documented a layer model of an SDN architecture. This was due to the following controversial discussion topics (among others). What exactly is SDN? What is the layer structure of the SDN architecture? How do layers interface with each other?
RFC 7426 [RFC7426]で、IRTF Software-Defined Networking Research Group（SDNRG）は、SDNアーキテクチャのレイヤーモデルを文書化しました。これは、（特に）次の議論の多い議論のトピックによるものでした。 SDNとは正確には何ですか？ SDNアーキテクチャのレイヤー構造は何ですか？レイヤーはどのように相互にやり取りしますか？
Figure 4 reproduces the figure included in RFC 7426 [RFC7426] to summarize the SDN architecture abstractions in the form of a detailed, high-level schematic. In a particular implementation, planes can be collocated with other planes or can be physically separated.
図4は、RFC 7426 [RFC7426]に含まれている図を再現して、詳細な高レベルの回路図の形式でSDNアーキテクチャの抽象化を要約しています。特定の実装では、プレーンは他のプレーンと同じ場所に配置することも、物理的に分離することもできます。
In SDN, a controller manipulates controlled entities via an interface. Interfaces, when local, are mostly API invocations through some library or system call. However, such interfaces may be extended via some protocol definition, which may use local interprocess communication (IPC) or a protocol that could also act remotely; the protocol may be defined as an open standard or in a proprietary manner.
SDNでは、コントローラーはインターフェースを介して被制御エンティティーを操作します。インターフェイスは、ローカルの場合、ほとんどの場合、いくつかのライブラリまたはシステムコールを介したAPI呼び出しです。ただし、そのようなインターフェースは、ローカルのプロセス間通信（IPC）またはリモートで動作する可能性のあるプロトコルを使用する可能性があるプロトコル定義を介して拡張できます。プロトコルは、オープンスタンダードとして、または独自の方法で定義できます。
SDN expands multiple planes: forwarding, operational, control, management, and application. All planes mentioned above are connected via interfaces. Additionally, RFC 7426 [RFC7426] considers four abstraction layers: the Device and resource Abstraction Layer (DAL), the Control Abstraction Layer (CAL), the Management Abstraction Layer (MAL), and the Network Services Abstraction Layer (NSAL).
SDNは、転送、運用、制御、管理、アプリケーションなど、複数のプレーンを拡張します。上記のすべてのプレーンは、インターフェースを介して接続されます。さらに、RFC 7426 [RFC7426]は4つの抽象化レイヤーを考慮します。デバイスおよびリソース抽象化レイヤー（DAL）、制御抽象化レイヤー（CAL）、管理抽象化レイヤー（MAL）、およびネットワークサービス抽象化レイヤー（NSAL）です。
o--------------------------------o
| |
| +-------------+ +----------+ |
| | Application | | Service | |
| +-------------+ +----------+ |
| Application Plane |
o---------------Y----------------o
|
*-----------------------------Y---------------------------------*
| Network Services Abstraction Layer (NSAL) |
*------Y------------------------------------------------Y-------*
| |
| Service Interface |
| |
o------Y------------------o o---------------------Y------o
| | Control Plane | | Management Plane | |
| +----Y----+ +-----+ | | +-----+ +----Y----+ |
| | Service | | App | | | | App | | Service | |
| +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ |
| | | | | | | |
| *----Y-----------Y----* | | *---Y---------------Y----* |
| | Control Abstraction | | | | Management Abstraction | |
| | Layer (CAL) | | | | Layer (MAL) | |
| *----------Y----------* | | *----------Y-------------* |
| | | | | |
o------------|------------o o------------|---------------o
| |
| CP | MP
| Southbound | Southbound
| Interface | Interface
| |
*------------Y---------------------------------Y----------------*
| Device and resource Abstraction Layer (DAL) |
*------------Y---------------------------------Y----------------*
| | | |
| o-------Y----------o +-----+ o--------Y----------o |
| | Forwarding Plane | | App | | Operational Plane | |
| o------------------o +-----+ o-------------------o |
| Network Device |
+---------------------------------------------------------------+
Figure 4: SDN-Layer Architecture
図4：SDNレイヤーのアーキテクチャ
While SDN is often directly associated to OpenFlow, this is just one (relevant) example of a southbound protocol between the central controller and the network entities. Other relevant examples of protocols in the SDN family are NETCONF [RFC6241], RESTCONF [RFC8040], and ForCES [RFC5810].
SDNは多くの場合OpenFlowに直接関連付けられていますが、これは中央コントローラーとネットワークエンティティ間のサウスバウンドプロトコルの1つの（関連する）例にすぎません。 SDNファミリの他の関連するプロトコルの例は、NETCONF [RFC6241]、RESTCONF [RFC8040]、およびForCES [RFC5810]です。
The ITU-T (the Telecommunication standardization sector of the International Telecommunication Union) has also looked into SDN architectures, defining a slightly modified one from what other SDOs have done. In ITU-T recommendation Y.3302 [itu-t-y.3302], the ITU-T provides a functional architecture of SDN with descriptions of functional components and reference points. The described functional architecture is intended to be used as an enabler for further studies on other aspects such as protocols and security as well as being used to customize SDN in support of appropriate use cases (e.g., cloud computing, mobile networks). This recommendation is based on ITU-T Y.3300 [itu-t-y.3300] and ITU-T Y.3301 [itu-t-y.3301]. While the first describes the framework of SDN (including definitions, objectives, high-level capabilities, requirements, and the high-level architecture of SDN), the second describes more-detailed requirements.
ITU-T（国際電気通信連合の電気通信標準化部門）もSDNアーキテクチャを調査し、他のSDOが行ったものから少し変更したものを定義しています。 ITU-T勧告Y.3302 [itu-t-y.3302]では、ITU-TはSDNの機能アーキテクチャに機能コンポーネントと参照ポイントの説明を提供します。説明されている機能アーキテクチャは、プロトコルやセキュリティなどの他の側面に関するさらなる研究のイネーブラーとして使用されることを意図しているだけでなく、適切なユースケース（クラウドコンピューティング、モバイルネットワークなど）をサポートするためにSDNをカスタマイズするために使用されます。この推奨事項は、ITU-T Y.3300 [itu-t-y.3300]およびITU-T Y.3301 [itu-t-y.3301]に基づいています。 1つ目はSDNのフレームワーク（定義、目的、高レベルの機能、要件、およびSDNの高レベルのアーキテクチャーを含む）について説明していますが、2つ目はより詳細な要件について説明しています。
Figure 5 shows the SDN functional architecture defined by the ITU-T. It is a layered architecture composed of the SDN application layer (SDN-AL), the SDN control layer (SDN-CL), and the SDN resource layer (SDN-RL). It also has multi-layer management functions (MMF), which provide the ability to manage the functionalities of SDN layers, i.e., SDN-AL, SDN-CL, and SDN-RL. MMF interacts with these layers using Multi-layer Management Functions Application (MMFA), Multi-layer Management Functions Control (MMFC), and Multi-layer Management Functions Resource (MMFR) reference points.
図5は、ITU-Tによって定義されたSDN機能アーキテクチャを示しています。これは、SDNアプリケーションレイヤー（SDN-AL）、SDNコントロールレイヤー（SDN-CL）、SDNリソースレイヤー（SDN-RL）で構成される階層型アーキテクチャーです。また、SDNレイヤー（SDN-AL、SDN-CL、SDN-RL）の機能を管理する機能を提供するマルチレイヤー管理機能（MMF）も備えています。 MMFは、マルチレイヤー管理機能アプリケーション（MMFA）、マルチレイヤー管理機能制御（MMFC）、およびマルチレイヤー管理機能リソース（MMFR）参照ポイントを使用して、これらのレイヤーと対話します。
The SDN-AL enables a service-aware behavior of the underlying network in a programmatic manner. The SDN-CL provides programmable means to control the behavior of SDN-RL resources (such as data transport and processing) following requests received from the SDN-AL according to MMF policies. The SDN-RL is where the physical or virtual network elements perform transport and/or processing of data packets according to SDN-CL decisions.
SDN-ALは、プログラム的な方法で、基盤となるネットワークのサービス認識動作を可能にします。 SDN-CLは、MMFポリシーに従ってSDN-ALから受信した要求に続くSDN-RLリソース（データ転送や処理など）の動作を制御するプログラム可能な手段を提供します。 SDN-RLは、物理または仮想ネットワーク要素がSDN-CLの決定に従ってデータパケットの転送や処理を実行する場所です。
MMFO MMFA
+-----+ . +---------------------+ . +--------------------+
| | . |+---+ +---+ +-------+| . |+---------+ +-----+ |
| | . || | | | | || . || AL. | | | |
| | . || E | | | | App. || . || Mngmt. | | SDN | | SDN-AL
| | . || x | | M | | Layer || . || Support | | App | |
| | . || t.| | u | | Mngmt.|| . || & Orch. | | | |
| | . || | | l | +-------+| . |+---------+ +-----+ |
| | . || R | | t | | . +--------------------+
| | . || e | | i | |MMFC ..................... ACI
| | . || l | | - | | . +--------------------+
| | . || a | | l | +-------+| . |+------+ +---------+|
| OSS/| . || t | | a | | || . || | | App. ||
| BSS | . || i | | y | | || . || | | Support ||
| | . || o | | e | | || . || | +---------+|
| | . || n | | r | | || . || CL | +---------+|
| | . || s | | | |Control|| . ||Mngmt.| | Control ||
| | . || h | | M | | Layer || . || Supp.| | Layer || SDN-CL
| | . || i | | a | | Mngmt.|| . || and | | Serv. ||
| | . || p | | n | | || . || Orch.| +---------+|
| | . || | | a | | || . || | +---------+|
| | . || M | | g | | || . || | | Resource||
| | . || n | | e | | || . || | | Abstrac.||
| | . || g | | m | +-------+| . |+------+ +---------+|
| | . || m | | e | | . +--------------------+
| | . || t.| | n | |MMFR ..................... RCI
| | . || | | t | | . +--------------------+
+-----+ . |+---+ | | +-------+| . |+------++----------+|
| | O | | || . || ||RL Control||
| | r | |Resour.|| . || RL |+----------+|
MMF | | c | | Layer || . ||Mngmt.|+----++----+| SDN-RL
| | h.| | Mngmt.|| . || Supp.||Data||Data||
| | | | || . || ||Tran||Proc||
| +---+ +-------+| . |+------++----++----+|
+---------------------+ . +--------------------+
Legend: ACI: Application Control Interface MMFA: Multi-layer Management Functions Application MMFC: Multi-layer Management Functions Control MMFO: Multi-layer Management Functions OSS/BSS MMFR: Multi-layer Management Functions Resource RCI: Resource Control Interfaces RL: Resource Layer
凡例：ACI：アプリケーション制御インターフェースMMFA：マルチレイヤー管理機能アプリケーションMMFC：マルチレイヤー管理機能コントロールMMFO：マルチレイヤー管理機能OSS / BSS MMFR：マルチレイヤー管理機能リソースRCI：リソース制御インターフェースRL：リソース層
Figure 5: ITU-T SDN Functional Architecture
図5：ITU-T SDN機能アーキテクチャ
Multi-access Edge Computing (MEC) -- formerly known as Mobile Edge Computing -- capabilities deployed in the edge of the mobile network can facilitate the efficient and dynamic provision of services to mobile users. The ETSI ISG MEC working group, operative from end of 2014, intends to specify an open environment for integrating MEC capabilities with service providers' networks, also including applications from third parties. These distributed computing capabilities provide IT infrastructure as in a cloud environment for the deployment of functions in mobile access networks. It can be seen then as a complement to both NFV and SDN.
マルチアクセスエッジコンピューティング（MEC）（以前はモバイルエッジコンピューティングと呼ばれていました）は、モバイルネットワークのエッジに配置された機能により、モバイルユーザーへのサービスの効率的で動的な提供を促進できます。 2014年末から活動しているETSI ISG MECワーキンググループは、MEC機能をサービスプロバイダーのネットワークと統合するためのオープン環境を指定する予定であり、サードパーティからのアプリケーションも含まれます。これらの分散コンピューティング機能は、モバイルアクセスネットワークに機能を展開するためのクラウド環境と同様にITインフラストラクチャを提供します。 NFVとSDNの両方を補完するものと見なすことができます。
The IEEE 802.1CF Recommended Practice [omniran] specifies an access network that connects terminals to their access routers utilizing technologies based on the family of IEEE 802 Standards (e.g., 802.3 Ethernet, 802.11 Wi-Fi, etc.). The specification defines an access network reference model, including entities and reference points along with behavioral and functional descriptions of communications among those entities.
IEEE 802.1CF推奨プラクティス[omniran]は、IEEE 802標準のファミリー（802.3イーサネット、802.11 Wi-Fiなど）に基づくテクノロジーを利用して、端末をアクセスルーターに接続するアクセスネットワークを規定しています。この仕様では、エンティティと参照ポイント、およびエンティティ間の通信の動作と機能の説明を含む、アクセスネットワーク参照モデルを定義しています。
The goal of this project is to help unify the support of different interfaces, enabling shared-network control and use of SDN principles, thereby lowering the barriers to new network technologies, to new network operators, and to new service providers.
このプロジェクトの目的は、さまざまなインターフェースのサポートを統合し、共有ネットワーク制御とSDN原則の使用を可能にすることで、新しいネットワークテクノロジー、新しいネットワークオペレーター、および新しいサービスプロバイダーへの障壁を下げることです。
The DMTF <https://www.dmtf.org/> is an industry standards organization working to simplify the manageability of network-accessible technologies through open and collaborative efforts by some technology companies. The DMTF is involved in the creation and adoption of interoperable management standards, supporting implementations that enable the management of diverse traditional and emerging technologies including cloud, virtualization, network, and infrastructure.
DMTF <https://www.dmtf.org/>は、一部のテクノロジー企業によるオープンで協力的な取り組みを通じて、ネットワークアクセス可能なテクノロジーの管理を簡素化するために取り組んでいる業界標準化団体です。 DMTFは、相互運用可能な管理標準の作成と採用に関与しており、クラウド、仮想化、ネットワーク、インフラストラクチャなど、従来の新しいテクノロジーの管理を可能にする実装をサポートしています。
There are several DMTF initiatives that are relevant to the network virtualization area, such as the Open Virtualization Format (OVF) for VNF packaging; the Cloud Infrastructure Management Interface (CIMI) for cloud infrastructure management; the Network Management (NETMAN), for VNF management; and the Virtualization Management (VMAN), for virtualization infrastructure management.
VNFパッケージ用のOpen Virtualization Format（OVF）など、ネットワーク仮想化領域に関連するDMTFイニシアチブがいくつかあります。クラウドインフラストラクチャ管理のためのクラウドインフラストラクチャ管理インターフェイス（CIMI）。 VNF管理用のネットワーク管理（NETMAN）。仮想化インフラストラクチャ管理のための仮想化管理（VMAN）。
The open-source community is especially active in the area of network virtualization and orchestration. We next summarize some of the active efforts:
オープンソースコミュニティは、ネットワークの仮想化とオーケストレーションの分野で特に活発です。次に、積極的な取り組みのいくつかを要約します。
o OpenStack. OpenStack is a free and open-source cloud-computing software platform. OpenStack software controls large pools of compute, storage, and networking resources throughout a data center, managed through a dashboard or via the OpenStack API.
o OpenStack。 OpenStackは、無料でオープンソースのクラウドコンピューティングソフトウェアプラットフォームです。 OpenStackソフトウェアは、ダッシュボードまたはOpenStack APIを介して管理される、データセンター全体のコンピューティング、ストレージ、およびネットワークリソースの大規模なプールを制御します。
o Kubernetes. Kubernetes is an open-source system for automating deployment, scaling and management of containerized applications. Kubernetes can schedule and run application containers on clusters of physical or virtual machines. Kubernetes allows (i) Scale on the fly, (ii) Limit hardware usage to required resources only, (iii) Load-balancing Monitoring, and (iv) Efficient life-cycle management.
o Kubernetes。 Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するためのオープンソースシステムです。 Kubernetesは、物理マシンまたは仮想マシンのクラスタでアプリケーションコンテナをスケジュールして実行できます。 Kubernetesでは、（i）オンザフライでスケーリング、（ii）ハードウェアの使用を必要なリソースのみに制限、（iii）負荷分散モニタリング、（iv）効率的なライフサイクル管理が可能です。
o OpenDayLight. OpenDayLight (ODL) is a highly available, modular, extensible and scalable multiprotocol controller infrastructure built for SDN deployments on modern heterogeneous multi-vendor networks. It provides a model-driven service abstraction platform that allows users to write apps that easily work across a wide variety of hardware and southbound protocols.
o OpenDayLight。 OpenDayLight（ODL）は、最新の異種マルチベンダーネットワークでのSDN導入用に構築された、可用性が高く、モジュール化された、拡張可能でスケーラブルなマルチプロトコルコントローラーインフラストラクチャです。これは、モデル駆動型のサービス抽象化プラットフォームを提供し、ユーザーがさまざまなハードウェアとサウスバウンドプロトコルで簡単に動作するアプリを作成できるようにします。
o ONOS. The Open Network Operating System (ONOS) project is an open-source community hosted by The Linux Foundation. The goal of the project is to create an SDN operating system for communications service providers that is designed for scalability, high performance, and high availability.
o ONOS。 Open Network Operating System（ONOS）プロジェクトは、The Linux Foundationがホストするオープンソースコミュニティです。このプロジェクトの目標は、スケーラビリティ、高性能、高可用性を実現するように設計された、通信サービスプロバイダー向けのSDNオペレーティングシステムを作成することです。
o OpenContrail. OpenContrail is a licensed Apache 2.0 project that is built using standards-based protocols and that provides all the necessary components for network virtualization: an SDN controller, a virtual router, an analytics engine, and published northbound APIs. It has an extensive Representational State Transfer (REST) API to configure and gather operational and analytics data from the system.
o OpenContrail。 OpenContrailは、標準ベースのプロトコルを使用して構築され、ネットワーク仮想化に必要なすべてのコンポーネント（SDNコントローラー、仮想ルーター、分析エンジン、公開されたノースバウンドAPI）を提供する、ライセンス済みのApache 2.0プロジェクトです。これには、システムから運用データと分析データを構成および収集するための広範なREST（Representational State Transfer）APIがあります。
o OPNFV. The Open Platform for NFV (OPNFV) is a carrier-grade, integrated, open-source platform to accelerate the introduction of new NFV products and services. By integrating components from upstream projects, the OPNFV community aims at conducting performance and use case-based testing to ensure the platform's suitability for NFV use cases. The scope of OPNFV's initial release is focused on building NFV Infrastructure (NFVI) and Virtualized Infrastructure Manager (VIM) by integrating components from upstream projects such as OpenDayLight, OpenStack, Ceph Storage, Kernel-based Virtual Machine (KVM), Open vSwitch, and Linux. These components, along with APIs to other NFV elements, form the basic infrastructure required for Virtualized Network Functions (VNFs) and Management and Orchestration (MANO) components. OPNFV's goal is to (i) increase performance and power efficiency, (ii) improve reliability, availability, and serviceability, and (iii) deliver comprehensive platform instrumentation.
o OPNFV。 Open Platform for NFV（OPNFV）は、新しいNFV製品およびサービスの導入を促進するためのキャリアグレードの統合オープンソースプラットフォームです。上流プロジェクトのコンポーネントを統合することにより、OPNFVコミュニティは、パフォーマンスとユースケースベースのテストを実施して、プラットフォームがNFVユースケースに適していることを確認することを目的としています。 OPNFVの初期リリースの範囲は、OpenDayLight、OpenStack、Ceph Storage、カーネルベースの仮想マシン（KVM）、Open vSwitch、 Linux。これらのコンポーネントは、他のNFV要素へのAPIとともに、仮想ネットワーク機能（VNF）と管理およびオーケストレーション（MANO）コンポーネントに必要な基本インフラストラクチャを形成します。 OPNFVの目標は、（i）パフォーマンスと電力効率の向上、（ii）信頼性、可用性、および保守性の向上、（iii）包括的なプラットフォーム計測の提供です。
o OSM. Open Source Mano (OSM) is an ETSI-hosted project to develop an Open Source NFV Management and Orchestration (MANO) software stack aligned with ETSI NFV. OSM is based on components from previous projects, such Telefonica's OpenMANO or Canonical's Juju, among others.
o OSM。オープンソースMano（OSM）は、ETSIがホストするプロジェクトであり、ETSI NFVと連携するオープンソースNFV管理およびオーケストレーション（MANO）ソフトウェアスタックを開発します。 OSMは、TelefonicaのOpenMANOやCanonicalのJujuなど、以前のプロジェクトのコンポーネントに基づいています。
o OpenBaton. OpenBaton is a Network Function Virtualization Orchestrator (NFVO) that is ETSI NFV compliant. OpenBaton was part of the OpenSDNCore project started with the objective of providing a compliant implementation of the ETSI NFV specification.
o OpenBaton。 OpenBatonは、ETSI NFVに準拠したネットワーク機能仮想化オーケストレーター（NFVO）です。 OpenBatonは、ETSI NFV仕様の準拠した実装を提供することを目的として開始されたOpenSDNCoreプロジェクトの一部でした。
o ONAP. Open Network Automation Platform (ONAP) is an open-source software platform that delivers capabilities for the design, creation, orchestration, monitoring, and life-cycle management of (i) Virtual Network Functions (VNFs), (ii) The carrier-scale Software-Defined Networks (SDNs) that contain them, and (iii) higher-level services that combine the above. ONAP (derived from the AT&T's ECOMP) provides for automatic, policy-driven interaction of these functions and services in a dynamic, real-time cloud environment.
o ONAP。オープンネットワークオートメーションプラットフォーム（ONAP）は、（i）仮想ネットワーク機能（VNF）、（ii）キャリアスケールの設計、作成、オーケストレーション、監視、およびライフサイクル管理の機能を提供するオープンソースソフトウェアプラットフォームです。それらを含むソフトウェア定義ネットワーク（SDN）、および（iii）上記を組み合わせた高レベルのサービス。 ONAP（AT＆TのECOMPから派生）は、動的なリアルタイムクラウド環境で、これらの機能とサービスの自動的なポリシー主導の相互作用を提供します。
o SONA. The Simplified Overlay Network Architecture (SONA) is an extension to ONOS to have an almost full SDN network control in OpenStack for virtual tenant network provisioning. Basically, SONA is an SDN-based network virtualization solution for cloud DC.
o ソナ。 Simplified Overlay Network Architecture（SONA）はONOSの拡張機能で、OpenStackでほぼ完全なSDNネットワークを制御して、仮想テナントネットワークプロビジョニングを実現します。基本的に、SONAはクラウドDC向けのSDNベースのネットワーク仮想化ソリューションです。
Among the main areas that are being developed by the aforementioned open-source activities that relate to network virtualization research, we can highlight policy-based resource management, analytics for visibility and orchestration, and service verification with regard to security and resiliency.
ネットワーク仮想化研究に関連する前述のオープンソース活動によって開発されている主要な領域の中で、ポリシーベースのリソース管理、可視性とオーケストレーションの分析、およびセキュリティと復元力に関するサービス検証を強調できます。
Network virtualization is changing the way the telecommunications sector will deploy, extend, and operate their networks. These new technologies aim at reducing the overall costs by moving communication services from specific hardware in the operators' cores to server farms scattered in data centers (i.e., compute and storage virtualization). In addition, the networks interconnecting the functions that compose a network service are fundamentally affected in the way they route, process, and control traffic (i.e., network virtualization).
ネットワーク仮想化は、通信セクターがネットワークを展開、拡張、運用する方法を変えています。これらの新しいテクノロジーは、通信サービスをオペレーターのコア内の特定のハードウェアからデータセンターに分散しているサーバーファーム（つまり、コンピューティングとストレージの仮想化）に移動することで、全体的なコストを削減することを目的としています。さらに、ネットワークサービスを構成する機能を相互接続するネットワークは、トラフィックのルーティング、処理、および制御（つまり、ネットワーク仮想化）の方法に根本的な影響があります。
Achieving a given QoS in an NFV environment with virtualized and distributed computing, storage, and networking functions is more challenging than providing the equivalent in discrete non-virtualized components. For example, ensuring a guaranteed and stable forwarding data rate has proven not to be straightforward when the forwarding function is virtualized and runs on top of COTS server hardware [openmano_dataplane] [NFV-COTS] [etsi_nfv_whitepaper_3]. Again, the comparison point is against a router or forwarder built on optimized hardware. We next identify some of the challenges that this poses.
仮想化および分散されたコンピューティング、ストレージ、およびネットワーキング機能を備えたNFV環境で特定のQoSを達成することは、個別の非仮想化コンポーネントで同等のものを提供するよりも困難です。たとえば、転送機能が仮想化され、COTSサーバーハードウェア[openmano_dataplane] [NFV-COTS] [etsi_nfv_whitepaper_3]上で実行される場合、保証された安定した転送データレートを確保することは簡単ではないことが判明しています。ここでも、比較ポイントは、最適化されたハードウェア上に構築されたルーターまたはフォワーダーに対するものです。次に、これがもたらすいくつかの課題を特定します。
The issue of guaranteeing a network QoS is less of an issue for "traditional" cloud computing because the workloads that are treated there are servers or clients in the networking sense and hardly ever process packets. Cloud computing provides hosting for applications on shared servers in a highly separated way. Its main advantage is that the infrastructure costs are shared among tenants and that the cloud infrastructure provides levels of reliability that can not be achieved on individual premises in a cost-efficient way [intel_10_differences_nfv_cloud]. NFV has very strict requirements posed in terms of performance, stability, and consistency. Although there are some tools and mechanisms to improve this, such as Enhanced Performance Awareness (EPA), Single Root I/O Virtualization (SR-IOV), Non-Uniform Memory Access (NUMA), Data Plane Development Kit (DPDK), etc., these are still unsolved challenges. One open research issue is finding out technologies that are different from Virtual Machines (VMs) and more suitable for dealing with network functionalities.
ネットワークのQoSを保証する問題は、「従来の」クラウドコンピューティングの問題ではありません。処理されるワークロードは、ネットワークの意味でのサーバーまたはクライアントであり、ほとんどパケットを処理しないためです。クラウドコンピューティングは、非常に分離された方法で共有サーバー上のアプリケーションのホスティングを提供します。その主な利点は、インフラストラクチャコストがテナント間で共有され、クラウドインフラストラクチャが、コスト効率の高い方法[intel_10_differences_nfv_cloud]では個々の施設では達成できないレベルの信頼性を提供することです。 NFVには、パフォーマンス、安定性、および一貫性に関して非常に厳しい要件があります。これを改善するためのいくつかのツールとメカニズムがありますが、拡張パフォーマンス認識（EPA）、シングルルートI / O仮想化（SR-IOV）、非均一メモリアクセス（NUMA）、データプレーン開発キット（DPDK）などがあります。 、、これらはまだ未解決の課題です。未解決の研究課題の1つは、仮想マシン（VM）とは異なり、ネットワーク機能の処理により適したテクノロジーを見つけることです。
Lately, a number of lightweight virtualization technologies including containers, unikernels (specialized VMs) and minimalistic distributions of general-purpose OSes have appeared as virtualization approaches that can be used when constructing an NFV platform. [LIGHT-NFV] describes the challenges in building such a platform and discusses to what extent these technologies, as well as traditional VMs, are able to address them.
最近、コンテナー、ユニカーネル（特殊なVM）、および汎用OSの最小限の配布を含む多くの軽量仮想化技術が、NFVプラットフォームを構築するときに使用できる仮想化アプローチとして登場しています。 [LIGHT-NFV]は、そのようなプラットフォームを構築する上での課題を説明し、これらのテクノロジーと従来のVMがそれらにどの程度対応できるかについて説明します。
Another relevant aspect is the need for tools for diagnostics and measurements suited for NFV. There is a pressing need to define metrics and associated protocols to measure the performance of NFV. Specifically, since NFV is based on the concept of taking centralized functions and evolving them to highly distributed software (SW) functions, there is a commensurate need to fully understand and measure the baseline performance of such systems.
別の関連する側面は、NFVに適した診断と測定のためのツールの必要性です。 NFVのパフォーマンスを測定するためのメトリックと関連プロトコルを定義する差し迫ったニーズがあります。具体的には、NFVは一元化された機能を採用して高度に分散されたソフトウェア（SW）機能に進化させるという概念に基づいているため、そのようなシステムのベースラインパフォーマンスを完全に理解して測定する必要があります。
The IP Performance Metrics (IPPM) WG defines metrics that can be used to measure the quality and performance of Internet services and applications running over transport-layer protocols (e.g., TCP and UDP) over IP. It also develops and maintains protocols for the measurement of these metrics. While the IPPM WG is a long-running WG that started in 1997, at the time of writing, it does not have a charter item or active Internet-Drafts related to the topic of network virtualization. In addition to using IPPM to evaluate QoS, there is a need for specific metrics for assessing the performance of network-virtualization techniques.
IPパフォーマンスメトリック（IPPM）WGは、IP上のトランスポート層プロトコル（TCPやUDPなど）で実行されているインターネットサービスおよびアプリケーションの品質とパフォーマンスを測定するために使用できるメトリックを定義します。また、これらのメトリックを測定するためのプロトコルを開発および保守します。 IPPM WGは、1997年に始まった長期的なWGですが、執筆時点では、ネットワーク仮想化のトピックに関連する憲章やアクティブなインターネットドラフトはありません。 IPPMを使用してQoSを評価することに加えて、ネットワーク仮想化技術のパフォーマンスを評価するための特定のメトリックが必要です。
The Benchmarking Methodology Working Group (BMWG) is also performing work related to NFV metrics. For example, [RFC8172] investigates additional methodological considerations necessary when benchmarking VNFs that are instantiated and hosted in general-purpose hardware, using bare-metal hypervisors or other isolation environments (such as Linux containers). An essential consideration is benchmarking physical and VNFs in the same way when possible, thereby allowing direct comparison.
ベンチマーク手法ワーキンググループ（BMWG）も、NFVメトリックに関連する作業を行っています。たとえば、[RFC8172]は、ベアメタルハイパーバイザーまたはその他の分離環境（Linuxコンテナーなど）を使用して、インスタンス化され、汎用ハードウェアでホストされているVNFをベンチマークするときに必要な追加の方法論の考慮事項を調査します。重要な考慮事項は、可能な場合は物理とVNFを同じ方法でベンチマークすることで、直接比較できるようにすることです。
There is a clear motivation for the work on performance metrics for NFV [etsi_gs_nfv_per_001], as stated in [RFC8172] (and replicated here):
[RFC8172]で述べられているように（そしてここで複製されている）、NFV [etsi_gs_nfv_per_001]のパフォーマンスメトリックに関する作業には明確な動機があります。
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 HW 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ベンダーが私が従ったHW推奨事項を提供したため、最初の手順は簡単でした。今、私は新しいベンダーからより多くのVNFを展開する必要があり、さまざまなハードウェアの推奨事項があります。新しいVNFは既存のハードウェアでどの程度うまく機能しますか？特定のカテゴリのいくつかの新しいVNFのうち、提供する容量の点で最も効率的なのはどれですか。また、ハードウェアプラットフォーム上でVNF（およびPNF）の複数のカテゴリを*同時に*操作して、リソースを共有する場合、新しいパフォーマンスの制限は何か、また、選択したハードウェアプラットフォームを最適化するためにできるソフトウェア設計の選択肢は何ですか？逆に、これらの同時に動作するVNFの容量を増やすには、どのようなハードウェアプラットフォームのアップグレードを行う必要がありますか？
Lately, there are also some efforts looking into VNF benchmarking. The selection of an NFV Infrastructure Point of Presence to host a VNF or allocation of resources (e.g., virtual CPUs, memory) needs to be done over virtualized (abstracted and simplified) resource views [vnf_benchmarking] [VNF-VBAAS].
最近、VNFベンチマークを検討する取り組みもあります。 VNFをホストするためのNFVインフラストラクチャのPoint of Presenceの選択またはリソース（仮想CPU、メモリなど）の割り当ては、仮想化（抽象化および簡略化）されたリソースビュー[vnf_benchmarking] [VNF-VBAAS]で行う必要があります。
On top of diagnostic tools that enable an assessment of the QoS, predictive analyses are required to react before anomalies occur. Due to the SW characteristics of VNFs, a reliable diagnosis framework could potentially enable the prevention of issues by a proper diagnosis and then a reaction in terms of acting on the potentially impacted service (e.g., migration to a different compute node, scaling in/out, up/down, etc.).
QoSの評価を可能にする診断ツールに加えて、異常が発生する前に対応するために予測分析が必要です。 VNFのソフトウェアの特性により、信頼性の高い診断フレームワークは、適切な診断によって問題の防止を可能にし、影響を受ける可能性のあるサービス（たとえば、別のコンピューティングノードへの移行、スケールイン/アウト）に対処するという観点からの反応を可能にする可能性があります。 、アップ/ダウンなど）。
Portability in NFV refers to the ability to run a given VNF on multiple NFVIs, that is, guaranteeing that the VNF would be able to perform its functions with a high and predictable performance given that a set of requirements on the NFVI resources is met. Therefore, portability is a key feature that, if fully enabled, would contribute to making the NFV environment achieve a better reliability than a traditional system. Implementing functionality in SW over "commodity" infrastructure should make it much easier to port/move functions from one place to another. However, this is not yet as ideal as it sounds, and there are aspects that are not fully tackled. The existence of different hypervisors, specific hardware dependencies (e.g., EPA related), or state-synchronization aspects are just some examples of troublemakers for portability purposes.
NFVの移植性とは、特定のVNFを複数のNFVIで実行する機能を指します。つまり、NFVIリソースに対する一連の要件が満たされていれば、VNFが高い予測可能なパフォーマンスで機能を実行できることを保証します。したがって、移植性は重要な機能であり、完全に有効にすると、NFV環境で従来のシステムよりも優れた信頼性を実現できるようになります。 「コモディティ」インフラストラクチャを介してSWに機能を実装すると、機能をある場所から別の場所に移植/移動することがはるかに簡単になります。ただし、これはまだ思ったほど理想的ではなく、十分に取り組んでいない側面もあります。さまざまなハイパーバイザーの存在、特定のハードウェアの依存関係（EPA関連など）、または状態同期の側面は、移植性を目的としたトラブルメーカーのほんの一例です。
The ETSI NFV ISG is doing work in relation to portability. [etsi_gs_nfv_per_001] provides a list of minimal features that the VM Descriptor and Compute Host Descriptor should contain for the appropriate deployment of VM images over an NFVI (i.e., a "telco data center"), in order to guarantee high and predictable performance of data-plane workloads while assuring their portability. In addition, [etsi_gs_nfv_per_001] provides a set of recommendations on the minimum requirements that hardware (HW) and hypervisor should have for a "telco data center" suitable for different workloads (data plane, control plane, etc.) present in VNFs. The purpose of
ETSI NFV ISGは、移植性に関する作業を行っています。 [etsi_gs_nfv_per_001]は、データの高い予測可能なパフォーマンスを保証するために、NFVI（つまり、「telcoデータセンター」）を介したVMイメージの適切な導入のためにVM記述子およびCompute Host Descriptorに含める必要がある最小限の機能のリストを提供します可搬性を確保しながら、平面ワークロード。さらに、[etsi_gs_nfv_per_001]は、ハードウェア（HW）とハイパーバイザーがVNFに存在するさまざまなワークロード（データプレーン、コントロールプレーンなど）に適した「電話会社のデータセンター」に必要な最小要件に関する一連の推奨事項を提供します。の目的
[etsi_gs_nfv_per_001] is to provide the list of VM requirements that should be included in the VM Descriptor template, and the list of HW capabilities that should be included in the Compute Host Descriptor (CHD) to assure predictable high performance. ETSI NFV assumes that the MANO functions will make the mix & match. Therefore, there are still several research challenges to be addressed here.
[etsi_gs_nfv_per_001]は、VM記述子テンプレートに含める必要があるVM要件のリストと、予測可能な高いパフォーマンスを保証するためにコンピュートホスト記述子（CHD）に含める必要があるHW機能のリストを提供します。 ETSI NFVは、MANO関数が混合と一致を行うことを前提としています。したがって、ここで取り組む必要があるいくつかの研究課題があります。
Virtualization is typically seen as a direct enabler of energy savings. Some of the enablers for this that are often mentioned [nfv_sota_research_challenges] are (i) the multiplexing gains achieved by centralizing functions in data centers reduce the overall energy consumed and (ii) the flexibility brought by network programmability enables to switch off infrastructure as needed in a much easier way. However, there is still a lot of room for improvement in terms of virtualization techniques to reduce the power consumption, such as enhanced-hypervisor technologies.
仮想化は通常、エネルギー節約を直接実現するものと見なされています。 [nfv_sota_research_challenges]が頻繁に言及されるこのためのイネーブラーの一部は、（i）データセンターで機能を集中化することにより達成される多重化のゲインにより、全体的な消費エネルギーを削減し、（ii）ネットワークプログラマビリティによってもたらされる柔軟性により、必要に応じてインフラストラクチャをオフに切り替えることができます。はるかに簡単な方法です。ただし、拡張ハイパーバイザテクノロジなど、消費電力を削減するための仮想化技術に関しては、まだ改善の余地がたくさんあります。
Some additional examples of research topics that could enable energy savings are [nfv_sota_research_challenges]:
エネルギー節約を可能にする可能性がある研究トピックのいくつかの追加の例は、[nfv_sota_research_challenges]です。
o Energy-aware scaling (e.g., reductions in CPU speeds and partially turning off some hardware components to meet a given energy consumption target.
o エネルギーを考慮したスケーリング（CPU速度の低下、特定のエネルギー消費目標を満たすために一部のハードウェアコンポーネントを部分的にオフにするなど）。
o Energy-aware function placement.
o エネルギー認識機能の配置。
o Scheduling and chaining algorithms, for example, adapting the network topology and operating parameters to minimize the operation cost (e.g., tracking energy costs to identify the cheapest prices).
o スケジューリングとチェーンアルゴリズム。たとえば、ネットワークトポロジと運用パラメータを調整して運用コストを最小化します（たとえば、エネルギーコストを追跡して最も安い価格を特定します）。
Note that it is also important to analyze the trade-off between energy efficiency and network performance.
エネルギー効率とネットワークパフォーマンスのトレードオフを分析することも重要です。
The use of NFV and SDN technologies can help improve link usage. SDN has already shown that it can greatly increase average link utilization (e.g., Google example [google_sdn_wan]). NFV adds more complexity (e.g., due to service-function chaining / VNF forwarding graphs), which needs to be considered. Aspects like the ones described in [NFVRG-TOPO] (on NFV data center topology design) have to be looked at carefully as well.
NFVおよびSDNテクノロジーを使用すると、リンクの使用率を向上させることができます。 SDNは、リンクの平均使用率を大幅に向上できることをすでに示しています（例：Googleの例[google_sdn_wan]）。 NFVはさらに複雑になるため（たとえば、サービス機能の連鎖/ VNF転送グラフによる）、これを考慮する必要があります。 [NFVRG-TOPO]（NFVデータセンターのトポロジー設計について）で説明されているような側面も注意深く検討する必要があります。
Market fragmentation has resulted in a multitude of network operators each focused on different countries and regions. This makes it difficult to create infrastructure services spanning multiple countries, such as virtual connectivity or compute resources, as no single operator has a footprint everywhere. Cross-domain orchestration of services over multiple administrations or over multi-domain single administrations will allow end-to-end network and service elements to mix in multi-vendor, heterogeneous technology, and resource environments [multi-domain_5GEx].
市場の断片化により、さまざまな国や地域に焦点を当てた多数のネットワークオペレーターが生まれました。このため、単一の事業者があらゆる場所に足跡を置くことはできないため、仮想接続やコンピューティングリソースなど、複数の国にまたがるインフラストラクチャサービスを作成することは困難です。複数の管理またはマルチドメインの単一管理にわたるサービスのクロスドメインオーケストレーションにより、エンドツーエンドのネットワークおよびサービス要素を、マルチベンダー、異種テクノロジー、およびリソース環境で混在させることができます[multi-domain_5GEx]。
For the specific use case of 'Network as a Service', it becomes even more important to ensure that Cross Domain Orchestration also takes care of hierarchy of networks and their association, with respect to provisioning tunnels and overlays.
「サービスとしてのネットワーク」の特定の使用例では、クロスドメインオーケストレーションがトンネルとオーバーレイのプロビジョニングに関して、ネットワークとその関連付けの階層も処理するようにすることがさらに重要になります。
Multi-domain orchestration is currently an active research topic, which is being tackled, among others, by ETSI NFV ISG and the 5GEx project <https://www.5gex.eu/> [MULTI-NMRG] [multi-domain_5GEx].
マルチドメインオーケストレーションは現在活発な研究トピックであり、とりわけETSI NFV ISGおよび5GExプロジェクト<https://www.5gex.eu/> [MULTI-NMRG] [multi-domain_5GEx]によって取り組んでいます。
Another side of the multi-domain problem is the integration/ harmonization of different management domains. A key example comes from Multi-access Edge Computing, which, according to ETSI, comes with its own MANO system and would require integration if interconnected to a generic NFV system.
マルチドメイン問題のもう1つの側面は、異なる管理ドメインの統合/調和です。主要な例はマルチアクセスエッジコンピューティングであり、ETSIによると、独自のMANOシステムが付属しており、汎用のNFVシステムに相互接続する場合は統合が必要です。
From the beginning of all 5G discussions in the research and industry fora, it has been agreed that 5G will have to address many more use cases than the preceding wireless generations, which first focused on voice services and then on voice and high-speed packet data services. In this case, 5G should be able to handle not only the same (or enhanced) voice and packet data services, but also emerging services like tactile Internet and the Internet of Things (IoT). These use cases take the requirements to opposite extremes, as some of them require ultra-low latency and higher-speed, whereas some others require ultra-low power consumption and high-delay tolerance.
研究および業界のフォーラムでのすべての5Gの議論の初めから、5Gは、最初の音声サービス、次に音声および高速パケットデータに重点を置いた以前のワイヤレス世代よりも多くのユースケースに対処する必要があることが合意されています。サービス。この場合、5Gは同じ（または拡張された）音声およびパケットデータサービスだけでなく、触覚インターネットやモノのインターネット（IoT）などの新しいサービスも処理できる必要があります。これらのユースケースは、極端に低いレイテンシと高速を必要とするものもあれば、超低消費電力と高い遅延許容度を必要とするものもあります。
Because of these very extreme 5G use cases, it is envisioned that selective combinations of radio access networks and core network components will have to be combined into a given network slice to address the specific requirements of each use case.
これらの非常に極端な5Gの使用例のため、無線アクセスネットワークとコアネットワークコンポーネントの選択的な組み合わせを特定のネットワークスライスに組み合わせて、各使用例の特定の要件に対処する必要があると想定されます。
For example, within the major IoT category, which is perhaps the most disrupting one, some autonomous IoT devices will have very low throughput, will have much longer sleep cycles (and therefore high latency), and a battery life time exceeding by a factor of thousands that of smartphones or some other devices that will have almost continuous control and data communications. Hence, it is envisioned that a customized network slice will have to be stitched together from virtual resources or sub-slices to meet these requirements.
たとえば、おそらく最も破壊的なものである主要なIoTカテゴリ内では、一部の自律型IoTデバイスはスループットが非常に低く、スリープサイクルが非常に長く（したがって待ち時間が長く）、バッテリ寿命が何千ものスマートフォンや、ほぼ継続的な制御とデータ通信を行うその他のデバイス。したがって、これらの要件を満たすために、カスタマイズされたネットワークスライスを仮想リソースまたはサブスライスからつなぎ合わせる必要があると想定されます。
The actual definition of a "network slice" from an IP infrastructure viewpoint is currently undergoing intense debate; see [COMS-PS], [NETSLICES], [SLICE-3GPP], and [ngmn_5G_whitepaper]. Network slicing is a key for introducing new actors in existing markets at a low cost -- by letting new players rent "blocks" of capacity, if the new business model enables performance that meets the application needs (e.g., broadcasting updates to many sensors with satellite broadcasting capabilities). However, more work needs to be done to define the basic architectural approach of how network slices will be defined and formed. For example, is it mostly a matter of defining the appropriate network models (e.g., YANG) to stitch the network slice from existing components? Or do end-to-end timing, synchronization, and other low-level requirements mean that more fundamental research has to be done?
IPインフラストラクチャの観点から見た「ネットワークスライス」の実際の定義については、現在、激しい議論が交わされています。 [COMS-PS]、[NETSLICES]、[SLICE-3GPP]、および[ngmn_5G_whitepaper]を参照してください。ネットワークスライシングは、既存の市場に新しい俳優を低コストで導入するための鍵です。新しいビジネスモデルがアプリケーションのニーズを満たすパフォーマンスを可能にする場合（たとえば、更新を多数のセンサーにブロードキャストする場合）衛星放送機能）。ただし、ネットワークスライスを定義および形成する方法の基本的なアーキテクチャアプローチを定義するには、さらに作業が必要です。たとえば、既存のコンポーネントからネットワークスライスをステッチするために、適切なネットワークモデル（YANGなど）を定義することが主な問題ですか？または、エンドツーエンドのタイミング、同期、およびその他の低レベルの要件により、より基本的な調査を行う必要があることを意味しますか？
The widespread use/discussion/practice of system and network virtualization technologies has led to new business opportunities, enlarging the offer of IT resources with virtual network and computing resources, among others. As a consequence, the network ecosystem now differentiates between the owner of physical resources, the Infrastructure Provider (InP), and the intermediary that conforms and delivers network services to the final customers, the Virtual Network Operator (VNO).
システムおよびネットワーク仮想化テクノロジーの広範な使用/ディスカッション/実践により、新しいビジネスチャンスが生まれ、特に仮想ネットワークやコンピューティングリソースを備えたITリソースの提供が拡大しています。その結果、ネットワークエコシステムは、物理リソースの所有者であるインフラストラクチャプロバイダー（InP）と、ネットワークサービスに適合して最終的な顧客である仮想ネットワークオペレーター（VNO）に配信する仲介者とを区別するようになりました。
VNOs aim to exploit the virtualized infrastructures to deliver new-and-improved services to their customers. However, current network virtualization techniques offer poor support for VNOs to control their resources. It has been considered that the InP is responsible for the reliability of the virtual resources, but there are several situations in which a VNO requires a finer control on its resources. For instance, dynamic events, such as the identification of new requirements or the detection of incidents within the virtual system, might urge a VNO to quickly reform its virtual infrastructure and resource allocation. However, the interfaces offered by current virtualization platforms do not offer the necessary functions for VNOs to perform the elastic adaptations they need to conduct in dynamic environments.
VNOは、仮想化されたインフラストラクチャを活用して、顧客に新しく改善されたサービスを提供することを目的としています。ただし、現在のネットワーク仮想化手法では、VNOがリソースを制御するためのサポートが不十分です。 InPは仮想リソースの信頼性に責任があると考えられてきましたが、VNOがそのリソースをより細かく制御する必要がある状況がいくつかあります。たとえば、新しい要件の特定や仮想システム内のインシデントの検出などの動的なイベントは、VNOに仮想インフラストラクチャとリソース割り当てを迅速に改革するように促す場合があります。ただし、現在の仮想化プラットフォームが提供するインターフェースは、動的な環境で実行する必要のある柔軟な適応を実行するためにVNOに必要な機能を提供していません。
Beyond their heterogeneity, which can be resolved by software adapters, current virtualization platforms do not have common methods and functions, so it is difficult for the virtual network controllers used by the VNOs to actually manage and control virtual resources instantiated on different platforms, not even considering different InPs. Therefore, it is necessary to reach a common definition of the functions that should be offered by underlying platforms to give such overlay controllers the possibility to allocate and deallocate resources dynamically and get monitoring data about them.
現在の仮想化プラットフォームには、ソフトウェアアダプターで解決できる異種性以外に、共通のメソッドと機能がないため、VNOが使用する仮想ネットワークコントローラーが、異なるプラットフォームでインスタンス化された仮想リソースを実際に管理および制御することは困難です。さまざまなInPを検討します。したがって、そのようなオーバーレイコントローラーにリソースを動的に割り当てたり割り当て解除したりして、それらに関する監視データを取得する可能性を与えるには、基盤となるプラットフォームによって提供される機能の共通定義に到達する必要があります。
Such common methods should be offered by all underlying controllers, regardless of being network-oriented (e.g., ODL, ONOS, and Ryu) or computing-oriented (e.g., OpenStack, OpenNebula, and Eucalyptus). Furthermore, it is important for those platforms to offer some "PUSH" function to report resource state, avoiding the need for the VNO's controller to "POLL" for such data. A starting point to get proper notifications within current REST APIs could be to consider the protocol proposed by the WEBPUSH WG [RFC8030].
このような一般的なメソッドは、ネットワーク指向（ODL、ONOS、Ryuなど）やコンピューティング指向（OpenStack、OpenNebula、Eucalyptusなど）に関係なく、すべての基盤となるコントローラーで提供する必要があります。さらに、これらのプラットフォームでは、リソースの状態を報告するための「PUSH」機能を提供し、VNOのコントローラーがそのようなデータを「ポーリング」する必要がないようにすることが重要です。現在のREST API内で適切な通知を取得するための開始点は、WEBPUSH WG [RFC8030]によって提案されたプロトコルを検討することです。
Finally, in order to establish a proper order and allow the coexistence and collaboration of different systems, a common ontology regarding network and system virtualization should be defined and agreed upon, so different and heterogeneous systems can understand each other without requiring reliance on specific adaptation mechanisms that might break with any update on any side of the relation.
最後に、適切な順序を確立し、異なるシステムの共存とコラボレーションを可能にするために、ネットワークとシステムの仮想化に関する共通のオントロジーを定義して合意する必要があります。これにより、特定の適応メカニズムに依存することなく、異なる異種システムが互いに理解できるようになります。これは、関係のいずれかの側で更新を行うと壊れる可能性があります。
The Internet of Things (IoT) refers to the vision of connecting a multitude of automated devices (e.g., lights, environmental sensors, traffic lights, parking meters, health and security systems, etc.) to the Internet for purposes of reporting and remote command and control of the device. This vision is being realized by a multi-pronged approach of standardization in various forums and complementary open-source activities. For example, in the IETF, support of IoT web services has been defined by an HTTP-like protocol adapted for IoT called "CoAP" [RFC7252]; and, lately, a group has been studying the need to develop a new network layer to support IP applications over Low-Power Wide Area Networks (LPWAN).
モノのインターネット（IoT）とは、レポートやリモートコマンドの目的で、多数の自動化されたデバイス（ライト、環境センサー、信号機、パーキングメーター、ヘルスおよびセキュリティシステムなど）をインターネットに接続するビジョンを指します。デバイスの制御。このビジョンは、さまざまなフォーラムでの標準化と補足的なオープンソース活動の多面的なアプローチによって実現されています。たとえば、IETFでは、IoT Webサービスのサポートは、「CoAP」[RFC7252]と呼ばれるIoTに適合したHTTPのようなプロトコルによって定義されています。そして最近、グループは、低電力ワイドエリアネットワーク（LPWAN）を介したIPアプリケーションをサポートするための新しいネットワーク層を開発する必要性を研究しています。
Elsewhere, for 5G cellular evolution, there is much discussion on the need for supporting virtual network slices for the expected massive numbers of IoT devices. A separate virtual network slice is considered necessary for different 5G IoT use cases because devices will have very different characteristics than typical cellular devices like smartphones [ngmn_5G_whitepaper], and the number of IoT devices is expected to be at least one or two orders of magnitude higher than other 5G devices (see Section 4.5).
その他、5Gセルラーの進化については、予想される膨大な数のIoTデバイスの仮想ネットワークスライスをサポートする必要性について多くの議論があります。デバイスは、スマートフォンなどの一般的な携帯電話デバイスとは非常に異なる特性を持ち、IoTデバイスの数は少なくとも1桁または2桁大きいと予想されるため、別々の仮想ネットワークスライスが異なる5G IoTユースケースに必要であると見なされます。他の5Gデバイスよりも（セクション4.5を参照）。
The specific nature of the IoT ecosystem, particularly reflected in the Machine-to-Machine (M2M) communications, leads to the creation of new and highly distributed systems which demand location-based network and computing services. A specific example can be represented by a set of "things" that suddenly require the setup of a firewall to allow external entities to access their data while outsourcing some computation requirements to more powerful systems relying on cloud-based services. This representative use case exposes important requirements for both NFV and the underlying cloud infrastructures.
特にMachine-to-Machine（M2M）通信に反映されているIoTエコシステムの固有の性質により、ロケーションベースのネットワークとコンピューティングサービスを必要とする、高度に分散された新しいシステムが作成されます。特定の例は、クラウドベースのサービスに依存するより強力なシステムに一部の計算要件をアウトソーシングしながら、外部エンティティがデータにアクセスできるようにファイアウォールの設定を突然必要とする一連の「もの」で表すことができます。この代表的な使用例は、NFVと基盤となるクラウドインフラストラクチャの両方の重要な要件を明らかにしています。
In order to provide the aforementioned location-based functions integrated with highly distributed systems, the so-called fog infrastructures should be able to instantiate VNFs, placing them in the required place, e.g., close to their consumers. This requirement implies that the interfaces offered by virtualization platforms must support the specification of location-based resources, which is a key function in those scenarios. Moreover, those platforms must also be able to interpret and understand the references used by IoT systems to their location (e.g., "My-AP" or "5BLDG+2F") and also the specification of identifiers linked to other resources, such as the case of requiring the infrastructure to establish a link between a specific Access Point (AP) and a specific virtual computing node. In summary, the research gap is exact localization of VNFs at far network edge infrastructure, which is highly distributed and dynamic.
高度に分散されたシステムと統合された前述の場所ベースの機能を提供するために、いわゆるフォグインフラストラクチャはVNFをインスタンス化して、必要な場所、たとえば消費者の近くに配置できる必要があります。この要件は、仮想化プラットフォームによって提供されるインターフェイスが、これらのシナリオで重要な機能である場所ベースのリソースの仕様をサポートする必要があることを意味します。さらに、これらのプラットフォームは、IoTシステムがその場所に使用する参照（「My-AP」または「5BLDG + 2F」など）や、他のリソースにリンクされている識別子の仕様などを解釈および理解できなければなりません。特定のアクセスポイント（AP）と特定の仮想コンピューティングノード間のリンクを確立するためにインフラストラクチャを必要とするケース。要約すると、研究ギャップは遠く離れたネットワークエッジインフラストラクチャでのVNFの正確なローカリゼーションであり、これは高度に分散された動的なものです。
Current network services deployed by operators often involve the composition of several individual functions (such as packet filtering, deep-packet inspection, load-balancing). These services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network, not necessarily on the direct data path. This requires traffic to be steered through the required service functions, wherever they are deployed [RFC7498].
事業者によって展開されている現在のネットワークサービスは、多くの場合、いくつかの個別の機能（パケットフィルタリング、ディープパケットインスペクション、ロードバランシングなど）の構成を伴います。これらのサービスは、通常、必ずしも直接データパス上ではなく、ネットワーク内のさまざまなポイントに展開されるいくつかのサービス機能の順序付けられた組み合わせによって実装されます。これは、トラフィックが展開される場所にかかわらず、必要なサービス機能を介してトラフィックを誘導する必要があります[RFC7498]。
For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called "Service Function Chaining" (SFC) [sfc_challenges], which is called "Network Function Forwarding Graph" (NF-FG) in ETSI. SFC is instantiated through the selection of specific service function instances on specific network nodes to form a service graph: this is called a "Service Function Path" (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.).
特定のサービスについて、必要なサービス機能とそれらが適用される順序の抽象化されたビューは「サービス機能チェーン」（SFC）[sfc_challenges]と呼ばれ、「ネットワーク機能転送グラフ」（NF-FG）と呼ばれます）ETSIで。 SFCは、特定のネットワークノード上の特定のサービス関数インスタンスを選択してインスタンス化され、サービスグラフを形成します。これは「サービス関数パス」（SFP）と呼ばれます。サービス機能は、ネットワークプロトコルスタック内の任意の層（ネットワーク層、トランスポート層、アプリケーション層など）に適用できます。
Service composition is a powerful means that can provide significant benefits when applied in a softwarized network environment. However, there are many research challenges in this area; for example, the ones related to composition mechanisms and algorithms to enable load-balancing and improve reliability. The service composition should also act as an enabler to gather information across all hierarchies (underlays and overlays) of network deployments that may span across multiple operators for faster serviceability, thus facilitating accomplishing aforementioned goals of "load-balancing and improving reliability".
サービス構成は、ソフトウェア化されたネットワーク環境に適用すると、大きなメリットをもたらす強力な手段です。ただし、この分野には多くの研究課題があります。たとえば、ロードバランシングを可能にし、信頼性を向上させるための構成メカニズムとアルゴリズムに関連するものです。また、サービス構成は、より迅速な保守性のために複数の事業者にまたがる可能性のあるネットワーク展開のすべての階層（アンダーレイとオーバーレイ）にわたって情報を収集するためのイネーブラーとしても機能する必要があります。
As described in [dynamic_chaining], different algorithms can be used to enable dynamic service composition that optimizes a QoS-based utility function (e.g., minimizing the latency per-application traffic flows) for a given composition plan. Such algorithms can consider the computation capabilities and load status of resources executing the VNF instances, either deduced through estimations from historical usage data or collected through real-time monitoring (i.e., context-aware selection). For this reason, selections should include references to dynamic information on the status of the service instance and its constituent elements, i.e., monitoring information related to individual VNF instances and links connecting them as well as derived monitoring information at the chain level (e.g., end-to-end delay). At runtime, if one or more VNF instances are no longer available or QoS degrades below a given threshold, the service selection task can be rerun to perform service substitution.
[dynamic_chaining]で説明されているように、QoSベースのユーティリティ機能を最適化する動的なサービス構成を可能にするために、さまざまなアルゴリズムを使用できます（たとえば、アプリケーショントラフィックフローごとのレイテンシの最小化）。このようなアルゴリズムは、VNFインスタンスを実行しているリソースの計算機能とロードステータスを考慮できます。これは、使用履歴データからの推定によって推定されるか、リアルタイムモニタリング（つまり、コンテキストアウェア選択）によって収集されます。このため、選択には、サービスインスタンスとその構成要素のステータスに関する動的情報への参照を含める必要があります。つまり、個々のVNFインスタンスとそれらを接続するリンクに関する監視情報、およびチェーンレベルでの派生監視情報（たとえば、エンド-to-end delay）。実行時に、1つ以上のVNFインスタンスが利用できなくなった場合、またはQoSが特定のしきい値を下回った場合、サービス選択タスクを再実行して、サービス置換を実行できます。
There are different research directions that relate to the previous point. For example, the use of Integer Linear Programming (ILP) techniques can be explored to optimize the management of diverse traffic flows. Deep-machine learning can also be applied to optimize service chains using information parameters, such as some of the ones mentioned above. Newer scheduling paradigms, like co-flows, can also be used.
以前のポイントに関連するさまざまな研究方向があります。たとえば、整数線形計画法（ILP）技術の使用を検討して、多様なトラフィックフローの管理を最適化できます。深層機械学習を適用して、上記のような情報パラメーターを使用してサービスチェーンを最適化することもできます。コフローなどの新しいスケジューリングパラダイムも使用できます。
The SFC working group is working on an architecture for SFC [RFC7665] that includes the necessary protocols or protocol extensions to convey the SFC and SFP information to nodes that are involved in the implementation of service functions and SFCs as well as mechanisms for steering traffic through service functions.
SFCワーキンググループは、SFCのアーキテクチャ[RFC7665]に取り組んでいます。これには、サービス機能とSFCの実装に関与するノードにSFCおよびSFP情報を伝達するために必要なプロトコルまたはプロトコル拡張、およびトラフィックをステアリングするメカニズムが含まれます。サービス機能。
In terms of actual work items, the SFC WG has not yet considered working on the management and configuration of SFC components related to the support of SFC. This part is of special interest for operators and would be required in order to actually put SFC mechanisms into operation. Similarly, redundancy and reliability mechanisms for SFC are currently not dealt with by any WG in the IETF. While this was the main goal of the VNFpool BoF efforts, it still remains unaddressed.
実際の作業項目に関して、SFC WGは、SFCのサポートに関連するSFCコンポーネントの管理と構成に取り組むことをまだ検討していません。この部分はオペレーターにとって特別な関心事であり、実際にSFCメカニズムを作動させるために必要です。同様に、SFCの冗長性と信頼性のメカニズムは、現在IETFのどのWGでも処理されていません。これはVNFpool BoFの取り組みの主な目標でしたが、まだ対処されていません。
So far, most of the network softwarization efforts have focused on virtualizing functions of network elements. While virtualization of network elements started with the core, mobile-network architectures are now heavily switching to also virtualize Radio Access Network (RAN) functions. The next natural step is to get virtualization down at the level of the end-user device (e.g., virtualizing a smartphone) [virtualization_mobile_device]. The cloning of a device in the cloud (central or local) bears attractive benefits to both the device and network operations alike (e.g., power saving at the device by offloading computational-heaving functions to the cloud, optimized networking -- both device-to-device and device-to-infrastructure) for service delivery through tighter integration of the device (via its clone in the networking infrastructure). This is, for example, being explored by the European H2020 ICIRRUS project <https://www.icirrus-5gnet.eu>.
これまでのところ、ネットワークのソフト化の取り組みのほとんどは、ネットワーク要素の機能の仮想化に重点を置いてきました。ネットワーク要素の仮想化はコアから始まりましたが、モバイルネットワークアーキテクチャは現在、無線アクセスネットワーク（RAN）機能も仮想化するように大幅に切り替えられています。次の自然なステップは、エンドユーザーデバイスのレベルで仮想化をダウンさせることです（たとえば、スマートフォンの仮想化）[virtualization_mobile_device]。クラウド（中央またはローカル）でのデバイスのクローン作成は、デバイスとネットワークの両方の操作に魅力的な利点をもたらします（たとえば、計算量の多い機能をクラウドにオフロードすることによるデバイスの省電力、最適化されたネットワーク-両方のデバイスから-デバイスとデバイスからインフラストラクチャへの接続）（ネットワークインフラストラクチャ内のそのクローンを介して）デバイスのより緊密な統合によるサービス配信。これは、たとえば、ヨーロッパのH2020 ICIRRUSプロジェクト<https://www.icirrus-5gnet.eu>によって調査されています。
Similar to any other situations where resources are shared, security and privacy are two important aspects that need to be taken into account.
リソースが共有される他のすべての状況と同様に、セキュリティとプライバシーは考慮に入れる必要がある2つの重要な側面です。
In the case of security, there are situations where multiple service providers will need to coexist in a virtual or hybrid physical/ virtual environment. This requires attestation procedures amongst different virtual/physical functions and resources as well as ongoing external monitoring. Similarly, different network slices operating on the same infrastructure can present security problems, for instance, if one slice running critical applications (e.g., support for a safety system) is affected by another slice running a less critical application. In general, the minimum common denominator for security measures on a shared system should be equal to or higher than the one required by the most-critical application. Multiple and continuous threat model analysis as well as a DevOps model are required to maintain a certain level of security in an NFV system. Simplistically, DevOps is a process that combines multiple functions into single cohesive teams in order to quickly produce quality software. Typically, it relies on also applying the Agile development process, which focuses on (among many things) dividing large features into multiple, smaller deliveries. One part of this is to immediately test the new smaller features in order to get immediate feedback on errors so that if present, they can be immediately fixed and redeployed.
セキュリティの場合、複数のサービスプロバイダーが仮想環境または物理/仮想ハイブリッド環境で共存する必要がある状況があります。これには、さまざまな仮想/物理機能およびリソース間での証明手順と、継続的な外部監視が必要です。同様に、たとえば、重要なアプリケーションを実行している1つのスライス（たとえば、安全システムのサポート）が重要度の低いアプリケーションを実行している別のスライスの影響を受ける場合、同じインフラストラクチャで動作する異なるネットワークスライスはセキュリティの問題を引き起こす可能性があります。一般に、共有システムのセキュリティ対策の最小の共通要素は、最も重要なアプリケーションで必要なものと同じかそれ以上にする必要があります。 NFVシステムで特定のレベルのセキュリティを維持するには、複数の継続的な脅威モデル分析とDevOpsモデルが必要です。簡単に言うと、DevOpsは、高品質のソフトウェアを迅速に作成するために、複数の機能を1つのまとまったチームに結合するプロセスです。通常、これはアジャイル開発プロセスの適用にも依存します。アジャイル開発プロセスは、（とりわけ）大きな機能を複数の小さな配信に分割することに焦点を当てています。これの一部は、新しい小さな機能をすぐにテストしてエラーに関するフィードバックを即座に取得し、存在する場合はすぐに修正して再デプロイできるようにすることです。
On the other hand, privacy refers to concerns about the control of personal data and the decision of what to reveal to whom. In this case, the storage, transmission, collection, and potential correlation of information in the NFV system, for purposes not originally intended or not known by the user, should be avoided. This is particularly challenging, as future intentions and threats cannot be easily predicted and still can be applied on data collected in the past. Therefore, well-known techniques, such as data minimization using privacy features as default and allowing users to opt in/out, should be used to prevent potential privacy issues.
一方、プライバシーとは、個人データの管理と誰に何を公開するかの決定に関する懸念を指します。この場合、NFVシステム内での情報の保存、送信、収集、および潜在的な相関関係は、本来意図されていない、またはユーザーが知らない目的のために、回避する必要があります。将来の意図や脅威を簡単に予測できず、過去に収集されたデータにも適用できるため、これは特に困難です。したがって、プライバシー機能をデフォルトとして使用し、ユーザーがオプトイン/オプトアウトできるようにするデータ最小化などのよく知られた手法を使用して、潜在的なプライバシーの問題を回避する必要があります。
Compared to traditional networks, NFV will result in networks that are much more dynamic (in function distribution and topology) and elastic (in size and boundaries). Thus, NFV will require network operators to evolve their operational and administrative security solutions to work in this new environment. For example, in NFV, the network orchestrator will become a key node to provide security policy orchestration across the different physical and virtual components of the virtualized network. For highly confidential data, for example, the network orchestrator should take into account if certain physical HW of the network is considered to be more secure (e.g., because it is located in secure premises) than other HW.
従来のネットワークと比較して、NFVの結果、ネットワークははるかに動的になり（関数の分散とトポロジーが）、弾力性のある（サイズと境界が）なります。したがって、NFVは、この新しい環境で動作するようにネットワークオペレーターに運用および管理セキュリティソリューションを進化させることを要求します。たとえば、NFVでは、ネットワークオーケストレーターは、仮想化ネットワークのさまざまな物理コンポーネントと仮想コンポーネント全体にセキュリティポリシーオーケストレーションを提供するための重要なノードになります。たとえば、機密性の高いデータの場合、ネットワークオーケストレータは、ネットワークの特定の物理ハードウェアが他のハードウェアよりも安全であると考えられる場合（たとえば、安全な構内にあるため）を考慮する必要があります。
Traditional telecom networks typically run under a single administrative domain controlled by (exactly) one operator. With NFV, it is expected that in many cases, the telecom operator will now become a tenant (running the VNFs), and the infrastructure (NFVI) may be run by a different operator and/or cloud service provider (see also Section 4.4). Thus, there will be multiple administrative domains involved, making security policy coordination more complex. For example, who will be in charge of provisioning and maintaining security credentials such as public and private keys? Also, should private keys be allowed to be replicated across the NFV for redundancy reasons? Alternatively, it can be investigated how to develop a mechanism that avoids such a security policy coordination, thus making the system more robust.
従来の通信ネットワークは、通常、（厳密に）1人のオペレーターによって制御される単一の管理ドメインの下で実行されます。 NFVを使用すると、多くの場合、通信事業者は（VNFを実行する）テナントになり、インフラストラクチャ（NFVI）は別の事業者やクラウドサービスプロバイダーによって実行されることが予想されます（セクション4.4も参照） 。したがって、複数の管理ドメインが関与し、セキュリティポリシーの調整がより複雑になります。たとえば、公開キーや秘密キーなどのセキュリティ資格情報のプロビジョニングと維持を担当するのは誰ですか。また、冗長性の理由から、秘密鍵をNFV全体に複製できるようにする必要がありますか？または、そのようなセキュリティポリシーの調整を回避してシステムをより堅牢にするメカニズムを開発する方法を調査することもできます。
On a positive note, NFV may better defend against denial-of-service (DoS) attacks because of the distributed nature of the network (i.e., no single point of failure) and the ability to steer (undesirable) traffic quickly [etsi_gs_nfv_sec_001]. Also, NFVs that have physical HW that is distributed across multiple data centers will also provide better fault isolation environments. Particularly, this holds true if each data center is protected separately via firewalls, Demilitarized Zones (DMZs), and other network-protection techniques.
ポジティブな点として、NFVは、ネットワークの分散型の性質（つまり、単一障害点がない）とトラフィックをすばやく操作する（望ましくない）機能[etsi_gs_nfv_sec_001]により、サービス拒否（DoS）攻撃からの防御を強化する可能性があります。また、複数のデータセンターに分散された物理ハードウェアを備えたNFVも、より優れた障害分離環境を提供します。特に、ファイアウォール、非武装地帯（DMZ）、およびその他のネットワーク保護技術を介して各データセンターが個別に保護されている場合、これは当てはまります。
SDN can also be used to help improve security by facilitating the operation of existing protocols, such as Authentication, Authorization and Accounting (AAA). The management of AAA infrastructures, namely the management of AAA routing and the establishment of security associations between AAA entities, can be performed using SDN, as analyzed in [SDN-AAA].
SDNは、認証、承認、アカウンティング（AAA）などの既存のプロトコルの操作を容易にすることにより、セキュリティの向上にも役立ちます。 [SDN-AAA]で分析されているように、AAAインフラストラクチャの管理、つまりAAAルーティングの管理とAAAエンティティ間のセキュリティアソシエーションの確立は、SDNを使用して実行できます。
NFV environments offer two possible levels of SDN control. One level is the need for controlling the NFVI to provide connectivity end-to-end among VNFs or among VNFs and Physical Network Functions (PNFs). A second level is the control and configuration of the VNFs themselves (in other words, the configuration of the network service implemented by those VNFs), taking advantage of the programmability brought by SDN. Both control concerns are separated in nature. However, interaction between both could be expected in order to optimize, scale, or influence each other.
NFV環境は、2つのレベルのSDN制御を提供します。 1つのレベルは、NFVを制御してVNF間またはVNFと物理ネットワーク機能（PNF）間でエンドツーエンドの接続を提供する必要性です。 2番目のレベルは、SDNによってもたらされるプログラマビリティを利用した、VNF自体の制御と構成（つまり、それらのVNFによって実装されるネットワークサービスの構成）です。両方の管理上の懸念は本質的に分離されています。ただし、最適化、スケーリング、または相互に影響を与えるために、両方の相互作用が期待できます。
Clear mechanisms for such interactions are needed in order to avoid malfunctioning or interference concerns. These ideas are considered in [etsi_gs_nfv_eve005] and [LAYERED-SDN].
誤動作や干渉の問題を回避するために、このような相互作用の明確なメカニズムが必要です。これらのアイデアは、[etsi_gs_nfv_eve005]と[LAYERED-SDN]で検討されています。
Network function placement is a problem in any kind of network telecommunications infrastructure. Moreover, the increased degree of freedom added by network virtualization makes this problem even more important, and also harder to tackle. Deciding where to place VNFs is a resource-allocation problem that needs to (or may) take into consideration quite a few aspects: resiliency, (anti-)affinity, security, privacy, energy efficiency, etc.
ネットワーク機能の配置は、あらゆる種類のネットワーク通信インフラストラクチャの問題です。さらに、ネットワーク仮想化によって追加された自由度の増加により、この問題はさらに重要になり、対処も困難になります。 VNFを配置する場所を決定することは、リソース割り当ての問題であり、非常に多くの側面を考慮に入れる必要があります（または考慮する可能性があります）。
When several functions are chained (typical scenario), placement algorithms become more complex and important (as described in Section 4.6). While there has been research on the topic ([nfv_piecing], [dynamic_placement], and [vnf-p]), this still remains an open challenge that requires more attention. The use of multi-domains adds another component of complexity to this problem that has to be considered.
複数の関数がチェーン化されると（典型的なシナリオ）、配置アルゴリズムはより複雑で重要になります（セクション4.6で説明）。トピック（[nfv_piecing]、[dynamic_placement]、および[vnf-p]）に関する調査が行われていますが、これは未だ未解決の課題であり、さらに注意が必要です。マルチドメインを使用すると、考慮しなければならないこの問題に別の複雑な要素が追加されます。
The impacts of network virtualization on testing can be divided into three groups:
テストに対するネットワーク仮想化の影響は、3つのグループに分類できます。
1. Changes in methodology
1. 方法論の変更
2. New functionality
2. 新機能
3. Opportunities
3. 機会
The largest impact of NFV is the ability to isolate the System Under Test (SUT). When testing PNFs, isolating the SUT means that all the other devices that the SUT communicates with are replaced with simulations (or controlled executions) in order to place the SUT under test by itself. The SUT may be comprised of one or more devices. The simulations use the appropriate traffic type and protocols in order to execute test cases.
NFVの最大の影響は、テスト対象システム（SUT）を分離する機能です。 PNFをテストする場合、SUTを分離するとは、SUTが通信する他のすべてのデバイスをシミュレーション（または制御された実行）に置き換えて、SUTを単独でテストすることを意味します。 SUTは1つ以上のデバイスで構成されます。シミュレーションでは、テストケースを実行するために適切なトラフィックタイプとプロトコルを使用します。
As shown in Figure 2, NFV provides a common architecture for all functions to use. A VNF is executed using resources offered by the NFVI, which have been allocated using the MANO function. It is not possible to test a VNF by itself, without the entire supporting environment present. This fundamentally changes how to consider the SUT. In the case of a VNF (or multiple VNFs), the SUT is part of a larger architecture that is necessary in order to run the SUTs.
図2に示すように、NFVは、使用するすべての機能に共通のアーキテクチャを提供します。 VNFは、MANO関数を使用して割り当てられたNFVIによって提供されるリソースを使用して実行されます。サポート環境全体が存在しないと、VNFを単独でテストすることはできません。これにより、SUTの検討方法が根本的に変わります。 VNF（または複数のVNF）の場合、SUTは、SUTを実行するために必要なより大きなアーキテクチャの一部です。
Therefore, isolation of the SUT becomes controlling the environment in a disciplined manner. The components of the environment necessary to run the SUTs that are not part of the SUT itself become the test environment. In the case of VNFs that are part of the SUT, the NFVI and MANO become the test environment. The configurations and policies that guide the test environment should remain constant during the execution of the tests, and also from test to test. Configurations such as CPU pinning, NUMA configuration, the SW versions and configurations of the hypervisor, vSwitch and NICs should remain constant. The only variables in the testing should be those controlling the SUT itself. If any configuration in the test environment is changed from test to test, the results become very difficult, if not impossible, to compare since the test environment behavior may change the results as a consequence of the configuration change.
したがって、SUTの分離により、規律ある方法で環境が制御されます。 SUTの一部ではないSUTの実行に必要な環境のコンポーネントがテスト環境になります。 SUTの一部であるVNFの場合、NFVIとMANOがテスト環境になります。テスト環境を導く構成とポリシーは、テストの実行中、およびテスト間で一定に保つ必要があります。 CPUピニング、NUMA構成、SWバージョン、ハイパーバイザー、vSwitch、NICの構成などの構成は、一定に保つ必要があります。テストの唯一の変数は、SUT自体を制御するものでなければなりません。テスト環境の構成をテストごとに変更すると、構成変更の結果としてテスト環境の動作によって結果が変わる可能性があるため、結果を比較することは不可能ではないにしても非常に困難になります。
Testing the NFVI itself also presents new considerations. With a PNF, the dedicated hardware supporting it is optimized for the particular workload of the function. Routing hardware is specially built to support packet forwarding functions, while the hardware to support a purely control-plane application (say, a DNS server, or a Diameter function) will not have this specialized capability. In NFV, the NFVI is required to support all types of potentially different workload types.
NFVI自体のテストでは、新しい考慮事項も提示されます。 PNFを使用すると、それをサポートする専用ハードウェアは、関数の特定のワークロード用に最適化されます。ルーティングハードウェアは、パケット転送機能をサポートするために特別に構築されていますが、純粋なコントロールプレーンアプリケーション（たとえば、DNSサーバーやDiameter機能）をサポートするハードウェアには、この特別な機能はありません。 NFVでは、NFVIはすべてのタイプの潜在的に異なるワークロードタイプをサポートする必要があります。
Therefore, testing the NFVI requires careful consideration about what types of metrics are sought. This, in turn, depends on the workload type the expected VNF will be. Examples of different workload types are data forwarding, control plane, encryption, and authentication. All these types of expected workloads will determine the types of metrics that should be sought. For example, if the workload is control plane, then a metric such as jitter is not useful, but dropped packets are critical. In a multi-tenant environment, the NFVI could support various types of workloads. In this case, testing with a variety of traffic types while measuring the corresponding metrics simultaneously becomes necessary.
したがって、NFVIをテストするには、どのタイプのメトリックが求められているかについて慎重に検討する必要があります。これは、予想されるVNFのワークロードタイプによって異なります。さまざまなワークロードタイプの例には、データ転送、コントロールプレーン、暗号化、および認証があります。これらすべてのタイプの予想されるワークロードにより、求めるべきメトリックのタイプが決まります。たとえば、ワークロードがコントロールプレーンの場合、ジッターなどのメトリックは役に立ちませんが、ドロップされたパケットは重要です。マルチテナント環境では、NFVIはさまざまなタイプのワークロードをサポートできます。この場合、対応するメトリックを同時に測定しながら、さまざまなトラフィックタイプでテストする必要があります。
Test beds for any type of testing for an NFV-based system will be largely similar to previously used test architectures. The methods are impacted by virtualization, as described above, but the design of test beds are similar as in the past. There are two main new considerations:
NFVベースのシステムのあらゆるタイプのテストのテストベッドは、以前に使用されたテストアーキテクチャとほぼ同じです。前述のように、方法は仮想化の影響を受けますが、テストベッドの設計はこれまでと同様です。 2つの主な新しい考慮事項があります。
o Since networking is based on software, which has lead to greater automation in deployment, the test system should also be deployable with the rest of the system in order to fully automate the system. This is especially relevant in a DevOps environment supported by a Continuous Integration and Continuous Deployment (CI/CD) tool chain (see Section 4.11.3 below).
o ネットワーキングはソフトウェアに基づいているため、導入の自動化が進んでいるため、システムを完全に自動化するために、テストシステムもシステムの残りの部分とともに導入できる必要があります。これは、継続的インテグレーションと継続的デプロイメント（CI / CD）ツールチェーン（以下のセクション4.11.3を参照）でサポートされるDevOps環境に特に関係します。
o In any performance test bed, the test system should not share the same resources as the SUT. While multi-tenancy is a reality in virtualization, having the test system share resources with the SUT will impact the measured results in a performance test bed. The test system should be deployed on a separate platform in order not to impact the resources available to the SUT.
o どのパフォーマンステストベッドでも、テストシステムはSUTと同じリソースを共有しないでください。仮想化ではマルチテナンシーが現実ですが、テストシステムがSUTとリソースを共有すると、パフォーマンステストベッドでの測定結果に影響します。 SUTで利用可能なリソースに影響を与えないように、テストシステムは別のプラットフォームに展開する必要があります。
NFV presents a collection of new functionality in order to support the goal of software networking. Each component on the architecture shown in Figure 2 has an associated set of functionality that allows VNFs to run the following: onboarding, life-cycle management for VNFs and Network Services (NS), resource allocation, hypervisor functions, etc.
NFVは、ソフトウェアネットワーキングの目標をサポートするために、新しい機能のコレクションを提供します。図2に示すアーキテクチャの各コンポーネントには、VNFがオンボーディング、VNFとネットワークサービス（NS）のライフサイクル管理、リソース割り当て、ハイパーバイザー機能などを実行できるようにする関連機能セットがあります。
One of the new capabilities enabled by NFV is VNF Forwarding Graphs (VNFFG). This refers to the graph that represents a network service by chaining together VNFs into a forwarding path. In practice, the forwarding path can be implemented in a variety of ways using different networking capabilities: vSwitch, SDN, and SDN with a northbound application. Additionally, the VNFFG might use tunneling protocols like Virtual eXtensible Local Area Network (VXLAN). The dynamic allocation and implementation of these networking paths will have different performance characteristics depending on the methods used. The path implementation mechanism becomes a variable in the network testing of the NSs. The methodology used to test the various mechanisms should largely remain the same; as usual, the test environment should remain constant for each of the tests, focusing on varying the path establishment method.
NFVによって可能になる新機能の1つは、VNF転送グラフ（VNFFG）です。これは、VNFを転送パスにチェーンすることによってネットワークサービスを表すグラフを指します。実際には、フォワーディングパスは、vSwitch、SDN、ノースバウンドアプリケーションを使用するSDNなど、さまざまなネットワーク機能を使用してさまざまな方法で実装できます。さらに、VNFFGはVirtual eXtensible Local Area Network（VXLAN）などのトンネリングプロトコルを使用する場合があります。これらのネットワークパスの動的な割り当てと実装は、使用する方法に応じて異なるパフォーマンス特性を持ちます。パス実装メカニズムは、NSのネットワークテストで変数になります。さまざまなメカニズムをテストするために使用される方法論は、ほとんど同じままでなければなりません。いつものように、テスト環境は、パス確立方法の変更に焦点を合わせて、各テストで一定に保つ必要があります。
"Scaling" refers to the change in allocation of resources to a VNF or NS. It happens dynamically at run-time, based on defined policies and triggers. The triggers can be network, compute, or storage based. Scaling can allocate more resources in times of need, or reduce the amount of resources allocated when the demand is reduced. The SUT in this case becomes much larger than the VNF itself: MANO controls how scaling is done based on policies, and then allocates the resources accordingly in the NFVI. Essentially, the testing of scaling includes the entire NFV architecture components into the SUT.
「スケーリング」とは、VNFまたはNSへのリソースの割り当ての変更を指します。定義されたポリシーとトリガーに基づいて、実行時に動的に発生します。トリガーは、ネットワーク、コンピューティング、またはストレージベースにすることができます。スケーリングにより、必要なときにより多くのリソースを割り当てることができます。または、需要が減少したときに割り当てられるリソースの量を減らすことができます。この場合のSUTはVNF自体よりもはるかに大きくなります。MANOは、ポリシーに基づいてスケーリングの方法を制御し、それに応じてNFVIでリソースを割り当てます。基本的に、スケーリングのテストには、NFVアーキテクチャコンポーネント全体がSUTに含まれています。
Softwarization of networking functionality leads to softwarization of the test as well. As PNFs are being transformed into VNFs, so are the test tools. This leads to the fact that test tools are also being controlled and executed in the same environment as the VNFs. This presents an opportunity to include VNF-based test tools along with the deployment of the VNFs supporting the services of the service provider into the host data centers. Therefore, tests can be automatically executed upon deployment in the target environment, for each deployment, and each service. With PNFs, this was very difficult to achieve.
ネットワーク機能のソフトウォーカリゼーションは、テストのソフトウォーカリゼーションにもつながります。 PNFがVNFに変換されているので、テストツールもそうです。これにより、テストツールもVNFと同じ環境で制御および実行されます。これは、サービスプロバイダーのサービスをサポートするVNFをホストデータセンターに展開するとともに、VNFベースのテストツールを含める機会を提供します。したがって、ターゲット環境での展開時に、各展開および各サービスに対してテストを自動的に実行できます。 PNFでは、これを達成するのは非常に困難でした。
This new concept helps to enable modern concepts like DevOps and Continuous Integration and Continuous Deployment in the NFV environment. The CI/CD pipeline supports this concept. It consists of a series of tools, among which immediate testing is an integral part, to deliver software from source to deployment. The ability to deploy the test tools themselves into the production environment stretches the CI/CD pipeline all the way to production deployment, allowing a range of tests to be executed. The tests can be simple, with a goal of verifying the correct deployment and networking establishment, but can also be more complex, like testing VNF functionality.
この新しいコンセプトは、NFV環境でのDevOps、継続的インテグレーション、継続的デプロイメントなどの最新のコンセプトを実現するのに役立ちます。 CI / CDパイプラインはこの概念をサポートしています。これは、ソフトウェアをソースからデプロイメントに配信するための即時テストが不可欠な部分である一連のツールで構成されています。テストツール自体を本番環境にデプロイする機能により、CI / CDパイプラインが本番デプロイメントまで拡張され、さまざまなテストを実行できます。テストは単純で、正しい展開とネットワークの確立を確認することを目的とする場合がありますが、VNF機能のテストのように、より複雑な場合もあります。
Table 1 correlates the open network virtualization research areas identified in this document to potential IETF and IRTF groups that could address some aspects of them. An example of a specific gap that the group could potentially address is identified as a parenthetical beside the group name.
表1は、このドキュメントで特定されているオープンネットワーク仮想化の研究分野と、それらのいくつかの側面に対処できる潜在的なIETFおよびIRTFグループを関連付けています。グループが対処できる可能性のある特定のギャップの例は、グループ名の横の括弧として識別されます。
+-------------------------+-----------------------------------------+
| Open Research Area | Potential IETF/IRTF Group |
+-------------------------+-----------------------------------------+
| 1) Guaranteeing QoS | IPPM WG (Measurements of NFVI) |
| | |
| 2) Performance | SFC WG, NFVRG (energy-driven |
| improvement | orchestration) |
| | |
| 3) Multiple Domains | NFVRG (multi-domain orchestration) |
| | |
| 4) Network Slicing | NVO3 WG, NETSLICES bar BoF (multi- |
| | tenancy support) |
| | |
| 5) Service Composition | SFC WG (SFC Mgmt and Config) |
| | |
| 6) End-user device | N/A |
| virtualization | |
| | |
| 7) Security | N/A |
| | |
| 8) Separation of | NFVRG (separation between transport |
| control concerns | control and services) |
| | |
| 9) Testing | NFVRG (testing of scaling) |
| | |
| 10) Function placement | NFVRG, SFC WG (VNF placement algorithms |
| | and protocols) |
+-------------------------+-----------------------------------------+
Table 1: Mapping of Open Research Areas to Potential IETF Groups
表1：潜在的なIETFグループへのオープンリサーチエリアのマッピング
Table 2 correlates the currently identified NFVRG topics of interest / focus areas to the open network virtualization research areas enumerated in this document. This can help the NFVRG in identifying and prioritizing research topics. The current list of NFVRG focus points is the following:
表2は、現在特定されている関心のあるNFVRGトピックと重点分野を、このドキュメントで列挙されているオープンネットワーク仮想化の研究分野と関連付けています。これは、NFVRGが研究トピックを特定して優先順位を付けるのに役立ちます。 NFVRGフォーカスポイントの現在のリストは次のとおりです。
o Re-architecting functions, including aspects such as new architectural and design patterns (e.g., containerization, statelessness, serverless, control/data plane separation), SDN integration, and proposals on programmability.
o 新しいアーキテクチャーおよび設計パターン（コンテナー化、ステートレス、サーバーレス、コントロール/データプレーンの分離など）、SDN統合、プログラマビリティに関する提案などの側面を含む、機能の再構築。
o New management frameworks, considering aspects related to new OAM mechanisms (e.g., configuration control, hybrid descriptors) and lightweight MANO proposals.
o 新しいOAMメカニズム（構成制御、ハイブリッド記述子など）に関連する側面と軽量なMANOの提案を考慮した新しい管理フレームワーク。
o Techniques to guarantee low latency, resource isolation, and other data-plane features, including hardware acceleration, functional offloading to data-plane elements (including NICs), and related approaches.
o ハードウェアアクセラレーション、データプレーンエレメント（NICを含む）への機能的オフロード、および関連するアプローチなど、低レイテンシ、リソース分離、およびその他のデータプレーン機能を保証する手法。
o Measurement and benchmarking, addressing both internal measurements and external applications.
o 内部測定と外部アプリケーションの両方に対応する測定とベンチマーク。
+-------------------------------------+-------------------------+
| NFVRG Focus Point | Open Research Area |
+-------------------------------------+-------------------------+
| 1) Re-architecting functions | - Performance improvem. |
| | - Network Slicing |
| | - Guaranteeing QoS |
| | - Security |
| | - End-user device virt. |
| | - Separation of control |
| | |
| 2) New management frameworks | - Multiple Domains |
| | - Service Composition |
| | - End-user device virt. |
| | |
| 3) Low latency, resource isolation, | - Performance improvem. |
| etc. | - Separation of control |
| | |
| 4) Measurement and benchmarking | - Guaranteeing QoS |
| | - Testing |
+-------------------------------------+-------------------------+
Table 2: Mapping of NFVRG Focus Points to Open Research Areas
表2：オープンリサーチエリアへのNFVRGフォーカスポイントのマッピング
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This is an Informational RFC that details research challenges; it does not introduce any security threat. Research challenges and gaps related to security and privacy have been included in Section 4.8.
これは、研究の課題を詳しく説明する情報RFCです。セキュリティ上の脅威はありません。セキュリティとプライバシーに関連する研究課題とギャップは、セクション4.8に含まれています。
[COMS-PS] Geng, L., Slawomir, S., Qiang, L., Matsushima, S., Galis, A., and L. Contreras, "Problem Statement of Common Operation and Management of Network Slicing", Work in Progress, draft-geng-coms-problem-statement-04, March 2018.
[COMS-PS] Geng、L.、Slawomir、S.、Qiang、L.、Matsushima、S.、Galis、A.、and L. Contreras、 "Problem Statement of Common Operation and Management of Network Slicing"、Work in進捗状況、draft-geng-coms-problem-statement-04、2018年3月。
[dynamic_chaining] Martini, B. and F. Paganelli, "A Service-Oriented Approach for Dynamic Chaining of Virtual Network Functions over Multi-Provider Software-Defined Networks", Future Internet Vol. 8, No. 2, DOI 10.3390/fi8020024, June 2016.
[dynamic_chaining] Martini、B。およびF. Paganelli、「マルチプロバイダーソフトウェア定義ネットワーク上の仮想ネットワーク機能の動的チェーンのためのサービス指向アプローチ」、Future Internet Vol。 8、No。2、DOI 10.3390 / fi8020024、2016年6月。
[dynamic_placement] Clayman, S., Maini, E., Galis, A., Manzalini, A., and N. Mazzocca, "The dynamic placement of virtual network functions", 2014 IEEE Network Operations and Management Symposium (NOMS) pp. 1-9, DOI 10.1109/NOMS.2014.6838412, May 2014.
[dynamic_placement] Clayman、S.、Maini、E.、Galis、A.、Manzalini、A.、and N. Mazzocca、 "動的配置の仮想ネットワーク機能"、2014 IEEEネットワーク運用および管理シンポジウム（NOMS）pp。 1-9、DOI 10.1109 / NOMS.2014.6838412、2014年5月。
[etsi_gs_nfv_003] ETSI NFV ISG, "Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1 NFV 003, December 2014, <http://www.etsi.org/deliver/etsi_gs/ NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.
[etsi_gs_nfv_003] ETSI NFV ISG、「ネットワーク機能仮想化（NFV）; NFVの主な概念の用語」、ETSI GS NFV 003 V1.2.1 NFV 003、2014年12月、<http://www.etsi.org/deliver/etsi_gs / NFV / 001_099 / 003 / 01.02.01_60 / gs_NFV003v010201p.pdf>。
[etsi_gs_nfv_eve005] ETSI NFV ISG, "Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV Architectural Framework", ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005, December 2015, <http://www.etsi.org/deliver/etsi_gs/NFV-EVE/001_099/ 005/01.01.01_60/gs_NFV-EVE005v010101p.pdf>.
[etsi_gs_nfv_eve005] ETSI NFV ISG、「Network Functions Virtualization（NFV）; Ecosystem; Report on SDN Usage in NFV Architectural Framework」、ETSI GS NFV-EVE 005 V1.1.1 NFV-EVE 005、12月2015、<http：// www .etsi.org / deliver / etsi_gs / NFV-EVE / 001_099 / 005 / 01.01.01_60 / gs_NFV-EVE005v010101p.pdf>。
[etsi_gs_nfv_per_001] ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV Performance & Portability Best Practises", ETSI GS NFV-PER 001 V1.1.2 NFV-PER 001, December 2014, <https://www.etsi.org/deliver/etsi_gs/nfv-per/ 001_099/001/01.01.02_60/gs_nfv-per001v010102p.pdf>.
[etsi_gs_nfv_per_001] ETSI NFV ISG、「Network Functions Virtualization（NFV）; NFV Performance＆Portability Best Practises」、ETSI GS NFV-PER 001 V1.1.2 NFV-PER 001、2014年12月、<https://www.etsi.org /配信/ etsi_gs / nfv-per / 001_099 / 001 / 01.01.02_60 / gs_nfv-per001v010102p.pdf>。
[etsi_gs_nfv_sec_001] ETSI NFV ISG, "Network Functions Virtualisation (NFV); NFV Security; Problem Statement", ETSI GS NFV-SEC 001 V1.1.1 NFV-SEC 001, October 2014, <http://www.etsi.org/deliver/ etsi_gs/NFV-SEC/001_099/001/01.01.01_60/ gs_NFV-SEC001v010101p.pdf>.
[etsi_gs_nfv_sec_001] ETSI NFV ISG、「Network Functions Virtualization（NFV）; NFV Security; Problem Statement」、ETSI GS NFV-SEC 001 V1.1.1 NFV-SEC 001、2014年10月、<http://www.etsi.org/配信/ etsi_gs / NFV-SEC / 001_099 / 001 / 01.01.01_60 / gs_NFV-SEC001v010101p.pdf>。
[etsi_nfv_whitepaper_3] ETSI, "Network Functions Virtualisation (NFV) - White Paper #3: Network Operator Perspectives on Industry Progress", Issue 1, SDN & OpenFlow World Congress Dusseldorf, Germany, October 2014, <http://portal.etsi.org/NFV/NFV_White_Paper3.pdf>.
[etsi_nfv_whitepaper_3] ETSI、「Network Functions Virtualization（NFV）-White Paper＃3：Network Operator Perspectives on Industry Progress」、SDW＆OpenFlow World Congress Dusseldorf、ドイツ、2014年10月、<http：//portal.etsi。 org / NFV / NFV_White_Paper3.pdf>。
[google_sdn_wan] Jain, S., et al., "B4: experience with a globally-deployed Software Defined WAN", SIGCOMM '13: Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM, pp. 3-14, Hong Kong China, DOI 10.1145/2486001.2486019, August 2013.
[google_sdn_wan] Jain、S.、et al。、 "B4：experience with a globally-deployed Software Defined WAN"、SIGCOMM '13：Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM、pp。3-14、Hong Kong China、 DOI 10.1145 / 2486001.2486019、2013年8月。
[intel_10_differences_nfv_cloud] Torre, P., "Discover the Top 10 Differences Between NFV and Cloud Environments", November 2015, <https://software.intel.com/en-us/videos/discover-the-top-10-differences-between-nfv-and-cloud-environments>.
[intel_10_differences_nfv_cloud] Torre、P。、「NFVとクラウド環境の違いのトップ10を発見する」、2015年11月、<https://software.intel.com/en-us/videos/discover-the-top-10-differences -between-nfv-and-cloud-environments>。
[itu-t-y.3300] ITU-T, "Y.3300: Framework of software-defined networking", ITU-T Recommendation Y.3300, June 2014, <http://www.itu.int/rec/T-REC-Y.3300-201406-I/en>.
[itu-ty.3300] ITU-T、「Y.3300：ソフトウェア定義ネットワークのフレームワーク」、ITU-T勧告Y.3300、2014年6月、<http://www.itu.int/rec/T- REC-Y.3300-201406-I / en>。
[itu-t-y.3301] ITU-T, "Y.3301: Functional requirements of software-defined networking", ITU-T Recommendation Y.3301, September 2016, <http://www.itu.int/rec/T-REC-Y.3301-201609-I/en>.
[itu-ty.3301] ITU-T、「Y.3301：ソフトウェア定義ネットワークの機能要件」、ITU-T勧告Y.3301、2016年9月、<http://www.itu.int/rec/T -REC-Y.3301-201609-I / en>。
[itu-t-y.3302] ITU-T, "Y.3302: Functional architecture of software-defined networking", ITU-T Recommendation Y.3302, January 2017, <http://www.itu.int/rec/T-REC-Y.3302-201701-I/en>.
[itu-ty.3302] ITU-T、「Y.3302：ソフトウェア定義ネットワークの機能アーキテクチャ」、ITU-T勧告Y.3302、2017年1月、<http://www.itu.int/rec/T -REC-Y.3302-201701-I / en>。
[LAYERED-SDN] Contreras, L., Bernardos, C., Lopez, D., Boucadair, M., and P. Iovanna, "Cooperating Layered Architecture for Software Defined Networking (CLAS)", Work in Progress, draft-contreras-layered-sdn-03, November 2018.
[LAYERED-SDN] Contreras、L.、Bernardos、C.、Lopez、D.、Boucadair、M。、およびP. Iovanna、「Cooperating Layered Architecture for Software Defined Networking（CLAS）」、Work in Progress、draft-contreras -layered-sdn-03、2018年11月。
[LIGHT-NFV] Sriram, N., Krishnan, R., Ghanwani, A., Krishnaswamy, D., Willis, P., Chaudhary, A., and F. Huici, "An Analysis of Lightweight Virtualization Technologies for NFV", Work in Progress, draft-natarajan-nfvrg-containers-for-nfv-03, July 2016.
[LIGHT-NFV]スリラム、N。、クリシュナン、R。、ガンワニ、A。、クリシュナスワミー、D。、ウィリス、P。、チョーダリー、A。、およびF.ヒューチ、「NFVの軽量仮想化テクノロジーの分析」 、Work in Progress、draft-natarajan-nfvrg-containers-for-nfv-03、2016年7月。
[multi-domain_5GEx] Bernardos, C., Gero, B., Di Girolamo, M., Kern, A., Martini, B., and I. Vaishnavi, "5GEx: Realizing a Europe-wide Multi-domain framework for software-defined infrastructures", Transactions on Emerging Telecommunications Technologies Vol. 27, No. 9, pp. 1271-1280, DOI 10.1002/ett.3085, July 2016.
[multi-domain_5GEx] Bernardos、C.、Gero、B.、Di Girolamo、M.、Kern、A.、Martini、B.、and I. Vaishnavi、 "5GEx：Realizing the European-wide Multi-domain framework for software定義されたインフラストラクチャー」、「新興の通信技術に関するトランザクションVol。 27、No。9、pp。1271-1280、DOI 10.1002 / ett.3085、2016年7月。
[MULTI-NMRG] Bernardos, C., Contreras, L., Vaishnavi, I., Szabo, R., Li, X., Paolucci, F., Sgambelluri, A., Martini, B., Valcarenghi, L., Landi, G., Andrushko, D., and A. Mourad, "Multi-domain Network Virtualization", Work in Progress, draft-bernardos-nmrg-multidomain-00, March 2019.
[MULTI-NMRG] Bernardos、C.、Contreras、L.、Vaishnavi、I.、Szabo、R.、Li、X.、Paolucci、F.、Sgambelluri、A.、Martini、B.、Valcarenghi、L。、 Landi、G.、Andrushko、D.、およびA. Mourad、「Multi-domain Network Virtualization」、Work in Progress、draft-bernardos-nmrg-multidomain-00、March 2019。
[NETSLICES] Galis, A., Dong, J., Makhijani, K., Bryant, S., Boucadair, M., and P. Martinez-Julia, "Network Slicing - Introductory Document and Revised Problem Statement", Work in Progress, draft-gdmb-netslices-intro-and-ps-02, February 2017.
[NETSLICES] Galis、A.、Dong、J.、Makhijani、K.、Bryant、S.、Boucadair、M。、およびP. Martinez-Julia、「ネットワークスライシング-導入文書および改訂された問題ステートメント」、進行中の作業、draft-gdmb-netslices-intro-and-ps-02、2017年2月。
[NFV-COTS] Mo, L. and B. Khasnabish, "NFV Reliability using COTS Hardware", Work in Progress, draft-mlk-nfvrg-nfv-reliability-using-cots-01, October 2015.
[NFV-COTS] Mo、L。、およびB. Khasnabish、「COTSハードウェアを使用したNFV信頼性」、作業中、draft-mlk-nfvrg-nfv-reliability-using-cots-01、2015年10月。
[nfv_piecing] Luizelli, M., Bays, L., Buriol, L., Barcellos, M., and L. Gaspary, "Piecing together the NFV provisioning puzzle: Efficient placement and chaining of virtual network functions", 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM) pp. 98-106, DOI 10.1109/INM.2015.7140281, May 2015.
[nfv_piecing] Luizelli、M.、Bays、L.、Buriol、L.、Barcellos、M。、およびL. Gaspary、「NFVプロビジョニングパズルの統合：仮想ネットワーク機能の効率的な配置とチェーン」、2015 IFIP / IEEE統合ネットワーク管理（IM）に関する国際シンポジウムpp。98-106、DOI 10.1109 / INM.2015.7140281、2015年5月。
[nfv_sota_research_challenges] Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De Turck, F., and R. Boutaba, "Network Function Virtualization: State-of-the-art and Research Challenges", IEEE Communications Surveys & Tutorials Volume: 18, Issue: 1, pp. 236-262, DOI 10.1109/COMST.2015.2477041, September 2015.
[nfv_sota_research_challenges] Mijumbi、R.、Serrat、J.、Gorricho、JL。、Bouten、N.、De Turck、F。、およびR. Boutaba、「ネットワーク機能の仮想化：最先端の研究課題」 、IEEE Communications Surveys＆Tutorials Volume：18、Issue：1、pp.236-262、DOI 10.1109 / COMST.2015.2477041、September 2015。
[NFVRG-TOPO] Bagnulo, M. and D. Dolson, "NFVI PoP Network Topology: Problem Statement", Work in Progress, draft-bagnulo-nfvrg-topology-01, March 2016.
[NFVRG-TOPO] Bagnulo、M。、およびD. Dolson、「NFVI PoP Network Topology：Problem Statement」、Work in Progress、draft-bagnulo-nfvrg-topology-01、2016年3月。
[ngmn_5G_whitepaper] NGMN Alliance, "NGMN 5G White Paper", Version 1.0, February 2015, <https://www.ngmn.org/fileadmin/ngmn/content/ images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf>.
[ngmn_5G_whitepaper] NGMNアライアンス、「NGMN 5Gホワイトペーパー」、バージョン1.0、2015年2月、<https://www.ngmn.org/fileadmin/ngmn/content/images/news/ngmn_news/NGMN_5G_White_Paper_V1_0.pdf>。
[omniran] IEEE, "Recommended Practice for Network Reference Model and Functional Description of IEEE 802 Access Network", P802.1CF IEEE Draft, December 2017.
[omniran] IEEE、「ネットワーク参照モデルとIEEE 802アクセスネットワークの機能説明の推奨プラクティス」、P802.1CF IEEEドラフト、2017年12月。
[onf_tr_521] Open Networking Foundation, "SDN Architecture", ONF TR-521 TR-521, Issue 1.1, February 2016, <https://www.opennetworking.org/images/stories/downloads/ sdn-resources/technical-reports/ TR-521_SDN_Architecture_issue_1.1.pdf>.
[onf_tr_521] Open Networking Foundation、「SDN Architecture」、ONF TR-521 TR-521、Issue 1.1、2016年2月、<https://www.opennetworking.org/images/stories/downloads/ sdn-resources / technical-reports / TR-521_SDN_Architecture_issue_1.1.pdf>。
[OpenFlow] Open Networking Foundation, "OpenFlow Switch Specification", ONF TS-025, Version 1.5.1 (Protocol version 0x06), March 2015.
[OpenFlow] Open Networking Foundation、「OpenFlow Switch Specification」、ONF TS-025、バージョン1.5.1（プロトコルバージョン0x06）、2015年3月。
[openmano_dataplane] Lopez, D., "OpenMANO: The Dataplane Ready Open Source NFV MANO Stack", March 2015, <https://www.ietf.org/ proceedings/92/slides/slides-92-nfvrg-7.pdf>.
[openmano_dataplane] Lopez、D。、「OpenMANO：The Dataplane Ready Open Source NFV MANO Stack」、2015年3月、<https://www.ietf.org/procendings/92/slides/slides-92-nfvrg-7.pdf >。
[RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010, <https://www.rfc-editor.org/info/rfc5810>.
[RFC5810]ドリア、A。、編、ハディサリム、J。、編、ハース、R。、編、コスラビ、H。、編、王、W。、編、ドン、L。、ゴパル、R。、およびJ. Halpern、「Forwarding and Control Element Separation（ForCES）Protocol Specification」、RFC 5810、DOI 10.17487 / RFC5810、2010年3月、<https://www.rfc-editor.org/info/rfc5810> 。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D。、およびO. Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]クイン、P。、エド。 T.ナドー編、「サービス機能連鎖の問題ステートメント」、RFC 7498、DOI 10.17487 / RFC7498、2015年4月、<https://www.rfc-editor.org/info/rfc7498>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030] Thomson、M.、Damaggio、E。、およびB. Raymor、編、「HTTPプッシュを使用した一般的なイベント配信」、RFC 8030、DOI 10.17487 / RFC8030、2016年12月、<https：//www.rfc- editor.org/info/rfc8030>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8172] Morton, A., "Considerations for Benchmarking Virtual Network Functions and Their Infrastructure", RFC 8172, DOI 10.17487/RFC8172, July 2017, <https://www.rfc-editor.org/info/rfc8172>.
[RFC8172] Morton、A。、「仮想ネットワーク機能とそのインフラストラクチャのベンチマークに関する考慮事項」、RFC 8172、DOI 10.17487 / RFC8172、2017年7月、<https://www.rfc-editor.org/info/rfc8172>。
[SDN-AAA] Lopez, R. and G. Lopez-Millan, "Software-Defined Networking (SDN)-based AAA Infrastructures Management", Work in Progress, draft-marin-sdnrg-sdn-aaa-mng-00, November 2015.
[SDN-AAA] Lopez、R。およびG. Lopez-Millan、「Software-Defined Networking（SDN）-based AAA Infrastructures Management」、Work in Progress、draft-marin-sdnrg-sdn-aaa-mng-00、11月2015。
[sfc_challenges] Medhat, A., Taleb, T., Elmangoush, A., Carella, G., Covaci, S., and T. Magedanz, "Service Function Chaining in Next Generation Networks: State of the Art and Research Challenges", IEEE Communications Magazine vol. 55, no. 2, pp. 216-223, DOI 10.1109/MCOM.2016.1600219RP, February 2017.
[sfc_challenges] Medhat、A.、Taleb、T.、Elmangoush、A.、Carella、G.、Covaci、S。、およびT. Magedanz、「次世代ネットワークにおけるサービス機能の連鎖：最先端の研究課題」 、IEEE Communications Magazine vol。 55、いいえ。 2、pp。216-223、DOI 10.1109 / MCOM.2016.1600219RP、2017年2月。
[SLICE-3GPP] Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case", Work in Prgoress, draft-defoy-netslices-3gpp-network-slicing-02, October 2017.
[SLICE-3GPP] Foy、X。およびA. Rahman、「ネットワークスライシング-3GPPユースケース」、作業中、draft-foy-net slices-3gpp-network-slicing-02、2017年10月。
[virtualization_mobile_device] Sproule, W. and A. Fernando, "Virtualization of Mobile Device User Experience", US Patent 9.542.062 B2, filed October 2013 and issued December 2014, Current Assignee: Microsoft Technology Licensing LLC.
[virtualization_mobile_device] Sproule、W。およびA. Fernando、「モバイルデバイスのユーザーエクスペリエンスの仮想化」、米国特許9.542.062 B2、2013年10月に提出、2014年12月に発行、現在の譲受人：マイクロソフトテクノロジーライセンスLLC。
[vnf-p] Moens, H. and , "VNF-P: A model for efficient placement of virtualized network functions", 10th International Conference on Network and Service Management (CNSM) and Workshop pp. 418-423, DOI 10.1109/CNSM.2014.7014205, November 2014.
[vnf-p] Moens、H。および、「VNF-P：仮想化ネットワーク機能の効率的な配置のためのモデル」、第10回ネットワークおよびサービス管理国際会議（CNSM）およびワークショップpp。418-423、DOI 10.1109 / CNSM .2014.7014205、2014年11月。
[VNF-VBAAS] Rosa, R., Rothenberg, C., and R. Szabo, "VNF Benchmark-as-a-Service", Work in Progress, draft-rorosz-nfvrg-vbaas-00, October 2015.
[VNF-VBAAS] Rosa、R.、Rothenberg、C。、およびR. Szabo、「VNF Benchmark-as-a-Service」、Work in Progress、draft-rorosz-nfvrg-vbaas-00、2015年10月。
[vnf_benchmarking] Rosa, R., Rothenberg, C., and R. Szabo, "A VNF Testing Framework Design, Implementation and Partial Results", NFVRG IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-nfvrg-06-vnf-benchmarking-00.pdf>.
[vnf_benchmarking] Rosa、R.、Rothenberg、C、およびR. Szabo、「VNFテストフレームワークの設計、実装、および部分的な結果」、NFVRG IETF 97、2016年11月、<https://www.ietf.org/proceedings /97/slides/slides-97-nfvrg-06-vnf-benchmarking-00.pdf>。
Acknowledgments
謝辞
The authors want to thank Dirk von Hugo, Rafa Marin, Diego Lopez, Ramki Krishnan, Kostas Pentikousis, Rana Pratap Sircar, Alfred Morton, Nicolas Kuhn, Saumya Dikshit, Fabio Giust, Evangelos Haleplidis, Angeles Vazquez-Castro, Barbara Martini, Jose Saldana, and Gino Carrozzo for their very useful reviews and comments to the document. Special thanks to Pedro Martinez-Julia, who provided text for the network slicing section.
著者は、Dirk von Hugo、Rafa Marin、Diego Lopez、Ramki Krishnan、Kostas Pentikousis、Rana Pratap Sircar、Alfred Morton、Nicolas Kuhn、Saumya Dikshit、Fabio Giust、Evangelos Haleplidis、Angeles Vazquez-Castro、Barbara Martini、Barbara Martiniに感謝します、およびドキュメントに対する非常に有用なレビューとコメントを提供したGino Carrozzo。ネットワークスライスセクションのテキストを提供してくれたPedro Martinez-Juliaに特に感謝します。
The authors want to also thank Dave Oran and Michael Welzl for their very detailed IRSG reviews.
著者は、非常に詳細なIRSGレビューについてDave OranとMichael Welzlにも感謝します。
The work of Carlos J. Bernardos and Luis M. Contreras is partially supported by the H2020 5GEx (Grant Agreement no. 671636) and 5G-TRANSFORMER (Grant Agreement no. 761536) projects.
Carlos J. BernardosおよびLuis M. Contrerasの作業は、H2020 5GEx（Grant Agreement no。671636）および5G-TRANSFORMER（Grant Agreement no。761536）プロジェクトによって部分的にサポートされています。
Authors' Addresses
著者のアドレス
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドスカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Akbar Rahman InterDigital Communications、LLC 1000 Sherbrooke Street West、10th floor Montreal、Quebec H3A 3G4 Canada
Email: Akbar.Rahman@InterDigital.com
URI: http://www.InterDigital.com/
Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand Labege 31670 France
フアンカルロススニガSIGFOX 425 rue Jean Rostand Labege 31670フランス
Email: j.c.zuniga@ieee.org
URI: http://www.sigfox.com/
Luis M. Contreras Telefonica I+D Ronda de la Comunicacion, S/N Madrid 28050 Spain
Luis M. Contreras Telefonica I + D Ronda de la Comunicacion、S / Nマドリード28050スペイン
Email: luismiguel.contrerasmurillo@telefonica.com
Pedro Aranda Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
ペドロアランダカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Email: pedroandres.aranda@uc3m.es
Pierre Lynch Keysight Technologies 800 Perimeter Park Dr, Suite A Morrisville, NC 27560 United States of America
Pierre Lynch Keysight Technologies 800 Perimeter Park Dr、Suite A Morrisville、NC 27560アメリカ合衆国
Email: pierre.lynch@keysight.com
URI: http://www.keysight.com