[要約] RFC 7586は、大規模データセンター向けのスケーラブルなアドレス解決プロトコル（SARP）に関するものです。このRFCの目的は、データセンター内のネットワークアドレスの解決を効率的かつスケーラブルに行うためのプロトコルを提案することです。
Independent Submission Y. Nachum
Request for Comments: 7586
Category: Experimental L. Dunbar
ISSN: 2070-1721 Huawei
I. Yerushalmi
T. Mizrahi
Marvell
June 2015
The Scalable Address Resolution Protocol (SARP) for Large Data Centers
大規模データセンター向けのスケーラブルなアドレス解決プロトコル（SARP）
Abstract
概要
This document introduces the Scalable Address Resolution Protocol (SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.
このドキュメントでは、プロキシゲートウェイを使用して大規模なデータセンターネットワークを拡張するアーキテクチャであるScalable Address Resolution Protocol（SARP）を紹介します。 SARPは高速プロキシに基づいており、スイッチのフィルタリングデータベース（FDB）テーブルのサイズを大幅に削減し、1つのサブネット（またはVLAN）内のホストがさまざまな場所に広がる可能性のある環境で、ネットワーク要素に対するARPおよび近隣探索（ND）の影響を軽減します。 SARPは、さまざまな物理的な場所を移動できる多数の仮想マシン（VM）を持つ大規模なデータセンターを対象としています。
Independent Submissions Editor Note
Independent Submissions Editor Note
This is an Experimental document; that experiment will end two years after the RFC is published. At that point, the RFC authors will attempt to determine how widely SARP has been implemented and used.
これは実験的なドキュメントです。この実験は、RFCが公開されてから2年後に終了します。その時点で、RFCの作成者は、SARPがどの程度広く実装および使用されているかを判断しようとします。
IESG Note
IESG Note
The IESG notes that the problems described in RFC 6820 can already be addressed through the simple combination of existing standardized or other published techniques including Layer 2 VPN (RFC 4664), proxy ARP (RFC 925), proxy Neighbor Discovery (RFC 4389), IGMP and MLD snooping (RFC 4541), and ARP mediation for IP interworking of Layer 2 VPNs (RFC 6575).
IESGは、RFC 6820で説明されている問題は、レイヤー2 VPN（RFC 4664）、プロキシARP（RFC 925）、プロキシネイバーディスカバリー（RFC 4389）、IGMPを含む既存の標準化または他の公開された手法の単純な組み合わせですでに対処できることに注意していますMLDスヌーピング（RFC 4541）、およびレイヤー2 VPNのIPインターワーキングのためのARPメディエーション（RFC 6575）。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7586.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7586で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
1.1. SARP Motivation ............................................4
1.2. SARP Overview ..............................................7
1.3. SARP Deployment Options ....................................8
1.4. Comparison with Existing Solutions .........................9
2. Terms and Abbreviations Used in This Document ..................10
3. SARP: Theory of Operation ......................................11
3.1. Control Plane: ARP/ND .....................................11
3.1.1. ARP/NS Request for a Local VM ......................11
3.1.2. ARP/NS Request for a Remote VM .....................12
3.1.3. Gratuitous ARP and Unsolicited Neighbor
Advertisement (UNA) ................................13
3.2. Data Plane: Packet Transmission ...........................13
3.2.1. Local Packet Transmission ..........................13
3.2.2. Packet Transmission between Sites ..................13
3.3. VM Migration ..............................................14
3.3.1. VM Local Migration .................................14
3.3.2. VM Migration from One Site to Another ..............14
3.3.2.1. Impact on IP-to-MAC Mapping Cache
Table of Migrated VMs .....................16
3.4. Multicast and Broadcast ...................................17
3.5. Non-IP Packet .............................................17
3.6. High Availability and Load Balancing ......................17
3.7. SARP Interaction with Overlay Networks ....................18
4. Security Considerations ........................................18
5. References .....................................................19
5.1. Normative References ......................................19
5.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
This document describes a proxy gateway technique, called the Scalable Address Resolution Protocol (SARP), which reduces switches' Filtering Database (FDB) size and ARP/Neighbor Discovery impact on network elements in an environment where hosts within one subnet (or VLAN) can spread over various access domains in data centers.
このドキュメントでは、スケーラブルアドレス解決プロトコル（SARP）と呼ばれるプロキシゲートウェイテクニックについて説明します。データセンターのさまざまなアクセスドメインに広がります。
The main idea of SARP is to represent all VMs (or hosts) under each access domain by the MAC address of their corresponding access node (or aggregation node). For example (Figure 1), when host A in the west site needs to communicate with host B, which is on the same VLAN but connected to a different access domain (east site), SARP requires host A to use the MAC address of SARP proxy 2, rather than the address of host B. By doing so, switches in each domain do not need to maintain a list of MAC addresses for all the VMs (hosts) in different access domains; every switch only needs to be familiar with MAC addresses that reside in the current domain, and addresses of remote SARP proxy gateways. Therefore, the switches' FDB size is limited regardless of the number of access domains.
SARPの主な考え方は、各アクセスドメインの下のすべてのVM（またはホスト）を、対応するアクセスノード（または集約ノード）のMACアドレスで表すことです。たとえば（図1）、ウェストサイトのホストAが、同じVLAN上にあるが異なるアクセスドメイン（イーストサイト）に接続されているホストBと通信する必要がある場合、SARPはホストAにSARPのMACアドレスを使用するように要求しますホストBのアドレスではなくプロキシ2。そうすることで、各ドメインのスイッチは、異なるアクセスドメインのすべてのVM（ホスト）のMACアドレスのリストを維持する必要がなくなります。すべてのスイッチは、現在のドメインに存在するMACアドレスと、リモートSARPプロキシゲートウェイのアドレスに精通している必要があります。したがって、スイッチのFDBサイズは、アクセスドメインの数に関係なく制限されます。
+-------+ +-------+ _ __ +-------+ +-------+
| | | SARP | / \_/ \_ | SARP | | |
|host A |<===>| proxy |<=>\_ \<==>| proxy |<===>|host B |
| | | 1 | / _/ | 2 | | |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Figure 1: A Brief Overview of SARP
図1：SARPの概要
[RFC6820] discusses the impacts and scaling issues that arise in data center networks when subnets span across multiple Layer 2 / Layer 3 (L2/L3) boundary routers.
[RFC6820]では、サブネットが複数のレイヤー2 /レイヤー3（L2 / L3）境界ルーターにまたがる場合に、データセンターネットワークで発生する影響とスケーリングの問題について説明します。
Unfortunately, when the combined number of VMs (or hosts) in all those subnets is large, it can lead to an explosion of the size of the switches' MAC address table and a heavy impact on network elements.
残念ながら、これらすべてのサブネットのVM（またはホスト）の合計数が多い場合、スイッチのMACアドレステーブルのサイズが爆発的に増加し、ネットワーク要素に大きな影響を与える可能性があります。
There are four major issues associated with subnets spanning across multiple L2/L3 boundary router ports:
複数のL2 / L3境界ルーターポートにまたがるサブネットに関連する4つの主要な問題があります。
1) Explosion of the size of the intermediate switches' MAC address table (FDB).
1）中間スイッチのMACアドレステーブル（FDB）のサイズの爆発。
When hosts in a VLAN (or subnet) span across multiple access domains and each access domain has hosts belonging to different VLANs, each access switch has to enable multiple VLANs. Thus, those access switches are exposed to all MAC addresses across all VLANs.
VLAN（またはサブネット）内のホストが複数のアクセスドメインにまたがり、各アクセスドメインに異なるVLANに属するホストがある場合、各アクセススイッチは複数のVLANを有効にする必要があります。したがって、これらのアクセススイッチは、すべてのVLANにわたってすべてのMACアドレスに公開されます。
For example, for an access switch with 40 attached physical servers, where each server has 100 VMs, the access switch has 4,000 attached MAC addresses. If hosts/VMs can indeed be moved anywhere, the worst case for the Access Switch is when all those 4,000 VMs belong to different VLANs, i.e., the access switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this access switch's MAC address table potentially has 200 * 4,000 = 800,000 entries.
たとえば、40台の物理サーバーが接続されたアクセススイッチの場合、各サーバーには100個のVMがあり、アクセススイッチには4,000個のMACアドレスが接続されています。ホスト/ VMが実際にどこにでも移動できる場合、アクセススイッチの最悪のケースは、それらの4,000のVMすべてが異なるVLANに属している場合です。つまり、アクセススイッチで4000のVLANが有効になっている場合です。各VLANに200のホストがある場合、このアクセススイッチのMACアドレステーブルには、200 * 4,000 = 800,000のエントリが含まれる可能性があります。
It is important to note that the example above is relevant regardless of whether IPv4 or IPv6 is used.
上記の例は、IPv4とIPv6のどちらが使用されているかに関係なく、重要であることに注意してください。
The example illustrates a scenario that is worse than what today's L2/L3 gateway has to face. In today's environment, where each subnet is limited to a few access switches, the number of MAC addresses the gateway has to learn is of a significantly smaller scale.
この例は、今日のL2 / L3ゲートウェイが直面しなければならないシナリオよりも悪いシナリオを示しています。各サブネットがいくつかのアクセススイッチに制限されている今日の環境では、ゲートウェイが学習する必要のあるMACアドレスの数は非常に小規模です。
2) ARP/ND processing load impact on the L2/L3 boundary routers.
2）L2 / L3境界ルーターへのARP / ND処理負荷の影響。
All VMs periodically send NDs to their corresponding gateway nodes to get gateway nodes' MAC addresses. When the combined number of VMs across all the VLANs is large, processing the responses to the ND requests from those VMs can easily exhaust the gateway's CPU utilization.
すべてのVMは、対応するゲートウェイノードにNDを定期的に送信して、ゲートウェイノードのMACアドレスを取得します。すべてのVLANにわたるVMの合計数が多い場合、それらのVMからのND要求への応答を処理すると、ゲートウェイのCPU使用率を簡単に使い果たす可能性があります。
An L2/L3 boundary router could be hit with ARP/ND twice when the originating and destination stations are in different subnets attached to the same router and when those hosts do not communicate with external peers very frequently. The first hit is when the originating station in subnet 1 initiates an ARP/ND request to the L2/L3 boundary router. The second hit is when the L2/L3 boundary router initiates an ARP/ND request to the target in subnet 2 if the target is not in the router's ARP/ND cache.
発信ステーションと宛先ステーションが同じルーターに接続された異なるサブネットにあり、それらのホストが外部ピアと頻繁に通信しない場合、L2 / L3境界ルーターがARP / NDに2回ヒットする可能性があります。最初のヒットは、サブネット1の発信ステーションがL2 / L3境界ルーターへのARP / ND要求を開始したときです。 2番目のヒットは、ターゲットがルーターのARP / NDキャッシュにない場合に、L2 / L3境界ルーターがサブネット2のターゲットへのARP / ND要求を開始したときです。
3) In IPv4, every end station in a subnet receives ARP broadcast messages from all other end stations in the subnet. IPv6 ND has eliminated this issue by using multicast.
3）IPv4では、サブネット内のすべての端末が、サブネット内の他のすべての端末からARPブロードキャストメッセージを受信します。 IPv6 NDは、マルチキャストを使用することでこの問題を解消しました。
However, most devices support a limited number of multicast addresses, due to the scaling of multicast filtering. Once the number of multicast addresses exceeds the multicast filter limit, the multicast addresses have to be processed by the devices' CPUs (i.e., the slow path).
ただし、マルチキャストフィルタリングのスケーリングにより、ほとんどのデバイスは限られた数のマルチキャストアドレスをサポートします。マルチキャストアドレスの数がマルチキャストフィルターの制限を超えると、マルチキャストアドレスはデバイスのCPU（つまり、低速パス）によって処理される必要があります。
It is less of an issue in data centers without VM mobility, since each port is only dedicated to one (or a small number of) VLANs. Thus, the number of multicast addresses hitting each port is significantly lower.
各ポートは1つ（または少数）のVLAN専用であるので、VMモビリティのないデータセンターではそれほど問題になりません。したがって、各ポートに到達するマルチキャストアドレスの数は大幅に少なくなります。
4) The ARP/ND messages are flooded to many physical link segments that can reduce the bandwidth utilization for user traffic.
4）ARP / NDメッセージは多くの物理リンクセグメントにフラッディングされるため、ユーザートラフィックの帯域幅使用率を削減できます。
ARP/ND flooding is, in most cases, an insignificant issue in today's data center networks, as the majority of data center servers are shifting towards 1G or 10G Ethernet ports. The bandwidth used by ARP/ND, even when flooded to all physical links, becomes negligible compared to the link bandwidth. Furthermore, IGMP and Multicast Listener Discovery (MLD) snooping [RFC4541] can further reduce the ND multicast traffic to some physical link segments.
データセンターサーバーの大半が1Gまたは10Gイーサネットポートに移行しているため、ARP / NDフラッディングは、ほとんどの場合、今日のデータセンターネットワークでは重要な問題ではありません。 ARP / NDが使用する帯域幅は、すべての物理リンクにフラッディングされた場合でも、リンク帯域幅と比較して無視できる程度になります。さらに、IGMPおよびMulticast Listener Discovery（MLD）スヌーピング[RFC4541]は、一部の物理リンクセグメントへのNDマルチキャストトラフィックをさらに削減できます。
Statistics gathered by Merit Network [ARMDStats] have shown that the major impact of a large number of VMs in data centers is on the L2/L3 boundary routers, i.e., issue 2 above. An L2/L3 boundary router could be hit with ARP/ND twice when 1) the originating and destination stations are in different subnets attached to the same router, and 2) those hosts do not communicate with external peers often enough.
Merit Network [ARMDStats]によって収集された統計は、データセンター内の多数のVMの主な影響がL2 / L3境界ルーター、つまり上記の問題2にあることを示しています。 L2 / L3境界ルーターは、1）発信ステーションと宛先ステーションが同じルーターに接続された異なるサブネットにあり、2）これらのホストが外部ピアと十分に頻繁に通信しない場合、ARP / NDに2回ヒットする可能性があります。
Overlay approaches, e.g., [RFC7364], can hide addresses of hosts (VMs) in the core, but they do not prevent the MAC address table explosion problem (issue 1) unless the Network Virtualization Edge (NVE) is on a server.
[RFC7364]などのオーバーレイアプローチでは、コアのホスト（VM）のアドレスを非表示にできますが、ネットワーク仮想化エッジ（NVE）がサーバー上にない限り、MACアドレステーブルの爆発の問題（問題1）を防ぐことはできません。
The scaling practices documented in [RFC7342] can only reduce some ARP impact on L2/L3 boundary routers in some scenarios, but not all.
[RFC7342]で文書化されているスケーリングプラクティスは、一部のシナリオではL2 / L3境界ルーターへの一部のARP影響のみを削減できますが、すべてではありません。
In order to protect router CPUs from being overburdened by target resolution requests, some routers rate-limit the target MAC resolution requests to the router's CPU. When the rate limit is exceeded, the incoming data frames are dropped. In traditional data centers, this issue is less significant, since the number of hosts attached to one L2/L3 boundary router is limited by the number of physical ports of the switches/routers. When servers are virtualized to support 30+ VMs, the number of hosts under one router can grow by a factor of 30+. Furthermore, in traditional data center networks, each subnet is neatly bound to a limited number of server racks, i.e., switches only need to be familiar with MAC addresses of hosts that reside in this small number of subnets. In contemporary data center networks, as subnets are spread across many server racks, switches are exposed to VLAN/MAC addresses of many subnets, greatly increasing the size of switches' FDB tables.
ルーターのCPUがターゲット解決要求によって過負荷にならないように保護するために、一部のルーターは、ターゲットMAC解決要求をルーターのCPUにレート制限します。レート制限を超えると、着信データフレームはドロップされます。従来のデータセンターでは、1つのL2 / L3境界ルーターに接続されているホストの数はスイッチ/ルーターの物理ポートの数によって制限されるため、この問題はそれほど重要ではありません。サーバーが仮想化されて30以上のVMをサポートする場合、1台のルーターの下にあるホストの数は30以上に増える可能性があります。さらに、従来のデータセンターネットワークでは、各サブネットは限られた数のサーバーラックにきちんとバインドされています。つまり、スイッチは、この少数のサブネットに存在するホストのMACアドレスに精通している必要があるだけです。現在のデータセンターネットワークでは、サブネットが多くのサーバーラックに分散しているため、スイッチは多くのサブネットのVLAN / MACアドレスに公開され、スイッチのFDBテーブルのサイズが大幅に増加しています。
The solution proposed in this document can eliminate or reduce the likelihood of inter-subnet data frames being dropped and reduce the number of host MAC addresses that intermediate switches are exposed to, thus reducing switches' FDB table sizes.
このドキュメントで提案されているソリューションは、サブネット間データフレームがドロップされる可能性を排除または削減し、中間スイッチが公開されるホストMACアドレスの数を削減し、スイッチのFDBテーブルサイズを削減します。
The SARP approach uses proxy gateways to address the problems discussed above.
SARPアプローチでは、プロキシゲートウェイを使用して、上記の問題に対処します。
Note: The guidelines to proxy developers [RFC4389] have been carefully considered for SARP. Section 3.3 discusses how SARP works when VMs are moved from one segment to another.
注：代理開発者向けのガイドライン[RFC4389]は、SARPについて慎重に検討されています。セクション3.3では、VMが1つのセグメントから別のセグメントに移動されたときにSARPがどのように機能するかについて説明します。
In order to enable VMs to be moved across servers while ensuring their MAC/IP addresses remain unchanged, the Layer 2 network (e.g., VLAN) that interconnects those VMs may spread across different server racks, different rows of server racks, or even different data center sites.
MAC / IPアドレスを変更せずにサーバー間でVMを移動できるようにするために、それらのVMを相互接続するレイヤー2ネットワーク（VLANなど）は、異なるサーバーラック、異なるサーバーラックの列、または異なるデータにまで広がる場合があります。センターサイト。
A multisite data center network is comprised of two main building blocks: an interconnecting segment and an access segment. While the access network is, in most cases, a Layer 2 network, the interconnecting segment is not necessarily a Layer 2 network.
マルチサイトデータセンターネットワークは、相互接続セグメントとアクセスセグメントという2つの主要な構成要素で構成されています。アクセスネットワークはほとんどの場合レイヤ2ネットワークですが、相互接続セグメントは必ずしもレイヤ2ネットワークである必要はありません。
The SARP proxies are located at the boundaries where the access segment connects to its interconnecting segment. The boundary node can be a hypervisor virtual switch, a top-of-rack switch, an aggregation switch (or end-of-row switch), or a data center core switch. Figure 2 depicts an example of two remote data centers that are managed as a single, flat Layer 2 domain. SARP proxies are implemented at the edge devices connecting the data center to the transport network. SARP significantly reduces the ARP/ND transmissions over the interconnecting network.
SARPプロキシは、アクセスセグメントが相互接続するセグメントに接続する境界にあります。境界ノードは、ハイパーバイザー仮想スイッチ、トップオブラックスイッチ、アグリゲーションスイッチ（またはエンドオブロースイッチ）、またはデータセンターコアスイッチにすることができます。図2は、単一のフラットなレイヤー2ドメインとして管理される2つのリモートデータセンターの例を示しています。 SARPプロキシは、データセンターをトランスポートネットワークに接続するエッジデバイスに実装されます。 SARPは、相互接続ネットワークを介したARP / ND送信を大幅に削減します。
*-------------------*
| |
+-------| Interconnecting |-------+
| | network | |
| *-------------------* |
| |
*-----------------* *----------------*
| SARP Proxies | | SARP Proxies |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
|Access | |Access | |Access | |Access |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
|
*--------*
|Virtual |
|Machine |
*--------*
(West Site) (East Site)
（西サイト）（東サイト）
Figure 2: SARP: Network Architecture Example
図2：SARP：ネットワークアーキテクチャの例
SARP deployment is tightly coupled with the data center architecture. SARP proxies are located at the point where the Layer 2 infrastructure connects to its Layer 2 cloud using overlay networks. SARP proxies can be located at the data center edge (as Figure 2 depicts), data center core, or data center aggregation (denoted by "Agg" in the figure). SARP can also be implemented by the hypervisor (as Figure 3 depicts).
SARPの導入は、データセンターのアーキテクチャと密接に結び付いています。 SARPプロキシは、レイヤ2インフラストラクチャがオーバーレイネットワークを使用してレイヤ2クラウドに接続するポイントに配置されています。 SARPプロキシは、データセンターエッジ（図2に示す）、データセンターコア、またはデータセンターアグリゲーション（図では「Agg」と表記）に配置できます。 SARPはハイパーバイザーでも実装できます（図3を参照）。
To simplify the description, we will focus on data centers that are managed as a single, flat Layer 2 network, where SARP proxies are located at the boundary where the data center connects to the transport network (as Figure 2 depicts).
説明を簡単にするために、データセンターがトランスポートネットワークに接続する境界にSARPプロキシが配置されている単一のフラットレイヤー2ネットワークとして管理されるデータセンターに焦点を当てます（図2に示すように）。
*-------------------*
| |
+-------| TRANSPORT |-------+
| | | |
| *-------------------* |
| |
*-----------------* *----------------*
| Edge Device | | Edge Device |
*-----------------* *----------------*
| |
*-----------------* *----------------*
| Core | | Core |
*-----------------* *----------------*
| | | |
*-------* *-------* *-------* *-------*
| Agg | | Agg | | Agg | | Agg |
*-------* *-------* *-------* *-------*
|
*----------*
|Hypervisor|
*----------*
(West Site) (East Site)
（西サイト）（東サイト）
Figure 3: SARP Deployment Options
図3：SARP展開オプション
The IETF has developed several mechanisms to address issues associated with Layer 2 networks over multiple geographic locations, for example, Layer 2 VPN [RFC4664], proxy ARP [RFC925] [ProxyARP], proxy Neighbor Discovery [RFC4389], IGMP and MLD snooping [RFC4541], and ARP mediation for IP interworking of Layer 2 VPNs [RFC6575].
IETFは、レイヤー2 VPN [RFC4664]、プロキシARP [RFC925] [ProxyARP]、プロキシネイバーディスカバリー[RFC4389]、IGMPおよびMLDスヌーピングなど、複数の地理的位置にわたるレイヤー2ネットワークに関連する問題に対処するためのいくつかのメカニズムを開発しましたRFC4541]、およびレイヤ2 VPNのIPインターワーキング用のARPメディエーション[RFC6575]。
However, all those solutions work well when hosts within one subnet are placed together under one access domain, so that the intermediate switches in each access domain are only exposed to host addresses from a limited number of subnets. SARP is to provide a solution when hosts within one subnet are spread across multiple access domains, and each access domain has hosts from many subnets. Under this environment, the intermediate switches in each access domain are exposed to combined hosts of all the subnets that are enabled by the access domain.
ただし、これらのソリューションはすべて、1つのサブネット内のホストが1つのアクセスドメインの下に配置されている場合にうまく機能するため、各アクセスドメインの中間スイッチは、限られた数のサブネットからのホストアドレスにのみ公開されます。 SARPは、1つのサブネット内のホストが複数のアクセスドメインに分散しており、各アクセスドメインに多数のサブネットのホストがある場合のソリューションを提供します。この環境では、各アクセスドメインの中間スイッチは、アクセスドメインによって有効化されたすべてのサブネットの結合されたホストに公開されます。
ARP: Address Resolution Protocol [ARP]
ARP：アドレス解決プロトコル[ARP]
FDB: Filtering Database, which is used for Layer 2 switches [802.1Q]. Layer 2 switches flood data frames when the Destination Address (DA) is not in the FDB, whereas routers drop data frames when the DA is not in the Forwarding Information Base (FIB). That is why the FDB is used for Layer 2 switches.
FDB：レイヤ2スイッチ[802.1Q]に使用されるフィルタリングデータベース。レイヤー2スイッチは、宛先アドレス（DA）がFDBにない場合にデータフレームをフラッディングしますが、ルーターはDAが転送情報ベース（FIB）にない場合にデータフレームをドロップします。そのため、FDBはレイヤ2スイッチに使用されます。
FIB: Forwarding Information Base
FIB：転送情報ベース
Hypervisor: a software layer that creates and runs virtual machines on a server
ハイパーバイザー：サーバー上で仮想マシンを作成して実行するソフトウェアレイヤー
IP-D: IP address of the destination virtual machine
IP-D：ターゲット仮想マシンのIPアドレス
IP-S: IP address of the source virtual machine
IP-S：ソース仮想マシンのIPアドレス
MAC-D: MAC address of the destination virtual machine
MAC-D：ターゲット仮想マシンのMACアドレス
MAC-E: MAC address of the East Proxy SARP Device
MAC-E：East Proxy SARPデバイスのMACアドレス
MAC-S: MAC address of the source virtual machine
MAC-S：ソース仮想マシンのMACアドレス
NA: IPv6 ND's Neighbor Advertisement
NA：IPv6 NDのネイバーアドバタイズメント
ND: IPv6 Neighbor Discovery Protocol [ND]. In this document, ND also refers to Neighbor Solicitation, Neighbor Advertisement, and Unsolicited Neighbor Advertisement messages defined by RFC 4861.
ND：IPv6近隣探索プロトコル[ND]。このドキュメントでは、NDは、RFC 4861で定義されている近隣要請、近隣アドバタイズ、および非要請近隣アドバタイズメッセージも指します。
NS: IPv6 ND's Neighbor Solicitation
NS：IPv6 NDの近隣要請
SARP Proxy: The components that participate in SARP
SARPプロキシ：SARPに参加するコンポーネント
UNA: IPv6 ND's Unsolicited Neighbor Advertisement [ND]
UNA：IPv6 NDの一方的な近隣広告[ND]
VM: Virtual Machine
VM：仮想マシン
This section describes the ARP/ND procedure scenarios. The first scenario addresses a case where both the source and destination VMs reside in the same access segment. In the second scenario, the source VM is in the local access segment and the destination VM is located at the remote access segment.
このセクションでは、ARP / ND手順のシナリオについて説明します。最初のシナリオは、ソースVMと宛先VMの両方が同じアクセスセグメントに存在する場合に対処します。 2番目のシナリオでは、ソースVMはローカルアクセスセグメントにあり、宛先VMはリモートアクセスセグメントにあります。
In all scenarios, the VMs (source and destination) share the same L2 broadcast domain.
すべてのシナリオで、VM（ソースと宛先）は同じL2ブロードキャストドメインを共有します。
When source and destination VMs are located at the same access segment (Figure 4), the address resolution process is as described in [ARP] and [ND]; host A sends an ARP request or an IPv6 Neighbor Solicitation (NS) to learn the IP-to-MAC mapping of host B, and it receives a reply from host B with the IP-D to MAC-D mapping.
ソースVMと宛先VMが同じアクセスセグメントにある場合（図4）、アドレス解決プロセスは[ARP]と[ND]で説明されています。ホストAは、ARP要求またはIPv6近隣要請（NS）を送信してホストBのIPからMACへのマッピングを学習し、IP-DからMAC-DへのマッピングでホストBから応答を受信します。
+-------+ _ __ +-------+ _ __
|host A | / \_/ \_ | SARP | / \_/ \_
| IP-S |<--->\_access \<==>| proxy |<===>\_interc.\
| MAC-S | /network_/ | 1 | /network_/
+-------+ +->\__ _/ +-------+ \__ _/
| \_/ \_/
+-------+ |
|host B |<-+
| IP-D |
| MAC-D |
+-------+
<--------------West Site------------>
Figure 4: SARP: Two Hosts in the Same Access Segment
図4：SARP：同じアクセスセグメント内の2つのホスト
When the source and destination VMs are located at different access segments, the address resolution process is as follows.
ソースVMと宛先VMが異なるアクセスセグメントにある場合、アドレス解決プロセスは次のようになります。
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host B |
| IP-S |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-S | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Figure 5: SARP: Two Hosts That Reside in Different Segments
図5：SARP：異なるセグメントに存在する2つのホスト
In the example illustrated in Figure 5, the source VM is located at the west access segment and the destination VM is located at the east access segment.
図5に示す例では、ソースVMはウェストアクセスセグメントにあり、宛先VMはイーストアクセスセグメントにあります。
When host A sends an ARP/NS request to find out the IP-to-MAC mapping of host B:
ホストAがホストBのIPからMACへのマッピングを見つけるためにARP / NS要求を送信すると、次のようになります。
1. If SARP proxy 1 does not have IP-D in its ARP cache, the ARP/NS request is propagated to all access segments that might have VMs in the same virtual network as the originating VM, including the east access segment.
1. SARPプロキシ1のARPキャッシュにIP-Dがない場合、ARP / NS要求は、イーストアクセスセグメントを含む、元のVMと同じ仮想ネットワーク内にVMを持つ可能性があるすべてのアクセスセグメントに伝播されます。
2. As SARP proxy 1 forwards the ARP/NS message, it replaces the source MAC address, MAC-S, with its own MAC address, MAC-W. Thus, all switches that reside in the interconnecting segment are not exposed to MAC-S.
2. SARPプロキシ1がARP / NSメッセージを転送すると、送信元MACアドレスMAC-Sが独自のMACアドレスMAC-Wに置き換えられます。したがって、相互接続セグメントにあるすべてのスイッチはMAC-Sに公開されません。
3. The ARP/NS request reaches SARP proxy 2.
3. ARP / NS要求がSARPプロキシ2に到達します。
4. If SARP proxy 2 does not have IP-D in its ARP cache, the ARP/NS request is forwarded to the east access network. Host B responds with an ARP reply (IPv4) or a Neighbor Advertisement (IPv6) to the request with MAC-D.
4. SARPプロキシ2のARPキャッシュにIP-Dがない場合、ARP / NS要求はイーストアクセスネットワークに転送されます。ホストBは、ARP応答（IPv4）またはネイバーアドバタイズ（IPv6）でMAC-Dの要求に応答します。
5. When the response message reaches SARP proxy 2, it replaces MAC-D with MAC-E; thus, the response reaches SARP proxy 1 with MAC-E.
5. 応答メッセージがSARPプロキシ2に到達すると、MAC-DがMAC-Eに置き換えられます。したがって、応答はMAC-Eを使用してSARPプロキシ1に到達します。
6. As SARP proxy 1 forwards the response to host A, it replaces the destination address from MAC-W to MAC-S.
6. SARPプロキシ1が応答をホストAに転送すると、宛先アドレスがMAC-WからMAC-Sに置き換えられます。
SARP Proxy ARP/ND Cache
SARPプロキシARP / NDキャッシュ
SARP proxies maintain a cache of the IP-to-MAC mapping. This cache is based on ARP/ND messages that are sent by hosts and traverse the SARP proxies.
SARPプロキシは、IP-to-MACマッピングのキャッシュを維持します。このキャッシュは、ホストによって送信され、SARPプロキシを通過するARP / NDメッセージに基づいています。
In steps 1 and 4 above, if the SARP proxy has IP-D in its ARP cache, it responds with MAC-E, without forwarding the ARP/NS request.
上記のステップ1と4で、SARPプロキシのARPキャッシュにIP-Dがある場合、ARP / NS要求を転送せずにMAC-Eで応答します。
This caching approach significantly reduces the volume of the ARP/ND transmission over the network and reduces the round-trip time of ARP/ND requests.
このキャッシングアプローチは、ネットワークを介したARP / ND送信の量を大幅に減らし、ARP / ND要求の往復時間を減らします。
When the west SARP proxy caches the IP-to-MAC mapping entries for remote VMs, the expiration timers should be set to relatively low values to prevent stale entries due to remote VMs being moved or deleted. In environments where VMs move more frequently, it is not recommended for SARP proxies to cache the IP-to-MAC mapping entries of remote VMs.
ウェストSARPプロキシがリモートVMのIP-to-MACマッピングエントリをキャッシュする場合、リモートVMが移動または削除されることによる古いエントリを防ぐために、有効期限タイマーを比較的低い値に設定する必要があります。 VMがより頻繁に移動する環境では、SARPプロキシがリモートVMのIPからMACへのマッピングエントリをキャッシュすることはお勧めしません。
Hosts (or VMs) send out Gratuitous ARP (IPv4) [TcpIp] and Unsolicited Neighbor Advertisement (UNA) (IPv6) messages to allow other nodes to refresh IP-to-MAC entries in their caches.
ホスト（またはVM）はGratuitous ARP（IPv4）[TcpIp]およびUnsolicited Neighbor Advertisement（UNA）（IPv6）メッセージを送信して、他のノードがキャッシュ内のIP-to-MACエントリを更新できるようにします。
The local SARP proxy processes the Gratuitous ARP or UNA message in the same way as the ARP reply or IPv6 NA, i.e., replaces the MAC addresses in the same manner.
ローカルSARPプロキシは、ARP応答またはIPv6 NAと同じ方法でGratuitous ARPまたはUNAメッセージを処理します。つまり、同じ方法でMACアドレスを置き換えます。
When a VM transmits packets to a destination VM that is located at the same site (Figure 4), the data plane is unaffected by SARP; packets are sent from (IP-S, MAC-S) to (IP-D, MAC-D).
VMが同じサイトにある宛先VMにパケットを送信する場合（図4）、データプレーンはSARPの影響を受けません。パケットは（IP-S、MAC-S）から（IP-D、MAC-D）に送信されます。
Packets that are sent between sites (Figure 5) traverse the SARP proxy of both sites.
サイト間で送信されるパケット（図5）は、両方のサイトのSARPプロキシを通過します。
A packet sent from host A to host B undergoes the following procedure:
ホストAからホストBに送信されるパケットは、次の手順に従います。
1. Host A sends a packet to IP-D, and based on its ARP table, it uses the MAC addresses {MAC-E, MAC-S}.
1. ホストAはIP-Dにパケットを送信し、そのARPテーブルに基づいて、MACアドレス{MAC-E、MAC-S}を使用します。
2. SARP proxy 1 receives the packet and replaces the source MAC address, such that the packet includes {MAC-E, MAC-W}.
2. SARPプロキシ1はパケットを受信し、送信元MACアドレスを置き換えて、パケットに{MAC-E、MAC-W}が含まれるようにします。
3. SARP proxy 2 receives the packet and replaces the destination MAC address, and the packet is sent to host B with {MAC-D, MAC-W}.
3. SARPプロキシ2はパケットを受信して宛先MACアドレスを置き換え、パケットは{MAC-D、MAC-W}を使用してホストBに送信されます。
SARP proxy 1 replaces the source MAC address with its own, since switches in the interconnecting segment are only familiar with SARP proxy MAC addresses and are not familiar with host addresses.
相互接続セグメント内のスイッチはSARPプロキシMACアドレスにのみ精通しており、ホストアドレスには精通していないため、SARPプロキシ1は送信元MACアドレスを独自のMACアドレスに置き換えます。
Note: it is a common security practice in data center networks to use access lists, allowing each VM to communicate only with a list of authorized peer VMs. In most cases, such access control lists are based on IP addresses and, hence, are not affected by the MAC address replacement in SARP.
注：データセンターネットワークでは、アクセスリストを使用して各VMが許可されたピアVMのリストとのみ通信できるようにするのが一般的なセキュリティ対策です。ほとんどの場合、このようなアクセス制御リストはIPアドレスに基づいているため、SARPでのMACアドレス置換の影響を受けません。
When a VM migrates locally within its access segment, SARP does not require any special behavior. VM migration is resolved entirely by the Layer 2 mechanisms.
VMがそのアクセスセグメント内でローカルに移行する場合、SARPは特別な動作を必要としません。 VMの移行は、レイヤー2メカニズムによって完全に解決されます。
This section focuses on a scenario where a VM migrates from the west site to the east site while maintaining its MAC and IP addresses.
このセクションでは、VMがそのMACアドレスとIPアドレスを維持しながらウェストサイトからイーストサイトに移行するシナリオに焦点を当てます。
VM migration might affect networking elements based on their respective locations:
VMの移行は、それぞれの場所に基づいてネットワーク要素に影響を与える可能性があります。
- origin site (west site)
- 起点サイト（西サイト）
- destination site (east site)
- 宛先サイト（東サイト）
- other sites
- 他のサイト
+-------+ +-------+ _ __ +-------+ +-------+
|host A | | SARP | / \_/ \_ | SARP | |host A |
| IP-D |<===>|proxy 1|<=>\_ \<==>|proxy 2|<===>| IP-D |
| MAC-D | | MAC-W | / _/ | MAC-E | | MAC-D |
+-------+ +-------+ \__ _/ +-------+ +-------+
\_/
<------West Site------> <------East Site------>
Origin Site Destination Site
Figure 6: SARP: Host A Migrates from West Site to East Site
図6：SARP：ホストAが西サイトから東サイトに移行する
Origin Site
起点サイト
The origin site is the site where the VM resides before the migration (west site).
起点サイトは、移行前にVMが存在するサイト（西サイト）です。
Before the VM (IP=IP-D, MAC=MAC-D) is moved, all VMs at the west site that have an ARP entry of IP-D in their ARP table have the IP-D -> MAC-D mapping. VMs on other access segments have an ARP entry of IP-D -> MAC-W mapping where MAC-W is the MAC address of the SARP proxy on the west access segment.
VM（IP = IP-D、MAC = MAC-D）を移動する前に、ARPテーブルにIP-DのARPエントリがあるウェストサイトのすべてのVMには、IP-D-> MAC-Dマッピングがあります。他のアクセスセグメント上のVMには、IP-D-> MAC-WマッピングのARPエントリがあります。MAC-Wは、ウェストアクセスセグメント上のSARPプロキシのMACアドレスです。
After the VM (IP-D) in the west site moves to the east site, if a Gratuitous ARP (IPv4) or an Unsolicited Neighbor Advertisement (IPv6) message is sent out by the destination hypervisor on behalf of the VM (IP-D), then the IP-to-MAC mapping cache of the VMs in all access segments is updated by IP-D -> MAC-E, where MAC-E is the MAC address of the SARP proxy on the east site. If no Gratuitous ARP or UNA message is sent out by the destination hypervisor, the IP-to-MAC cache on the VMs in the west site (and other sites) is eventually aged out.
ウェストサイトのVM（IP-D）がイーストサイトに移動した後、Gratuitous ARP（IPv4）またはUnsolicited Neighbor Advertisement（IPv6）メッセージがVM（IP-D ）、その後、すべてのアクセスセグメント内のVMのIPからMACへのマッピングキャッシュがIP-D-> MAC-Eによって更新されます。ここで、MAC-EはイーストサイトのSARPプロキシのMACアドレスです。宛先ハイパーバイザーによってGratuitous ARPまたはUNAメッセージが送信されない場合、ウェストサイト（および他のサイト）のVM上のIP-to-MACキャッシュは、最終的に期限切れになります。
Until the IP-to-MAC mapping cache tables are updated, the source VMs from the west site continue sending packets locally to MAC-D, and switches at the west site are still configured with the old location of MAC-D. This transient condition can be resolved by having the VM manager send out a fake Gratuitous ARP or UNA message on behalf of the destination Hypervisor. Another alternative is to have a shorter aging timer configured for the IP-to-MAC cache table.
IP-to-MACマッピングキャッシュテーブルが更新されるまで、ウェストサイトのソースVMはローカルでMAC-Dにパケットを送信し続け、ウェストサイトのスイッチは引き続きMAC-Dの古い場所で構成されます。この一時的な状態は、VMマネージャーに宛先ハイパーバイザーに代わって偽のGratuitous ARPまたはUNAメッセージを送信させることで解決できます。別の方法として、IP-to-MACキャッシュテーブルに設定するエージングタイマーを短くする方法があります。
Destination Site
宛先サイト
The destination site is the site to which the VM migrated, i.e., the east site in Figure 6.
宛先サイトは、VMの移行先のサイト、つまり図6のイーストサイトです。
Before any Gratuitous ARP or UNA messages are sent out by the destination hypervisor, all VMs at the east site (and all other sites) might have an IP-D -> MAC-W mapping in their IP-to-MAC mapping cache. The IP-to-MAC mapping cache is updated by aging or by a Gratuitous ARP or UNA message sent by the destination hypervisor. Until the IP-to-MAC mapping caches are updated, VMs from the east site continue to send packets to MAC-W. This can be resolved by having the VM manager send out a fake Gratuitous ARP or UNA message immediately after the VM migration or by redirecting the packets from the SARP proxy of the east site back to the migrated VM by updating the destination MAC of the packets to MAC-D.
Gratuitous ARPまたはUNAメッセージが宛先ハイパーバイザーによって送信される前に、イーストサイト（および他のすべてのサイト）のすべてのVMは、IP-to-MACマッピングキャッシュにIP-D-> MAC-Wマッピングを持っている可能性があります。 IP-to-MACマッピングキャッシュは、エージング、または宛先ハイパーバイザーによって送信されたGratuitous ARPまたはUNAメッセージによって更新されます。 IP-to-MACマッピングキャッシュが更新されるまで、イーストサイトのVMは引き続きMAC-Wにパケットを送信します。これは、VMの移行直後にVMマネージャーに偽のGratuitous ARPまたはUNAメッセージを送信させるか、またはパケットの宛先MACを更新して、イーストサイトのSARPプロキシから移行したVMにパケットをリダイレクトすることで解決できます。 MAC-D。
Other Sites
他のサイト
All VMs at the other sites that have an ARP entry of IP-D in their ARP table have the IP-D -> MAC-W mapping. The ARP mapping is updated by aging or by a Gratuitous ARP message sent by the destination hypervisor of the migrated VM and modified by the SARP proxy of the east site to an IP-D -> MAC-E mapping. Until ARP tables are updated, VMs from other sites continue sending packets to MAC-W.
ARPテーブルにIP-DのARPエントリがある他のサイトのすべてのVMには、IP-D-> MAC-Wマッピングがあります。 ARPマッピングは、エージングまたは移行されたVMの宛先ハイパーバイザーによって送信されたGratuitous ARPメッセージによって更新され、イーストサイトのSARPプロキシによってIP-D-> MAC-Eマッピングに変更されます。 ARPテーブルが更新されるまで、他のサイトのVMはMAC-Wにパケットを送信し続けます。
When a VM (IP-D) is moved from one site to another, its IP-to-MAC mapping entries for VMs located at other sites (i.e., neither the east site nor the west site) are still valid, even though most guest OSs (or VMs) will refresh their IP-to-MAC cache after migration.
VM（IP-D）があるサイトから別のサイトに移動されても、他のサイト（つまり、イーストサイトでもウェストサイトでもない）にあるVMのIP-to-MACマッピングエントリは、ほとんどのゲストがOS（またはVM）は、移行後にIP-to-MACキャッシュを更新します。
The migrated VM's IP-to-MAC mapping entries for VMs located at the east site, if not refreshed after migration, can be kept with no change until the ARP aging time, as these entries are mapped to MAC-E. All traffic originated from the migrated VM in its new location to VMs located at the east site traverses the SARP proxy of the east site. That SARP proxy can redirect the traffic back to the corresponding destinations on the east site. Furthermore, an ARP/UNA message sent by the SARP proxy of the east site or by the VMs on the east site can refresh the corresponding entries in the migrated VM's IP-to-MAC cache.
移行されたVMのイーストサイトにあるVMのIPからMACへのマッピングエントリは、移行後に更新されない場合、これらのエントリがMAC-Eにマップされるため、ARPエージングタイムまで変更なしで保持できます。新しい場所にある移行されたVMから発信され、イーストサイトにあるVMに向かうすべてのトラフィックは、イーストサイトのSARPプロキシを通過します。そのSARPプロキシは、トラフィックをイーストサイトの対応する宛先にリダイレクトして戻すことができます。さらに、イーストサイトのSARPプロキシまたはイーストサイトのVMによって送信されたARP / UNAメッセージは、移行されたVMのIP-to-MACキャッシュ内の対応するエントリを更新できます。
The migrated VM's ARP entries for VMs located at the west site remain unchanged until either the ARP entries age out or new data frames are received from the remote sites. Since all MAC addresses of the VMs located at the west site are unknown at the east site, all unknown traffic from the VM is intercepted by the SARP proxy of the east site and forwarded to the SARP proxy of the west site (during the transient period before the ARP entries age out). This transient behavior is avoided if the SARP proxy has the destination IP address in its ARP cache, and, upon receiving a packet with an unknown destination MAC address, it could send a Gratuitous ARP or UNA message to the migrated VM.
移行されたVMのウェストサイトにあるVMのARPエントリは、ARPエントリが期限切れになるか、リモートサイトから新しいデータフレームを受信するまで変更されません。ウェストサイトにあるVMのすべてのMACアドレスはイーストサイトでは不明であるため、VMからのすべての不明なトラフィックはイーストサイトのSARPプロキシによってインターセプトされ、ウェストサイトのSARPプロキシに転送されます（一時的な期間中） ARPエントリが期限切れになる前に）。この一時的な動作は、SARPプロキシのARPキャッシュに宛先IPアドレスがあり、不明な宛先MACアドレスを持つパケットを受信すると、移行されたVMにGratuitous ARPまたはUNAメッセージを送信する場合に回避されます。
Note that overlay networks providing Layer 2 network virtualization services configure their edge-device MAC aging timers to be greater than the ARP request interval.
レイヤ2ネットワーク仮想化サービスを提供するオーバーレイネットワークは、エッジデバイスのMACエージングタイマーがARP要求間隔よりも大きくなるように設定することに注意してください。
Multicast and broadcast traffic is forwarded by SARP proxies as follows:
マルチキャストおよびブロードキャストトラフィックは、次のようにSARPプロキシによって転送されます。
o SARP proxies modify the source MAC address of multicast and broadcast packets as described in Section 3.2.
o SARPプロキシは、セクション3.2で説明されているように、マルチキャストおよびブロードキャストパケットの送信元MACアドレスを変更します。
o SARP proxies do not modify the destination MAC address of multicast and broadcast packets.
o SARPプロキシは、マルチキャストおよびブロードキャストパケットの宛先MACアドレスを変更しません。
The L2/L3 boundary routers in the current document are capable of forwarding non-IP IEEE 802.1 Ethernet frames (Layer 2) without changing the MAC headers. When subnets span across multiple ports of those routers, they are still under the category of a single link, or a multi-access link model recommended by [RFC4903]. They differ from the "multi-link" subnets described in [MultLinkSub] and [RFC4903], which refer to a different physical media with the same prefix connected to a router, where the Layer 2 frames cannot be natively forwarded without changing the headers.
現在のドキュメントのL2 / L3境界ルーターは、MACヘッダーを変更せずに非IP IEEE 802.1イーサネットフレーム（レイヤー2）を転送できます。サブネットがこれらのルーターの複数のポートにまたがる場合、それらは依然として単一のリンク、または[RFC4903]が推奨するマルチアクセスリンクモデルのカテゴリに属しています。これらは、[MultLinkSub]と[RFC4903]で説明されている「マルチリンク」サブネットとは異なります。これらのサブネットは、同じプレフィックスがルーターに接続されている異なる物理メディアを指し、ヘッダーを変更しないとレイヤー2フレームをネイティブに転送できません。
The SARP proxy is located at the boundary where the local Layer 2 infrastructure connects to the interconnecting network. All traffic from the local site to the remote sites traverses the SARP proxy. The SARP proxy is subject to high-availability and bandwidth requirements.
SARPプロキシは、ローカルのレイヤ2インフラストラクチャが相互接続するネットワークに接続する境界にあります。ローカルサイトからリモートサイトへのすべてのトラフィックは、SARPプロキシを通過します。 SARPプロキシは、高可用性と帯域幅の要件の影響を受けます。
The SARP architecture supports multiple SARP proxies connecting a single site to the transport network. In the SARP architecture, all proxies can be active and can back up one another. The SARP architecture is robust and allows network administrators to allocate proxies according to bandwidth and high-availability requirements.
SARPアーキテクチャは、単一のサイトをトランスポートネットワークに接続する複数のSARPプロキシをサポートしています。 SARPアーキテクチャでは、すべてのプロキシをアクティブにして、相互にバックアップできます。 SARPアーキテクチャは堅牢で、ネットワーク管理者は帯域幅と高可用性の要件に従ってプロキシを割り当てることができます。
Traffic is segregated between SARP proxies by using VLANs. An SARP proxy is the Master SARP proxy of a set of VLANs and the Backup SARP proxy of another set of VLANs.
トラフィックは、VLANを使用してSARPプロキシ間で分離されます。 SARPプロキシは、VLANのセットのマスターSARPプロキシであり、別のVLANのセットのバックアップSARPプロキシです。
For example, assume the SARP proxies of the west site are SARP proxy 1 and SARP proxy 2. The west site supports VLAN 1 and VLAN 2, while SARP proxy 1 is the Master SARP proxy of VLAN 1 and the Backup SARP proxy of VLAN 2, and SARP proxy 2 is the Master SARP proxy of VLAN 2 and the Backup SARP proxy of VLAN 1. Both proxies are members of VLAN 1 and VLAN 2.
たとえば、ウェストサイトのSARPプロキシがSARPプロキシ1とSARPプロキシ2であると想定します。ウェストサイトはVLAN 1とVLAN 2をサポートし、SARPプロキシ1はVLAN 1のマスターSARPプロキシであり、VLAN 2のバックアップSARPプロキシです。 、そしてSARPプロキシ2はVLAN 2のマスターSARPプロキシであり、VLAN 1のバックアップSARPプロキシです。両方のプロキシはVLAN 1とVLAN 2のメンバーです。
The Master SARP proxy updates its Backup SARP proxy with all the ARP reply messages. The Backup SARP proxy maintains a backup database to all the VLANs that it is the Backup SARP proxy of.
マスターSARPプロキシは、すべてのARP応答メッセージでバックアップSARPプロキシを更新します。バックアップSARPプロキシは、バックアップSARPプロキシであるすべてのVLANへのバックアップデータベースを維持します。
The Master and the Backup SARP proxies maintain a keepalive mechanism. In case of a failure, the Backup SARP proxy becomes the Master SARP proxy. The failure decision is per VLAN. When the Master and the Backup SARP proxies switch over, the Backup SARP proxy can use the MAC address of the Master SARP proxy. The Backup SARP proxy sends locally a Gratuitous ARP message with the MAC address of the Master SARP proxy to update the forwarding tables on the local switches. The Backup SARP proxy also updates the remote SARP proxies on the change.
マスターおよびバックアップSARPプロキシは、キープアライブメカニズムを維持します。障害が発生した場合、バックアップSARPプロキシがマスターSARPプロキシになります。障害の決定はVLANごとです。マスターとバックアップSARPプロキシが切り替わると、バックアップSARPプロキシはマスターSARPプロキシのMACアドレスを使用できます。バックアップSARPプロキシは、ローカルSAの転送テーブルを更新するために、マスターSARPプロキシのMACアドレスを含むGratuitous ARPメッセージをローカルに送信します。バックアップSARPプロキシは、変更時にリモートSARPプロキシも更新します。
SARP can be used over overlay networks, providing L2 network virtualization (such as IP, Virtual Private LAN Service (VPLS), Transparent Interconnection of Lots of Links (TRILL), Overlay Transport Virtualization (OTV), Network Virtualization using GRE (NVGRE), and Virtual eXtensible Local Area Network (VXLAN)). The mapping of SARP to overlay networks is straightforward; the VM does the mapping of the destination IP to the SARP proxy MAC address. The mapping of the proxy MAC to its correct tunnel is done by the overlay networks.
SARPはオーバーレイネットワークで使用でき、L2ネットワーク仮想化（IP、仮想プライベートLANサービス（VPLS）、リンクの透過的相互接続（TRILL）、オーバーレイトランスポート仮想化（OTV）、GREを使用したネットワーク仮想化（NVGRE）など）を提供します。および仮想拡張可能ローカルエリアネットワーク（VXLAN））。 SARPのオーバーレイネットワークへのマッピングは簡単です。 VMは、宛先IPのSARPプロキシMACアドレスへのマッピングを行います。プロキシMACの正しいトンネルへのマッピングは、オーバーレイネットワークによって行われます。
SARP significantly scales down the complexity of the overlay networks and transport networks by reducing the mapping tables to the number of SARP proxies.
SARPは、マッピングテーブルをSARPプロキシの数まで削減することにより、オーバーレイネットワークとトランスポートネットワークの複雑さを大幅に縮小します。
SARP proxies are located at the boundaries of access networks, where the local Layer 2 infrastructure connects to its Layer 2 cloud. SARP proxies interoperate with overlay network protocols that extend the Layer 2 subnet across data centers or between different systems within a data center.
SARPプロキシは、ローカルレイヤー2インフラストラクチャがレイヤー2クラウドに接続するアクセスネットワークの境界に配置されます。 SARPプロキシは、データセンター全体またはデータセンター内の異なるシステム間でレイヤー2サブネットを拡張するオーバーレイネットワークプロトコルと相互運用します。
SARP does not expose the network to security threats beyond those that exist whether or not SARP is present.
SARPは、SARPの有無に関係なく、ネットワークをセキュリティ上の脅威にさらすことはありません。
SARP proxies may be exposed to denial-of-service (DoS) attacks by means of ARP/ND message flooding. Thus, SARP proxies must have sufficient resources to support the SARP control plane without making the network more vulnerable to DoS than it was without SARP proxies.
SARPプロキシは、ARP / NDメッセージフラッディングによってサービス拒否（DoS）攻撃にさらされる可能性があります。したがって、SARPプロキシは、ネットワークがSARPプロキシがない場合よりもDoSに対して脆弱になることなく、SARPコントロールプレーンをサポートするための十分なリソースを備えている必要があります。
SARP adds security to the data plane in terms of network reconnaissance, by hiding all the local Layer 2 MAC addresses from potential attackers located at the interconnecting network and significantly limiting the number of addresses exposed to an attacker at a remote site.
SARPは、相互接続ネットワークにある潜在的な攻撃者からすべてのローカルレイヤー2 MACアドレスを隠し、リモートサイトで攻撃者にさらされるアドレスの数を大幅に制限することにより、ネットワーク偵察の観点からデータプレーンにセキュリティを追加します。
[ARP] 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>.
[ARP]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはイーサネットプロトコルハードウェアで伝送するための48.ビットイーサネットアドレスへの変換」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[ND] 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>.
[ND] 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>。
[ProxyARP] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, DOI 10.17487/RFC1027, October 1987, <http://www.rfc-editor.org/info/rfc1027>.
[ProxyARP] Carl-Mitchell、S。およびJ. Quarterman、「ARPを使用した透過サブネットゲートウェイの実装」、RFC 1027、DOI 10.17487 / RFC1027、1987年10月、<http://www.rfc-editor.org/info/ rfc1027>。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, DOI 10.17487/RFC0925, October 1984, <http://www.rfc-editor.org/info/rfc925>.
[RFC925] Postel、J。、「Multi-LAN address resolution」、RFC 925、DOI 10.17487 / RFC0925、1984年10月、<http://www.rfc-editor.org/info/rfc925>。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、DOI 10.17487 / RFC4389、2006年4月、<http：//www.rfc-editor。 org / info / rfc4389>。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <http://www.rfc-editor.org/info/rfc4541>.
[RFC4541] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリ（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、DOI 10.17487 / RFC4541、2006年5月、 <http://www.rfc-editor.org/info/rfc4541>。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664] Andersson、L.、Ed。とE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks（L2VPNs）"、RFC 4664、DOI 10.17487 / RFC4664、September 2006、<http：// www。 rfc-editor.org/info/rfc4664>。
[RFC6575] Shah, H., Ed., Rosen, E., Ed., Heron, G., Ed., and V. Kompella, Ed., "Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs", RFC 6575, DOI 10.17487/RFC6575, June 2012, <http://www.rfc-editor.org/info/rfc6575>.
[RFC6575] Shah、H.、Ed。、Rosen、E.、Ed。、Heron、G.、Ed。、およびV. Kompella、Ed。、「レイヤ2 VPNのIPインターワーキングのためのアドレス解決プロトコル（ARP）メディエーション"、RFC 6575、DOI 10.17487 / RFC6575、2012年6月、<http://www.rfc-editor.org/info/rfc6575>。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", IEEE Std 802.1Q.
[802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、IEEE Std 802.1Q。
[ARMDStats] Karir, M., and J. Rees, "Address Resolution Statistics", Work in Progress, draft-karir-armd-statistics-01, July 2011.
[ARMDStats] Karir、M。、およびJ. Rees、「Address Resolution Statistics」、Work in Progress、draft-karir-armd-statistics-01、2011年7月。
[MultLinkSub] Thaler, D., and C. Huitema, "Multi-link Subnet Support in IPv6", Work in Progress, draft-ietf-ipv6-multi-link-subnets-00, June 2002.
[MultLinkSub] Thaler、D。、およびC. Huitema、「IPv6でのマルチリンクサブネットサポート」、作業中、draft-ietf-ipv6-multi-link-subnets-00、2002年6月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007, <http://www.rfc-editor.org/info/rfc4903>.
[RFC4903]ターラー、D。、「マルチリンクサブネットの問題」、RFC 4903、DOI 10.17487 / RFC4903、2007年6月、<http://www.rfc-editor.org/info/rfc4903>。
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, DOI 10.17487/RFC6820, January 2013, <http://www.rfc-editor.org/info/rfc6820>.
[RFC6820] Narten、T.、Kairr、M。、およびI. Foo、「大規模なデータセンターネットワークにおけるアドレス解決の問題」、RFC 6820、DOI 10.17487 / RFC6820、2013年1月、<http：//www.rfc-editor .org / info / rfc6820>。
[RFC7342] Dunbar, L., Kumari, W., and I. Gashinsky, "Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers", RFC 7342, DOI 10.17487/RFC7342, August 2014, <http://www.rfc-editor.org/info/rfc7342>.
[RFC7342]ダンバー、L。、クマリ、W、およびI.ガシンスキー、「大規模データセンターでのARPおよび近隣探索（ND）のスケーリングの実践」、RFC 7342、DOI 10.17487 / RFC7342、2014年8月、<http：/ /www.rfc-editor.org/info/rfc7342>。
[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>。
[TcpIp] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[TcpIp] Stevens、W。、「TCP / IP Illustrated、Volume 1：The Protocols」、Addison-Wesley、1994。
Acknowledgments
謝辞
The authors thank Ted Lemon, Eric Gray, and Adrian Farrel for providing valuable comments and suggestions for the document.
著者は、文書に対する貴重なコメントと提案を提供してくれたTed Lemon、Eric Gray、およびAdrian Farrelに感謝します。
Authors' Addresses
著者のアドレス
Youval Nachum EMail: youval.nachum@gmail.com
Youval Nachum Eメール：youval.nachum@gmail.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024 United States Phone: (469) 277 5840 EMail: ldunbar@huawei.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive、Suite＃175 Plano、TX 75024 United States電話：（469）277 5840メール：ldunbar@huawei.com
Ilan Yerushalmi Marvell 6 Hamada St. Yokneam, 20692 Israel EMail: yilan@marvell.com
Ilan Yerushalmi Marvell 6 Hamada St. Yokneam、20692 Israel EMail：yilan@marvell.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel EMail: talmi@marvell.com
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel EMail：talmi@marvell.com