[要約] RFC 7364は、ネットワーク仮想化のためのオーバーレイに関する問題を述べたものです。このRFCの目的は、オーバーレイネットワークの設計と展開に関連する問題を明確にし、ネットワーク仮想化の進化を促進することです。
Internet Engineering Task Force (IETF) T. Narten, Ed.
Request for Comments: 7364 IBM
Category: Informational E. Gray, Ed.
ISSN: 2070-1721 Ericsson
D. Black
EMC
L. Fang
Microsoft
L. Kreeger
Cisco
M. Napierala
AT&T
October 2014
Problem Statement: Overlays for Network Virtualization
問題の説明：ネットワーク仮想化のオーバーレイ
Abstract
概要
This document describes issues associated with providing multi-tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks. Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway). Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures.
このドキュメントでは、大規模なデータセンターネットワークでのマルチテナンシーの提供に関連する問題と、オーバーレイベースのネットワーク仮想化アプローチを使用してこれらの問題に対処する方法について説明します。マルチテナントの重要な要件は、1つのテナントのトラフィックが他のどのテナントからも見えないようにトラフィックを分離することです。別の要件は、異なるテナントが異なる仮想ネットワーク内で同じアドレス空間を使用できるようにするためのアドレス空間分離です。トラフィックとアドレス空間の分離は、1つ以上の仮想ネットワークを各テナントに割り当てることによって実現されます。仮想ネットワーク内のトラフィックは、制御された方法で（たとえば、構成されたルーターやセキュリティゲートウェイを介して）別の仮想ネットワークにしか渡れません。仮想ネットワークをプロビジョニングし、仮想マシンのネットワークインターフェースを適切な仮想ネットワークに関連付け、仮想マシンがアクティブ化、移行、非アクティブ化されるときにその関連付けを維持するには、追加の機能が必要です。オーバーレイベースのアプローチを使用すると、大規模なネットワークインフラストラクチャでのスケーラブルな展開が可能になります。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7364.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7364で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 .....................................................6
3. Problem Areas ...................................................6
3.1. Need for Dynamic Provisioning ..............................6
3.2. Virtual Machine Mobility Limitations .......................7
3.3. Inadequate Forwarding Table Sizes ..........................7
3.4. Need to Decouple Logical and Physical Configuration ........7
3.5. Need for Address Separation between Virtual Networks .......8
3.6. Need for Address Separation between Virtual Networks and ...8
3.7. Optimal Forwarding .........................................9
4. Using Network Overlays to Provide Virtual Networks .............10
4.1. Overview of Network Overlays ..............................10
4.2. Communication between Virtual and Non-virtualized
Networks ..................................................12
4.3. Communication between Virtual Networks ....................12
4.4. Overlay Design Characteristics ............................13
4.5. Control-Plane Overlay Networking Work Areas ...............14
4.6. Data-Plane Work Areas .....................................15
5. Related IETF and IEEE Work .....................................15
5.1. BGP/MPLS IP VPNs ..........................................16
5.2. BGP/MPLS Ethernet VPNs ....................................16
5.3. 802.1 VLANs ...............................................17
5.4. IEEE 802.1aq -- Shortest Path Bridging ....................17
5.5. VDP .......................................................17
5.6. ARMD ......................................................18
5.7. TRILL .....................................................18
5.8. L2VPNs ....................................................18
5.9. Proxy Mobile IP ...........................................19
5.10. LISP .....................................................19
6. Summary ........................................................19
7. Security Considerations ........................................19
8. References .....................................................20
8.1. Normative Reference .......................................20
8.2. Informative References ....................................20
Acknowledgments ...................................................22
Contributors ......................................................22
Authors' Addresses ................................................23
Data centers are increasingly being consolidated and outsourced in an effort to improve the deployment time of applications and reduce operational costs. This coincides with an increasing demand for compute, storage, and network resources from applications. In order to scale compute, storage, and network resources, physical resources are being abstracted from their logical representation, in what is referred to as server, storage, and network virtualization. Virtualization can be implemented in various layers of computer systems or networks.
アプリケーションの展開時間を改善し、運用コストを削減するために、データセンターはますます統合およびアウトソーシングされています。これは、アプリケーションからのコンピューティング、ストレージ、およびネットワークリソースに対する需要の増加と一致しています。コンピューティング、ストレージ、およびネットワークリソースをスケーリングするために、物理リソースは、サーバー、ストレージ、およびネットワーク仮想化と呼ばれるもので、それらの論理表現から抽象化されています。仮想化は、コンピューターシステムまたはネットワークのさまざまなレイヤーで実装できます。
The demand for server virtualization is increasing in data centers. With server virtualization, each physical server supports multiple virtual machines (VMs), each running its own operating system, middleware, and applications. Virtualization is a key enabler of workload agility, i.e., allowing any server to host any application and providing the flexibility of adding, shrinking, or moving services within the physical infrastructure. Server virtualization provides numerous benefits, including higher utilization, increased security, reduced user downtime, reduced power usage, etc.
サーバー仮想化の需要はデータセンターで高まっています。サーバー仮想化では、各物理サーバーが複数の仮想マシン（VM）をサポートし、それぞれが独自のオペレーティングシステム、ミドルウェア、およびアプリケーションを実行します。仮想化は、ワークロードの俊敏性を実現する重要な要素です。つまり、任意のサーバーが任意のアプリケーションをホストできるようにし、物理インフラストラクチャ内でサービスを追加、縮小、または移動する柔軟性を提供します。サーバーの仮想化には、使用率の向上、セキュリティの向上、ユーザーのダウンタイムの削減、電力使用量の削減など、多くのメリットがあります。
Multi-tenant data centers are taking advantage of the benefits of server virtualization to provide a new kind of hosting, a virtual hosted data center. Multi-tenant data centers are ones where individual tenants could belong to a different company (in the case of a public provider) or a different department (in the case of an internal company data center). Each tenant has the expectation of a level of security and privacy separating their resources from those of other tenants. For example, one tenant's traffic must never be exposed to another tenant, except through carefully controlled interfaces, such as a security gateway (e.g., a firewall).
マルチテナントデータセンターは、サーバー仮想化の利点を利用して、新しい種類のホスティングである仮想ホストデータセンターを提供しています。マルチテナントデータセンターとは、個々のテナントが別の会社（公共プロバイダーの場合）または別の部門（社内のデータセンターの場合）に属している可能性があるデータセンターです。各テナントは、リソースを他のテナントのリソースから分離するセキュリティとプライバシーのレベルを期待しています。たとえば、セキュリティゲートウェイ（ファイアウォールなど）などの慎重に制御されたインターフェースを介する場合を除いて、あるテナントのトラフィックが別のテナントに公開されてはなりません。
To a tenant, virtual data centers are similar to their physical counterparts, consisting of end stations attached to a network, complete with services such as load balancers and firewalls. But unlike a physical data center, Tenant Systems connect to a virtual network (VN). To Tenant Systems, a virtual network looks like a normal network (e.g., providing an Ethernet or L3 service), except that the only end stations connected to the virtual network are those belonging to a tenant's specific virtual network.
テナントにとって、仮想データセンターは、ネットワークに接続されたエンドステーションで構成される物理的な対応センターに似ており、ロードバランサーやファイアウォールなどのサービスを備えています。ただし、物理データセンターとは異なり、テナントシステムは仮想ネットワーク（VN）に接続します。テナントシステムにとって、仮想ネットワークは通常のネットワークのように見えます（イーサネットまたはL3サービスを提供するなど）。ただし、仮想ネットワークに接続されているエンドステーションは、テナントの特定の仮想ネットワークに属するものだけです。
A tenant is the administrative entity on whose behalf one or more specific virtual network instances and their associated services (whether virtual or physical) are managed. In a cloud environment, a tenant would correspond to the customer that is using a particular virtual network. However, a tenant may also find it useful to create multiple different virtual network instances. Hence, there is a one- to-many mapping between tenants and virtual network instances. A single tenant may operate multiple individual virtual network instances, each associated with a different service.
テナントは、1つ以上の特定の仮想ネットワークインスタンスとそれらに関連するサービス（仮想または物理）が管理される管理エンティティです。クラウド環境では、テナントは特定の仮想ネットワークを使用している顧客に対応します。ただし、テナントは、複数の異なる仮想ネットワークインスタンスを作成すると便利な場合もあります。したがって、テナントと仮想ネットワークインスタンスの間には1対多のマッピングがあります。単一のテナントが、それぞれが異なるサービスに関連付けられた複数の個別の仮想ネットワークインスタンスを運用できます。
How a virtual network is implemented does not generally matter to the tenant; what matters is that the service provided (Layer 2 (L2) or Layer 3 (L3)) has the right semantics, performance, etc. It could be implemented via a pure routed network, a pure bridged network, or a combination of bridged and routed networks. A key requirement is that each individual virtual network instance be isolated from other virtual network instances, with traffic crossing from one virtual network to another only when allowed by policy.
仮想ネットワークの実装方法は、通常、テナントにとって重要ではありません。重要なのは、提供されるサービス（レイヤー2（L2）またはレイヤー3（L3））が適切なセマンティクス、パフォーマンスなどを備えていることです。これは、純粋なルーティングネットワーク、純粋なブリッジネットワーク、またはブリッジとルーティングされたネットワーク。重要な要件は、個々の仮想ネットワークインスタンスを他の仮想ネットワークインスタンスから分離し、ポリシーで許可されている場合にのみトラフィックが1つの仮想ネットワークから別の仮想ネットワークに渡ることです。
For data center virtualization, two key issues must be addressed. First, address space separation between tenants must be supported. Second, it must be possible to place (and migrate) VMs anywhere in the data center, without restricting VM addressing to match the subnet boundaries of the underlying data center network.
データセンターの仮想化では、2つの重要な問題に対処する必要があります。まず、テナント間のアドレス空間の分離をサポートする必要があります。次に、基盤となるデータセンターネットワークのサブネット境界に一致するようにVMのアドレス指定を制限することなく、データセンターの任意の場所にVMを配置（および移行）できる必要があります。
This document outlines problems encountered in scaling the number of isolated virtual networks in a data center. Furthermore, the document presents issues associated with managing those virtual networks in relation to operations, such as virtual network creation/ deletion and end-node membership change. Finally, this document makes the case that an overlay-based approach has a number of advantages over traditional, non-overlay approaches. The purpose of this document is to identify the set of issues that any solution has to address in building multi-tenant data centers. With this approach, the goal is to allow the construction of standardized, interoperable implementations to allow the construction of multi-tenant data centers.
このドキュメントでは、データセンター内の分離された仮想ネットワークの数をスケーリングする際に発生する問題について概説します。さらに、このドキュメントでは、仮想ネットワークの作成/削除、エンドノードメンバーシップの変更など、操作に関連するこれらの仮想ネットワークの管理に関連する問題について説明しています。最後に、このドキュメントは、オーバーレイベースのアプローチが、従来の非オーバーレイアプローチよりも多くの利点を持つことを証明しています。このドキュメントの目的は、マルチテナントデータセンターの構築においてソリューションが対処しなければならない一連の問題を特定することです。このアプローチの目標は、標準化された相互運用可能な実装を構築して、マルチテナントデータセンターを構築できるようにすることです。
This document is the problem statement for the "Network Virtualization over Layer 3" (NVO3) Working Group. NVO3 is focused on the construction of overlay networks that operate over an IP (L3) underlay transport network. NVO3 expects to provide both L2 service and IP service to Tenant Systems (though perhaps as two different solutions). Some deployments require an L2 service, others an L3 service, and some may require both.
このドキュメントは、「レイヤー3を介したネットワーク仮想化」（NVO3）ワーキンググループの問題ステートメントです。 NVO3は、IP（L3）アンダーレイトランスポートネットワーク上で動作するオーバーレイネットワークの構築に重点を置いています。 NVO3は、L2サービスとIPサービスの両方をテナントシステムに提供することを期待しています（おそらく2つの異なるソリューションとして）。 L2サービスを必要とする展開もあれば、L3サービスを必要とする展開もあり、両方が必要な展開もあります。
Section 2 gives terminology. Section 3 describes the problem space details. Section 4 describes overlay networks in more detail. Section 5 reviews related and further work, and Section 6 closes with a summary.
セクション2では用語を説明します。セクション3では、問題のスペースの詳細について説明します。セクション4では、オーバーレイネットワークについて詳しく説明します。セクション5は関連する作業と今後の作業をレビューし、セクション6は要約で締めくくります。
This document uses the same terminology as [RFC7365]. In addition, this document use the following terms.
このドキュメントでは、[RFC7365]と同じ用語を使用しています。また、このドキュメントでは次の用語を使用しています。
Overlay Network: A virtual network in which the separation of tenants is hidden from the underlying physical infrastructure. That is, the underlying transport network does not need to know about tenancy separation to correctly forward traffic. IEEE 802.1 Provider Backbone Bridging (PBB) [IEEE-802.1Q] is an example of an L2 overlay network. PBB uses MAC-in-MAC encapsulation (where "MAC" refers to "Media Access Control"), and the underlying transport network forwards traffic using only the Backbone MAC (B-MAC) and Backbone VLAN Identifier (B-VID) in the outer header. The underlay transport network is unaware of the tenancy separation provided by, for example, a 24-bit Backbone Service Instance Identifier (I-SID).
オーバーレイネットワーク：テナントの分離が基盤となる物理インフラストラクチャから隠されている仮想ネットワーク。つまり、基盤となるトランスポートネットワークは、トラフィックを正しく転送するために、テナンシーの分離について知る必要はありません。 IEEE 802.1プロバイダーバックボーンブリッジング（PBB）[IEEE-802.1Q]は、L2オーバーレイネットワークの例です。 PBBはMAC-in-MACカプセル化を使用し（「MAC」は「メディアアクセス制御」を指します）、基になるトランスポートネットワークは、バックボーンMAC（B-MAC）とバックボーンVLAN識別子（B-VID）のみを使用してトラフィックを転送します外部ヘッダー。アンダーレイトランスポートネットワークは、たとえば24ビットのバックボーンサービスインスタンス識別子（I-SID）によって提供されるテナンシー分離を認識しません。
C-VLAN: This document refers to Customer VLANs (C-VLANs) as implemented by many routers, i.e., an L2 virtual network identified by a Customer VLAN Identifier (C-VID). An end station (e.g., a VM) in this context that is part of an L2 virtual network will effectively belong to a C-VLAN. Within an IEEE 802.1Q-2011 network, other tags may be used as well, but such usage is generally not visible to the end station. Section 5.3 provides more details on VLANs defined by [IEEE-802.1Q].
C-VLAN：このドキュメントは、多くのルーター、つまり、カスタマーVLAN識別子（C-VID）によって識別されるL2仮想ネットワークによって実装されるカスタマーVLAN（C-VLAN）に言及しています。 L2仮想ネットワークの一部であるこのコンテキストのエンドステーション（VMなど）は、実質的にC-VLANに属します。 IEEE 802.1Q-2011ネットワーク内では、他のタグも使用できますが、そのような使用法は通常、エンドステーションからは見えません。セクション5.3は、[IEEE-802.1Q]によって定義されたVLANの詳細を提供します。
This document uses the phrase "virtual network instance" with its ordinary meaning to represent an instance of a virtual network. Its usage may differ from the "VNI" acronym defined in the framework document [RFC7365]. The "VNI" acronym is not used in this document.
このドキュメントでは、「仮想ネットワークインスタンス」という語句を通常の意味で使用して、仮想ネットワークのインスタンスを表します。その使用法は、フレームワークドキュメント[RFC7365]で定義されている「VNI」の頭字語とは異なる場合があります。このドキュメントでは「VNI」という頭字語は使用されていません。
The following subsections describe aspects of multi-tenant data center networking that pose problems for network infrastructure. Different problem aspects may arise based on the network architecture and scale.
以下のサブセクションでは、ネットワークインフラストラクチャに問題を引き起こすマルチテナントデータセンターネットワーキングの側面について説明します。ネットワークのアーキテクチャと規模に基づいて、さまざまな問題が発生する可能性があります。
Some service providers offer services to multiple customers whereby services are dynamic and the resources assigned to support them must be able to change quickly as demand changes. In current systems, it can be difficult to provision resources for individual tenants (e.g., QoS) in such a way that provisioned properties migrate automatically when services are dynamically moved around within the data center to optimize workloads.
一部のサービスプロバイダーは複数の顧客にサービスを提供しており、サービスは動的であり、それらをサポートするために割り当てられたリソースは、需要の変化に応じて迅速に変更できる必要があります。現在のシステムでは、ワークロードを最適化するためにサービスがデータセンター内で動的に移動するときにプロビジョニングされたプロパティが自動的に移行するように、個々のテナントにリソース（QoSなど）をプロビジョニングすることが難しい場合があります。
A key benefit of server virtualization is virtual machine (VM) mobility. A VM can be migrated from one server to another live, i.e., while continuing to run and without needing to shut down and restart at the new location. A key requirement for live migration is that a VM retain critical network state at its new location, including its IP and MAC address(es). Preservation of MAC addresses may be necessary, for example, when software licenses are bound to MAC addresses. More generally, any change in the VM's MAC addresses resulting from a move would be visible to the VM and thus potentially result in unexpected disruptions. Retaining IP addresses after a move is necessary to prevent existing transport connections (e.g., TCP) from breaking and needing to be restarted.
サーバー仮想化の主な利点は、仮想マシン（VM）のモビリティです。 VMは、あるサーバーから別のサーバーにライブで移行できます。つまり、実行を継続しながら、新しい場所でシャットダウンして再起動する必要はありません。ライブマイグレーションの重要な要件は、VMがIPやMACアドレスなどの新しい場所で重要なネットワーク状態を保持することです。たとえば、ソフトウェアライセンスがMACアドレスにバインドされている場合、MACアドレスの保持が必要になることがあります。より一般的には、移動に起因するVMのMACアドレスの変更はVMから見えるため、予期しない中断が発生する可能性があります。移動後にIPアドレスを保持することは、既存のトランスポート接続（TCPなど）が壊れて再起動する必要がないようにするために必要です。
In data center networks, servers are typically assigned IP addresses based on their physical location, for example, based on the Top-of-Rack (ToR) switch for the server rack or the C-VLAN configured to the server. Servers can only move to other locations within the same IP subnet. This constraint is not problematic for physical servers, which move infrequently, but it restricts the placement and movement of VMs within the data center. Any solution for a scalable multi-tenant data center must allow a VM to be placed (or moved) anywhere within the data center without being constrained by the subnet boundary concerns of the host servers.
データセンターネットワークでは、サーバーには通常、物理的な場所に基づいて、たとえばサーバーラックのトップオブラック（ToR）スイッチまたはサーバーに構成されたC-VLANに基づいてIPアドレスが割り当てられます。サーバーは、同じIPサブネット内の他の場所にのみ移動できます。この制約は、頻繁に移動しない物理サーバーでは問題にはなりませんが、データセンター内でのVMの配置と移動を制限します。スケーラブルなマルチテナントデータセンターのソリューションでは、ホストサーバーのサブネット境界の問題に制約されることなく、データセンター内の任意の場所にVMを配置（または移動）できる必要があります。
Today's virtualized environments place additional demands on the forwarding tables of forwarding nodes in the physical infrastructure. The core problem is that location independence results in specific end state information being propagated into the forwarding system (e.g., /32 host routes in IPv4 networks or MAC addresses in IEEE 802.3 Ethernet networks). In L2 networks, for instance, instead of just one address per server, the network infrastructure may have to learn addresses of the individual VMs (which could range in the hundreds per server). This increases the demand on a forwarding node's table capacity compared to non-virtualized environments.
今日の仮想化環境では、物理インフラストラクチャの転送ノードの転送テーブルに追加の要求が出されます。中心的な問題は、場所に依存しないため、特定の最終状態情報が転送システムに伝達されることです（たとえば、IPv4ネットワークの/ 32ホストルートまたはIEEE 802.3イーサネットネットワークのMACアドレス）。たとえば、L2ネットワークでは、サーバーごとに1つのアドレスではなく、ネットワークインフラストラクチャが個々のVMのアドレスを学習する必要がある場合があります（サーバーごとに数百にも及ぶ可能性があります）。これにより、非仮想化環境と比較して、転送ノードのテーブル容量に対する需要が増加します。
Data center operators must be able to achieve high utilization of server and network capacity. For efficient and flexible allocation, operators should be able to spread a virtual network instance across servers in any rack in the data center. It should also be possible to migrate compute workloads to any server anywhere in the network while retaining the workload's addresses.
データセンターのオペレーターは、サーバーとネットワーク容量の高い利用率を達成できなければなりません。効率的で柔軟な割り当てのために、オペレーターは仮想ネットワークインスタンスをデータセンターの任意のラック内のサーバーに分散できる必要があります。また、ワークロードのアドレスを保持したまま、ネットワーク内の任意のサーバーにコンピューティングワークロードを移行することもできます。
In networks of many types (e.g., IP subnets, MPLS VPNs, VLANs, etc.), moving servers elsewhere in the network may require expanding the scope of a portion of the network (e.g., subnet, VPN, VLAN, etc.) beyond its original boundaries. While this can be done, it requires potentially complex network configuration changes and may, in some cases (e.g., a VLAN or L2VPN), conflict with the desire to bound the size of broadcast domains. In addition, when VMs migrate, the physical network (e.g., access lists) may need to be reconfigured, which can be time consuming and error prone.
多くのタイプのネットワーク（IPサブネット、MPLS VPN、VLANなど）で、ネットワーク内の別の場所にサーバーを移動するには、ネットワークの一部（サブネット、VPN、VLANなど）のスコープを拡張する必要がある場合があります。その元の境界。これは可能ですが、複雑なネットワーク構成の変更が必要になる可能性があり、場合によっては（VLANまたはL2VPNなど）、ブロードキャストドメインのサイズを制限したいという欲求と競合する可能性があります。さらに、VMの移行時に、物理ネットワーク（アクセスリストなど）の再構成が必要になる場合があり、時間がかかり、エラーが発生しやすくなります。
An important use case is cross-pod expansion. A pod typically consists of one or more racks of servers with associated network and storage connectivity. A tenant's virtual network may start off on a pod and, due to expansion, require servers/VMs on other pods, especially the case when other pods are not fully utilizing all their resources. This use case requires that virtual networks span multiple pods in order to provide connectivity to all of the tenants' servers/VMs. Such expansion can be difficult to achieve when tenant addressing is tied to the addressing used by the underlay network or when the expansion requires that the scope of the underlying C-VLAN expand beyond its original pod boundary.
重要なユースケースは、クロスポッド拡張です。ポッドは通常、関連するネットワークおよびストレージ接続を備えたサーバーの1つ以上のラックで構成されます。テナントの仮想ネットワークは、ポッドで開始する場合があり、拡張のため、他のポッドにサーバー/ VMが必要になります。他のポッドがすべてのリソースを完全に利用していない場合は特にそうです。この使用例では、テナントのすべてのサーバー/ VMへの接続を提供するために、仮想ネットワークが複数のポッドにまたがっている必要があります。このような拡張は、テナントのアドレス指定がアンダーレイネットワークで使用されるアドレス指定に関連付けられている場合、または基になるC-VLANのスコープが元のポッド境界を超えて拡張する必要がある場合は、実現が難しい場合があります。
Individual tenants need control over the addresses they use within a virtual network. But it can be problematic when different tenants want to use the same addresses or even if the same tenant wants to reuse the same addresses in different virtual networks. Consequently, virtual networks must allow tenants to use whatever addresses they want without concern for what addresses are being used by other tenants or other virtual networks.
個々のテナントは、仮想ネットワーク内で使用するアドレスを制御する必要があります。ただし、異なるテナントが同じアドレスを使用する場合や、同じテナントが異なる仮想ネットワークで同じアドレスを再利用する場合でも、問題が発生する可能性があります。したがって、仮想ネットワークでは、他のテナントや他の仮想ネットワークがどのアドレスを使用しているかに関係なく、テナントが任意のアドレスを使用できるようにする必要があります。
3.6. Need for Address Separation between Virtual Networks and Infrastructure
3.6. 仮想ネットワークとインフラストラクチャ間のアドレス分離の必要性
As in the previous case, a tenant needs to be able to use whatever addresses it wants in a virtual network independent of what addresses the underlying data center network is using. Tenants (and the underlay infrastructure provider) should be able use whatever addresses make sense for them without having to worry about address collisions between addresses used by tenants and those used by the underlay data center network.
前のケースと同様に、テナントは、基盤となるデータセンターネットワークが使用しているアドレスに関係なく、仮想ネットワーク内で必要なアドレスを使用できる必要があります。テナント（およびアンダーレイインフラストラクチャプロバイダー）は、テナントが使用するアドレスとアンダーレイデータセンターネットワークが使用するアドレスとのアドレスの衝突を心配する必要なく、自分にとって意味のあるアドレスを使用できる必要があります。
Another problem area relates to the optimal forwarding of traffic between peers that are not connected to the same virtual network. Such forwarding happens when a host on a virtual network communicates with a host not on any virtual network (e.g., an Internet host) as well as when a host on a virtual network communicates with a host on a different virtual network. A virtual network may have two (or more) gateways for forwarding traffic onto and off of the virtual network, and the optimal choice of which gateway to use may depend on the set of available paths between the communicating peers. The set of available gateways may not be equally "close" to a given destination. The issue appears both when a VM is initially instantiated on a virtual network or when a VM migrates or is moved to a different location. After a migration, for instance, a VM's best-choice gateway for such traffic may change, i.e., the VM may get better service by switching to the "closer" gateway, and this may improve the utilization of network resources.
別の問題領域は、同じ仮想ネットワークに接続されていないピア間のトラフィックの最適な転送に関連しています。このような転送は、仮想ネットワーク上のホストが仮想ネットワーク上にないホスト（インターネットホストなど）と通信する場合、および仮想ネットワーク上のホストが別の仮想ネットワーク上のホストと通信する場合に発生します。仮想ネットワークには、仮想ネットワークにトラフィックを転送するための2つ（またはそれ以上）のゲートウェイがあり、使用するゲートウェイの最適な選択は、通信するピア間の利用可能なパスのセットによって異なります。利用可能なゲートウェイのセットは、特定の宛先に等しく「近い」とは限りません。この問題は、VMが仮想ネットワークで最初にインスタンス化されたとき、またはVMが別の場所に移行または移動されたときに発生します。たとえば、移行後、そのようなトラフィックに対するVMの最適なゲートウェイが変更される可能性があります。つまり、「より近い」ゲートウェイに切り替えることでVMのサービスが向上し、ネットワークリソースの利用率が向上する可能性があります。
IP implementations in network endpoints typically do not distinguish between multiple routers on the same subnet -- there may only be a single default gateway in use, and any use of multiple routers usually considers all of them to be one hop away. Routing protocol functionality is constrained by the requirement to cope with these endpoint limitations -- for example, the Virtual Router Redundancy Protocol (VRRP) has one router serve as the master to handle all outbound traffic. This problem can be particularly acute when the virtual network spans multiple data centers, as a VM is likely to receive significantly better service when forwarding external traffic through a local router compared to using a router at a remote data center.
ネットワークエンドポイントのIP実装は、通常、同じサブネット上の複数のルーターを区別しません。使用されているデフォルトゲートウェイは1つだけであり、通常、複数のルーターを使用する場合、すべてのルーターが1ホップ離れていると見なされます。ルーティングプロトコル機能は、これらのエンドポイントの制限に対処するための要件によって制約されます。たとえば、仮想ルーター冗長プロトコル（VRRP）には、すべての送信トラフィックを処理するマスターとして機能する1つのルーターがあります。この問題は、仮想ネットワークが複数のデータセンターにまたがっている場合に特に深刻になる可能性があります。リモートデータセンターでルーターを使用する場合と比較して、ローカルルーター経由で外部トラフィックを転送する場合、VMは非常に優れたサービスを受け取る可能性が高いためです。
The optimal forwarding problem applies to both outbound and inbound traffic. For outbound traffic, the choice of outbound router determines the path of outgoing traffic from the VM, which may be sub-optimal after a VM move. For inbound traffic, the location of the VM within the IP subnet for the VM is not visible to the routers beyond the virtual network. Thus, the routing infrastructure will have no information as to which of the two externally visible gateways leading into the virtual network would be the better choice for reaching a particular VM.
最適な転送の問題は、送信トラフィックと受信トラフィックの両方に当てはまります。送信トラフィックの場合、送信ルーターの選択により、VMからの送信トラフィックのパスが決まります。これは、VMの移動後に最適とは限りません。受信トラフィックの場合、VMのIPサブネット内のVMの場所は、仮想ネットワークを超えたルーターからは見えません。したがって、ルーティングインフラストラクチャには、仮想ネットワークにつながる外部から見える2つのゲートウェイのどちらが特定のVMに到達するためのより良い選択であるかについての情報がありません。
The issue is further complicated when middleboxes (e.g., load balancers, firewalls, etc.) must be traversed. Middleboxes may have session state that must be preserved for ongoing communication, and traffic must continue to flow through the middlebox, regardless of which router is "closest".
ミドルボックス（ロードバランサ、ファイアウォールなど）を通過する必要がある場合、問題はさらに複雑になります。ミドルボックスには、進行中の通信のために保持する必要があるセッション状態があり、どのルータが「最も近い」かに関係なく、トラフィックはミドルボックスを流れ続ける必要があります。
Virtual networks are used to isolate a tenant's traffic from that of other tenants (or even traffic within the same tenant network that requires isolation). There are two main characteristics of virtual networks:
仮想ネットワークは、テナントのトラフィックを他のテナントのトラフィックから分離するために使用されます（または、分離が必要な同じテナントネットワーク内のトラフィックでさえも）。仮想ネットワークには2つの主な特徴があります。
1. Virtual networks isolate the address space used in one virtual network from the address space used by another virtual network. The same network addresses may be used in different virtual networks at the same time. In addition, the address space used by a virtual network is independent from that used by the underlying physical network.
1. 仮想ネットワークは、ある仮想ネットワークで使用されるアドレススペースを別の仮想ネットワークで使用されるアドレススペースから分離します。同じネットワークアドレスを、異なる仮想ネットワークで同時に使用できます。さらに、仮想ネットワークが使用するアドレス空間は、基礎となる物理ネットワークが使用するアドレス空間から独立しています。
2. Virtual networks limit the scope of packets sent on the virtual network. Packets sent by Tenant Systems attached to a virtual network are delivered as expected to other Tenant Systems on that virtual network and may exit a virtual network only through controlled exit points, such as a security gateway. Likewise, packets sourced from outside of the virtual network may enter the virtual network only through controlled entry points, such as a security gateway.
2. 仮想ネットワークは、仮想ネットワークで送信されるパケットのスコープを制限します。仮想ネットワークに接続されたテナントシステムによって送信されたパケットは、その仮想ネットワーク上の他のテナントシステムに期待どおりに配信され、セキュリティゲートウェイなどの制御された出口ポイントを介してのみ仮想ネットワークを出ることができます。同様に、仮想ネットワークの外部から送信されたパケットは、セキュリティゲートウェイなどの制御されたエントリポイントを通じてのみ仮想ネットワークに入ることができます。
To address the problems described in Section 3, a network overlay approach can be used.
セクション3で説明した問題に対処するには、ネットワークオーバーレイアプローチを使用できます。
The idea behind an overlay is quite straightforward. Each virtual network instance is implemented as an overlay. The original packet is encapsulated by the first-hop network device, called a Network Virtualization Edge (NVE), and tunneled to a remote NVE. The encapsulation identifies the destination of the device that will perform the decapsulation (i.e., the egress NVE for the tunneled packet) before delivering the original packet to the endpoint. The rest of the network forwards the packet based on the encapsulation header and can be oblivious to the payload that is carried inside.
オーバーレイの背後にある考え方は非常に簡単です。各仮想ネットワークインスタンスは、オーバーレイとして実装されます。元のパケットは、ネットワーク仮想化エッジ（NVE）と呼ばれる最初のホップのネットワークデバイスによってカプセル化され、リモートNVEにトンネリングされます。カプセル化は、元のパケットをエンドポイントに配信する前に、カプセル化解除を実行するデバイスの宛先（つまり、トンネリングされたパケットの出力NVE）を識別します。ネットワークの残りの部分は、カプセル化ヘッダーに基づいてパケットを転送し、内部で運ばれるペイロードに気付かない可能性があります。
Overlays are based on what is commonly known as a "map-and-encap" architecture. When processing and forwarding packets, three distinct and logically separable steps take place:
オーバーレイは、一般に「マップアンドエンキャップ」アーキテクチャとして知られているものに基づいています。パケットを処理および転送する場合、3つの異なる論理的に分離可能なステップが実行されます。
1. The first-hop overlay device implements a mapping operation that determines where the encapsulated packet should be sent to reach its intended destination VM. Specifically, the mapping function maps the destination address (either L2 or L3) of a packet received from a VM into the corresponding destination address of the egress NVE device. The destination address will be the underlay address of the NVE device doing the decapsulation and is an IP address.
1.ファーストホップオーバーレイデバイスは、カプセル化されたパケットを送信して目的の宛先VMに到達する場所を決定するマッピング操作を実装します。具体的には、マッピング機能は、VMから受信したパケットの宛先アドレス（L2またはL3のいずれか）を、出口NVEデバイスの対応する宛先アドレスにマッピングします。宛先アドレスは、カプセル化解除を行うNVEデバイスのアンダーレイアドレスであり、IPアドレスです。
2. Once the mapping has been determined, the ingress overlay NVE device encapsulates the received packet within an overlay header.
2. マッピングが決定されると、入力オーバーレイNVEデバイスは、受信したパケットをオーバーレイヘッダー内にカプセル化します。
3. The final step is to actually forward the (now encapsulated) packet to its destination. The packet is forwarded by the underlay (i.e., the IP network) based entirely on its outer address. Upon receipt at the destination, the egress overlay NVE device decapsulates the original packet and delivers it to the intended recipient VM.
3. 最後のステップは、（カプセル化された）パケットを宛先に実際に転送することです。パケットは、完全にその外部アドレスに基づいて、アンダーレイ（つまり、IPネットワーク）によって転送されます。宛先で受信すると、出力オーバーレイNVEデバイスは元のパケットのカプセル化を解除し、それを目的の受信者VMに配信します。
Each of the above steps is logically distinct, though an implementation might combine them for efficiency or other reasons. It should be noted that in L3 BGP/VPN terminology, the above steps are commonly known as "forwarding" or "virtual forwarding".
上記の各ステップは論理的に異なりますが、実装によっては、効率やその他の理由でそれらを組み合わせる場合があります。 L3 BGP / VPN用語では、上記の手順は一般に「転送」または「仮想転送」として知られていることに注意してください。
The first-hop NVE device can be a traditional switch or router or the virtual switch residing inside a hypervisor. Furthermore, the endpoint can be a VM, or it can be a physical server. Examples of architectures based on network overlays include BGP/MPLS IP VPNs [RFC4364], Transparent Interconnection of Lots of Links (TRILL) [RFC6325], the Locator/ID Separation Protocol (LISP) [RFC6830], and Shortest Path Bridging (SPB) [IEEE-802.1aq].
最初のホップのNVEデバイスは、従来のスイッチまたはルーター、またはハイパーバイザー内にある仮想スイッチです。さらに、エンドポイントはVMにすることも、物理サーバーにすることもできます。ネットワークオーバーレイに基づくアーキテクチャの例には、BGP / MPLS IP VPN [RFC4364]、リンクの透過的な相互接続（TRILL）[RFC6325]、ロケーター/ ID分離プロトコル（LISP）[RFC6830]、最短パスブリッジ（SPB）などがあります。 [IEEE-802.1aq]。
In the data plane, an overlay header provides a place to carry either the virtual network identifier or an identifier that is locally significant to the edge device. In both cases, the identifier in the overlay header specifies which specific virtual network the data packet belongs to. Since both routed and bridged semantics can be supported by a virtual data center, the original packet carried within the overlay header can be an Ethernet frame or just the IP packet.
データプレーンでは、オーバーレイヘッダーが、仮想ネットワーク識別子またはエッジデバイスにとってローカルで重要な識別子のいずれかを伝送する場所を提供します。どちらの場合も、オーバーレイヘッダーの識別子は、データパケットが属する特定の仮想ネットワークを指定します。ルーティングされたセマンティクスとブリッジされたセマンティクスの両方を仮想データセンターでサポートできるため、オーバーレイヘッダー内で伝送される元のパケットは、イーサネットフレームまたは単なるIPパケットにすることができます。
A key aspect of overlays is the decoupling of the "virtual" MAC and/ or IP addresses used by VMs from the physical network infrastructure and the infrastructure IP addresses used by the data center. If a VM changes location, the overlay edge devices simply update their mapping tables to reflect the new location of the VM within the data center's infrastructure space. Because an overlay network is used, a VM can now be located anywhere in the data center that the overlay reaches without regard to traditional constraints imposed by the underlay network, such as the C-VLAN scope or the IP subnet scope.
オーバーレイの重要な側面は、VMが使用する「仮想」MACアドレスまたはIPアドレス、あるいはその両方を、物理ネットワークインフラストラクチャおよびデータセンターが使用するインフラストラクチャIPアドレスから分離することです。 VMが場所を変更した場合、オーバーレイエッジデバイスは単にマッピングテーブルを更新して、データセンターのインフラストラクチャスペース内のVMの新しい場所を反映します。オーバーレイネットワークが使用されるため、C-VLANスコープやIPサブネットスコープなどのアンダーレイネットワークによって課せられた従来の制約に関係なく、オーバーレイが到達するデータセンター内の任意の場所にVMを配置できます。
Multi-tenancy is supported by isolating the traffic of one virtual network instance from traffic of another. Traffic from one virtual network instance cannot be delivered to another instance without (conceptually) exiting the instance and entering the other instance via an entity (e.g., a gateway) that has connectivity to both virtual network instances. Without the existence of a gateway entity, tenant traffic remains isolated within each individual virtual network instance.
マルチテナンシーは、1つの仮想ネットワークインスタンスのトラフィックを別の仮想ネットワークインスタンスのトラフィックから分離することによってサポートされます。 1つの仮想ネットワークインスタンスからのトラフィックは、（概念的に）インスタンスから出て、両方の仮想ネットワークインスタンスに接続できるエンティティ（ゲートウェイなど）を介して他のインスタンスに入るまで、別のインスタンスに配信できません。ゲートウェイエンティティが存在しない場合、テナントトラフィックは各仮想ネットワークインスタンス内で分離されたままになります。
Overlays are designed to allow a set of VMs to be placed within a single virtual network instance, whether that virtual network provides a bridged network or a routed network.
オーバーレイは、仮想ネットワークがブリッジネットワークとルーテッドネットワークのどちらを提供するかに関係なく、一連のVMを単一の仮想ネットワークインスタンス内に配置できるように設計されています。
Not all communication will be between devices connected to virtualized networks. Devices using overlays will continue to access devices and make use of services on non-virtualized networks, whether in the data center, the public Internet, or at remote/branch campuses. Any virtual network solution must be capable of interoperating with existing routers, VPN services, load balancers, intrusion-detection services, firewalls, etc., on external networks.
仮想化ネットワークに接続されたデバイス間ですべての通信が行われるわけではありません。オーバーレイを使用するデバイスは、デバイスにアクセスし続け、データセンター、パブリックインターネット、リモート/ブランチキャンパスなど、仮想化されていないネットワーク上のサービスを利用します。どの仮想ネットワークソリューションも、外部ネットワーク上の既存のルーター、VPNサービス、ロードバランサー、侵入検知サービス、ファイアウォールなどと相互運用できる必要があります。
Communication between devices attached to a virtual network and devices connected to non-virtualized networks is handled architecturally by having specialized gateway devices that receive packets from a virtualized network, decapsulate them, process them as regular (i.e., non-virtualized) traffic, and finally forward them on to their appropriate destination (and vice versa).
仮想ネットワークに接続されたデバイスと非仮想化ネットワークに接続されたデバイス間の通信は、仮想化ネットワークからパケットを受信し、それらをカプセル化解除し、それらを通常の（つまり非仮想化）トラフィックとして処理し、最後に特殊なゲートウェイデバイスを使用することにより、アーキテクチャ的に処理されます。それらを適切な宛先に転送します（逆も同様です）。
A wide range of implementation approaches are possible. Overlay gateway functionality could be combined with other network functionality into a network device that implements the overlay functionality and then forwards traffic between other internal components that implement functionality such as full router service, load balancing, firewall support, VPN gateway, etc.
幅広い実装アプローチが可能です。オーバーレイゲートウェイ機能を他のネットワーク機能と組み合わせて、オーバーレイ機能を実装するネットワークデバイスにし、ルーターサービス全体、負荷分散、ファイアウォールサポート、VPNゲートウェイなどの機能を実装する他の内部コンポーネント間でトラフィックを転送できます。
Communication between devices on different virtual networks is handled architecturally by adding specialized interconnect functionality among the otherwise isolated virtual networks. For a virtual network providing an L2 service, such interconnect functionality could be IP forwarding configured as part of the "default gateway" for each virtual network. For a virtual network providing L3 service, the interconnect functionality could be IP forwarding configured as part of routing between IP subnets, or it could be based on configured inter-virtual-network traffic policies.
異なる仮想ネットワーク上のデバイス間の通信は、他の方法では分離された仮想ネットワーク間に特殊な相互接続機能を追加することにより、アーキテクチャ的に処理されます。 L2サービスを提供する仮想ネットワークの場合、このような相互接続機能には、各仮想ネットワークの「デフォルトゲートウェイ」の一部として構成されたIP転送があります。 L3サービスを提供する仮想ネットワークの場合、相互接続機能は、IPサブネット間のルーティングの一部として構成されたIPフォワーディングである場合と、構成された仮想ネットワーク間トラフィックポリシーに基づく場合があります。
In both cases, the implementation of the interconnect functionality could be distributed across the NVEs and could be combined with other network functionality (e.g., load balancing and firewall support) that is applied to traffic forwarded between virtual networks.
どちらの場合も、相互接続機能の実装をNVE全体に分散し、仮想ネットワーク間で転送されるトラフィックに適用される他のネットワーク機能（ロードバランシングやファイアウォールサポートなど）と組み合わせることができます。
Below are some of the characteristics of environments that must be taken into account by the overlay technology.
以下は、オーバーレイテクノロジーで考慮する必要のある環境の特性の一部です。
1. Highly distributed systems: The overlay should work in an environment where there could be many thousands of access switches (e.g., residing within the hypervisors) and many more Tenant Systems (e.g., VMs) connected to them. This leads to a distributed mapping system that puts a low overhead on the overlay tunnel endpoints.
1. 高度に分散されたシステム：オーバーレイは、何千ものアクセススイッチ（ハイパーバイザー内に存在するなど）とそれらに接続されたさらに多くのテナントシステム（VMなど）が存在する可能性がある環境で機能する必要があります。これにより、オーバーレイトンネルエンドポイントのオーバーヘッドが低くなる分散マッピングシステムになります。
2. Many highly distributed virtual networks with sparse membership: Each virtual network could be highly dispersed inside the data center. Also, along with expectation of many virtual networks, the number of Tenant Systems connected to any one virtual network is expected to be relatively low; therefore, the percentage of NVEs participating in any given virtual network would also be expected to be low. For this reason, efficient delivery of multi-destination traffic within a virtual network instance should be taken into consideration.
2. 疎メンバーシップを備えた高度に分散された多くの仮想ネットワーク：各仮想ネットワークは、データセンター内に高度に分散する可能性があります。また、多くの仮想ネットワークの期待に加えて、1つの仮想ネットワークに接続されているテナントシステムの数は比較的少ないと予想されます。したがって、特定の仮想ネットワークに参加しているNVEの割合も低いと予想されます。このため、仮想ネットワークインスタンス内の複数の宛先トラフィックの効率的な配信を考慮する必要があります。
3. Highly dynamic Tenant Systems: Tenant Systems connected to virtual networks can be very dynamic, both in terms of creation/deletion/power-on/power-off and in terms of mobility from one access device to another.
3. 非常に動的なテナントシステム：仮想ネットワークに接続されたテナントシステムは、作成/削除/電源オン/電源オフの点でも、アクセスデバイス間の移動性の点でも非常に動的である場合があります。
4. Be incrementally deployable, without necessarily requiring major upgrade of the entire network: The first-hop device (or end system) that adds and removes the overlay header may require new software and may require new hardware (e.g., for improved performance). The rest of the network should not need to change just to enable the use of overlays.
4. ネットワーク全体のメジャーアップグレードを必ずしも必要とせずに、段階的に導入できます。オーバーレイヘッダーを追加および削除するファーストホップデバイス（またはエンドシステム）には、新しいソフトウェアが必要になる場合や、新しいハードウェアが必要になる場合があります（たとえば、パフォーマンスの向上のため）。オーバーレイを使用できるようにするためだけに、ネットワークの残りの部分を変更する必要はありません。
5. Work with existing data center network deployments without requiring major changes in operational or other practices: For example, some data centers have not enabled multicast beyond link-local scope. Overlays should be capable of leveraging underlay multicast support where appropriate, but not require its enablement in order to use an overlay solution.
5. 運用やその他のプラクティスに大きな変更を加えることなく、既存のデータセンターネットワーク展開を操作します。たとえば、一部のデータセンターでは、リンクローカルスコープを超えたマルチキャストを有効にしていません。オーバーレイは、必要に応じてアンダーレイマルチキャストサポートを活用できる必要がありますが、オーバーレイソリューションを使用するために有効にする必要はありません。
6. Network infrastructure administered by a single administrative domain: This is consistent with operation within a data center, and not across the Internet.
6. 単一の管理ドメインによって管理されるネットワークインフラストラクチャ：これは、インターネット全体ではなく、データセンター内での運用と一貫しています。
There are three specific and separate potential work areas in the area of control-plane protocols needed to realize an overlay solution. The areas correspond to different possible "on-the-wire" protocols, where distinct entities interact with each other.
オーバーレイソリューションを実現するために必要なコントロールプレーンプロトコルの領域には、3つの個別の潜在的な作業領域があります。これらの領域は、個別のエンティティが互いに相互作用するさまざまな「オンザワイヤ」プロトコルに対応しています。
One area of work concerns the address dissemination protocol an NVE uses to build and maintain the mapping tables it uses to deliver encapsulated packets to their proper destination. One approach is to build mapping tables entirely via learning (as is done in 802.1 networks). Another approach is to use a specialized control-plane protocol. While there are some advantages to using or leveraging an existing protocol for maintaining mapping tables, the fact that large numbers of NVEs will likely reside in hypervisors places constraints on the resources (CPU and memory) that can be dedicated to such functions.
作業の1つは、NVEがカプセル化されたパケットを適切な宛先に配信するために使用するマッピングテーブルを作成および維持するために使用するアドレス配布プロトコルに関係しています。 1つのアプローチは、完全に学習を介してマッピングテーブルを構築することです（802.1ネットワークで行われるように）。別のアプローチは、専用のコントロールプレーンプロトコルを使用することです。マッピングテーブルを維持するために既存のプロトコルを使用または活用することにはいくつかの利点がありますが、多数のNVEがハイパーバイザーに常駐する可能性があるという事実は、そのような機能に専用できるリソース（CPUおよびメモリ）に制約を課します。
From an architectural perspective, one can view the address-mapping dissemination problem as having two distinct and separable components. The first component consists of a back-end Network Virtualization Authority (NVA) that is responsible for distributing and maintaining the mapping information for the entire overlay system. For this document, we use the term "NVA" to refer to an entity that supplies answers, without regard to how it knows the answers it is providing. The second component consists of the on-the-wire protocols an NVE uses when interacting with the NVA.
アーキテクチャの観点から、アドレスマッピングの普及問題は、2つの別個の分離可能なコンポーネントがあると考えることができます。最初のコンポーネントは、オーバーレイシステム全体のマッピング情報の配布と維持を担当するバックエンドネットワーク仮想化機関（NVA）で構成されています。このドキュメントでは、「NVA」という用語を使用して、提供する回答がどのように認識されているかに関係なく、回答を提供するエンティティを指します。 2番目のコンポーネントは、NVEとの対話時にNVEが使用するオンザワイヤプロトコルで構成されています。
The first two areas of work are thus: describing the NVA function and defining NVA-NVE interactions.
したがって、最初の2つの作業領域は、NVA関数の説明とNVA-NVE相互作用の定義です。
The back-end NVA could provide high performance, high resiliency, failover, etc., and could be implemented in significantly different ways. For example, one model uses a traditional, centralized "directory-based" database, using replicated instances for reliability and failover. A second model involves using and possibly extending an existing routing protocol (e.g., BGP, IS-IS, etc.). To support different architectural models, it is useful to have one standard protocol for the NVE-NVA interaction while allowing different protocols and architectural approaches for the NVA itself. Separating the two allows NVEs to transparently interact with different types of NVAs, i.e., either of the two architectural models described above. Having separate protocols could also allow for a simplified NVE that only interacts with the NVA for the mapping table entries it needs and allows the NVA (and its associated protocols) to evolve independently over time with minimal impact to the NVEs.
バックエンドNVAは、高パフォーマンス、高回復力、フェイルオーバーなどを提供でき、大幅に異なる方法で実装できます。たとえば、1つのモデルは、信頼性とフェイルオーバーのために複製されたインスタンスを使用して、従来の集中型「ディレクトリベース」データベースを使用します。 2番目のモデルには、既存のルーティングプロトコル（BGP、IS-ISなど）の使用と拡張が含まれます。さまざまなアーキテクチャモデルをサポートするには、NVEとNVAの相互作用に1つの標準プロトコルを使用し、NVA自体にさまざまなプロトコルとアーキテクチャアプローチを許可すると便利です。 2つを分離することで、NVEは異なるタイプのNVA、つまり、上記の2つのアーキテクチャモデルのいずれかと透過的に対話できます。個別のプロトコルを使用すると、必要なマッピングテーブルエントリのNVAとのみ対話する簡略化されたNVEも可能になり、NVA（およびその関連プロトコル）は、NVEへの影響を最小限に抑えながら、時間の経過とともに独立して展開できます。
A third work area considers the attachment and detachment of VMs (or Tenant Systems [RFC7365], more generally) from a specific virtual network instance. When a VM attaches, the NVE associates the VM with a specific overlay for the purposes of tunneling traffic sourced from or destined to the VM. When a VM disconnects, the NVE should notify the NVA that the Tenant System to NVE address mapping is no longer valid. In addition, if this VM was the last remaining member of the virtual network, then the NVE can also terminate any tunnels used to deliver tenant multi-destination packets within the VN to the NVE. In the case where an NVE and hypervisor are on separate physical devices separated by an access network, a standardized protocol may be needed.
3番目の作業領域では、特定の仮想ネットワークインスタンスからのVM（またはより一般的にはテナントシステム[RFC7365]）のアタッチとデタッチを考慮します。 VMが接続されると、NVEはVMをソースまたは宛先とするトラフィックをトンネリングする目的で、VMを特定のオーバーレイに関連付けます。 VMが切断されると、NVEはテナントシステムからNVEアドレスへのマッピングが無効になったことをNVAに通知する必要があります。さらに、このVMが仮想ネットワークの最後の残りのメンバーであった場合、NVEは、VN内のテナントの複数宛先パケットをNVEに配信するために使用されるトンネルを終了することもできます。 NVEとハイパーバイザーがアクセスネットワークによって分離された別々の物理デバイス上にある場合、標準化されたプロトコルが必要になる場合があります。
In summary, there are three areas of potential work. The first area concerns the implementation of the NVA function itself and any protocols it needs (e.g., if implemented in a distributed fashion). A second area concerns the interaction between the NVA and NVEs. The third work area concerns protocols associated with attaching and detaching a VM from a particular virtual network instance. All three work areas are important to the development of scalable, interoperable solutions.
要約すると、潜在的な作業には3つの領域があります。最初の領域は、NVA機能自体の実装とそれが必要とするすべてのプロトコルに関係します（たとえば、分散方式で実装されている場合）。 2番目の領域は、NVAとNVE間の相互作用に関するものです。 3番目の作業領域は、特定の仮想ネットワークインスタンスへのVMの接続と切断に関連するプロトコルに関するものです。 3つの作業領域はすべて、スケーラブルで相互運用可能なソリューションの開発にとって重要です。
The data plane carries encapsulated packets for Tenant Systems. The data-plane encapsulation header carries a VN Context identifier [RFC7365] for the virtual network to which the data packet belongs. Numerous encapsulation or tunneling protocols already exist that can be leveraged. In the absence of strong and compelling justification, it would not seem necessary or helpful to develop yet another encapsulation format just for NVO3.
データプレーンは、テナントシステムのカプセル化されたパケットを伝送します。データプレーンカプセル化ヘッダーは、データパケットが属する仮想ネットワークのVNコンテキスト識別子[RFC7365]を伝送します。すでに活用されているカプセル化またはトンネリングプロトコルは数多く存在します。強力で説得力のある正当化がない場合、NVO3専用のさらに別のカプセル化形式を開発することは必要または役に立たないと思われます。
The following subsections discuss related IETF and IEEE work. These subsections are not meant to provide complete coverage of all IETF and IEEE work related to data centers, and the descriptions should not be considered comprehensive. Each area aims to address particular limitations of today's data center networks. In all areas, scaling is a common theme as are multi-tenancy and VM mobility. Comparing and evaluating the work result and progress of each work area listed is out of the scope of this document. The intent of this section is to provide a reference to the interested readers. Note that NVO3 is scoped to running over an IP/L3 underlay network.
以下のサブセクションでは、関連するIETFおよびIEEEの作業について説明します。これらのサブセクションは、データセンターに関連するすべてのIETFおよびIEEEの作業を完全に網羅することを意図したものではなく、説明は包括的であると見なすべきではありません。各エリアは、今日のデータセンターネットワークの特定の制限に対処することを目的としています。すべての領域で、マルチテナントとVMモビリティと同様に、スケーリングは共通のテーマです。リストされている各作業領域の作業結果と進捗状況の比較と評価は、このドキュメントの範囲外です。このセクションの目的は、関心のある読者への参照を提供することです。 NVO3のスコープは、IP / L3アンダーレイネットワークで実行されることに注意してください。
BGP/MPLS IP VPNs [RFC4364] support multi-tenancy, VPN traffic isolation, address overlapping, and address separation between tenants and network infrastructure. The BGP/MPLS control plane is used to distribute the VPN labels and the tenant IP addresses that identify the tenants (or to be more specific, the particular VPN/ virtual network) and tenant IP addresses. Deployment of enterprise L3 VPNs has been shown to scale to thousands of VPNs and millions of VPN prefixes. BGP/MPLS IP VPNs are currently deployed in some large enterprise data centers. The potential limitation for deploying BGP/ MPLS IP VPNs in data center environments is the practicality of using BGP in the data center, especially reaching into the servers or hypervisors. There may be computing workforce skill set issues, equipment support issues, and potential new scaling challenges. A combination of BGP and lighter-weight IP signaling protocols, e.g., the Extensible Messaging and Presence Protocol (XMPP), has been proposed to extend the solutions into the data center environment [END-SYSTEM] while taking advantage of built-in VPN features with its rich policy support; it is especially useful for inter-tenant connectivity.
BGP / MPLS IP VPN [RFC4364]は、マルチテナント、VPNトラフィックの分離、アドレスの重複、テナントとネットワークインフラストラクチャ間のアドレスの分離をサポートしています。 BGP / MPLSコントロールプレーンは、VPNラベルと、テナント（より具体的には、特定のVPN /仮想ネットワーク）およびテナントIPアドレスを識別するテナントIPアドレスを配布するために使用されます。エンタープライズL3 VPNの展開は、数千のVPNと数百万のVPNプレフィックスにまで拡張できることが示されています。 BGP / MPLS IP VPNは現在、一部の大規模エンタープライズデータセンターに導入されています。データセンター環境にBGP / MPLS IP VPNを展開することの潜在的な制限は、データセンターでBGPを使用することの実用性、特にサーバーまたはハイパーバイザーに到達することです。コンピューティングワーカーのスキルセットの問題、機器のサポートの問題、および潜在的な新しいスケーリングの課題がある可能性があります。 BGPと軽量IPシグナリングプロトコル（Extensible Messaging and Presence Protocol（XMPP）など）の組み合わせが、組み込みのVPN機能を活用しながらソリューションをデータセンター環境に拡張するために提案されています[END-SYSTEM]豊富なポリシーサポート。これは、テナント間の接続に特に役立ちます。
Ethernet Virtual Private Networks (E-VPNs) [EVPN] provide an emulated L2 service in which each tenant has its own Ethernet network over a common IP or MPLS infrastructure. A BGP/MPLS control plane is used to distribute the tenant MAC addresses and the MPLS labels that identify the tenants and tenant MAC addresses. Within the BGP/MPLS control plane, a 32-bit Ethernet tag is used to identify the broadcast domains (VLANs) associated with a given L2 VLAN service instance, and these Ethernet tags are mapped to VLAN IDs understood by the tenant at the service edges. This means that any VLAN-based limitation on the customer site is associated with an individual tenant service edge, enabling a much higher level of scalability. Interconnection between tenants is also allowed in a controlled fashion.
イーサネット仮想プライベートネットワーク（E-VPN）[EVPN]は、各テナントが共通のIPまたはMPLSインフラストラクチャ上に独自のイーサネットネットワークを持つエミュレートされたL2サービスを提供します。 BGP / MPLSコントロールプレーンは、テナントのMACアドレスと、テナントとテナントのMACアドレスを識別するMPLSラベルを配布するために使用されます。 BGP / MPLSコントロールプレーン内では、32ビットイーサネットタグを使用して、特定のL2 VLANサービスインスタンスに関連付けられたブロードキャストドメイン（VLAN）を識別し、これらのイーサネットタグは、サービスエッジのテナントが理解するVLAN IDにマッピングされます。これは、顧客サイトのVLANベースの制限が個々のテナントサービスエッジに関連付けられていることを意味し、はるかに高いレベルのスケーラビリティを実現します。テナント間の相互接続も制御された方法で許可されます。
VM mobility [MOBILITY] introduces the concept of a combined L2/L3 VPN service in order to support the mobility of individual virtual machines (VMs) between data centers connected over a common IP or MPLS infrastructure.
VMモビリティ[MOBILITY]は、共通のIPまたはMPLSインフラストラクチャを介して接続されたデータセンター間の個々の仮想マシン（VM）のモビリティをサポートするために、L2 / L3 VPNサービスの組み合わせの概念を導入します。
VLANs are a well-understood construct in the networking industry, providing an L2 service via a physical network in which tenant forwarding information is part of the physical network infrastructure. A VLAN is an L2 bridging construct that provides the semantics of virtual networks mentioned above: a MAC address can be kept unique within a VLAN, but it is not necessarily unique across VLANs. Traffic scoped within a VLAN (including broadcast and multicast traffic) can be kept within the VLAN it originates from. Traffic forwarded from one VLAN to another typically involves router (L3) processing. The forwarding table lookup operation may be keyed on {VLAN, MAC address} tuples.
VLANは、ネットワーク業界でよく知られている構造であり、テナント転送情報が物理ネットワークインフラストラクチャの一部である物理ネットワークを介してL2サービスを提供します。 VLANは、上記の仮想ネットワークのセマンティクスを提供するL2ブリッジ構成です。MACアドレスはVLAN内で一意に保つことができますが、VLAN全体で一意である必要はありません。 VLAN内にスコープされたトラフィック（ブロードキャストおよびマルチキャストトラフィックを含む）は、そのトラフィックが発生したVLAN内に保持できます。あるVLANから別のVLANに転送されるトラフィックには、通常、ルーター（L3）処理が含まれます。転送テーブルのルックアップ操作は、{VLAN、MACアドレス}タプルをキーにすることができます。
VLANs are a pure L2 bridging construct, and VLAN identifiers are carried along with data frames to allow each forwarding point to know what VLAN the frame belongs to. Various types of VLANs are available today and can be used for network virtualization, even together. The C-VLAN, Service VLAN (S-VLAN), and Backbone VLAN (B-VLAN) IDs [IEEE-802.1Q] are 12 bits. The 24-bit I-SID [IEEE-802.1aq] allows the support of more than 16 million virtual networks.
VLANは純粋なL2ブリッジ構成であり、VLAN識別子はデータフレームとともに伝送され、各転送ポイントはフレームがどのVLANに属しているかを認識できます。現在、さまざまなタイプのVLANが利用可能で、ネットワーク仮想化に使用することもできます。 C-VLAN、サービスVLAN（S-VLAN）、およびバックボーンVLAN（B-VLAN）ID [IEEE-802.1Q]は12ビットです。 24ビットのI-SID [IEEE-802.1aq]では、1600万を超える仮想ネットワークをサポートできます。
Shortest Path Bridging (SPB) [IEEE-802.1aq] is an overlay based on IS-IS that operates over L2 Ethernets. SPB supports multipathing and addresses a number of shortcomings in the original Ethernet Spanning Tree Protocol. Shortest Path Bridging Mac (SPBM) uses IEEE 802.1ah PBB (MAC-in-MAC) encapsulation and supports a 24-bit I-SID, which can be used to identify virtual network instances. SPBM provides multi-pathing and supports easy virtual network creation or update.
最短パスブリッジング（SPB）[IEEE-802.1aq]は、L2イーサネット上で動作するIS-ISに基づくオーバーレイです。 SPBはマルチパスをサポートし、元のイーサネットスパニングツリープロトコルの多くの欠点に対処します。最短パスブリッジングMac（SPBM）は、IEEE 802.1ah PBB（MAC-in-MAC）カプセル化を使用し、仮想ネットワークインスタンスを識別するために使用できる24ビットI-SIDをサポートします。 SPBMはマルチパスを提供し、簡単な仮想ネットワークの作成または更新をサポートします。
SPBM extends IS-IS in order to perform link-state routing among core SPBM nodes, obviating the need for bridge learning for communication among core SPBM nodes. Learning is still used to build and maintain the mapping tables of edge nodes to encapsulate Tenant System traffic for transport across the SPBM core.
SPBMはIS-ISを拡張して、コアSPBMノード間でリンクステートルーティングを実行し、コアSPBMノード間の通信のためのブリッジ学習の必要性を排除します。エッジノードのマッピングテーブルを構築および維持するために学習が引き続き使用され、SPBMコアを介して転送するテナントシステムトラフィックをカプセル化します。
SPB is compatible with all other 802.1 standards and thus allows leveraging of other features, e.g., VSI Discovery Protocol (VDP), Operations, Administration, and Maintenance (OAM), or scalability solutions.
SPBは他のすべての802.1標準と互換性があるため、VSI検出プロトコル（VDP）、運用、管理、保守（OAM）、スケーラビリティソリューションなどの他の機能を活用できます。
VDP is the Virtual Station Interface (VSI) Discovery and Configuration Protocol specified by IEEE P802.1Qbg [IEEE-802.1Qbg]. VDP is a protocol that supports the association of a VSI with a port.
VDPは、IEEE P802.1Qbg [IEEE-802.1Qbg]で規定されているVirtual Station Interface（VSI）検出および構成プロトコルです。 VDPは、VSIとポートの関連付けをサポートするプロトコルです。
VDP is run between the end station (e.g., a server running a hypervisor) and its adjacent switch (i.e., the device on the edge of the network). VDP is used, for example, to communicate to the switch that a virtual machine (virtual station) is moving, i.e., designed for VM migration.
VDPは、エンドステーション（ハイパーバイザーを実行しているサーバーなど）とその隣接スイッチ（ネットワークのエッジにあるデバイスなど）の間で実行されます。 VDPは、たとえば、仮想マシン（仮想ステーション）が移動している、つまりVM移行用に設計されたスイッチと通信するために使用されます。
The Address Resolution for Massive numbers of hosts in the Data center (ARMD) WG examined data center scaling issues with a focus on address resolution and developed a problem statement document [RFC6820]. While an overlay-based approach may address some of the "pain points" that were raised in ARMD (e.g., better support for multi-tenancy), analysis will be needed to understand the scaling trade-offs of an overlay-based approach compared with existing approaches. On the other hand, existing IP-based approaches such as proxy ARP may help mitigate some concerns.
データセンター（ARMD）WGの多数のホストのアドレス解決では、アドレス解決に焦点を当ててデータセンターのスケーリングの問題を調査し、問題ステートメントドキュメント[RFC6820]を作成しました。オーバーレイベースのアプローチは、ARMDで発生したいくつかの「問題点」（たとえば、マルチテナンシーのサポートの向上）に対処する可能性がありますが、オーバーレイベースのアプローチのスケーリングのトレードオフを理解するために分析が必要になります。既存のアプローチ。一方、プロキシARPなどの既存のIPベースのアプローチは、いくつかの懸念を軽減するのに役立ちます。
TRILL is a network protocol that provides an Ethernet L2 service to end systems and is designed to operate over any L2 link type. TRILL establishes forwarding paths using IS-IS routing and encapsulates traffic within its own TRILL header. TRILL, as originally defined, supports only the standard (and limited) 12-bit C-VID identifier. Work to extend TRILL to support more than 4094 VLANs has recently completed and is defined in [RFC7172]
TRILLは、エンドシステムにイーサネットL2サービスを提供するネットワークプロトコルであり、あらゆるL2リンクタイプで動作するように設計されています。 TRILLは、IS-ISルーティングを使用して転送パスを確立し、独自のTRILLヘッダー内にトラフィックをカプセル化します。 TRILLは、最初に定義されたとおり、標準（および制限付き）の12ビットC-VID識別子のみをサポートします。 4094を超えるVLANをサポートするようにTRILLを拡張する作業が最近完了し、[RFC7172]で定義されています
The IETF has specified a number of approaches for connecting L2 domains together as part of the L2VPN Working Group. That group, however, has historically been focused on provider-provisioned L2 VPNs, where the service provider participates in management and provisioning of the VPN. In addition, much of the target environment for such deployments involves carrying L2 traffic over WANs. Overlay approaches as discussed in this document are intended be used within data centers where the overlay network is managed by the data center operator rather than by an outside party. While overlays can run across the Internet as well, they will extend well into the data center itself (e.g., up to and including hypervisors) and include large numbers of machines within the data center itself.
IETFは、L2VPNワーキンググループの一部として、L2ドメインを接続するための多くのアプローチを指定しています。ただし、そのグループは、サービスプロバイダーがVPNの管理とプロビジョニングに参加するプロバイダープロビジョニングのL2 VPNにこれまで焦点を当ててきました。さらに、そのような展開のターゲット環境の多くは、WANを介したL2トラフィックの伝送を伴います。このドキュメントで説明するオーバーレイアプローチは、オーバーレイネットワークが外部の当事者ではなくデータセンターのオペレーターによって管理されるデータセンター内で使用することを目的としています。オーバーレイはインターネット上でも実行できますが、データセンター自体（ハイパーバイザーまで）まで拡張され、データセンター自体に多数のマシンが含まれます。
Other L2VPN approaches, such as the Layer 2 Tunneling Protocol (L2TP) [RFC3931] require significant tunnel state at the encapsulating and decapsulating endpoints. Overlays require less tunnel state than other approaches, which is important to allow overlays to scale to hundreds of thousands of endpoints. It is assumed that smaller switches (i.e., virtual switches in hypervisors or the adjacent devices to which VMs connect) will be part of the overlay network and be responsible for encapsulating and decapsulating packets.
レイヤ2トンネリングプロトコル（L2TP）[RFC3931]などの他のL2VPNアプローチでは、カプセル化およびエンドカプセル化のエンドポイントで重要なトンネル状態が必要です。オーバーレイに必要なトンネル状態は他のアプローチよりも少なくて済みます。これは、オーバーレイを数十万のエンドポイントにスケーリングできるようにするために重要です。より小さいスイッチ（つまり、ハイパーバイザー内の仮想スイッチまたはVMが接続する隣接デバイス）は、オーバーレイネットワークの一部であり、パケットのカプセル化とカプセル化解除を担当すると想定されています。
Proxy Mobile IP [RFC5213] [RFC5844] makes use of the Generic Routing Encapsulation (GRE) Key Field [RFC5845] [RFC6245], but not in a way that supports multi-tenancy.
プロキシモバイルIP [RFC5213] [RFC5844]は、Generic Routing Encapsulation（GRE）キーフィールド[RFC5845] [RFC6245]を利用しますが、マルチテナンシーをサポートする方法では利用しません。
LISP [RFC6830] essentially provides an IP-over-IP overlay where the internal addresses are end station identifiers and the outer IP addresses represent the location of the end station within the core IP network topology. The LISP overlay header uses a 24-bit Instance ID used to support overlapping inner IP addresses.
LISP [RFC6830]は基本的に、IP-over-IPオーバーレイを提供します。この場合、内部アドレスは端末の識別子であり、外部IPアドレスはコアIPネットワークトポロジ内の端末の場所を表します。 LISPオーバーレイヘッダーは、重複する内部IPアドレスをサポートするために使用される24ビットのインスタンスIDを使用します。
This document has argued that network virtualization using overlays addresses a number of issues being faced as data centers scale in size. In addition, careful study of current data center problems is needed for development of proper requirements and standard solutions.
このドキュメントでは、オーバーレイを使用したネットワーク仮想化が、データセンターの規模の拡大に伴い直面している多くの問題に対処していると主張しました。さらに、適切な要件と標準ソリューションを開発するには、現在のデータセンターの問題を注意深く調査する必要があります。
This document identifies three potential control protocol work areas. The first involves a back-end NVA and how it learns and distributes the mapping information NVEs use when processing tenant traffic. A second involves the protocol an NVE would use to communicate with the back-end NVA to obtain the mapping information. The third potential work concerns the interactions that take place when a VM attaches or detaches from a specific virtual network instance.
このドキュメントは、3つの潜在的な制御プロトコル作業領域を識別します。 1つ目は、バックエンドNVAと、テナントトラフィックを処理するときにNVEが使用するマッピング情報を学習および配信する方法です。 2つ目は、マッピング情報を取得するためにNVEがバックエンドNVAと通信するために使用するプロトコルです。 3番目の潜在的な作業は、VMが特定の仮想ネットワークインスタンスに接続または切断するときに行われる相互作用に関係します。
There are a number of approaches that provide some, if not all, of the desired semantics of virtual networks. Each approach needs to be analyzed in detail to assess how well it satisfies the requirements.
すべてではないにしても、仮想ネットワークの望ましいセマンティクスのいくつかを提供する多くのアプローチがあります。それぞれのアプローチを詳細に分析して、要件をどれだけ満たしているかを評価する必要があります。
Because this document describes the problem space associated with the need for virtualization of networks in complex, large-scale, data-center networks, it does not itself introduce any security risks. However, it is clear that security concerns need to be a consideration of any solutions proposed to address this problem space.
このドキュメントでは、複雑で大規模なデータセンターネットワークにおけるネットワークの仮想化の必要性に関連する問題領域について説明しているため、それ自体はセキュリティリスクをもたらしません。ただし、セキュリティの問題は、この問題の領域に対処するために提案されたすべてのソリューションを考慮する必要があることは明らかです。
Solutions will need to address both data-plane and control-plane security concerns.
ソリューションは、データプレーンとコントロールプレーンの両方のセキュリティ問題に対処する必要があります。
In the data plane, isolation of virtual network traffic from other virtual networks is a primary concern -- for NVO3, this isolation may be based on VN identifiers that are not involved in underlay network packet forwarding between overlay edges (NVEs). Use of a VN identifier in the overlay reduces the underlay network's role in isolating virtual networks by comparison to approaches where VN identifiers are involved in packet forwarding (e.g., 802.1 VLANs as described in Section 5.3).
データプレーンでは、他の仮想ネットワークからの仮想ネットワークトラフィックの分離が主な関心事です。NVO3の場合、この分離は、オーバーレイエッジ（NVE）間のアンダーレイネットワークパケット転送に関与しないVN識別子に基づいている場合があります。オーバーレイでVN識別子を使用すると、VN識別子がパケット転送に関与するアプローチ（セクション5.3で説明されている802.1 VLANなど）と比較して、仮想ネットワークの分離におけるアンダーレイネットワークの役割が減少します。
In addition to isolation, assurances against spoofing, snooping, transit modification and denial of service are examples of other important data-plane considerations. Some limited environments may even require confidentiality.
分離に加えて、スプーフィング、スヌーピング、トランジット変更、およびサービス拒否に対する保証は、他の重要なデータプレーンの考慮事項の例です。一部の制限された環境では、機密性が要求される場合もあります。
In the control plane, the primary security concern is ensuring that an unauthorized party does not compromise the control-plane protocol in ways that improperly impact the data plane. Some environments may also be concerned about confidentiality of the control plane.
コントロールプレーンでは、セキュリティ上の主な懸念事項は、権限のない者がデータプレーンに不適切な影響を与える方法でコントロールプレーンプロトコルを侵害しないことを保証することです。一部の環境では、コントロールプレーンの機密性についても懸念される場合があります。
More generally, denial-of-service concerns may also be a consideration. For example, a tenant on one virtual network could consume excessive network resources in a way that degrades services for other tenants on other virtual networks.
より一般的には、サービス拒否の懸念も考慮事項となる場合があります。たとえば、1つの仮想ネットワーク上のテナントは、他の仮想ネットワーク上の他のテナントのサービスを低下させるような方法で過剰なネットワークリソースを消費する可能性があります。
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, 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、2014年10月、<http：/ /www.rfc-editor.org/info/rfc7365>。
[END-SYSTEM] Marques, P., Fang, L., Sheth, N., Napierala, M., and N. Bitar, "BGP-signaled end-system IP/VPNs", Work in Progress, draft-ietf-l3vpn-end-system-04, October 2014.
[END-SYSTEM] Marques、P.、Fang、L.、Sheth、N.、Napierala、M。、およびN. Bitar、「BGP信号によるエンドシステムIP / VPN」、Work in Progress、draft-ietf- l3vpn-end-system-04、2014年10月。
[EVPN] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", Work in Progress, draft-ietf-l2vpn-evpn-10, October 2014.
[EVPN] Sajassi、A.、Aggarwal、R.、Bitar、N.、Isaac、A.、J。Uttaro、「BGP MPLSベースのイーサネットVPN」、作業中、draft-ietf-l2vpn-evpn-10、 2014年10月。
[IEEE-802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE 802.1Q-2011, August 2011, <http://standards.ieee.org/getieee802/ download/802.1Q-2011.pdf>.
[IEEE-802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE 802.1Q-2011、August 2011、<http：// standards。 ieee.org/getieee802/download/802.1Q-2011.pdf>。
[IEEE-802.1Qbg] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 21: Edge Virtual Bridging", IEEE 802.1Qbg-2012, July 2012, <http://standards.ieee.org/getieee802/ download/802.1Qbg-2012.pdf>.
[IEEE-802.1Qbg] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks-Amendment 21：Edge Virtual Bridging」、IEEE 802.1Qbg-2012、2012年7月、<http://standards.ieee.org/getieee802/ download / 802.1Qbg-2012.pdf>。
[IEEE-802.1aq] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE 802.1aq, June 2012, <http://standards.ieee.org/getieee802/ download/802.1aq-2012.pdf>.
[IEEE-802.1aq] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks-Amendment 20：Shortest Path Bridging」、IEEE 802.1aq、2012年6月、< http://standards.ieee.org/getieee802/ download / 802.1aq-2012.pdf>。
[MOBILITY] Aggarwal, R., Rekhter, Y., Henderickx, W., Shekhar, R., Fang, L., and A. Sajassi, "Data Center Mobility based on E-VPN, BGP/MPLS IP VPN, IP Routing and NHRP", Work in Progress, draft-raggarwa-data-center-mobility-07, June 2014.
[モバイル性] Aggarwal、R.、Rekhter、Y.、Henderickx、W.、Shekhar、R.、Fang、L。、およびA. Sajassi、「E-VPN、BGP / MPLS IP VPN、IPに基づくデータセンターのモビリティRouting and NHRP」、Work in Progress、draft-raggarwa-data-center-mobility-07、2014年6月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005, <http://www.rfc-editor.org/info/rfc3931>.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「Layer Two Tunneling Protocol-Version 3（L2TPv3）」、RFC 3931、2005年3月、<http://www.rfc-editor.org/ info / rfc3931>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、2006年2月、<http://www.rfc-editor.org/info/rfc4364>。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213] Gundavelli、S.、Leung、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、August 2008、<http：//www.rfc-editor .org / info / rfc5213>。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.
[RFC5844]脇川R.およびS. Gundavelli、「プロキシモバイルIPv6のIPv4サポート」、RFC 5844、2010年5月、<http://www.rfc-editor.org/info/rfc5844>。
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010, <http://www.rfc-editor.org/info/rfc5845>.
[RFC5845] Muhanna、A.、Khalil、M.、Gundavelli、S。、およびK. Leung、「Generic Routing Encapsulation（GRE）Key Option for Proxy Mobile IPv6」、RFC 5845、2010年6月、<http：// www .rfc-editor.org / info / rfc5845>。
[RFC6245] Yegani, P., Leung, K., Lior, A., Chowdhury, K., and J. Navali, "Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4", RFC 6245, May 2011, <http://www.rfc-editor.org/info/rfc6245>.
[RFC6245] Yegani、P.、Leung、K.、Lior、A.、Chowdhury、K。、およびJ. Navali、「Generic Routing Encapsulation（GRE）Key Extension for Mobile IPv4」、RFC 6245、2011年5月、<http ：//www.rfc-editor.org/info/rfc6245>。
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011, <http://www.rfc-editor.org/info/6325>.
[RFC6325] Perlman、R.、Eastlake、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月、<http：/ /www.rfc-editor.org/info/6325>。
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, January 2013, <http://www.rfc-editor.org/info/rfc6820>.
[RFC6820] Narten、T.、Kairr、M。、およびI. Foo、「大規模データセンターネットワークにおけるアドレス解決の問題」、RFC 6820、2013年1月、<http://www.rfc-editor.org/info/ rfc6820>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、RFC 6830、2013年1月、<http：//www.rfc- editor.org/info/rfc6830>。
[RFC7172] Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake、D.、Zhang、M.、Agarwal、P.、Perlman、R。、およびD. Dutt、「多数のリンクの透過的な相互接続（TRILL）：きめの細かいラベル付け」、RFC 7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
Acknowledgments
謝辞
Helpful comments and improvements to this document have come from Lou Berger, John Drake, Ilango Ganga, Ariel Hendel, Vinit Jain, Petr Lapukhov, Thomas Morin, Benson Schliesser, Qin Wu, Xiaohu Xu, Lucy Yong, and many others on the NVO3 mailing list.
このドキュメントに対する有益なコメントと改善は、LOU Berger、John Drake、Ilango Ganga、Ariel Hendel、Vinit Jain、Petr Lapukhov、Thomas Morin、Benson Schliesser、Qin Wu、Xiaohu Xu、Lucy Yong、その他多くのNVO3メーリングから寄せられましたリスト。
Special thanks to Janos Farkas for his persistence and numerous detailed comments related to the lack of precision in the text relating to IEEE 802.1 technologies.
持続可能性と、IEEE 802.1テクノロジに関連するテキストの正確性の欠如に関連する多数の詳細なコメントについて、Janos Farkasに特に感謝します。
Contributors
貢献者
Dinesh Dutt and Murari Sridharin were original co-authors of the Internet-Draft that led to the BoF that formed the NVO3 WG. That original draft eventually became the basis for this document.
Dinesh DuttとMurari Sridharinは、NVO3 WGを形成したBoFにつながったInternet-Draftの最初の共著者でした。その元の草案は、最終的にこのドキュメントの基礎となりました。
Authors' Addresses
著者のアドレス
Thomas Narten (editor) IBM Research Triangle Park, NC United States EMail: narten@us.ibm.com
Thomas Narten（編集者）IBM Research Triangle Park、NCアメリカ合衆国Eメール：narten@us.ibm.com
Eric Gray (editor) Ericsson EMail: eric.gray@ericsson.com
エリック・グレイ（編集者）エリクソンEメール：eric.gray@ericsson.com
David Black EMC Corporation 176 South Street Hopkinton, MA 01748 United States EMail: david.black@emc.com
David Black EMC Corporation 176 South Street Hopkinton、MA 01748 United Statesメール：david.black@emc.com
Luyuan Fang Microsoft 5600 148th Ave NE Redmond, WA 98052 United States EMail: lufang@microsoft.com
Luyuan Fang Microsoft 5600 148th Ave NE Redmond、WA 98052 United Statesメール：lufang@microsoft.com
Lawrence Kreeger Cisco 170 W. Tasman Avenue San Jose, CA 95134 United States EMail: kreeger@cisco.com
Lawrence Kreeger Cisco 170 W. Tasman Avenue San Jose、CA 95134アメリカ合衆国Eメール：kreeger@cisco.com
Maria Napierala AT&T 200 S. Laurel Avenue Middletown, NJ 07748 United States EMail: mnapierala@att.com
Maria Napierala AT＆T 200 S. Laurel Avenue Middletown、NJ 07748アメリカ合衆国Eメール：mnapierala@att.com