[要約] RFC 8014は、データセンターネットワーク仮想化のためのアーキテクチャであり、Layer 3上でのネットワーク仮想化を提供します。このRFCの目的は、データセンターネットワークの柔軟性とスケーラビリティを向上させることです。
Internet Engineering Task Force (IETF) D. Black
Request for Comments: 8014 Dell EMC
Category: Informational J. Hudson
ISSN: 2070-1721 L. Kreeger
M. Lasserre
Independent
T. Narten
IBM
December 2016
An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)
レイヤー3（NVO3）上のデータセンターネットワーク仮想化のアーキテクチャ
Abstract
概要
This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.
このドキュメントでは、データセンターネットワーク仮想化オーバーレイヤー3（NVO3）ネットワークを構築するための高レベルの概要アーキテクチャについて説明します。アーキテクチャは、システム全体の主要なコンポーネントを示す高レベルで提供されます。重要な目標は、スペースを個々の小さなコンポーネントに分割し、コンポーネント間の明確なインターフェースと相互作用を使用して独立して実装できるようにすることです。個別のコンポーネントを個別に構築および実装し、それらを他の独立して実装されたコンポーネントと相互運用できるようにする必要があります。このようにして、実装者は個々のコンポーネントの実装に柔軟性があり、他のコンポーネントに変更を加えることなく、それぞれのコンポーネント内で最適化および革新できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8014.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8014で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. VN Service (L2 and L3) . . . . . . . . . . . . . . . . . 7
3.1.1. VLAN Tags in L2 Service . . . . . . . . . . . . . . . 8
3.1.2. Packet Lifetime Considerations . . . . . . . . . . . 8
3.2. Network Virtualization Edge (NVE) Background . . . . . . 9
3.3. Network Virtualization Authority (NVA) Background . . . . 10
3.4. VM Orchestration Systems . . . . . . . . . . . . . . . . 11
4. Network Virtualization Edge (NVE) . . . . . . . . . . . . . . 12
4.1. NVE Co-located with Server Hypervisor . . . . . . . . . . 12
4.2. Split-NVE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Tenant VLAN Handling in Split-NVE Case . . . . . . . 14
4.3. NVE State . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Multihoming of NVEs . . . . . . . . . . . . . . . . . . . 15
4.5. Virtual Access Point (VAP) . . . . . . . . . . . . . . . 16
5. Tenant System Types . . . . . . . . . . . . . . . . . . . . . 16
5.1. Overlay-Aware Network Service Appliances . . . . . . . . 16
5.2. Bare Metal Servers . . . . . . . . . . . . . . . . . . . 17
5.3. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Gateway Taxonomy . . . . . . . . . . . . . . . . . . 18
5.3.1.1. L2 Gateways (Bridging) . . . . . . . . . . . . . 18
5.3.1.2. L3 Gateways (Only IP Packets) . . . . . . . . . . 18
5.4. Distributed Inter-VN Gateways . . . . . . . . . . . . . . 19
5.5. ARP and Neighbor Discovery . . . . . . . . . . . . . . . 20
6. NVE-NVE Interaction . . . . . . . . . . . . . . . . . . . . . 20
7. Network Virtualization Authority (NVA) . . . . . . . . . . . 21
7.1. How an NVA Obtains Information . . . . . . . . . . . . . 21
7.2. Internal NVA Architecture . . . . . . . . . . . . . . . . 22
7.3. NVA External Interface . . . . . . . . . . . . . . . . . 22
8. NVE-NVA Protocol . . . . . . . . . . . . . . . . . . . . . . 24
8.1. NVE-NVA Interaction Models . . . . . . . . . . . . . . . 24
8.2. Direct NVE-NVA Protocol . . . . . . . . . . . . . . . . . 25
8.3. Propagating Information Between NVEs and NVAs . . . . . . 25
9. Federated NVAs . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Inter-NVA Peering . . . . . . . . . . . . . . . . . . . . 29
10. Control Protocol Work Areas . . . . . . . . . . . . . . . . . 29
11. NVO3 Data-Plane Encapsulation . . . . . . . . . . . . . . . . 29
12. Operations, Administration, and Maintenance (OAM) . . . . . . 30
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
15. Informative References . . . . . . . . . . . . . . . . . . . 32
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
This document presents a high-level architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, which shows the major components of an overall system. An important goal is to divide the space into smaller individual components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.
このドキュメントでは、データセンターネットワーク仮想化オーバーレイヤー3（NVO3）ネットワークを構築するための高レベルアーキテクチャについて説明します。アーキテクチャは、システム全体の主要コンポーネントを示す高レベルで提供されます。重要な目標は、スペースをより小さな個々のコンポーネントに分割し、コンポーネント間のインターフェースと相互作用を明確にして独立して実装できるようにすることです。個別のコンポーネントを個別に構築および実装し、それらを他の独立して実装されたコンポーネントと相互運用できるようにする必要があります。このようにして、実装者は個々のコンポーネントの実装に柔軟性があり、他のコンポーネントに変更を加えることなく、それぞれのコンポーネント内で最適化および革新できます。
The motivation for overlay networks is given in "Problem Statement: Overlays for Network Virtualization" [RFC7364]. "Framework for Data Center (DC) Network Virtualization" [RFC7365] provides a framework for discussing overlay networks generally and the various components that must work together in building such systems. This document differs from the framework document in that it doesn't attempt to cover all possible approaches within the general design space. Rather, it describes one particular approach that the NVO3 WG has focused on.
オーバーレイネットワークの動機は、「問題ステートメント：ネットワーク仮想化のためのオーバーレイ」[RFC7364]に記載されています。 「データセンター（DC）ネットワーク仮想化のフレームワーク」[RFC7365]は、オーバーレイネットワーク全般と、そのようなシステムを構築する際に連携して動作する必要のあるさまざまなコンポーネントについて説明するためのフレームワークを提供します。このドキュメントは、フレームワークドキュメントとは異なり、一般的なデザインスペース内のすべての可能なアプローチをカバーすることを試みていません。むしろ、NVO3 WGが焦点を当てた1つの特定のアプローチについて説明しています。
This document uses the same terminology as [RFC7365]. In addition, the following terms are used:
このドキュメントでは、[RFC7365]と同じ用語を使用しています。さらに、次の用語が使用されます。
NV Domain: A Network Virtualization Domain is an administrative construct that defines a Network Virtualization Authority (NVA), the set of Network Virtualization Edges (NVEs) associated with that NVA, and the set of virtual networks the NVA manages and supports. NVEs are associated with a (logically centralized) NVA, and an NVE supports communication for any of the virtual networks in the domain.
NVドメイン：ネットワーク仮想化ドメインは、ネットワーク仮想化機関（NVA）、そのNVAに関連付けられたネットワーク仮想化エッジ（NVE）のセット、およびNVAが管理およびサポートする仮想ネットワークのセットを定義する管理構造です。 NVEは（論理的に一元化された）NVAに関連付けられ、NVEはドメイン内の任意の仮想ネットワークの通信をサポートします。
NV Region: A region over which information about a set of virtual networks is shared. The degenerate case of a single NV Domain corresponds to an NV Region corresponding to that domain. The more interesting case occurs when two or more NV Domains share information about part or all of a set of virtual networks that they manage. Two NVAs share information about particular virtual networks for the purpose of supporting connectivity between tenants located in different NV Domains. NVAs can share information about an entire NV Domain, or just individual virtual networks.
NVリージョン：仮想ネットワークのセットに関する情報が共有されるリージョン。単一のNVドメインの縮退ケースは、そのドメインに対応するNVリージョンに対応します。より興味深いケースは、2つ以上のNVドメインが、管理する一連の仮想ネットワークの一部またはすべてに関する情報を共有する場合に発生します。 2つのNVAは、異なるNVドメインにあるテナント間の接続をサポートする目的で、特定の仮想ネットワークに関する情報を共有します。 NVAは、NVドメイン全体、または個別の仮想ネットワークに関する情報を共有できます。
Tenant System Interface (TSI): The interface to a Virtual Network (VN) as presented to a Tenant System (TS, see [RFC7365]). The TSI logically connects to the NVE via a Virtual Access Point (VAP). To the Tenant System, the TSI is like a Network Interface Card (NIC); the TSI presents itself to a Tenant System as a normal network interface.
テナントシステムインターフェイス（TSI）：テナントシステム（TS、[RFC7365]を参照）に提示される仮想ネットワーク（VN）へのインターフェイス。 TSIは、仮想アクセスポイント（VAP）を介して論理的にNVEに接続します。テナントシステムにとって、TSIはネットワークインターフェイスカード（NIC）のようなものです。 TSIは、通常のネットワークインターフェイスとしてテナントシステムに提示されます。
VLAN: Unless stated otherwise, the terms "VLAN" and "VLAN Tag" are used in this document to denote a Customer VLAN (C-VLAN) [IEEE.802.1Q]; the terms are used interchangeably to improve readability.
VLAN：特に明記しない限り、「VLAN」および「VLANタグ」という用語は、このドキュメントではカスタマーVLAN（C-VLAN）[IEEE.802.1Q]を示すために使用されます。これらの用語は読みやすくするために同じ意味で使用されています。
Overlay networks are an approach for providing network virtualization services to a set of Tenant Systems (TSs) [RFC7365]. With overlays, data traffic between tenants is tunneled across the underlying data center's IP network. The use of tunnels provides a number of benefits by decoupling the network as viewed by tenants from the underlying physical network across which they communicate. Additional discussion of some NVO3 use cases can be found in [USECASES].
オーバーレイネットワークは、一連のテナントシステム（TS）[RFC7365]にネットワーク仮想化サービスを提供するためのアプローチです。オーバーレイを使用すると、テナント間のデータトラフィックは、基盤となるデータセンターのIPネットワークを介してトンネリングされます。トンネルを使用すると、テナントが通信する基礎となる物理ネットワークからテナントを見るとネットワークが分離されるため、多くの利点があります。いくつかのNVO3の使用例についての追加の議論は[USECASES]にあります。
Tenant Systems connect to Virtual Networks (VNs), with each VN having associated attributes defining properties of the network (such as the set of members that connect to it). Tenant Systems connected to a virtual network typically communicate freely with other Tenant Systems on the same VN, but communication between Tenant Systems on one VN and those external to the VN (whether on another VN or connected to the Internet) is carefully controlled and governed by policy. The NVO3 architecture does not impose any restrictions to the application of policy controls even within a VN.
テナントシステムは、仮想ネットワーク（VN）に接続します。各VNには、ネットワークのプロパティ（ネットワークに接続するメンバーのセットなど）を定義する属性が関連付けられています。仮想ネットワークに接続されたテナントシステムは、通常、同じVN上の他のテナントシステムと自由に通信しますが、1つのVN上のテナントシステムとVNの外部のテナントシステム間の通信（別のVN上またはインターネットに接続されているかどうか）は、以下によって慎重に制御および管理されますポリシー。 NVO3アーキテクチャは、VN内でもポリシー制御の適用に制限を課しません。
A Network Virtualization Edge (NVE) [RFC7365] is the entity that implements the overlay functionality. An NVE resides at the boundary between a Tenant System and the overlay network as shown in Figure 1. An NVE creates and maintains local state about each VN for which it is providing service on behalf of a Tenant System.
ネットワーク仮想化エッジ（NVE）[RFC7365]は、オーバーレイ機能を実装するエンティティです。図1に示すように、NVEはテナントシステムとオーバーレイネットワークの間の境界にあります。NVEは、テナントシステムに代わってサービスを提供する各VNに関するローカル状態を作成および維持します。
+--------+ +--------+
| Tenant +--+ +----| Tenant |
| System | | (') | System |
+--------+ | ................ ( ) +--------+
| +-+--+ . . +--+-+ (_)
| | NVE|--. .--| NVE| |
+--| | . . | |---+
+-+--+ . . +--+-+
/ . .
/ . L3 Overlay . +--+-++--------+
+--------+ / . Network . | NVE|| Tenant |
| Tenant +--+ . .- -| || System |
| System | . . +--+-++--------+
+--------+ ................
|
+----+
| NVE|
| |
+----+
|
|
=====================
| |
+--------+ +--------+
| Tenant | | Tenant |
| System | | System |
+--------+ +--------+
Figure 1: NVO3 Generic Reference Model
図1：NVO3汎用参照モデル
The following subsections describe key aspects of an overlay system in more detail. Section 3.1 describes the service model (Ethernet vs. IP) provided to Tenant Systems. Section 3.2 describes NVEs in more detail. Section 3.3 introduces the Network Virtualization Authority, from which NVEs obtain information about virtual networks. Section 3.4 provides background on Virtual Machine (VM) orchestration systems and their use of virtual networks.
以下のサブセクションでは、オーバーレイシステムの主要な側面について詳しく説明します。セクション3.1では、テナントシステムに提供されるサービスモデル（イーサネットとIP）について説明します。セクション3.2では、NVEについて詳しく説明します。セクション3.3では、NVEが仮想ネットワークに関する情報を取得するネットワーク仮想化機関を紹介します。セクション3.4では、仮想マシン（VM）オーケストレーションシステムの背景と、仮想ネットワークの使用について説明します。
A VN provides either Layer 2 (L2) or Layer 3 (L3) service to connected tenants. For L2 service, VNs transport Ethernet frames, and a Tenant System is provided with a service that is analogous to being connected to a specific L2 C-VLAN. L2 broadcast frames are generally delivered to all (and multicast frames delivered to a subset of) the other Tenant Systems on the VN. To a Tenant System, it appears as if they are connected to a regular L2 Ethernet link. Within the NVO3 architecture, tenant frames are tunneled to remote NVEs based on the Media Access Control (MAC) addresses of the frame headers as originated by the Tenant System. On the underlay, NVO3 packets are forwarded between NVEs based on the outer addresses of tunneled packets.
VNは、接続されたテナントにレイヤー2（L2）またはレイヤー3（L3）サービスを提供します。 L2サービスの場合、VNはイーサネットフレームを転送し、テナントシステムには、特定のL2 C-VLANに接続されているのと同様のサービスが提供されます。 L2ブロードキャストフレームは通常、VN上の他のすべてのテナントシステム（およびそのサブセットに配信されるマルチキャストフレーム）に配信されます。テナントシステムからは、通常のL2イーサネットリンクに接続されているように見えます。 NVO3アーキテクチャー内では、テナントシステムが発信したフレームヘッダーのメディアアクセス制御（MAC）アドレスに基づいて、テナントフレームがリモートNVEにトンネリングされます。アンダーレイでは、NVO3パケットはトンネルパケットの外部アドレスに基づいてNVE間で転送されます。
For L3 service, VNs are routed networks that transport IP datagrams, and a Tenant System is provided with a service that supports only IP traffic. Within the NVO3 architecture, tenant frames are tunneled to remote NVEs based on the IP addresses of the packet originated by the Tenant System; any L2 destination addresses provided by Tenant Systems are effectively ignored by the NVEs and overlay network. For L3 service, the Tenant System will be configured with an IP subnet that is effectively a point-to-point link, i.e., having only the Tenant System and a next-hop router address on it.
L3サービスの場合、VNはIPデータグラムを転送するルーティングされたネットワークであり、テナントシステムにはIPトラフィックのみをサポートするサービスが提供されます。 NVO3アーキテクチャー内では、テナントフレームは、テナントシステムが発信したパケットのIPアドレスに基づいてリモートNVEにトンネリングされます。テナントシステムによって提供されるL2宛先アドレスは、NVEおよびオーバーレイネットワークによって事実上無視されます。 L3サービスの場合、テナントシステムは、実質的にポイントツーポイントリンクであるIPサブネットで構成されます。つまり、テナントシステムとネクストホップルーターアドレスのみが存在します。
L2 service is intended for systems that need native L2 Ethernet service and the ability to run protocols directly over Ethernet (i.e., not based on IP). L3 service is intended for systems in which all the traffic can safely be assumed to be IP. It is important to note that whether or not an NVO3 network provides L2 or L3 service to a Tenant System, the Tenant System does not generally need to be aware of the distinction. In both cases, the virtual network presents itself to the Tenant System as an L2 Ethernet interface. An Ethernet interface is used in both cases simply as a widely supported interface type that essentially all Tenant Systems already support. Consequently, no special software is needed on Tenant Systems to use an L3 vs. an L2 overlay service.
L2サービスは、ネイティブのL2イーサネットサービスとイーサネット上で直接プロトコルを実行する機能（つまり、IPベースではない）を必要とするシステムを対象としています。 L3サービスは、すべてのトラフィックが安全にIPであると想定できるシステムを対象としています。 NVO3ネットワークがL2またはL3サービスをテナントシステムに提供するかどうかに関係なく、テナントシステムは通常、その違いを認識する必要がないことに注意することが重要です。どちらの場合も、仮想ネットワークはL2イーサネットインターフェイスとしてテナントシステムに提示されます。イーサネットインターフェイスはどちらの場合も、基本的にすべてのテナントシステムがすでにサポートしている広くサポートされているインターフェイスタイプとして使用されます。したがって、L3オーバーレイサービスとL2オーバーレイサービスを使用するために、テナントシステムで特別なソフトウェアは必要ありません。
NVO3 can also provide a combined L2 and L3 service to tenants. A combined service provides L2 service for intra-VN communication but also provides L3 service for L3 traffic entering or leaving the VN. Architecturally, the handling of a combined L2/L3 service within the NVO3 architecture is intended to match what is commonly done today in non-overlay environments by devices providing a combined bridge/ router service. With combined service, the virtual network itself retains the semantics of L2 service, and all traffic is processed according to its L2 semantics. In addition, however, traffic requiring IP processing is also processed at the IP level.
NVO3は、L2とL3を組み合わせたサービスをテナントに提供することもできます。複合サービスは、VN内通信にL2サービスを提供しますが、VNに出入りするL3トラフィックにL3サービスも提供します。アーキテクチャ上、NVO3アーキテクチャ内でのL2 / L3結合サービスの処理は、ブリッジ/ルーター結合サービスを提供するデバイスによって非オーバーレイ環境で現在一般的に行われていることと一致することを目的としています。複合サービスでは、仮想ネットワーク自体がL2サービスのセマンティクスを保持し、すべてのトラフィックがそのL2セマンティクスに従って処理されます。ただし、さらに、IP処理を必要とするトラフィックもIPレベルで処理されます。
The IP processing for a combined service can be implemented on a standalone device attached to the virtual network (e.g., an IP router) or implemented locally on the NVE (see Section 5.4 on Distributed Inter-VN Gateways). For unicast traffic, NVE implementation of a combined service may result in a packet being delivered to another Tenant System attached to the same NVE (on either the same or a different VN), tunneled to a remote NVE, or even forwarded outside the NV Domain. For multicast or broadcast packets, the combination of NVE L2 and L3 processing may result in copies of the packet receiving both L2 and L3 treatments to realize delivery to all of the destinations involved. This distributed NVE implementation of IP routing results in the same network delivery behavior as if the L2 processing of the packet included delivery of the packet to an IP router attached to the L2 VN as a Tenant System, with the router having additional network attachments to other networks, either virtual or not.
複合サービスのIP処理は、仮想ネットワークに接続されたスタンドアロンデバイス（IPルーターなど）に実装することも、NVEにローカルに実装することもできます（分散Inter-VNゲートウェイのセクション5.4を参照）。ユニキャストトラフィックの場合、複合サービスのNVE実装により、同じNVEに接続された（同じまたは異なるVNの）別のテナントシステムにパケットが配信されたり、リモートNVEにトンネリングされたり、NVドメインの外に転送されたりする可能性があります。マルチキャストパケットまたはブロードキャストパケットの場合、NVE L2とL3の処理の組み合わせにより、パケットのコピーがL2とL3の両方の処理を受信し、関係するすべての宛先への配信を実現できます。このIPルーティングの分散NVE実装により、パケットのL2処理に、テナントシステムとしてL2 VNに接続されたIPルーターへのパケットの配信が含まれているかのように、ネットワーク配信動作が同じになります。ネットワーク、仮想かどうか。
An NVO3 L2 virtual network service may include encapsulated L2 VLAN tags provided by a Tenant System but does not use encapsulated tags in deciding where and how to forward traffic. Such VLAN tags can be passed through so that Tenant Systems that send or expect to receive them can be supported as appropriate.
NVO3 L2仮想ネットワークサービスには、テナントシステムによって提供されるカプセル化されたL2 VLANタグが含まれる場合がありますが、トラフィックを転送する場所と方法を決定する際にカプセル化されたタグを使用しません。このようなVLANタグを通過させることができるため、それらを送信する、または受信する予定のテナントシステムを適切にサポートできます。
The processing of VLAN tags that an NVE receives from a TS is controlled by settings associated with the VAP. Just as in the case with ports on Ethernet switches, a number of settings are possible. For example, Customer VLAN Tags (C-TAGs) can be passed through transparently, could always be stripped upon receipt from a Tenant System, could be compared against a list of explicitly configured tags, etc.
NVEがTSから受信するVLANタグの処理は、VAPに関連付けられた設定によって制御されます。イーサネットスイッチのポートの場合と同様に、いくつかの設定が可能です。たとえば、カスタマーVLANタグ（C-TAG）は透過的に通過でき、テナントシステムからの受信時に常に削除されたり、明示的に構成されたタグのリストと比較したりできます。
Note that there are additional considerations when VLAN tags are used to identify both the VN and a Tenant System VLAN within that VN, as described in Section 4.2.1.
セクション4.2.1で説明されているように、VLANタグを使用してVNとそのVN内のテナントシステムVLANの両方を識別する場合、追加の考慮事項があることに注意してください。
For L3 service, Tenant Systems should expect the IPv4 Time to Live (TTL) or IPv6 Hop Limit in the packets they send to be decremented by at least 1. For L2 service, neither the TTL nor the Hop Limit (when the packet is IP) is modified. The underlay network manages TTLs and Hop Limits in the outer IP encapsulation -- the values in these fields could be independent from or related to the values in the same fields of tenant IP packets.
L3サービスの場合、テナントシステムは、送信するパケットのIPv4存続時間（TTL）またはIPv6ホップ制限が少なくとも1ずつ減ることを期待する必要があります。L2サービスの場合、TTLもホップ制限もありません（パケットがIPの場合）。 ）が変更されています。アンダーレイネットワークは、外部IPカプセル化でTTLとホップ制限を管理します。これらのフィールドの値は、テナントIPパケットの同じフィールドの値とは独立しているか、または関連している可能性があります。
Tenant Systems connect to NVEs via a Tenant System Interface (TSI). The TSI logically connects to the NVE via a Virtual Access Point (VAP), and each VAP is associated with one VN as shown in Figure 2. To the Tenant System, the TSI is like a NIC; the TSI presents itself to a Tenant System as a normal network interface. On the NVE side, a VAP is a logical network port (virtual or physical) into a specific virtual network. Note that two different Tenant Systems (and TSIs) attached to a common NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as they connect to the same VN.
テナントシステムは、テナントシステムインターフェイス（TSI）を介してNVEに接続します。 TSIは仮想アクセスポイント（VAP）を介してNVEに論理的に接続し、各VAPは図2に示すように1つのVNに関連付けられます。テナントシステムにとって、TSIはNICのようなものです。 TSIは、通常のネットワークインターフェイスとしてテナントシステムに提示されます。 NVE側では、VAPは特定の仮想ネットワークへの論理ネットワークポート（仮想または物理）です。共通のNVEに接続された2つの異なるテナントシステム（およびTSI）は、同じVNに接続している限り、VAP（図2のTS1とTS2など）を共有できます。
| Data-Center Network (IP) |
| |
+-----------------------------------------+
| |
| Tunnel Overlay |
+------------+---------+ +---------+------------+
| +----------+-------+ | | +-------+----------+ |
| | Overlay Module | | | | Overlay Module | |
| +---------+--------+ | | +---------+--------+ |
| | | | | |
NVE1 | | | | | | NVE2
| +--------+-------+ | | +--------+-------+ |
| | VNI1 VNI2 | | | | VNI1 VNI2 | |
| +-+----------+---+ | | +-+-----------+--+ |
| | VAP1 | VAP2 | | | VAP1 | VAP2|
+----+----------+------+ +----+-----------+-----+
| | | |
|\ | | |
| \ | | /|
-------+--\-------+-------------------+---------/-+-------
| \ | Tenant | / |
TSI1 |TSI2\ | TSI3 TSI1 TSI2/ TSI3
+---+ +---+ +---+ +---+ +---+ +---+
|TS1| |TS2| |TS3| |TS4| |TS5| |TS6|
+---+ +---+ +---+ +---+ +---+ +---+
Figure 2: NVE Reference Model
図2：NVE参照モデル
The Overlay Module performs the actual encapsulation and decapsulation of tunneled packets. The NVE maintains state about the virtual networks it is a part of so that it can provide the Overlay Module with information such as the destination address of the NVE to tunnel a packet to and the Context ID that should be placed in the encapsulation header to identify the virtual network that a tunneled packet belongs to.
オーバーレイモジュールは、トンネル化されたパケットの実際のカプセル化とカプセル化解除を実行します。 NVEは、それが属している仮想ネットワークに関する状態を維持するため、パケットをトンネルするNVEの宛先アドレスや、識別のためにカプセル化ヘッダーに配置する必要があるコンテキストIDなどの情報をオーバーレイモジュールに提供できます。トンネリングされたパケットが属する仮想ネットワーク。
On the side facing the data-center network, the NVE sends and receives native IP traffic. When ingressing traffic from a Tenant System, the NVE identifies the egress NVE to which the packet should be sent, adds an overlay encapsulation header, and sends the packet on the underlay network. When receiving traffic from a remote NVE, an NVE strips off the encapsulation header and delivers the (original) packet to the appropriate Tenant System. When the source and destination Tenant System are on the same NVE, no encapsulation is needed and the NVE forwards traffic directly.
データセンターネットワークに面する側で、NVEはネイティブIPトラフィックを送受信します。テナントシステムからトラフィックを入力すると、NVEはパケットの送信先となる出力NVEを識別し、オーバーレイカプセル化ヘッダーを追加して、パケットをアンダーレイネットワークに送信します。リモートNVEからトラフィックを受信すると、NVEはカプセル化ヘッダーを取り除き、（元の）パケットを適切なテナントシステムに配信します。ソースと宛先のテナントシステムが同じNVEにある場合、カプセル化は必要なく、NVEはトラフィックを直接転送します。
Conceptually, the NVE is a single entity implementing the NVO3 functionality. In practice, there are a number of different implementation scenarios, as described in detail in Section 4.
概念的には、NVEはNVO3機能を実装する単一のエンティティです。実際には、セクション4で詳しく説明するように、さまざまな実装シナリオがいくつかあります。
Address dissemination refers to the process of learning, building, and distributing the mapping/forwarding information that NVEs need in order to tunnel traffic to each other on behalf of communicating Tenant Systems. For example, in order to send traffic to a remote Tenant System, the sending NVE must know the destination NVE for that Tenant System.
アドレスの配布とは、通信しているテナントシステムに代わってトラフィックを相互にトンネリングするためにNVEが必要とするマッピング/転送情報を学習、構築、および配布するプロセスを指します。たとえば、リモートテナントシステムにトラフィックを送信するには、送信側NVEがそのテナントシステムの宛先NVEを知っている必要があります。
One way to build and maintain mapping tables is to use learning, as 802.1 bridges do [IEEE.802.1Q]. When forwarding traffic to multicast or unknown unicast destinations, an NVE could simply flood traffic. While flooding works, it can lead to traffic hot spots and to problems in larger networks (e.g., excessive amounts of flooded traffic).
マッピングテーブルを作成および維持する1つの方法は、802.1ブリッジが行う[IEEE.802.1Q]のように、学習を使用することです。トラフィックをマルチキャストまたは不明なユニキャスト宛先に転送する場合、NVEは単にトラフィックをフラッディングする可能性があります。フラッディングは機能しますが、トラフィックのホットスポットや大規模ネットワークでの問題（過剰な量のフラッディングトラフィックなど）につながる可能性があります。
Alternatively, to reduce the scope of where flooding must take place, or to eliminate it all together, NVEs can make use of a Network Virtualization Authority (NVA). An NVA is the entity that provides address mapping and other information to NVEs. NVEs interact with an NVA to obtain any required address-mapping information they need in order to properly forward traffic on behalf of tenants. The term "NVA" refers to the overall system, without regard to its scope or how it is implemented. NVAs provide a service, and NVEs access that service via an NVE-NVA protocol as discussed in Section 8.
または、フラッディングが発生する場所の範囲を削減する、またはフラッディングをすべて排除するために、NVEはネットワーク仮想化機関（NVA）を利用できます。 NVAは、NVEにアドレスマッピングやその他の情報を提供するエンティティです。 NVEはNVAと対話して、テナントに代わってトラフィックを適切に転送するために必要なアドレスマッピング情報を取得します。 「NVA」という用語は、その範囲や実装方法に関係なく、システム全体を指します。セクション8で説明するように、NVAはサービスを提供し、NVEはNVE-NVAプロトコルを介してそのサービスにアクセスします。
Even when an NVA is present, Ethernet bridge MAC address learning could be used as a fallback mechanism, should the NVA be unable to provide an answer or for other reasons. This document does not consider flooding approaches in detail, as there are a number of benefits in using an approach that depends on the presence of an NVA.
NVAが存在する場合でも、NVAが回答を提供できない場合やその他の理由で、イーサネットブリッジMACアドレスラーニングをフォールバックメカニズムとして使用できます。 NVAの存在に依存するアプローチを使用することには多くの利点があるため、このドキュメントではフラッディングアプローチを詳細に検討していません。
For the rest of this document, it is assumed that an NVA exists and will be used. NVAs are discussed in more detail in Section 7.
このドキュメントの残りの部分では、NVAが存在し、使用されることを前提としています。 NVAについては、セクション7で詳しく説明します。
VM orchestration systems manage server virtualization across a set of servers. Although VM management is a separate topic from network virtualization, the two areas are closely related. Managing the creation, placement, and movement of VMs also involves creating, attaching to, and detaching from virtual networks. A number of existing VM orchestration systems have incorporated aspects of virtual network management into their systems.
VMオーケストレーションシステムは、一連のサーバーにわたるサーバー仮想化を管理します。 VM管理はネットワーク仮想化とは別のトピックですが、2つの領域は密接に関連しています。 VMの作成、配置、移動の管理には、仮想ネットワークの作成、接続、および切り離しも含まれます。既存のVMオーケストレーションシステムの多くは、仮想ネットワーク管理の側面をシステムに組み込んでいます。
Note also that although this section uses the terms "VM" and "hypervisor" throughout, the same issues apply to other virtualization approaches, including Linux Containers (LXC), BSD Jails, Network Service Appliances as discussed in Section 5.1, etc. From an NVO3 perspective, it should be assumed that where the document uses the term "VM" and "hypervisor", the intention is that the discussion also applies to other systems, where, e.g., the host operating system plays the role of the hypervisor in supporting virtualization, and a container plays the equivalent role as a VM.
また、このセクションでは「VM」および「ハイパーバイザ」という用語を使用していますが、セクション5.1で説明したLinux Containers（LXC）、BSD Jails、ネットワークサービスアプライアンスなど、他の仮想化アプローチにも同じ問題が当てはまることにも注意してください。 NVO3の観点から、ドキュメントで「VM」および「ハイパーバイザ」という用語が使用されている場合、その説明は他のシステムにも適用されることが想定されます。たとえば、ホストオペレーティングシステムがハイパーバイザーの役割を果たし、仮想化であり、コンテナはVMと同等の役割を果たします。
When a new VM image is started, the VM orchestration system determines where the VM should be placed, interacts with the hypervisor on the target server to load and start the VM, and controls when a VM should be shut down or migrated elsewhere. VM orchestration systems also have knowledge about how a VM should connect to a network, possibly including the name of the virtual network to which a VM is to connect. The VM orchestration system can pass such information to the hypervisor when a VM is instantiated. VM orchestration systems have significant (and sometimes global) knowledge over the domain they manage. They typically know on what servers a VM is running, and metadata associated with VM images can be useful from a network virtualization perspective. For example, the metadata may include the addresses (MAC and IP) the VMs will use and the name(s) of the virtual network(s) they connect to.
新しいVMイメージが開始されると、VMオーケストレーションシステムは、VMを配置する場所を決定し、ターゲットサーバーのハイパーバイザーと対話してVMをロードして開始し、いつVMをシャットダウンまたは他の場所に移行するかを制御します。 VMオーケストレーションシステムは、VMがネットワークに接続する方法に関する知識も持っています。これには、VMが接続する仮想ネットワークの名前が含まれる場合もあります。 VMオーケストレーションシステムは、VMがインスタンス化されるときにそのような情報をハイパーバイザーに渡すことができます。 VMオーケストレーションシステムは、管理するドメインに関する重要な（場合によってはグローバルな）知識を持っています。彼らは通常、VMが実行されているサーバーを知っており、VMイメージに関連付けられたメタデータは、ネットワーク仮想化の観点から役立つ場合があります。たとえば、メタデータには、VMが使用するアドレス（MACおよびIP）と、VMが接続する仮想ネットワークの名前が含まれる場合があります。
VM orchestration systems run a protocol with an agent running on the hypervisor of the servers they manage. That protocol can also carry information about what virtual network a VM is associated with. When the orchestrator instantiates a VM on a hypervisor, the hypervisor interacts with the NVE in order to attach the VM to the virtual networks it has access to. In general, the hypervisor will need to communicate significant VM state changes to the NVE. In the reverse direction, the NVE may need to communicate network connectivity information back to the hypervisor. Examples of deployed VM orchestration systems include VMware's vCenter Server, Microsoft's System Center Virtual Machine Manager, and systems based on OpenStack and its associated plugins (e.g., Nova and Neutron). Each can pass information about what virtual networks a VM connects to down to the hypervisor. The protocol used between the VM orchestration system and hypervisors is generally proprietary.
VMオーケストレーションシステムは、管理するサーバーのハイパーバイザーで実行されるエージェントを使用してプロトコルを実行します。そのプロトコルは、VMが関連付けられている仮想ネットワークに関する情報も運ぶことができます。オーケストレーターがハイパーバイザーでVMをインスタンス化すると、ハイパーバイザーはNVEと対話して、VMがアクセスできる仮想ネットワークにVMを接続します。一般に、ハイパーバイザーはVMの状態の大幅な変更をNVEに通知する必要があります。逆方向では、NVEはネットワーク接続情報をハイパーバイザーに通信する必要がある場合があります。デプロイされたVMオーケストレーションシステムの例には、VMwareのvCenter Server、MicrosoftのSystem Center Virtual Machine Manager、OpenStackとその関連プラグイン（NovaやNeutronなど）に基づくシステムが含まれます。それぞれが、VMが接続する仮想ネットワークに関する情報をハイパーバイザーに渡すことができます。 VMオーケストレーションシステムとハイパーバイザー間で使用されるプロトコルは、一般的に独自仕様です。
It should be noted that VM orchestration systems may not have direct access to all networking-related information a VM uses. For example, a VM may make use of additional IP or MAC addresses that the VM management system is not aware of.
VMオーケストレーションシステムは、VMが使用するすべてのネットワーク関連情報に直接アクセスできない場合があることに注意してください。たとえば、VMは、VM管理システムが認識していない追加のIPアドレスまたはMACアドレスを使用する場合があります。
As introduced in Section 3.2, an NVE is the entity that implements the overlay functionality. This section describes NVEs in more detail. An NVE will have two external interfaces:
セクション3.2で紹介したように、NVEはオーバーレイ機能を実装するエンティティです。このセクションでは、NVEについて詳しく説明します。 NVEには2つの外部インターフェースがあります。
Facing the Tenant System: On the side facing the Tenant System, an NVE interacts with the hypervisor (or equivalent entity) to provide the NVO3 service. An NVE will need to be notified when a Tenant System "attaches" to a virtual network (so it can validate the request and set up any state needed to send and receive traffic on behalf of the Tenant System on that VN). Likewise, an NVE will need to be informed when the Tenant System "detaches" from the virtual network so that it can reclaim state and resources appropriately.
テナントシステムに面する：テナントシステムに面する側で、NVEはハイパーバイザー（または同等のエンティティ）と対話してNVO3サービスを提供します。テナントシステムが仮想ネットワークに「アタッチ」したときにNVEに通知する必要があります（そのVNでテナントシステムに代わってトラフィックを送受信するために必要な状態をセットアップしてリクエストを検証できるようにするため）。同様に、NVEは、テナントシステムが状態とリソースを適切に再利用できるように、仮想ネットワークから「切り離される」ときに通知を受ける必要があります。
Facing the Data-Center Network: On the side facing the data-center network, an NVE interfaces with the data-center underlay network, sending and receiving tunneled packets to and from the underlay. The NVE may also run a control protocol with other entities on the network, such as the Network Virtualization Authority.
データセンターネットワークに面する：データセンターネットワークに面する側で、NVEはデータセンターアンダーレイネットワークとインターフェースし、アンダーレイとの間でトンネルパケットを送受信します。 NVEは、ネットワーク仮想化機関など、ネットワーク上の他のエンティティと制御プロトコルを実行する場合もあります。
When server virtualization is used, the entire NVE functionality will typically be implemented as part of the hypervisor and/or virtual switch on the server. In such cases, the Tenant System interacts with the hypervisor, and the hypervisor interacts with the NVE. Because the interaction between the hypervisor and NVE is implemented entirely in software on the server, there is no "on-the-wire" protocol between Tenant Systems (or the hypervisor) and the NVE that needs to be standardized. While there may be APIs between the NVE and hypervisor to support necessary interaction, the details of such APIs are not in scope for the NVO3 WG at the time of publication of this memo.
サーバー仮想化を使用する場合、NVE機能全体は通常、サーバー上のハイパーバイザーまたは仮想スイッチ、あるいはその両方の一部として実装されます。このような場合、テナントシステムはハイパーバイザーと対話し、ハイパーバイザーはNVEと対話します。ハイパーバイザーとNVE間の相互作用はサーバー上のソフトウェアで完全に実装されているため、標準化する必要のあるテナントシステム（またはハイパーバイザー）とNVE間の「オンザワイヤー」プロトコルはありません。必要な相互作用をサポートするためにNVEとハイパーバイザーの間にAPIが存在する可能性がありますが、そのようなAPIの詳細は、このメモの公開時点ではNVO3 WGの範囲にはありません。
Implementing NVE functionality entirely on a server has the disadvantage that server CPU resources must be spent implementing the NVO3 functionality. Experimentation with overlay approaches and previous experience with TCP and checksum adapter offloads suggest that offloading certain NVE operations (e.g., encapsulation and decapsulation operations) onto the physical network adapter can produce performance advantages. As has been done with checksum and/ or TCP server offload and other optimization approaches, there may be benefits to offloading common operations onto adapters where possible. Just as important, the addition of an overlay header can disable existing adapter offload capabilities that are generally not prepared to handle the addition of a new header or other operations associated with an NVE.
サーバーにNVE機能を完全に実装すると、サーバーのCPUリソースをNVO3機能の実装に費やす必要があるという欠点があります。オーバーレイアプローチの実験と、TCPおよびチェックサムアダプターのオフロードに関する以前の経験から、物理ネットワークアダプターに特定のNVE操作（カプセル化やカプセル化解除の操作など）をオフロードすると、パフォーマンスが向上することが示唆されています。チェックサムやTCPサーバーのオフロードやその他の最適化アプローチで行われてきたように、可能であれば、一般的な操作をアダプターにオフロードすることには利点があるかもしれません。同様に重要なのは、オーバーレイヘッダーを追加すると、通常、新しいヘッダーの追加やNVEに関連するその他の操作を処理する準備ができていない既存のアダプターオフロード機能が無効になる可能性があることです。
While the exact details of how to split the implementation of specific NVE functionality between a server and its network adapters are an implementation matter and outside the scope of IETF standardization, the NVO3 architecture should be cognizant of and support such separation. Ideally, it may even be possible to bypass the hypervisor completely on critical data-path operations so that packets between a Tenant System and its VN can be sent and received without having the hypervisor involved in each individual packet operation.
特定のNVE機能の実装をサーバーとそのネットワークアダプターの間で分割する方法の正確な詳細は実装の問題であり、IETF標準化の範囲外ですが、NVO3アーキテクチャはそのような分離を認識し、サポートする必要があります。理想的には、重要なデータパス操作でハイパーバイザーを完全にバイパスして、テナントシステムとそのVN間のパケットを、ハイパーバイザーを個別のパケット操作に関与させることなく送受信できるようにすることさえ可能です。
Another possible scenario leads to the need for a split-NVE implementation. An NVE running on a server (e.g., within a hypervisor) could support NVO3 service towards the tenant but not perform all NVE functions (e.g., encapsulation) directly on the server; some of the actual NVO3 functionality could be implemented on (i.e., offloaded to) an adjacent switch to which the server is attached. While one could imagine a number of link types between a server and the NVE, one simple deployment scenario would involve a server and NVE separated by a simple L2 Ethernet link. A more complicated scenario would have the server and NVE separated by a bridged access network, such as when the NVE resides on a Top of Rack (ToR) switch, with an embedded switch residing between servers and the ToR switch.
別の考えられるシナリオでは、分割NVE実装が必要になります。サーバー上（ハイパーバイザー内など）で実行されているNVEは、テナントに対するNVO3サービスをサポートできますが、サーバー上ですべてのNVE機能（カプセル化など）を直接実行することはできません。実際のNVO3機能の一部は、サーバーが接続されている隣接スイッチに実装（つまり、オフロード）できます。サーバーとNVEの間のリンクタイプはいくつも考えられますが、1つの単純な導入シナリオでは、サーバーとNVEが単純なL2イーサネットリンクで分離されています。より複雑なシナリオでは、サーバーとNVEがブリッジアクセスネットワークによって分離されます。たとえば、NVEがトップオブラック（ToR）スイッチ上にあり、埋め込みスイッチがサーバーとToRスイッチの間にある場合です。
For the split-NVE case, protocols will be needed that allow the hypervisor and NVE to negotiate and set up the necessary state so that traffic sent across the access link between a server and the NVE can be associated with the correct virtual network instance. Specifically, on the access link, traffic belonging to a specific Tenant System would be tagged with a specific VLAN C-TAG that identifies which specific NVO3 virtual network instance it connects to. The hypervisor-NVE protocol would negotiate which VLAN C-TAG to use for a particular virtual network instance. More details of the protocol requirements for functionality between hypervisors and NVEs can be found in [NVE-NVA].
スプリットNVEの場合、ハイパーバイザーとNVEがネゴシエートして必要な状態を設定できるようにするプロトコルが必要です。これにより、サーバーとNVE間のアクセスリンクを介して送信されるトラフィックを正しい仮想ネットワークインスタンスに関連付けることができます。具体的には、アクセスリンクで、特定のテナントシステムに属するトラフィックは、接続先の特定のNVO3仮想ネットワークインスタンスを識別する特定のVLAN C-TAGでタグ付けされます。ハイパーバイザーNVEプロトコルは、特定の仮想ネットワークインスタンスに使用するVLAN C-TAGをネゴシエートします。ハイパーバイザーとNVE間の機能のプロトコル要件の詳細については、[NVE-NVA]を参照してください。
Preserving tenant VLAN tags across an NVO3 VN, as described in Section 3.1.1, poses additional complications in the split-NVE case. The portion of the NVE that performs the encapsulation function needs access to the specific VLAN tags that the Tenant System is using in order to include them in the encapsulated packet. When an NVE is implemented entirely within the hypervisor, the NVE has access to the complete original packet (including any VLAN tags) sent by the tenant. In the split-NVE case, however, the VLAN tag used between the hypervisor and offloaded portions of the NVE normally only identifies the specific VN that traffic belongs to. In order to allow a tenant to preserve VLAN information from end to end between Tenant Systems in the split-NVE case, additional mechanisms would be needed (e.g., carry an additional VLAN tag by carrying both a C-TAG and a Service VLAN Tag (S-TAG) as specified in [IEEE.802.1Q] where the C-TAG identifies the tenant VLAN end to end and the S-TAG identifies the VN locally between each Tenant System and the corresponding NVE).
セクション3.1.1で説明されているように、NVO3 VN全体でテナントVLANタグを保持すると、スプリットNVEのケースでさらに複雑になります。カプセル化機能を実行するNVEの部分は、それらをカプセル化されたパケットに含めるために、テナントシステムが使用している特定のVLANタグにアクセスする必要があります。 NVEが完全にハイパーバイザー内に実装されている場合、NVEはテナントによって送信された完全な元のパケット（VLANタグを含む）にアクセスできます。ただし、分割NVEの場合、ハイパーバイザーとNVEのオフロード部分の間で使用されるVLANタグは、通常、トラフィックが属する特定のVNのみを識別します。スプリットNVEの場合、テナントがテナントシステム間でエンドツーエンドでVLAN情報を保持できるようにするには、追加のメカニズムが必要になります（たとえば、C-TAGとサービスVLANタグの両方を運ぶことで追加のVLANタグを運ぶ（ S-TAG）[IEEE.802.1Q]で指定されているとおり、C-TAGはテナントVLANをエンドツーエンドで識別し、S-TAGは各テナントシステムと対応するNVEの間のVNをローカルで識別します）。
NVEs maintain internal data structures and state to support the sending and receiving of tenant traffic. An NVE may need some or all of the following information:
NVEは内部データ構造と状態を維持して、テナントトラフィックの送受信をサポートします。 NVEには、次の情報の一部またはすべてが必要な場合があります。
1. An NVE keeps track of which attached Tenant Systems are connected to which virtual networks. When a Tenant System attaches to a virtual network, the NVE will need to create or update the local state for that virtual network. When the last Tenant System detaches from a given VN, the NVE can reclaim state associated with that VN.
1. NVEは、接続されているどのテナントシステムがどの仮想ネットワークに接続されているかを追跡します。テナントシステムが仮想ネットワークに接続すると、NVEはその仮想ネットワークのローカル状態を作成または更新する必要があります。最後のテナントシステムが特定のVNから切り離されると、NVEはそのVNに関連付けられた状態を取り戻すことができます。
2. For tenant unicast traffic, an NVE maintains a per-VN table of mappings from Tenant System (inner) addresses to remote NVE (outer) addresses.
2. テナントユニキャストトラフィックの場合、NVEは、テナントシステム（内部）アドレスからリモートNVE（外部）アドレスへのマッピングのVNごとのテーブルを維持します。
3. For tenant multicast (or broadcast) traffic, an NVE maintains a per-VN table of mappings and other information on how to deliver tenant multicast (or broadcast) traffic. If the underlying network supports IP multicast, the NVE could use IP multicast to deliver tenant traffic. In such a case, the NVE would need to know what IP underlay multicast address to use for a given VN. Alternatively, if the underlying network does not support multicast, a source NVE could use unicast replication to deliver traffic. In such a case, an NVE would need to know which remote NVEs are participating in the VN. An NVE could use both approaches, switching from one mode to the other depending on factors such as bandwidth efficiency and group membership sparseness. [FRAMEWORK-MCAST] discusses the subject of multicast handling in NVO3 in further detail.
3.テナントマルチキャスト（またはブロードキャスト）トラフィックの場合、NVEは、マッピングのVNごとのテーブルと、テナントマルチキャスト（またはブロードキャスト）トラフィックの配信方法に関するその他の情報を維持します。基盤となるネットワークがIPマルチキャストをサポートしている場合、NVEはIPマルチキャストを使用してテナントトラフィックを配信できます。このような場合、NVEは特定のVNに使用するIPアンダーレイマルチキャストアドレスを知る必要があります。または、基盤となるネットワークがマルチキャストをサポートしていない場合、ソースNVEはユニキャストレプリケーションを使用してトラフィックを配信できます。このような場合、NVEはどのリモートNVEがVNに参加しているかを知る必要があります。 NVEは両方のアプローチを使用でき、帯域幅効率やグループメンバーシップのスパース性などの要素に応じて、1つのモードから別のモードに切り替えます。 [FRAMEWORK-MCAST]では、NVO3でのマルチキャスト処理の主題についてさらに詳しく説明しています。
4. An NVE maintains necessary information to encapsulate outgoing traffic, including what type of encapsulation and what value to use for a Context ID to identify the VN within the encapsulation header.
4. NVEは、カプセル化の種類、カプセル化ヘッダー内のVNを識別するためにコンテキストIDに使用する値など、発信トラフィックをカプセル化するために必要な情報を保持します。
5. In order to deliver incoming encapsulated packets to the correct Tenant Systems, an NVE maintains the necessary information to map incoming traffic to the appropriate VAP (i.e., TSI).
5. 着信カプセル化パケットを正しいテナントシステムに配信するために、NVEは着信トラフィックを適切なVAP（つまり、TSI）にマップするために必要な情報を維持します。
6. An NVE may find it convenient to maintain additional per-VN information such as QoS settings, Path MTU information, Access Control Lists (ACLs), etc.
6. NVEでは、QoS設定、パスMTU情報、アクセス制御リスト（ACL）などの追加のVNごとの情報を維持すると便利な場合があります。
NVEs may be multihomed. That is, an NVE may have more than one IP address associated with it on the underlay network. Multihoming happens in two different scenarios. First, an NVE may have multiple interfaces connecting it to the underlay. Each of those interfaces will typically have a different IP address, resulting in a specific Tenant Address (on a specific VN) being reachable through the same NVE but through more than one underlay IP address. Second, a specific Tenant System may be reachable through more than one NVE, each having one or more underlay addresses. In both cases, NVE address-mapping functionality needs to support one-to-many mappings and enable a sending NVE to (at a minimum) be able to fail over from one IP address to another, e.g., should a specific NVE underlay address become unreachable.
NVEはマルチホームにすることができます。つまり、NVEには、アンダーレイネットワーク上の複数のIPアドレスが関連付けられている場合があります。マルチホーミングは、2つの異なるシナリオで発生します。まず、NVEには、NVEをアンダーレイに接続する複数のインターフェイスがある場合があります。これらの各インターフェイスには通常、異なるIPアドレスが割り当てられているため、同じNVEを介して複数のアンダーレイIPアドレスを介して（特定のVN上の）特定のテナントアドレスに到達できます。第2に、特定のテナントシステムは、それぞれが1つ以上のアンダーレイアドレスを持つ複数のNVEを介して到達できる場合があります。どちらの場合も、NVEアドレスマッピング機能は、1対多のマッピングをサポートし、送信NVEが（少なくとも）特定のNVEアンダーレイアドレスになった場合などに、あるIPアドレスから別のIPアドレスにフェイルオーバーできるようにする必要があります。到達不能。
Finally, multihomed NVEs introduce complexities when source unicast replication is used to implement tenant multicast as described in Section 4.3. Specifically, an NVE should only receive one copy of a replicated packet.
最後に、セクション4.3で説明されているように、ソースユニキャストレプリケーションを使用してテナントマルチキャストを実装すると、マルチホームNVEが複雑になります。具体的には、NVEは複製されたパケットのコピーを1つだけ受信する必要があります。
Multihoming is needed to support important use cases. First, a bare metal server may have multiple uplink connections to either the same or different NVEs. Having only a single physical path to an upstream NVE, or indeed, having all traffic flow through a single NVE would be considered unacceptable in highly resilient deployment scenarios that seek to avoid single points of failure. Moreover, in today's networks, the availability of multiple paths would require that they be usable in an active-active fashion (e.g., for load balancing).
重要なユースケースをサポートするには、マルチホーミングが必要です。まず、ベアメタルサーバーには、同じまたは異なるNVEへの複数のアップリンク接続があります。アップストリームNVEへの物理パスが1つしかない場合、または実際に、すべてのトラフィックフローが1つのNVEを通過している場合は、単一障害点を回避しようとする復元力の高い展開シナリオでは受け入れられないと考えられます。さらに、今日のネットワークでは、複数のパスを使用できるようにするために、それらをアクティブ/アクティブな方法で使用できるようにする必要があります（たとえば、負荷分散など）。
The VAP is the NVE side of the interface between the NVE and the TS. Traffic to and from the tenant flows through the VAP. If an NVE runs into difficulties sending traffic received on the VAP, it may need to signal such errors back to the VAP. Because the VAP is an emulation of a physical port, its ability to signal NVE errors is limited and lacks sufficient granularity to reflect all possible errors an NVE may encounter (e.g., inability to reach a particular destination). Some errors, such as an NVE losing all of its connections to the underlay, could be reflected back to the VAP by effectively disabling it. This state change would reflect itself on the TS as an interface going down, allowing the TS to implement interface error handling (e.g., failover) in the same manner as when a physical interface becomes disabled.
VAPは、NVEとTS間のインターフェースのNVE側です。テナントとの間のトラフィックはVAPを流れます。 NVEがVAPで受信したトラフィックの送信に問題が発生した場合、そのようなエラーをVAPに通知する必要がある場合があります。 VAPは物理ポートのエミュレーションであるため、NVEエラーを通知する機能は制限されており、NVEで発生する可能性のあるすべてのエラー（特定の宛先に到達できないなど）を反映するための十分な粒度がありません。 NVEがアンダーレイへの接続をすべて失うなどの一部のエラーは、効果的に無効にすることでVAPに反映される可能性があります。この状態の変化は、ダウンしたインターフェースとしてTSに反映され、物理インターフェースが無効になった場合と同じ方法でTSがインターフェースのエラー処理（フェイルオーバーなど）を実装できるようにします。
This section describes a number of special Tenant System types and how they fit into an NVO3 system.
このセクションでは、いくつかの特殊なテナントシステムタイプと、それらがNVO3システムにどのように適合するかについて説明します。
Some Network Service Appliances [NVE-NVA] (virtual or physical) provide tenant-aware services. That is, the specific service they provide depends on the identity of the tenant making use of the service. For example, firewalls are now becoming available that support multitenancy where a single firewall provides virtual firewall service on a per-tenant basis, using per-tenant configuration rules and maintaining per-tenant state. Such appliances will be aware of the VN an activity corresponds to while processing requests. Unlike server virtualization, which shields VMs from needing to know about multitenancy, a Network Service Appliance may explicitly support multitenancy. In such cases, the Network Service Appliance itself will be aware of network virtualization and either embed an NVE directly or implement a split-NVE as described in Section 4.2. Unlike server virtualization, however, the Network Service Appliance may not be running a hypervisor, and the VM orchestration system may not interact with the Network Service Appliance. The NVE on such appliances will need to support a control plane to obtain the necessary information needed to fully participate in an NV Domain.
一部のネットワークサービスアプライアンス[NVE-NVA]（仮想または物理）は、テナント対応サービスを提供します。つまり、それらが提供する特定のサービスは、サービスを利用するテナントのIDに依存します。たとえば、マルチテナントをサポートするファイアウォールが利用可能になり、単一のファイアウォールがテナントごとに仮想ファイアウォールサービスを提供し、テナントごとの構成ルールを使用して、テナントごとの状態を維持しています。このようなアプライアンスは、リクエストの処理中にアクティビティが対応するVNを認識します。 VMがマルチテナンシーについて知る必要がないようにするサーバー仮想化とは異なり、ネットワークサービスアプライアンスはマルチテナンシーを明示的にサポートする場合があります。このような場合、ネットワークサービスアプライアンス自体はネットワーク仮想化を認識し、NVEを直接埋め込むか、セクション4.2で説明されているように分割NVEを実装します。ただし、サーバー仮想化とは異なり、Network Service Applianceはハイパーバイザーを実行していない場合があり、VMオーケストレーションシステムはNetwork Service Applianceと相互作用しない場合があります。このようなアプライアンスのNVEは、NVドメインに完全に参加するために必要な情報を取得するために、コントロールプレーンをサポートする必要があります。
Many data centers will continue to have at least some servers operating as non-virtualized (or "bare metal") machines running a traditional operating system and workload. In such systems, there will be no NVE functionality on the server, and the server will have no knowledge of NVO3 (including whether overlays are even in use). In such environments, the NVE functionality can reside on the first-hop physical switch. In such a case, the network administrator would (manually) configure the switch to enable the appropriate NVO3 functionality on the switch port connecting the server and associate that port with a specific virtual network. Such configuration would typically be static, since the server is not virtualized and, once configured, is unlikely to change frequently. Consequently, this scenario does not require any protocol or standards work.
多くのデータセンターでは、従来のオペレーティングシステムとワークロードを実行する非仮想化（または「ベアメタル」）マシンとして動作するサーバーが少なくともいくつかあります。このようなシステムでは、サーバーにNVE機能がなく、サーバーはNVO3を認識しません（オーバーレイが使用されているかどうかを含む）。このような環境では、NVE機能をファーストホップ物理スイッチに配置できます。このような場合、ネットワーク管理者は、サーバーを接続するスイッチポートで適切なNVO3機能を有効にし、そのポートを特定の仮想ネットワークに関連付けるように（手動で）スイッチを構成します。サーバーは仮想化されておらず、一度構成すると頻繁に変更されることはないため、このような構成は通常静的です。したがって、このシナリオでは、プロトコルや標準の作業は必要ありません。
Gateways on VNs relay traffic onto and off of a virtual network. Tenant Systems use gateways to reach destinations outside of the local VN. Gateways receive encapsulated traffic from one VN, remove the encapsulation header, and send the native packet out onto the data-center network for delivery. Outside traffic enters a VN in a reverse manner.
VNのゲートウェイは、仮想ネットワークのトラフィックを中継します。テナントシステムは、ゲートウェイを使用してローカルVN外の宛先に到達します。ゲートウェイは、1つのVNからカプセル化されたトラフィックを受信し、カプセル化ヘッダーを削除して、ネイティブパケットをデータセンターネットワークに送信して配信します。外部トラフィックは、逆の方法でVNに入ります。
Gateways can be either virtual (i.e., implemented as a VM) or physical (i.e., a standalone physical device). For performance reasons, standalone hardware gateways may be desirable in some cases. Such gateways could consist of a simple switch forwarding traffic from a VN onto the local data-center network or could embed router functionality. On such gateways, network interfaces connecting to virtual networks will (at least conceptually) embed NVE (or split-NVE) functionality within them. As in the case with Network Service Appliances, gateways may not support a hypervisor and will need an appropriate control-plane protocol to obtain the information needed to provide NVO3 service.
ゲートウェイは、仮想（VMとして実装される）または物理（スタンドアロンの物理デバイス）のいずれかです。パフォーマンス上の理由から、スタンドアロンのハードウェアゲートウェイが望ましい場合があります。このようなゲートウェイは、VNからローカルデータセンターネットワークにトラフィックを転送する単純なスイッチで構成することも、ルーター機能を組み込むこともできます。そのようなゲートウェイでは、仮想ネットワークに接続するネットワークインターフェイスが（少なくとも概念的には）NVE（またはスプリットNVE）機能をゲートウェイに組み込みます。ネットワークサービスアプライアンスの場合と同様に、ゲートウェイはハイパーバイザーをサポートしない場合があり、NVO3サービスを提供するために必要な情報を取得するために適切なコントロールプレーンプロトコルが必要になります。
Gateways handle several different use cases. For example, one use case consists of systems supporting overlays together with systems that do not (e.g., bare metal servers). Gateways could be used to connect legacy systems supporting, e.g., L2 VLANs, to specific virtual networks, effectively making them part of the same virtual network. Gateways could also forward traffic between a virtual network and other hosts on the data-center network or relay traffic between different VNs. Finally, gateways can provide external connectivity such as Internet or VPN access.
ゲートウェイは、いくつかの異なる使用例を処理します。たとえば、1つの使用例は、オーバーレイをサポートするシステムとサポートしないシステム（ベアメタルサーバーなど）で構成されます。ゲートウェイを使用して、L2 VLANなどをサポートするレガシーシステムを特定の仮想ネットワークに接続し、それらを効果的に同じ仮想ネットワークの一部にすることができます。ゲートウェイは、仮想ネットワークとデータセンターネットワーク上の他のホスト間のトラフィックを転送したり、異なるVN間のトラフィックを中継したりすることもできます。最後に、ゲートウェイはインターネットやVPNアクセスなどの外部接続を提供できます。
As can be seen from the discussion above, there are several types of gateways that can exist in an NVO3 environment. This section breaks them down into the various types that could be supported. Note that each of the types below could be either implemented in a centralized manner or distributed to coexist with the NVEs.
上記の説明からわかるように、NVO3環境に存在できるゲートウェイにはいくつかのタイプがあります。このセクションでは、それらをサポートできるさまざまなタイプに分類します。以下の各タイプは、集中管理された方法で実装することも、NVEと共存させるために分散することもできます。
L2 Gateways act as Layer 2 bridges to forward Ethernet frames based on the MAC addresses present in them.
L2ゲートウェイは、レイヤー2ブリッジとして機能し、そこに存在するMACアドレスに基づいてイーサネットフレームを転送します。
L2 VN to Legacy L2: This type of gateway bridges traffic between L2 VNs and other legacy L2 networks such as VLANs or L2 VPNs.
L2 VNからレガシーL2：このタイプのゲートウェイは、L2 VNと、VLANやL2 VPNなどの他のレガシーL2ネットワーク間のトラフィックをブリッジします。
L2 VN to L2 VN: The main motivation for this type of gateway is to create separate groups of Tenant Systems using L2 VNs such that the gateway can enforce network policies between each L2 VN.
L2 VNからL2 VN：このタイプのゲートウェイの主な動機は、ゲートウェイが各L2 VN間にネットワークポリシーを適用できるように、L2 VNを使用してテナントシステムの個別のグループを作成することです。
L3 Gateways forward IP packets based on the IP addresses present in the packets.
L3ゲートウェイは、パケット内に存在するIPアドレスに基づいてIPパケットを転送します。
L3 VN to Legacy L2: This type of gateway forwards packets between L3 VNs and legacy L2 networks such as VLANs or L2 VPNs. The original sender's destination MAC address in any frames that the gateway forwards from a legacy L2 network would be the MAC address of the gateway.
L3 VNからレガシーL2へ：このタイプのゲートウェイは、L3 VNとVLANやL2 VPNなどのレガシーL2ネットワークの間でパケットを転送します。ゲートウェイがレガシーL2ネットワークから転送するフレーム内の元の送信者の宛先MACアドレスは、ゲートウェイのMACアドレスになります。
L3 VN to Legacy L3: This type of gateway forwards packets between L3 VNs and legacy L3 networks. These legacy L3 networks could be local to the data center, be in the WAN, or be an L3 VPN.
L3 VNからレガシーL3へ：このタイプのゲートウェイは、L3 VNとレガシーL3ネットワークの間でパケットを転送します。これらのレガシーL3ネットワークは、データセンターのローカル、WAN内、またはL3 VPNの可能性があります。
L3 VN to L2 VN: This type of gateway forwards packets between L3 VNs and L2 VNs. The original sender's destination MAC address in any frames that the gateway forwards from a L2 VN would be the MAC address of the gateway.
L3 VNからL2 VN：このタイプのゲートウェイは、L3 VNとL2 VNの間でパケットを転送します。ゲートウェイがL2 VNから転送するフレーム内の元の送信者の宛先MACアドレスは、ゲートウェイのMACアドレスになります。
L2 VN to L2 VN: This type of gateway acts similar to a traditional router that forwards between L2 interfaces. The original sender's destination MAC address in any frames that the gateway forwards from any of the L2 VNs would be the MAC address of the gateway.
L2 VNからL2 VN：このタイプのゲートウェイは、L2インターフェース間で転送する従来のルーターと同様に機能します。ゲートウェイがいずれかのL2 VNから転送するフレーム内の元の送信者の宛先MACアドレスは、ゲートウェイのMACアドレスになります。
L3 VN to L3 VN: The main motivation for this type of gateway is to create separate groups of Tenant Systems using L3 VNs such that the gateway can enforce network policies between each L3 VN.
L3 VNからL3 VN：このタイプのゲートウェイの主な動機は、ゲートウェイが各L3 VN間にネットワークポリシーを適用できるように、L3 VNを使用してテナントシステムの個別のグループを作成することです。
The relaying of traffic from one VN to another deserves special consideration. Whether traffic is permitted to flow from one VN to another is a matter of policy and would not (by default) be allowed unless explicitly enabled. In addition, NVAs are the logical place to maintain policy information about allowed inter-VN communication. Policy enforcement for inter-VN communication can be handled in (at least) two different ways. Explicit gateways could be the central point for such enforcement, with all inter-VN traffic forwarded to such gateways for processing. Alternatively, the NVA can provide such information directly to NVEs by either providing a mapping for a target Tenant System (TS) on another VN or indicating that such communication is disallowed by policy.
あるVNから別のVNへのトラフィックの中継は、特別な考慮に値します。あるVNから別のVNへのトラフィックの流れを許可するかどうかはポリシーの問題であり、明示的に有効にしない限り（デフォルトでは）許可されません。さらに、NVAは、許可されたVN間通信に関するポリシー情報を維持するための論理的な場所です。 VN間通信のポリシー実施は、（少なくとも）2つの異なる方法で処理できます。明示的なゲートウェイは、そのような実施の中心点である可能性があり、すべてのVN間トラフィックは、処理のためにそのようなゲートウェイに転送されます。または、NVAは、別のVN上のターゲットテナントシステム（TS）のマッピングを提供するか、そのような通信がポリシーで許可されていないことを示すことにより、そのような情報をNVEに直接提供できます。
When inter-VN gateways are centralized, traffic between TSs on different VNs can take suboptimal paths, i.e., triangular routing results in paths that always traverse the gateway. In the worst case, traffic between two TSs connected to the same NVE can be hair-pinned through an external gateway. As an optimization, individual NVEs can be part of a distributed gateway that performs such relaying, reducing or completely eliminating triangular routing. In a distributed gateway, each ingress NVE can perform such relaying activity directly so long as it has access to the policy information needed to determine whether cross-VN communication is allowed. Having individual NVEs be part of a distributed gateway allows them to tunnel traffic directly to the destination NVE without the need to take suboptimal paths.
VN間ゲートウェイが集中化されている場合、異なるVN上のTS間のトラフィックは次善のパスをとることができます。つまり、三角形のルーティングは、常にゲートウェイを通過するパスになります。最悪の場合、同じNVEに接続された2つのTS間のトラフィックは、外部ゲートウェイを介してヘアピン接続できます。最適化として、個々のNVEは、このような中継を実行する分散ゲートウェイの一部にすることができ、三角ルーティングを削減または完全に排除します。分散ゲートウェイでは、VN間通信が許可されているかどうかを判断するために必要なポリシー情報にアクセスできる限り、各入力NVEはこのようなリレーアクティビティを直接実行できます。個々のNVEを分散ゲートウェイの一部にすることで、最適でないパスをとる必要なく、トラフィックを宛先NVEに直接トンネルできます。
The NVO3 architecture supports distributed gateways for the case of inter-VN communication. Such support requires that NVO3 control protocols include mechanisms for the maintenance and distribution of policy information about what type of cross-VN communication is allowed so that NVEs acting as distributed gateways can tunnel traffic from one VN to another as appropriate.
NVO3アーキテクチャは、VN間通信の場合の分散ゲートウェイをサポートします。このようなサポートでは、分散ゲートウェイとして機能するNVEが1つのVNから別のVNにトラフィックを適切にトンネリングできるように、NVO3制御プロトコルに、許可されるクロスVN通信のタイプに関するポリシー情報のメンテナンスと配布のメカニズムが含まれている必要があります。
Distributed gateways could also be used to distribute other traditional router services to individual NVEs. The NVO3 architecture does not preclude such implementations but does not define or require them as they are outside the scope of the NVO3 architecture.
分散ゲートウェイは、他の従来のルーターサービスを個々のNVEに配布するためにも使用できます。 NVO3アーキテクチャはそのような実装を排除するものではありませんが、NVO3アーキテクチャの範囲外であるため、それらを定義したり必要としたりすることはありません。
Strictly speaking, for an L2 service, special processing of the Address Resolution Protocol (ARP) [RFC826] and IPv6 Neighbor Discovery (ND) [RFC4861] is not required. ARP requests are broadcast, and an NVO3 can deliver ARP requests to all members of a given L2 virtual network just as it does for any packet sent to an L2 broadcast address. Similarly, ND requests are sent via IP multicast, which NVO3 can support by delivering via L2 multicast. However, as a performance optimization, an NVE can intercept ARP (or ND) requests from its attached TSs and respond to them directly using information in its mapping tables. Since an NVE will have mechanisms for determining the NVE address associated with a given TS, the NVE can leverage the same mechanisms to suppress sending ARP and ND requests for a given TS to other members of the VN. The NVO3 architecture supports such a capability.
厳密に言えば、L2サービスの場合、アドレス解決プロトコル（ARP）[RFC826]およびIPv6近隣探索（ND）[RFC4861]の特別な処理は必要ありません。 ARP要求はブロードキャストされ、NVO3は、L2ブロードキャストアドレスに送信されたパケットに対して行うのと同じように、特定のL2仮想ネットワークのすべてのメンバーにARP要求を配信できます。同様に、ND要求はIPマルチキャストを介して送信され、NVO3はL2マルチキャストを介して配信することでサポートできます。ただし、パフォーマンスの最適化として、NVEは接続されたTSからのARP（またはND）要求をインターセプトし、マッピングテーブルの情報を使用してそれらに直接応答できます。 NVEには特定のTSに関連付けられたNVEアドレスを決定するメカニズムがあるため、NVEは同じメカニズムを利用して、特定のTSに対するARPおよびND要求をVNの他のメンバーに送信しないようにすることができます。 NVO3アーキテクチャは、このような機能をサポートしています。
Individual NVEs will interact with each other for the purposes of tunneling and delivering traffic to remote TSs. At a minimum, a control protocol may be needed for tunnel setup and maintenance. For example, tunneled traffic may need to be encrypted or integrity protected, in which case it will be necessary to set up appropriate security associations between NVE peers. It may also be desirable to perform tunnel maintenance (e.g., continuity checks) on a tunnel in order to detect when a remote NVE becomes unreachable. Such generic tunnel setup and maintenance functions are not generally NVO3-specific. Hence, the NVO3 architecture expects to leverage existing tunnel maintenance protocols rather than defining new ones.
個々のNVEは、トラフィックをトンネリングしてリモートTSに配信する目的で相互に対話します。少なくとも、トンネルのセットアップとメンテナンスには制御プロトコルが必要になる場合があります。たとえば、トンネル化されたトラフィックは、暗号化または整合性保護が必要な場合があります。その場合、NVEピア間に適切なセキュリティアソシエーションをセットアップする必要があります。また、リモートNVEが到達不能になったことを検出するために、トンネルでトンネルのメンテナンス（継続性チェックなど）を実行することが望ましい場合もあります。このような一般的なトンネルのセットアップおよびメンテナンス機能は、一般にNVO3固有ではありません。したがって、NVO3アーキテクチャは、新しいプロトコルを定義するのではなく、既存のトンネル保守プロトコルを活用することを期待しています。
Some NVE-NVE interactions may be specific to NVO3 (in particular, be related to information kept in mapping tables) and agnostic to the specific tunnel type being used. For example, when tunneling traffic for TS-X to a remote NVE, it is possible that TS-X is not presently associated with the remote NVE. Normally, this should not happen, but there could be race conditions where the information an NVE has learned from the NVA is out of date relative to actual conditions. In such cases, the remote NVE could return an error or warning indication, allowing the sending NVE to attempt a recovery or otherwise attempt to mitigate the situation.
一部のNVE-NVE相互作用はNVO3に固有であり（特に、マッピングテーブルに保持されている情報に関連している）、使用されている特定のトンネルタイプに依存しない場合があります。たとえば、TS-XのトラフィックをリモートNVEにトンネリングする場合、TS-Xが現在リモートNVEに関連付けられていない可能性があります。通常、これは発生しないはずですが、NVEがNVAから学習した情報が実際の状態に比べて古くなっているという競合状態が発生する可能性があります。このような場合、リモートNVEはエラーまたは警告の表示を返す可能性があり、送信側のNVEが回復を試みたり、状況の緩和を試みたりできるようにします。
The NVE-NVE interaction could signal a range of indications, for example:
NVE-NVEインタラクションは、さまざまな表示を示すことができます。次に例を示します。
o "No such TS here", upon a receipt of a tunneled packet for an unknown TS
o 「このようなTSはありません」、不明なTSのトンネルパケットを受信したとき
o "TS-X not here, try the following NVE instead" (i.e., a redirect)
o 「TS-Xはここにありません。代わりに次のNVEを試してください」（つまり、リダイレクト）
o "Delivered to correct NVE but could not deliver packet to TS-X"
o 「NVEを修正するために配信されましたが、TS-Xにパケットを配信できませんでした」
When an NVE receives information from a remote NVE that conflicts with the information it has in its own mapping tables, it should consult with the NVA to resolve those conflicts. In particular, it should confirm that the information it has is up to date, and it might indicate the error to the NVA so as to nudge the NVA into following up (as appropriate). While it might make sense for an NVE to update its mapping table temporarily in response to an error from a remote NVE, any changes must be handled carefully as doing so can raise security considerations if the received information cannot be authenticated. That said, a sending NVE might still take steps to mitigate a problem, such as applying rate limiting to data traffic towards a particular NVE or TS.
NVEがリモートNVEから情報を受信すると、NVEは自身のマッピングテーブルにある情報と競合するため、NVAに相談してこれらの競合を解決する必要があります。特に、情報が最新であることを確認する必要があります。また、NVAに（必要に応じて）フォローアップするようにNVAにエラーを示す可能性があります。 NVEがリモートNVEからのエラーに応答して一時的にマッピングテーブルを更新することは理にかなっているかもしれませんが、受信した情報が認証されない場合にセキュリティ上の考慮事項が発生する可能性があるため、変更は慎重に処理する必要があります。つまり、送信側のNVEは、特定のNVEまたはTSへのデータトラフィックにレート制限を適用するなど、問題を軽減するための手順を実行する場合があります。
Before sending traffic to and receiving traffic from a virtual network, an NVE must obtain the information needed to build its internal forwarding tables and state as listed in Section 4.3. An NVE can obtain such information from a Network Virtualization Authority (NVA).
仮想ネットワークとの間でトラフィックを送受信する前に、NVEは、セクション4.3に記載されている内部転送テーブルと状態を構築するために必要な情報を取得する必要があります。 NVEは、Network Virtualization Authority（NVA）からそのような情報を取得できます。
The NVA is the entity that is expected to provide address mapping and other information to NVEs. NVEs can interact with an NVA to obtain any required information they need in order to properly forward traffic on behalf of tenants. The term "NVA" refers to the overall system, without regard to its scope or how it is implemented.
NVAは、アドレスマッピングおよびその他の情報をNVEに提供することが期待されるエンティティです。 NVEはNVAと対話して、テナントに代わってトラフィックを適切に転送するために必要な情報を取得できます。 「NVA」という用語は、その範囲や実装方法に関係なく、システム全体を指します。
There are two primary ways in which an NVA can obtain the address dissemination information it manages: from the VM orchestration system and/or directly from the NVEs themselves.
NVAが管理するアドレス配布情報を取得するには、VMオーケストレーションシステムから、またはNVE自体から直接、あるいはその両方で、主に2つの方法があります。
On virtualized systems, the NVA may be able to obtain the address-mapping information associated with VMs from the VM orchestration system itself. If the VM orchestration system contains a master database for all the virtualization information, having the NVA obtain information directly from the orchestration system would be a natural approach. Indeed, the NVA could effectively be co-located with the VM orchestration system itself. In such systems, the VM orchestration system communicates with the NVE indirectly through the hypervisor.
仮想化システムでは、NVAはVMオーケストレーションシステム自体からVMに関連付けられたアドレスマッピング情報を取得できる場合があります。 VMオーケストレーションシステムにすべての仮想化情報のマスターデータベースが含まれている場合、NVAがオーケストレーションシステムから直接情報を取得するのは自然なアプローチです。実際、NVAはVMオーケストレーションシステム自体と効果的に同じ場所に配置できます。このようなシステムでは、VMオーケストレーションシステムはハイパーバイザーを介して間接的にNVEと通信します。
However, as described in Section 4, not all NVEs are associated with hypervisors. In such cases, NVAs cannot leverage VM orchestration protocols to interact with an NVE and will instead need to peer directly with them. By peering directly with an NVE, NVAs can obtain information about the TSs connected to that NVE and can distribute information to the NVE about the VNs those TSs are associated with. For example, whenever a Tenant System attaches to an NVE, that NVE would notify the NVA that the TS is now associated with that NVE. Likewise, when a TS detaches from an NVE, that NVE would inform the NVA. By communicating directly with NVEs, both the NVA and the NVE are able to maintain up-to-date information about all active tenants and the NVEs to which they are attached.
ただし、セクション4で説明されているように、すべてのNVEがハイパーバイザーに関連付けられているわけではありません。そのような場合、NVAはVMオーケストレーションプロトコルを利用してNVEと対話することができず、代わりにそれらを直接ピアリングする必要があります。 NVEと直接ピアリングすることにより、NVAはそのNVEに接続されているTSに関する情報を取得し、それらのTSが関連付けられているVNに関する情報をNVEに配信できます。たとえば、テナントシステムがNVEに接続するときは常に、そのNVEはTSがそのNVEに関連付けられていることをNVAに通知します。同様に、TSがNVEから切り離されると、そのNVEはNVAに通知します。 NVEと直接通信することにより、NVAとNVEの両方が、アクティブなすべてのテナントとそれらが接続されているNVEに関する最新情報を維持できます。
For reliability and fault tolerance reasons, an NVA would be implemented in a distributed or replicated manner without single points of failure. How the NVA is implemented, however, is not important to an NVE so long as the NVA provides a consistent and well-defined interface to the NVE. For example, an NVA could be implemented via database techniques whereby a server stores address-mapping information in a traditional (possibly replicated) database. Alternatively, an NVA could be implemented in a distributed fashion using an existing (or modified) routing protocol to maintain and distribute mappings. So long as there is a clear interface between the NVE and NVA, how an NVA is architected and implemented is not important to an NVE.
信頼性とフォールトトレランスの理由から、NVAは単一障害点のない分散型または複製型で実装されます。ただし、NVAが一貫して明確に定義されたインターフェイスをNVEに提供する限り、NVAの実装方法はNVEにとって重要ではありません。たとえば、NVAは、データベース技術を使用して実装できます。これにより、サーバーはアドレスマッピング情報を従来の（場合によっては複製された）データベースに格納します。あるいは、NVAは、既存の（または変更された）ルーティングプロトコルを使用して分散方式で実装し、マッピングを維持および分散することもできます。 NVEとNVAの間に明確なインターフェースがある限り、NVAがどのように設計および実装されるかはNVEにとって重要ではありません。
A number of architectural approaches could be used to implement NVAs themselves. NVAs manage address bindings and distribute them to where they need to go. One approach would be to use the Border Gateway Protocol (BGP) [RFC4364] (possibly with extensions) and route reflectors. Another approach could use a transaction-based database model with replicated servers. Because the implementation details are local to an NVA, there is no need to pick exactly one solution technology, so long as the external interfaces to the NVEs (and remote NVAs) are sufficiently well defined to achieve interoperability.
多数のアーキテクチャアプローチを使用して、NVA自体を実装できます。 NVAはアドレスバインディングを管理し、それらを必要な場所に配布します。 1つのアプローチは、ボーダーゲートウェイプロトコル（BGP）[RFC4364]（おそらく拡張機能付き）とルートリフレクターを使用することです。別のアプローチでは、複製されたサーバーでトランザクションベースのデータベースモデルを使用できます。実装の詳細はNVAに対してローカルであるため、NVE（およびリモートNVA）への外部インターフェイスが相互運用性を実現するために十分に定義されている限り、1つのソリューションテクノロジーを選択する必要はありません。
Conceptually, from the perspective of an NVE, an NVA is a single entity. An NVE interacts with the NVA, and it is the NVA's responsibility to ensure that interactions between the NVE and NVA result in consistent behavior across the NVA and all other NVEs using the same NVA. Because an NVA is built from multiple internal components, an NVA will have to ensure that information flows to all internal NVA components appropriately.
概念的には、NVEの観点から見ると、NVAは単一のエンティティーです。 NVEはNVAと相互作用します。NVEとNVA間の相互作用により、NVAと同じNVAを使用する他のすべてのNVEで一貫した動作が確実に行われるようにするのは、NVAの責任です。 NVAは複数の内部コンポーネントから構築されているため、NVAは情報がすべての内部NVAコンポーネントに適切に流れるようにする必要があります。
One architectural question is how the NVA presents itself to the NVE. For example, an NVA could be required to provide access via a single IP address. If NVEs only have one IP address to interact with, it would be the responsibility of the NVA to handle NVA component failures, e.g., by using a "floating IP address" that migrates among NVA components to ensure that the NVA can always be reached via the one address. Having all NVA accesses through a single IP address, however, adds constraints to implementing robust failover, load balancing, etc.
アーキテクチャに関する1つの問題は、NVAがNVEにどのように提示されるかです。たとえば、単一のIPアドレスを介してアクセスを提供するためにNVAが必要になる場合があります。 NVEが相互作用するIPアドレスが1つしかない場合、NVAコンポーネント間で移行する「フローティングIPアドレス」を使用してNVAに常に到達できるようにするなど、NVAコンポーネントの障害を処理するのはNVAの責任です。 1つのアドレス。ただし、単一のIPアドレスを介してすべてのNVAアクセスを行うと、堅牢なフェイルオーバー、ロードバランシングなどの実装に制約が追加されます。
In the NVO3 architecture, an NVA is accessed through one or more IP addresses (or an IP address/port combination). If multiple IP addresses are used, each IP address provides equivalent functionality, meaning that an NVE can use any of the provided addresses to interact with the NVA. Should one address stop working, an NVE is expected to failover to another. While the different addresses result in equivalent functionality, one address may respond more quickly than another, e.g., due to network conditions, load on the server, etc.
NVO3アーキテクチャでは、NVAは1つ以上のIPアドレス（またはIPアドレスとポートの組み合わせ）を介してアクセスされます。複数のIPアドレスが使用されている場合、各IPアドレスは同等の機能を提供します。つまり、NVEは提供されたアドレスのいずれかを使用してNVAと対話できます。あるアドレスが機能を停止した場合、NVEは別のアドレスにフェイルオーバーすることが期待されます。異なるアドレスを使用しても同等の機能が得られますが、ネットワークの状態やサーバーの負荷などにより、あるアドレスが別のアドレスよりも速く応答する場合があります。
To provide some control over load balancing, NVA addresses may have an associated priority. Addresses are used in order of priority, with no explicit preference among NVA addresses having the same priority. To provide basic load balancing among NVAs of equal priorities, NVEs could use some randomization input to select among equal-priority NVAs. Such a priority scheme facilitates failover and load balancing, for example, by allowing a network operator to specify a set of primary and backup NVAs.
ロードバランシングをある程度制御するために、NVAアドレスに関連付けられた優先順位がある場合があります。アドレスは優先度の順に使用され、同じ優先度を持つNVAアドレス間の明示的な優先順位はありません。優先度が等しいNVA間で基本的なロードバランシングを提供するために、NVEはランダム化入力を使用して、優先度が等しいNVAから選択できます。このような優先度スキームは、たとえば、ネットワークオペレーターがプライマリとバックアップのNVAのセットを指定できるようにすることで、フェイルオーバーとロードバランシングを容易にします。
It may be desirable to have individual NVA addresses responsible for a subset of information about an NV Domain. In such a case, NVEs would use different NVA addresses for obtaining or updating information about particular VNs or TS bindings. Key questions with such an approach are how information would be partitioned and how an NVE could determine which address to use to get the information it needs.
NVドメインに関する情報のサブセットを担当する個々のNVAアドレスを持つことが望ましい場合があります。そのような場合、NVEは特定のVNまたはTSバインディングに関する情報を取得または更新するために異なるNVAアドレスを使用します。このようなアプローチの主な問題は、情報をどのように分割するか、およびNVEが必要な情報を取得するために使用するアドレスをどのように決定できるかです。
Another possibility is to treat the information on which NVA addresses to use as cached (soft-state) information at the NVEs, so that any NVA address can be used to obtain any information, but NVEs are informed of preferences for which addresses to use for particular information on VNs or TS bindings. That preference information would be cached for future use to improve behavior, e.g., if all requests for a specific subset of VNs are forwarded to a specific NVA component, the NVE can optimize future requests within that subset by sending them directly to that NVA component via its address.
別の可能性は、どのNVAアドレスを使用する情報をNVEでキャッシュされた（ソフトステート）情報として扱うかです。これにより、任意のNVAアドレスを使用して任意の情報を取得できますが、NVEには使用するアドレスの設定が通知されます。 VNまたはTSバインディングに関する特定の情報。その設定情報は、動作を改善するために将来使用するためにキャッシュされます。たとえば、VNの特定のサブセットに対するすべてのリクエストが特定のNVAコンポーネントに転送される場合、NVEは、それらを経由してNVAコンポーネントに直接送信することにより、そのサブセット内の将来のリクエストを最適化できます。そのアドレス。
As outlined in Section 4.3, an NVE needs certain information in order to perform its functions. To obtain such information from an NVA, an NVE-NVA protocol is needed. The NVE-NVA protocol provides two functions. First, it allows an NVE to obtain information about the location and status of other TSs with which it needs to communicate. Second, the NVE-NVA protocol provides a way for NVEs to provide updates to the NVA about the TSs attached to that NVE (e.g., when a TS attaches or detaches from the NVE) or about communication errors encountered when sending traffic to remote NVEs. For example, an NVE could indicate that a destination it is trying to reach at a destination NVE is unreachable for some reason.
セクション4.3で概説されているように、NVEはその機能を実行するために特定の情報を必要とします。このような情報をNVAから取得するには、NVE-NVAプロトコルが必要です。 NVE-NVAプロトコルは2つの機能を提供します。まず、NVEが通信する必要のある他のTSの場所とステータスに関する情報を取得できるようにします。次に、NVE-NVAプロトコルは、NVEがそのNVEに接続されたTS（たとえば、TSがNVEに接続または切断したとき）について、またはリモートNVEにトラフィックを送信するときに発生した通信エラーについて、NVAに更新を提供する方法を提供します。たとえば、NVEは、何らかの理由で、宛先NVEで到達しようとしている宛先に到達できないことを示している可能性があります。
While having a direct NVE-NVA protocol might seem straightforward, the existence of existing VM orchestration systems complicates the choices an NVE has for interacting with the NVA.
直接のNVE-NVAプロトコルを使用することは簡単に思えるかもしれませんが、既存のVMオーケストレーションシステムの存在は、NVEと対話するためのNVEの選択を複雑にします。
An NVE interacts with an NVA in at least two (quite different) ways:
NVEは、少なくとも2つの（まったく異なる）方法でNVAと対話します。
o NVEs embedded within the same server as the hypervisor can obtain necessary information entirely through the hypervisor-facing side of the NVE. Such an approach is a natural extension to existing VM orchestration systems supporting server virtualization because an existing protocol between the hypervisor and VM orchestration system already exists and can be leveraged to obtain any needed information. Specifically, VM orchestration systems used to create, terminate, and migrate VMs already use well-defined (though typically proprietary) protocols to handle the interactions between the hypervisor and VM orchestration system. For such systems, it is a natural extension to leverage the existing orchestration protocol as a sort of proxy protocol for handling the interactions between an NVE and the NVA. Indeed, existing implementations can already do this.
o ハイパーバイザーと同じサーバーに組み込まれたNVEは、NVEのハイパーバイザーに面する側から完全に必要な情報を取得できます。ハイパーバイザーとVMオーケストレーションシステムの間に既存のプロトコルがすでに存在し、これを利用して必要な情報を取得できるため、このようなアプローチはサーバー仮想化をサポートする既存のVMオーケストレーションシステムへの自然な拡張です。具体的には、VMの作成、終了、移行に使用されるVMオーケストレーションシステムは、ハイパーバイザーとVMオーケストレーションシステム間の相互作用を処理するために、明確に定義された（通常は独自仕様です）プロトコルをすでに使用しています。そのようなシステムの場合、NVEとNVA間の相互作用を処理するためのプロキシプロトコルの一種として既存のオーケストレーションプロトコルを活用することは自然な拡張です。実際、既存の実装はこれをすでに実行できます。
o Alternatively, an NVE can obtain needed information by interacting directly with an NVA via a protocol operating over the data-center underlay network. Such an approach is needed to support NVEs that are not associated with systems performing server virtualization (e.g., as in the case of a standalone gateway) or where the NVE needs to communicate directly with the NVA for other reasons.
o または、NVEは、データセンターアンダーレイネットワーク上で動作するプロトコルを介してNVAと直接対話することにより、必要な情報を取得できます。このようなアプローチは、サーバーの仮想化を実行するシステム（スタンドアロンゲートウェイの場合など）に関連付けられていない、またはNVEが他の理由でNVAと直接通信する必要があるNVEをサポートするために必要です。
The NVO3 architecture will focus on support for the second model above. Existing virtualization environments are already using the first model, but they are not sufficient to cover the case of standalone gateways -- such gateways may not support virtualization and do not interface with existing VM orchestration systems.
NVO3アーキテクチャは、上記の2番目のモデルのサポートに焦点を当てます。既存の仮想化環境はすでに最初のモデルを使用していますが、スタンドアロンゲートウェイのケースをカバーするには十分ではありません。このようなゲートウェイは仮想化をサポートしておらず、既存のVMオーケストレーションシステムとインターフェイスしない場合があります。
An NVE can interact directly with an NVA via an NVE-NVA protocol. Such a protocol can be either independent of the NVA internal protocol or an extension of it. Using a purpose-specific protocol would provide architectural separation and independence between the NVE and NVA. The NVE and NVA interact in a well-defined way, and changes in the NVA (or NVE) do not need to impact each other. Using a dedicated protocol also ensures that both NVE and NVA implementations can evolve independently and without dependencies on each other. Such independence is important because the upgrade path for NVEs and NVAs is quite different. Upgrading all the NVEs at a site will likely be more difficult in practice than upgrading NVAs because of their large number -- one on each end device. In practice, it would be prudent to assume that once an NVE has been implemented and deployed, it may be challenging to get subsequent NVE extensions and changes implemented and deployed, whereas an NVA (and its associated internal protocols) is more likely to evolve over time as experience is gained from usage and upgrades will involve fewer nodes.
NVEは、NVE-NVAプロトコルを介してNVAと直接対話できます。このようなプロトコルは、NVAの内部プロトコルから独立していても、その拡張であってもかまいません。目的固有のプロトコルを使用すると、NVEとNVAの間にアーキテクチャの分離と独立性が提供されます。 NVEとNVAは明確に定義された方法で相互作用し、NVA（またはNVE）の変更は互いに影響を与える必要はありません。専用プロトコルを使用すると、NVEとNVAの両方の実装が独立して、相互に依存することなく進化できるようになります。 NVEとNVAのアップグレードパスはまったく異なるため、このような独立性は重要です。サイトですべてのNVEをアップグレードすることは、NVAのアップグレードよりも実際には困難です。これは、NVAの数が多いためです（各エンドデバイスに1つ）。実際には、NVEが実装および展開された後、NVA拡張機能および変更を実装および展開することは難しいかもしれませんが、NVA（および関連する内部プロトコル）はより進化する可能性が高いと想定するのが賢明です。使用とアップグレードから経験が得られるので、時間がかかるノードは少なくなります。
Requirements for a direct NVE-NVA protocol can be found in [NVE-NVA].
直接NVE-NVAプロトコルの要件は、[NVE-NVA]にあります。
Information flows between NVEs and NVAs in both directions. The NVA maintains information about all VNs in the NV Domain so that NVEs do not need to do so themselves. NVEs obtain information from the NVA about where a given remote TS destination resides. NVAs, in turn, obtain information from NVEs about the individual TSs attached to those NVEs.
情報はNVEとNVAの間で双方向に流れます。 NVAは、NVドメイン内のすべてのVNに関する情報を維持するため、NVEがそれを行う必要はありません。 NVEは、特定のリモートTS宛先がどこにあるかについての情報をNVAから取得します。次に、NVAはNVEから、それらのNVEに接続されている個々のTSに関する情報を取得します。
While the NVA could push information relevant to every virtual network to every NVE, such an approach scales poorly and is unnecessary. In practice, a given NVE will only need and want to know about VNs to which it is attached. Thus, an NVE should be able to subscribe to updates only for the virtual networks it is interested in receiving updates for. The NVO3 architecture supports a model where an NVE is not required to have full mapping tables for all virtual networks in an NV Domain.
NVAはすべての仮想ネットワークに関連する情報をすべてのNVEにプッシュできますが、このようなアプローチは拡張性が低く、不要です。実際には、特定のNVEは、それが接続されているVNについてのみ必要であり、知りたいと思っています。したがって、NVEは、更新の受信に関心のある仮想ネットワークに対してのみ、更新をサブスクライブできる必要があります。 NVO3アーキテクチャは、NVEがNVドメイン内のすべての仮想ネットワークの完全なマッピングテーブルを持つ必要がないモデルをサポートします。
Before sending unicast traffic to a remote TS (or TSs for broadcast or multicast traffic), an NVE must know where the remote TS(s) currently reside. When a TS attaches to a virtual network, the NVE obtains information about that VN from the NVA. The NVA can provide that information to the NVE at the time the TS attaches to the VN, either because the NVE requests the information when the attach operation occurs or because the VM orchestration system has initiated the attach operation and provides associated mapping information to the NVE at the same time.
ユニキャストトラフィックをリモートTS（またはブロードキャストまたはマルチキャストトラフィックのTS）に送信する前に、NVEはリモートTSが現在どこにあるかを知っている必要があります。 TSが仮想ネットワークに接続すると、NVEはそのVNに関する情報をNVAから取得します。 NVAは、TSがVNにアタッチするときにその情報をNVEに提供できます。これは、アタッチ操作の発生時にNVEが情報を要求するか、VMオーケストレーションシステムがアタッチ操作を開始し、関連するマッピング情報をNVEに提供するためです。同時に。
There are scenarios where an NVE may wish to query the NVA about individual mappings within a VN. For example, when sending traffic to a remote TS on a remote NVE, that TS may become unavailable (e.g., because it has migrated elsewhere or has been shut down, in which case the remote NVE may return an error indication). In such situations, the NVE may need to query the NVA to obtain updated mapping information for a specific TS or to verify that the information is still correct despite the error condition. Note that such a query could also be used by the NVA as an indication that there may be an inconsistency in the network and that it should take steps to verify that the information it has about the current state and location of a specific TS is still correct.
NVEがVN内の個々のマッピングについてNVAに照会することを望むシナリオがあります。たとえば、リモートNVE上のリモートTSにトラフィックを送信すると、そのTSが使用できなくなる可能性があります（たとえば、他の場所に移行したかシャットダウンされたため、リモートNVEがエラーを返す場合があります）。このような状況では、NVEはNVAにクエリを実行して、特定のTSの更新されたマッピング情報を取得したり、エラー状態にもかかわらず情報が正しいことを確認したりする必要があります。このようなクエリは、ネットワークに不整合がある可能性があり、特定のTSの現在の状態と場所に関する情報がまだ正しいことを確認するための手順を実行する必要があることを示すために、NVAで使用することもできます。 。
For very large virtual networks, the amount of state an NVE needs to maintain for a given virtual network could be significant. Moreover, an NVE may only be communicating with a small subset of the TSs on such a virtual network. In such cases, the NVE may find it desirable to maintain state only for those destinations it is actively communicating with. In such scenarios, an NVE may not want to maintain full mapping information about all destinations on a VN. However, if it needs to communicate with a destination for which it does not have mapping information, it will need to be able to query the NVA on demand for the missing information on a per-destination basis.
非常に大規模な仮想ネットワークの場合、特定の仮想ネットワークに対してNVEが維持する必要のある状態の量は重要になる可能性があります。さらに、NVEは、そのような仮想ネットワーク上のTSの小さなサブセットとのみ通信している場合があります。このような場合、NVEは、アクティブに通信している宛先のみの状態を維持することが望ましいと判断する場合があります。このようなシナリオでは、NVEはVN上のすべての宛先に関する完全なマッピング情報を維持したくない場合があります。ただし、マッピング情報を持たない宛先と通信する必要がある場合は、宛先ごとに欠落している情報をオンデマンドでNVAに照会できる必要があります。
The NVO3 architecture will need to support a range of operations between the NVE and NVA. Requirements for those operations can be found in [NVE-NVA].
NVO3アーキテクチャは、NVEとNVA間のさまざまな操作をサポートする必要があります。これらの操作の要件は、[NVE-NVA]にあります。
An NVA provides service to the set of NVEs in its NV Domain. Each NVA manages network virtualization information for the virtual networks within its NV Domain. An NV Domain is administered by a single entity.
NVAは、そのNVドメイン内の一連のNVEにサービスを提供します。各NVAは、NVドメイン内の仮想ネットワークのネットワーク仮想化情報を管理します。 NVドメインは単一のエンティティによって管理されます。
In some cases, it will be necessary to expand the scope of a specific VN or even an entire NV Domain beyond a single NVA. For example, an administrator managing multiple data centers may wish to operate all of its data centers as a single NV Region. Such cases are handled by having different NVAs peer with each other to exchange mapping information about specific VNs. NVAs operate in a federated manner with a set of NVAs operating as a loosely coupled federation of individual NVAs. If a virtual network spans multiple NVAs (e.g., located at different data centers), and an NVE needs to deliver tenant traffic to an NVE that is part of a different NV Domain, it still interacts only with its NVA, even when obtaining mappings for NVEs associated with a different NV Domain.
場合によっては、特定のVNまたはNVドメイン全体の範囲を単一のNVAを超えて拡張する必要があります。たとえば、複数のデータセンターを管理している管理者は、すべてのデータセンターを単一のNVリージョンとして運用したい場合があります。このようなケースは、特定のVNに関するマッピング情報を交換するために異なるピアを相互にピアさせることによって処理されます。 NVAは、個別のNVAの疎結合の連携として動作する一連のNVAと連携して動作します。仮想ネットワークが複数のNVA（たとえば、異なるデータセンターに配置されている）にまたがり、NVEがテナントトラフィックを異なるNVドメインの一部であるNVEに配信する必要がある場合、NVAとのマッピングを取得する場合でも、NVAとのみ対話します別のNVドメインに関連付けられたNVE。
Figure 3 shows a scenario where two separate NV Domains (A and B) share information about a VN. VM1 and VM2 both connect to the same VN, even though the two VMs are in separate NV Domains. There are two cases to consider. In the first case, NV Domain B does not allow NVE-A to tunnel traffic directly to NVE-B. There could be a number of reasons for this. For example, NV Domains A and B may not share a common address space (i.e., traversal through a NAT device is required), or for policy reasons, a domain might require that all traffic between separate NV Domains be funneled through a particular device (e.g., a firewall). In such cases, NVA-2 will advertise to NVA-1 that VM1 on the VN is available and direct that traffic between the two nodes be forwarded via IP-G (an IP Gateway). IP-G would then decapsulate received traffic from one NV Domain, translate it appropriately for the other domain, and re-encapsulate the packet for delivery.
図3は、2つの個別のNVドメイン（AおよびB）がVNに関する情報を共有するシナリオを示しています。 VM1とVM2は両方とも同じVNに接続しますが、2つのVMは別々のNVドメインにあります。考慮すべき2つのケースがあります。最初のケースでは、NVドメインBは、NVE-AがトラフィックをNVE-Bに直接トンネルすることを許可しません。これにはいくつかの理由が考えられます。たとえば、NVドメインAとBは、共通のアドレススペースを共有しない場合があります（つまり、NATデバイスを介したトラバーサルが必要です）。または、ポリシー上の理由で、ドメインは、個別のNVドメイン間のすべてのトラフィックが特定のデバイス（例：ファイアウォール）。このような場合、NVA-2は、VN上のVM1が利用可能であることをNVA-1に通知し、2つのノード間のトラフィックがIP-G（IPゲートウェイ）を介して転送されるように指示します。次に、IP-Gは1つのNVドメインから受信したトラフィックのカプセル化を解除し、それを他のドメインに適切に変換し、配信用にパケットを再カプセル化します。
xxxxxx xxxx +-----+
+-----+ xxxxxx xxxxxx xxxxxx xxxxx | VM2 |
| VM1 | xx xx xxx xx |-----|
|-----| xx x xx x |NVE-B|
|NVE-A| x x +----+ x x +-----+
+--+--+ x NV Domain A x |IP-G|--x x |
+-------x xx--+ | x xx |
x x +----+ x NV Domain B x |
+---x xx xx x---+
| xxxx xx +->xx xx
| xxxxxxxx | xx xx
+---+-+ | xx xx
|NVA-1| +--+--+ xx xxx
+-----+ |NVA-2| xxxx xxxx
+-----+ xxxxx
Figure 3: VM1 and VM2 in Different NV Domains
図3：異なるNVドメインのVM1とVM2
NVAs at one site share information and interact with NVAs at other sites, but only in a controlled manner. It is expected that policy and access control will be applied at the boundaries between different sites (and NVAs) so as to minimize dependencies on external NVAs that could negatively impact the operation within a site. It is an architectural principle that operations involving NVAs at one site not be immediately impacted by failures or errors at another site.
1つのサイトのNVAは情報を共有し、他のサイトのNVAと対話しますが、制御された方法でのみ行います。サイト内の運用に悪影響を与える可能性のある外部のNVAへの依存性を最小限に抑えるために、ポリシーとアクセス制御は異なるサイト（およびNVA）間の境界に適用されることが予想されます。あるサイトでのNVAに関連する操作が、別のサイトでの障害やエラーの影響をすぐに受けないことは、アーキテクチャ上の原則です。
(Of course, communication between NVEs in different NV Domains may be impacted by such failures or errors.) It is a strong requirement that an NVA continue to operate properly for local NVEs even if external communication is interrupted (e.g., should communication between a local and remote NVA fail).
（もちろん、異なるNVドメイン内のNVE間の通信は、このような障害またはエラーの影響を受ける可能性があります。）外部通信が中断された場合でも、NVAがローカルNVEに対して適切に動作し続けることが強い要件です（たとえば、ローカル間の通信が必要な場合）およびリモートNVAは失敗します）。
At a high level, a federation of interconnected NVAs has some analogies to BGP and Autonomous Systems. Like an Autonomous System, NVAs at one site are managed by a single administrative entity and do not interact with external NVAs except as allowed by policy. Likewise, the interface between NVAs at different sites is well defined so that the internal details of operations at one site are largely hidden to other sites. Finally, an NVA only peers with other NVAs that it has a trusted relationship with, i.e., where a VN is intended to span multiple NVAs.
高レベルでは、相互接続されたNVAのフェデレーションは、BGPと自律システムに類似しています。自律システムと同様に、1つのサイトのNVAは単一の管理エンティティによって管理され、ポリシーで許可されている場合を除き、外部のNVAと対話しません。同様に、異なるサイトのNVA間のインターフェースは明確に定義されているため、1つのサイトでの操作の内部の詳細は、他のサイトにはほとんど隠されています。最後に、NVAは、信頼できる関係にある他のNVAとのみピアリングします。つまり、VNは複数のNVAにまたがることを目的としています。
Reasons for using a federated model include:
連合モデルを使用する理由は次のとおりです。
o Provide isolation among NVAs operating at different sites at different geographic locations.
o 地理的に異なる場所にある異なるサイトで動作しているNVAを分離します。
o Control the quantity and rate of information updates that flow (and must be processed) between different NVAs in different data centers.
o 異なるデータセンター内の異なるNVA間を流れる（処理する必要がある）情報更新の量と速度を制御します。
o Control the set of external NVAs (and external sites) a site peers with. A site will only peer with other sites that are cooperating in providing an overlay service.
o サイトがピアリングする外部NVA（および外部サイト）のセットを制御します。サイトは、オーバーレイサービスの提供に協力している他のサイトとのみピアリングします。
o Allow policy to be applied between sites. A site will want to carefully control what information it exports (and to whom) as well as what information it is willing to import (and from whom).
o サイト間でのポリシーの適用を許可します。サイトは、どの情報を（誰に）エクスポートするか、どの情報を誰から誰にインポートするかを慎重に制御する必要があります。
o Allow different protocols and architectures to be used for intra-NVA vs. inter-NVA communication. For example, within a single data center, a replicated transaction server using database techniques might be an attractive implementation option for an NVA, and protocols optimized for intra-NVA communication would likely be different from protocols involving inter-NVA communication between different sites.
o NVA内通信とNVA間通信で異なるプロトコルとアーキテクチャを使用できるようにします。たとえば、単一のデータセンター内では、データベース技術を使用した複製トランザクションサーバーはNVAの魅力的な実装オプションであり、NVA内通信用に最適化されたプロトコルは、異なるサイト間のNVA間通信を含むプロトコルとは異なる場合があります。
o Allow for optimized protocols rather than using a one-size-fits-all approach. Within a data center, networks tend to have lower latency, higher speed, and higher redundancy when compared with WAN links interconnecting data centers. The design constraints and trade-offs for a protocol operating within a data-center network are different from those operating over WAN links. While a single protocol could be used for both cases, there could be advantages to using different and more specialized protocols for the intra- and inter-NVA case.
o万能のアプローチを使用するのではなく、プロトコルを最適化できるようにします。データセンター内では、ネットワークは、データセンターを相互接続するWANリンクと比較して、待ち時間が短く、速度が高く、冗長性が高い傾向があります。データセンターネットワーク内で動作するプロトコルの設計上の制約とトレードオフは、WANリンク上で動作するものとは異なります。両方の場合に単一のプロトコルを使用できますが、NVA内およびNVAの場合に異なる、より専門的なプロトコルを使用することには利点があります。
To support peering between different NVAs, an inter-NVA protocol is needed. The inter-NVA protocol defines what information is exchanged between NVAs. It is assumed that the protocol will be used to share addressing information between data centers and must scale well over WAN links.
異なるNVA間のピアリングをサポートするには、NVA間プロトコルが必要です。 NVA間プロトコルは、NVA間で交換される情報を定義します。このプロトコルは、データセンター間でアドレス情報を共有するために使用され、WANリンク上で適切に拡張する必要があると想定されています。
The NVO3 architecture consists of two major distinct entities: NVEs and NVAs. In order to provide isolation and independence between these two entities, the NVO3 architecture calls for well-defined protocols for interfacing between them. For an individual NVA, the architecture calls for a logically centralized entity that could be implemented in a distributed or replicated fashion. While the IETF may choose to define one or more specific architectural approaches to building individual NVAs, there is little need to pick exactly one approach to the exclusion of others. An NVA for a single domain will likely be deployed as a single vendor product; thus, there is little benefit in standardizing the internal structure of an NVA.
NVO3アーキテクチャは、NVEとNVAの2つの主要なエンティティで構成されています。これらの2つのエンティティ間の分離と独立性を提供するために、NVO3アーキテクチャは、それらの間のインターフェイスのための明確に定義されたプロトコルを必要とします。個々のNVAの場合、このアーキテクチャでは、分散または複製された方法で実装できる論理的に集中化されたエンティティが必要です。 IETFは、個々のNVAを構築するための1つ以上の特定のアーキテクチャアプローチを定義することを選択する場合がありますが、他のものを除外するために1つのアプローチだけを選択する必要はほとんどありません。単一ドメインのNVAは、単一ベンダー製品として展開される可能性があります。したがって、NVAの内部構造を標準化してもほとんどメリットはありません。
Individual NVAs peer with each other in a federated manner. The NVO3 architecture calls for a well-defined interface between NVAs.
個々のNVAは、連合方式で相互にピアリングします。 NVO3アーキテクチャでは、NVA間の明確に定義されたインターフェイスが必要です。
Finally, a hypervisor-NVE protocol is needed to cover the split-NVE scenario described in Section 4.2.
最後に、セクション4.2で説明されているスプリットNVEシナリオをカバーするために、ハイパーバイザーNVEプロトコルが必要です。
When tunneling tenant traffic, NVEs add an encapsulation header to the original tenant packet. The exact encapsulation to use for NVO3 does not seem to be critical. The main requirement is that the encapsulation support a Context ID of sufficient size. A number of encapsulations already exist that provide a VN Context of sufficient size for NVO3. For example, Virtual eXtensible Local Area Network (VXLAN) [RFC7348] has a 24-bit VXLAN Network Identifier (VNI). Network Virtualization using Generic Routing Encapsulation (NVGRE) [RFC7637] has a 24-bit Tenant Network ID (TNI). MPLS-over-GRE provides a 20-bit label field. While there is widespread recognition that a 12-bit VN Context would be too small (only 4096 distinct values), it is generally agreed that 20 bits (1 million distinct values) and 24 bits (16.8 million distinct values) are sufficient for a wide variety of deployment scenarios.
テナントトラフィックをトンネリングするとき、NVEは元のテナントパケットにカプセル化ヘッダーを追加します。 NVO3に使用する正確なカプセル化は重要ではないようです。主な要件は、カプセル化が十分なサイズのコンテキストIDをサポートすることです。 NVO3に十分なサイズのVNコンテキストを提供する多くのカプセル化がすでに存在しています。たとえば、Virtual eXtensible Local Area Network（VXLAN）[RFC7348]には24ビットのVXLANネットワーク識別子（VNI）があります。 Generic Routing Encapsulation（NVGRE）[RFC7637]を使用したネットワーク仮想化には、24ビットのテナントネットワークID（TNI）があります。 MPLS-over-GREは、20ビットのラベルフィールドを提供します。 12ビットのVNコンテキストは小さすぎる（4096の異なる値のみ）と広く認識されていますが、一般に、20ビット（100万の異なる値）と24ビット（1680万の異なる値）で十分であることが広く合意されています。さまざまな展開シナリオ。
The simplicity of operating and debugging overlay networks will be critical for successful deployment.
オーバーレイネットワークの操作とデバッグのシンプルさは、展開を成功させるために重要です。
Overlay networks are based on tunnels between NVEs, so the Operations, Administration, and Maintenance (OAM) [RFC6291] framework for overlay networks can draw from prior IETF OAM work for tunnel-based networks, specifically L2VPN OAM [RFC6136]. RFC 6136 focuses on Fault Management and Performance Management as fundamental to L2VPN service delivery, leaving the Configuration Management, Accounting Management, and Security Management components of the Open Systems Interconnection (OSI) Fault, Configuration, Accounting, Performance, and Security (FCAPS) taxonomy [M.3400] for further study. This section does likewise for NVO3 OAM, but those three areas continue to be important parts of complete OAM functionality for NVO3.
オーバーレイネットワークはNVE間のトンネルに基づいているため、オーバーレイネットワークの運用、管理、保守（OAM）[RFC6291]フレームワークは、トンネルベースのネットワーク、特にL2VPN OAM [RFC6136]の以前のIETF OAM作業から引き出すことができます。 RFC 6136は、L2VPNサービス配信の基本として障害管理とパフォーマンス管理に焦点を当て、オープンシステム相互接続（OSI）障害、構成、アカウンティング、パフォーマンス、セキュリティ（FCAPS）分類の構成管理、アカウンティング管理、およびセキュリティ管理コンポーネントを残しています。 [M.3400]さらなる研究のため。このセクションはNVO3 OAMについても同様ですが、これらの3つの領域は、NVO3の完全なOAM機能の重要な部分であり続けます。
The relationship between the overlay and underlay networks is a consideration for fault and performance management -- a fault in the underlay may manifest as fault and/or performance issues in the overlay. Diagnosing and fixing such issues are complicated by NVO3 abstracting the underlay network away from the overlay network (e.g., intermediate nodes on the underlay network path between NVEs are hidden from overlay VNs).
オーバーレイネットワークとアンダーレイネットワークの関係は、障害とパフォーマンスの管理に関する考慮事項です。アンダーレイの障害は、オーバーレイの障害やパフォーマンスの問題として現れる可能性があります。このような問題の診断と修正は、NVO3がオーバーレイネットワークからアンダーレイネットワークを抽象化することで複雑になります（たとえば、NVE間のアンダーレイネットワークパス上の中間ノードはオーバーレイVNから隠されています）。
NVO3-specific OAM techniques, protocol constructs, and tools are needed to provide visibility beyond this abstraction to diagnose and correct problems that appear in the overlay. Two examples are underlay-aware traceroute [TRACEROUTE-VXLAN] and ping protocol constructs for overlay networks [VXLAN-FAILURE] [NVO3-OVERLAY].
NVO3固有のOAM技術、プロトコルコンストラクト、およびツールは、この抽象化を超えた可視性を提供して、オーバーレイに表示される問題を診断および修正するために必要です。 2つの例は、アンダーレイ対応のtraceroute [TRACEROUTE-VXLAN]とオーバーレイネットワークのpingプロトコルコンストラクト[VXLAN-FAILURE] [NVO3-OVERLAY]です。
NVO3-specific tools and techniques are best viewed as complements to (i.e., not as replacements for) single-network tools that apply to the overlay and/or underlay networks. Coordination among the individual network tools (for the overlay and underlay networks) and NVO3-aware, dual-network tools is required to achieve effective monitoring and fault diagnosis. For example, the defect detection intervals and performance measurement intervals ought to be coordinated among all tools involved in order to provide consistency and comparability of results.
NVO3固有のツールと手法は、オーバーレイネットワークまたはアンダーレイネットワーク、あるいはその両方に適用される単一ネットワークツールを補完するもの（つまり、その代わりではない）と見なすのが最適です。個々のネットワークツール（オーバーレイおよびアンダーレイネットワーク用）とNVO3対応のデュアルネットワークツール間の調整は、効果的な監視と障害診断を実現するために必要です。たとえば、欠陥検出間隔とパフォーマンス測定間隔は、結果の一貫性と比較可能性を提供するために、関係するすべてのツール間で調整する必要があります。
For further discussion of NVO3 OAM requirements, see [NVO3-OAM].
NVO3 OAM要件の詳細については、[NVO3-OAM]を参照してください。
This document presents the overall architecture for NVO3. The architecture calls for three main areas of protocol work:
このドキュメントでは、NVO3の全体的なアーキテクチャについて説明します。アーキテクチャでは、プロトコル作業の3つの主要な領域が必要です。
1. A hypervisor-NVE protocol to support split-NVEs as discussed in Section 4.2
1. セクション4.2で説明した分割NVEをサポートするハイパーバイザーNVEプロトコル
2. An NVE-NVA protocol for disseminating VN information (e.g., inner to outer address mappings)
2. VN情報を広めるためのNVE-NVAプロトコル（例：内部から外部へのアドレスマッピング）
3. An NVA-NVA protocol for exchange of information about specific virtual networks between federated NVAs
3. 連合NVA間で特定の仮想ネットワークに関する情報を交換するためのNVA-NVAプロトコル
It should be noted that existing protocols or extensions of existing protocols are applicable.
既存のプロトコルまたは既存のプロトコルの拡張が適用可能であることに注意する必要があります。
The data plane and control plane described in this architecture will need to address potential security threats.
このアーキテクチャで説明されているデータプレーンとコントロールプレーンは、潜在的なセキュリティの脅威に対処する必要があります。
For the data plane, tunneled application traffic may need protection against being misdelivered, being modified, or having its content exposed to an inappropriate third party. In all cases, encryption between authenticated tunnel endpoints (e.g., via use of IPsec [RFC4301]) and enforcing policies that control which endpoints and VNs are permitted to exchange traffic can be used to mitigate risks.
データプレーンの場合、トンネリングされたアプリケーショントラフィックは、誤配信、変更、またはコンテンツが不適切なサードパーティに公開されるのを防ぐ必要がある場合があります。すべての場合において、認証されたトンネルエンドポイント間の暗号化（IPsec [RFC4301]の使用など）と、トラフィックの交換を許可するエンドポイントとVNを制御するポリシーを適用することで、リスクを軽減できます。
For the control plane, a combination of authentication and encryption can be used between NVAs, between the NVA and NVE, as well as between different components of the split-NVE approach. All entities will need to properly authenticate with each other and enable encryption for their interactions as appropriate to protect sensitive information.
コントロールプレーンの場合、NVA間、NVAとNVE間、および分割NVEアプローチの異なるコンポーネント間で、認証と暗号化の組み合わせを使用できます。機密情報を保護するために、すべてのエンティティは相互に適切に認証し、必要に応じて相互作用の暗号化を有効にする必要があります。
Leakage of sensitive information about users or other entities associated with VMs whose traffic is virtualized can also be covered by using encryption for the control-plane protocols and enforcing policies that control which NVO3 components are permitted to exchange control-plane traffic.
トラフィックが仮想化されているVMに関連付けられているユーザーまたは他のエンティティに関する機密情報の漏洩は、コントロールプレーンプロトコルの暗号化を使用し、コントロールプレーントラフィックの交換を許可するNVO3コンポーネントを制御するポリシーを適用することによってもカバーできます。
Control-plane elements such as NVEs and NVAs need to collect performance and other data in order to carry out their functions. This data can sometimes be unexpectedly sensitive, for example, allowing non-obvious inferences of activity within a VM. This provides a reason to minimize the data collected in some environments in order to limit potential exposure of sensitive information. As noted briefly in RFC 6973 [RFC6973] and RFC 7258 [RFC7258], there is an inevitable tension between being privacy sensitive and taking into account network operations in NVO3 protocol development.
NVEやNVAなどのコントロールプレーン要素は、その機能を実行するためにパフォーマンスやその他のデータを収集する必要があります。このデータは、たとえばVM内のアクティビティの自明ではない推論を可能にするなど、予期せず機密となる場合があります。これは、機密情報の潜在的な公開を制限するために、一部の環境で収集されるデータを最小限にする理由を提供します。 RFC 6973 [RFC6973]およびRFC 7258 [RFC7258]で簡単に述べたように、プライバシーに配慮することと、NVO3プロトコル開発でのネットワーク操作を考慮することの間には避けられない緊張があります。
See the NVO3 framework security considerations in RFC 7365 [RFC7365] for further discussion.
詳細については、RFC 7365 [RFC7365]のNVO3フレームワークのセキュリティに関する考慮事項を参照してください。
[FRAMEWORK-MCAST] Ghanwani, A., Dunbar, L., McBride, M., Bannai, V., and R. Krishnan, "A Framework for Multicast in Network Virtualization Overlays", Work in Progress, draft-ietf-nvo3-mcast-framework-05, May 2016.
[FRAMEWORK-MCAST]ガンワニ、A。、ダンバー、L。、マクブライド、M。、バンナイ、V。、およびR.クリシュナン、「ネットワーク仮想化オーバーレイでのマルチキャストのフレームワーク」、Work in Progress、draft-ietf-nvo3 -mcast-framework-05、2016年5月。
[IEEE.802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6991460>.
[IEEE.802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks」、IEEE 802.1Q-2014、DOI 10.1109 / ieeestd.2014.6991462、<http://ieeexplore.ieee.org/servlet / opac？punumber = 6991460>。
[M.3400] ITU-T, "TMN management functions", ITU-T Recommendation M.3400, February 2000, <https://www.itu.int/rec/T-REC-M.3400-200002-I/>.
[M.3400] ITU-T、「TMN管理機能」、ITU-T勧告M.3400、2000年2月、<https://www.itu.int/rec/T-REC-M.3400-200002-I />。
[NVE-NVA] Kreeger, L., Dutt, D., Narten, T., and D. Black, "Network Virtualization NVE to NVA Control Protocol Requirements", Work in Progress, draft-ietf-nvo3-nve-nva-cp-req-05, March 2016.
[NVE-NVA]クリーガー、L。、ダット、D。、ナルテン、T。、およびD.ブラック、「ネットワーク仮想化NVEからNVA制御プロトコルの要件」、作業中、draft-ietf-nvo3-nve-nva- cp-req-05、2016年3月。
[NVO3-OAM] Chen, H., Ed., Ashwood-Smith, P., Xia, L., Iyengar, R., Tsou, T., Sajassi, A., Boucadair, M., Jacquenet, C., Daikoku, M., Ghanwani, A., and R. Krishnan, "NVO3 Operations, Administration, and Maintenance Requirements", Work in Progress, draft-ashwood-nvo3-oam-requirements-04, October 2015.
[NVO3-OAM] Chen、H.、Ed。、Ashwood-Smith、P.、Xia、L.、Iyengar、R.、Tsou、T.、Sajassi、A.、Boucadair、M.、Jacquenet、C。、 Daikoku、M.、Ghanwani、A.、and R. Krishnan、 "NVO3 Operations、Administration、and Maintenance Requirements"、Work in Progress、draft-ashwood-nvo3-oam-requirements-04、October 2015。
[NVO3-OVERLAY] Kumar, N., Pignataro, C., Rao, D., and S. Aldrin, "Detecting NVO3 Overlay Data Plane failures", Work in Progress, draft-kumar-nvo3-overlay-ping-01, January 2014.
[NVO3-OVERLAY] Kumar、N.、Pignataro、C.、Rao、D。、およびS. Aldrin、「Detecting NVO3 Overlay Data Plane failures」、Work in Progress、draft-kumar-nvo3-overlay-ping-01、 2014年1月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, DOI 10.17487/RFC6136, March 2011, <http://www.rfc-editor.org/info/rfc6136>.
[RFC6136] Sajassi、A.、Ed。およびD. Mohan、Ed。、「Layer 2 Virtual Private Network（L2VPN）Operations、Administration、and Maintenance（OAM）Requirements and Framework」、RFC 6136、DOI 10.17487 / RFC6136、2011年3月、<http：//www.rfc -editor.org/info/rfc6136>。
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <http://www.rfc-editor.org/info/rfc6291>.
[RFC6291] Andersson、L.、van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」の頭字語の使用に関するガイドライン」、BCP 161、RFC 6291 、DOI 10.17487 / RFC6291、2011年6月、<http://www.rfc-editor.org/info/rfc6291>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <http://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<http://www.rfc-editor.org/info/rfc7348>。
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, <http://www.rfc-editor.org/info/rfc7364>.
[RFC7364] Narten、T.、Ed。、Gray、E.、Ed。、Black、D.、Fang、L.、Kreeger、L。、およびM. Napierala、「Problem Statement：Overlays for Network Virtualization」、RFC 7364、DOI 10.17487 / RFC7364、2014年10月、<http://www.rfc-editor.org/info/rfc7364>。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc-editor.org/info/rfc7365>.
[RFC7365] Lasserre、M.、Balus、F.、Morin、T.、Bitar、N。、およびY. Rekhter、「Framework for Data Center（DC）Network Virtualization」、RFC 7365、DOI 10.17487 / RFC7365、2014年10月、<http://www.rfc-editor.org/info/rfc7365>。
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network Virtualization Using Generic Routing Encapsulation", RFC 7637, DOI 10.17487/RFC7637, September 2015, <http://www.rfc-editor.org/info/rfc7637>.
[RFC7637] Garg、P.、Ed。 Y. Wang、Ed。、「NVGRE：Network Virtualization Using Generic Routing Encapsulation」、RFC 7637、DOI 10.17487 / RFC7637、2015年9月、<http://www.rfc-editor.org/info/rfc7637>。
[TRACEROUTE-VXLAN] Nordmark, E., Appanna, C., Lo, A., Boutros, S., and A. Dubey, "Layer-Transcending Traceroute for Overlay Networks like VXLAN", Work in Progress, draft-nordmark-nvo3- transcending-traceroute-03, July 2016.
[TRACEROUTE-VXLAN] Nordmark、E.、Appanna、C.、Lo、A.、Boutros、S。、およびA. Dubey、「VXLANのようなオーバーレイネットワークのレイヤ超越トレースルート」、Work in Progress、draft-nordmark- nvo3- transcending-traceroute-03、2016年7月。
[USECASES] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, "Use Cases for Data Center Network Virtualization Overlay Networks", Work in Progress, draft-ietf-nvo3-use-case-15, December 2016.
[使用例] Yong、L.、Dunbar、L.、Toy、M.、Isaac、A。、およびV. Manral、「データセンターネットワーク仮想化オーバーレイネットワークの使用例」、作業中、draft-ietf-nvo3-ユースケース15、2016年12月。
[VXLAN-FAILURE] Jain, P., Singh, K., Balus, F., Henderickx, W., and V. Bannai, "Detecting VXLAN Segment Failure", Work in Progress, draft-jain-nvo3-vxlan-ping-00, June 2013.
[VXLAN-FAILURE] Jain、P.、Singh、K.、Balus、F.、Henderickx、W.、V。Bannai、「Detecting VXLAN Segment Failure」、作業中、draft-jain-nvo3-vxlan-ping -00、2013年6月。
Acknowledgements
謝辞
Helpful comments and improvements to this document have come from Alia Atlas, Abdussalam Baryun, Spencer Dawkins, Linda Dunbar, Stephen Farrell, Anton Ivanov, Lizhong Jin, Suresh Krishnan, Mirja Kuehlwind, Greg Mirsky, Carlos Pignataro, Dennis (Xiaohong) Qin, Erik Smith, Takeshi Takahashi, Ziye Yang, and Lucy Yong.
このドキュメントに対する有益なコメントと改善は、Alia Atlas、Abdussalam Baryun、Spencer Dawkins、Linda Dunbar、Stephen Farrell、Anton Ivanov、Lizhong Jin、Suresh Krishnan、Mirja Kuehlwind、Greg Mirsky、Carlos Pignataro、Dennis（Xiaohong）Qin、Erikから寄せられましたスミス、タカシタカシ、ジエヤン、ルーシーヨン。
Authors' Addresses
著者のアドレス
David Black Dell EMC
デビッドブラックデルEMC
Email: david.black@dell.com
Jon Hudson Independent
ジョンハドソン独立
Email: jon.hudson@gmail.com
Lawrence Kreeger Independent
ローレンスクリーガー独立
Email: lkreeger@gmail.com
Marc Lasserre Independent
マークラッセール独立
Email: mmlasserre@gmail.com
Thomas Narten IBM
Thomas Narten IBM
Email: narten@us.ibm.com