[要約] 要約：RFC 7067は、ディレクトリアシスタンスの問題と高レベルの設計提案に関するドキュメントです。 目的：ディレクトリアシスタンスの問題を理解し、高レベルの設計提案を通じて解決策を提供することを目的としています。
Internet Engineering Task Force (IETF) L. Dunbar
Request for Comments: 7067 D. Eastlake
Category: Informational Huawei
ISSN: 2070-1721 R. Perlman
Intel
I. Gashinsky
Yahoo
November 2013
Directory Assistance Problem and High-Level Design Proposal
ディレクトリアシスタンスの問題と高レベルの設計提案
Abstract
概要
Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station Address Distribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame's Data Label across the TRILL campus.
エッジTRILL（多数のリンクの透過的相互接続）スイッチは、MAC（メディアアクセス制御）アドレスとその出力TRILLスイッチ間のマッピングを、それらが入力または出力するデータパケットを監視することによって、またはTRILL ESADI（エンドステーションアドレス配布情報）によって現在学習しています。プロトコル。入力TRILLスイッチが、スイッチが認識していない宛先アドレス（MAC＆Label）のデータフレームを受信すると、データフレームはTRILLキャンパス全体のフレームのデータラベル内でフラッディングされます。
This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (Address Resolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security.
このドキュメントでは、ディレクトリサービスを使用してエッジTRILLスイッチがマルチ宛先フレーム、特に未知のユニキャストフレームのフラッディング、およびARP / ND（アドレス解決プロトコル/近隣探索）を削減できるようにフレームワークを説明し、TRILLネットワークのスケーラビリティとセキュリティを向上させます。
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/rfc7067.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7067で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................3
2. Terminology .....................................................4
3. Impact of Massive Number of End Stations ........................5
3.1. Issues of Flooding-Based Learning in Data Centers ..........5
3.2. Two Examples ...............................................6
4. Benefits of Directory-Assisted TRILL Edge .......................7
5. Generic Operation of Directory Assistance .......................8
5.1. Information in Directory for Edge RBridges .................8
5.2. Push Model and Requirements ................................9
5.3. Pull Model and Requirements ...............................11
6. Recommendation .................................................12
7. Security Considerations ........................................12
8. Acknowledgements ...............................................13
9. Informative References .........................................14
Edge TRILL (Transparent Interconnection of Lots of Links) switches (devices implementing [RFC6325], also known as RBridges) currently learn the mapping between destination MAC addresses and their egress TRILL switch by observing data packets or by the ESADI (End-Station Address Distribution Information) protocol. When an ingress RBridge (Routing Bridge) receives a data frame for a destination address (MAC&Label) that RBridge does not know, the data frame is flooded within that Data Label across the TRILL campus. (Data Labels are VLANs or FGLs (Fine-Grained Labels [FGL]).
Edge TRILL（多数のリンクの透過的相互接続）スイッチ（[RFC6325]を実装するデバイス、RBridgesとも呼ばれます）は現在、データパケットを監視するか、ESADI（End-Station Address Distribution）によって宛先MACアドレスとその出力TRILLスイッチ間のマッピングを学習します情報）プロトコル。入力RBridge（ルーティングブリッジ）が、RBridgeが認識していない宛先アドレス（MAC＆Label）のデータフレームを受信すると、データフレームはTRILLキャンパス全体のそのデータラベル内でフラッディングされます。 （データラベルはVLANまたはFGL（Fine-Grained Labels [FGL]））です。
This document describes a framework for using directory services in environments where such services are available, such as typical data centers, to assist edge TRILL switches. This assistance can reduce multi-destination frames, particularly ARP [RFC826], ND [RFC4861], and unknown unicast, thus improving TRILL network scalability. In addition, the information provided by a directory can be more secure than that learned from the data plane (see Section 7).
このドキュメントでは、典型的なデータセンターなど、ディレクトリサービスを利用できる環境でディレクトリサービスを使用して、エッジTRILLスイッチを支援するためのフレームワークについて説明します。この支援により、複数の宛先フレーム、特にARP [RFC826]、ND [RFC4861]、および未知のユニキャストを削減できるため、TRILLネットワークのスケーラビリティが向上します。さらに、ディレクトリによって提供される情報は、データプレーンから学んだ情報よりも安全です（セクション7を参照）。
Data centers, especially Internet and/or multi-tenant data centers, tend to have a large number of end stations with a wide variety of applications. Their networks differ from enterprise campus networks in several ways that make them attractive for the use of directory assistance, in particular:
データセンター、特にインターネットやマルチテナントデータセンターは、さまざまなアプリケーションを備えた多数のエンドステーションを持つ傾向があります。彼らのネットワークは、特にディレクトリアシスタンスの使用にとって魅力的ないくつかの点で、エンタープライズキャンパスネットワークとは異なります。
1. Data center topology is often based on racks and rows. Furthermore, a Server/VM (virtual machine) Management System orchestrates the assignment of guest operating systems to servers, racks, and rows; it is not done at random. So, the information necessary for a directory is normally available from that Management System.
1. データセンターのトポロジは、多くの場合、ラックと列に基づいています。さらに、サーバー/ VM（仮想マシン）管理システムは、ゲストオペレーティングシステムのサーバー、ラック、および行への割り当てを調整します。無作為には行われません。したがって、ディレクトリに必要な情報は通常、その管理システムから入手できます。
2. Rapid workload shifting in data centers can accelerate the frequency of the physical servers being reloaded with different applications. Sometimes, applications loaded into one physical server at different times can belong to different subnets. When a VM is moved to a new location or when a server is loaded with a new application with different IP/MAC addresses, it is more likely that the destination address of data packets sent out from those VMs are unknown to their attached edge RBridges.
2. データセンターでのワークロードの急速な移行により、さまざまなアプリケーションでリロードされる物理サーバーの頻度を加速できます。場合によっては、1つの物理サーバーに異なるタイミングで読み込まれるアプリケーションが、異なるサブネットに属することがあります。 VMが新しい場所に移動されたとき、またはサーバーに異なるIP / MACアドレスを持つ新しいアプリケーションがロードされたときに、それらのVMから送信されたデータパケットの宛先アドレスが、接続されたエッジRBridgeに認識されない可能性が高くなります。
3. With server virtualization, there is an increasing trend to dynamically create or delete VMs when the demand for resources changes, to move VMs from overloaded servers to less loaded servers, or to aggregate VMs onto fewer servers when demand is light. This results in the more frequent occurrence of multiple subnets on the same port at the same time and a higher change rate for VMs than for physical servers.
3.サーバーの仮想化では、リソースの需要が変化したときに動的にVMを作成または削除したり、過負荷のサーバーから負荷の少ないサーバーにVMを移動したり、需要が少ないときにVMをより少ないサーバーに集約したりする傾向が高まっています。これにより、同じポートで同時に複数のサブネットが頻繁に発生し、物理サーバーよりもVMの変更率が高くなります。
Both items 2 and 3 above can lead to applications in one subnet being placed in different locations (racks or rows) or one rack having applications belonging to different subnets.
上記の2と3の両方が原因で、1つのサブネット内のアプリケーションが異なる場所（ラックまたは行）に配置されるか、1つのラックが異なるサブネットに属するアプリケーションを持つ可能性があります。
The terms "VLAN" and "Data Label" are used interchangeably with "Subnet" in this document, because it is common to map one subnet to one VLAN or FGL.
「VLAN」および「データラベル」という用語は、1つのサブネットを1つのVLANまたはFGLにマッピングするのが一般的であるため、このドキュメントでは「サブネット」と同じ意味で使用されています。
Bridge: Device compliant with IEEE Std 802.1Q-2011 [802.1Q].
ブリッジ：IEEE Std 802.1Q-2011 [802.1Q]に準拠したデバイス。
Data Label: VLAN or FGL
データラベル：VLANまたはFGL
EoR: End-of-Row switches in a data center. Also known as aggregation switches.
EoR：データセンターの行末スイッチ。集約スイッチとも呼ばれます。
End Station: Guest OS running on a physical server or on a virtual machine. An end station in this document has at least one IP address, at least one MAC address, and is connected to a network.
エンドステーション：物理サーバーまたは仮想マシンで実行されるゲストOS。このドキュメントのエンドステーションには、少なくとも1つのIPアドレスと少なくとも1つのMACアドレスがあり、ネットワークに接続されています。
FGL: Fine-Grained Label [FGL]
FGL：きめの細かいラベル[FGL]
IS-IS: Intermediate System to Intermediate System routing protocol. TRILL uses IS-IS [IS-IS] [RFC6326].
IS-IS：Intermediate System to Intermediate Systemルーティングプロトコル。 TRILLはIS-IS [IS-IS] [RFC6326]を使用します。
RBridge: "Routing Bridge", an alternate name for a TRILL switch.
RBridge：「ルーティングブリッジ」、TRILLスイッチの別名。
ToR: Top-of-Rack switches in a data center. Also known as access switches in some data centers.
ToR：データセンターのトップオブラックスイッチ。一部のデータセンターではアクセススイッチとも呼ばれます。
TRILL: Transparent Interconnection of Lots of Links [RFC6325]
TRILL：多くのリンクの透過的な相互接続[RFC6325]
TRILL Switch: A device implementing the TRILL protocol [RFC6325].
TRILLスイッチ：TRILLプロトコル[RFC6325]を実装するデバイス。
VM: Virtual Machine
VM：仮想マシン
This section discusses the impact of a massive number of end stations in a TRILL campus using Data Centers as an example.
このセクションでは、例としてデータセンターを使用して、TRILLキャンパス内の多数のエンドステーションの影響について説明します。
It is common for Data Center networks to have multiple tiers of switches, for example, one or two Access Switches for each server rack (ToR), aggregation switches for some rows (or EoR switches), and some core switches to interconnect the aggregation switches. Many aggregation switches deployed in data centers have high port density. It is not uncommon to see aggregation switches interconnecting hundreds of ToR switches.
データセンターネットワークでは、スイッチの複数の層、たとえば、サーバーラック（ToR）ごとに1つまたは2つのアクセススイッチ、一部の行（またはEoRスイッチ）の集約スイッチ、集約スイッチを相互接続するいくつかのコアスイッチなどが一般的です。 。データセンターに導入された多くの集約スイッチは、高いポート密度を持っています。何百ものToRスイッチを相互接続する集約スイッチが見られることも珍しくありません。
+-------+ +------+
+/------+ | +/-----+ |
| Aggr11| + ----- |AggrN1| + EoR switches
+---+---+/ +------+/
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|T11|... |T1x| |T21| .. |T2y| ToR switches
+---+ +---+ +---+ +---+
| | | |
+-|-+ +-|-+ +-|-+ +-|-+
| |... | | | | .. | |
+---+ +---+ +---+ +---+ Server racks
| |... | | | | .. | |
+---+ +---+ +---+ +---+
| |... | | | | .. | |
+---+ +---+ +---+ +---+
Figure 1: Typical Data Center Network Design
図1：典型的なデータセンターネットワーク設計
The following problems could occur when TRILL is deployed in a data center with a large number of end stations and when the end stations in one subnet/Label are placed under multiple edge RBridges:
次の問題は、TRILLが多数のエンドステーションがあるデータセンターにデプロイされ、1つのサブネット/ラベル内のエンドステーションが複数のエッジRBridgeの下に配置されている場合に発生する可能性があります。
- Unnecessary filling of slots in the MAC address learning table of edge RBridges, e.g., RBridge T11, due to T11 receiving broadcast/multicast traffic (e.g., ARP/ND, cluster multicast, etc.) from end stations under other edge RBridges that are not actually communicating with any end stations attached to T11.
- T11がブロードキャスト/マルチキャストトラフィック（ARP / ND、クラスターマルチキャストなど）を他のエッジRBridgeの下にないエンドステーションから受信するため、エッジRBridge、たとえばRBridge T11のMACアドレス学習テーブルに不要なスロットを埋めるT11に接続されている端末と実際に通信している。
- Packets being flooded across a TRILL campus when their destination MAC addresses are not in the ingress RBridge's MAC address to the egress RBridge cache.
- 宛先MACアドレスが入力RBridgeのMACアドレス内になく出力RBridgeキャッシュにないときに、パケットがTRILLキャンパス全体にフラッディングされます。
Consider a data center with 1,600 server racks. Each server rack has at least one ToR switch. The ToR switches are further divided into 8 groups, with each group being connected by a set of aggregation switches. There could be 4 to 8 aggregation switches in each set to achieve load sharing for traffic to/from server racks. Let's consider the following two scenarios for the TRILL campus boundary if TRILL is deployed in this data center environment:
1,600台のサーバーラックを備えたデータセンターを考えてみましょう。各サーバーラックには、少なくとも1つのToRスイッチがあります。 ToRスイッチはさらに8つのグループに分けられ、各グループは一連の集約スイッチによって接続されます。サーバーラックとの間のトラフィックの負荷分散を実現するために、各セットに4〜8個の集約スイッチを配置できます。 TRILLがこのデータセンター環境に展開されている場合、TRILLキャンパス境界について次の2つのシナリオを検討してみましょう。
- Scenario #1: TRILL campus boundary starts at the ToR switches:
- シナリオ＃1：TRILLキャンパス境界はToRスイッチから始まります。
If each server rack has one ToR, there are 1,600 edge RBridges. If each rack has two ToR switches, then there will be 3,200 edge RBridges.
各サーバーラックに1つのToRがある場合、1,600のエッジRBridgeがあります。各ラックに2つのToRスイッチがある場合、3,200のエッジRBridgeがあります。
In this scenario, the TRILL campus will have more than 1,600 (or 3,200) + 8*4 (or 8*8) nodes, which is a large IS-IS area. Even though a mesh IS-IS area can scale up to thousands of nodes, it is challenging for aggregation switches to handle IS-IS link state advertisement among hundreds of parallel ports.
このシナリオでは、TRILLキャンパスには1,600（または3,200）を超えるノードと8 * 4（または8 * 8）のノードがあり、これは大きなIS-ISエリアです。メッシュIS-ISエリアは数千のノードにまで拡張できる場合でも、集約スイッチが数百のパラレルポート間でIS-ISリンクステートアドバタイズメントを処理することは困難です。
If each ToR has 40 downstream ports facing servers and each server has 10 VMs, there could be 40*10 = 400 end stations attached. If those end stations belong to 8 Labels, then the total number of MAC&Label entries learned by each edge RBridge in the worst case might be 400*8 = 3,200, which is not a large number.
各ToRにサーバーに面する40のダウンストリームポートがあり、各サーバーに10のVMがある場合、40 * 10 = 400のエンドステーションが接続される可能性があります。これらのエンドステーションが8つのラベルに属している場合、最悪の場合、各エッジRBridgeによって学習されるMAC＆Labelエントリの合計数は400 * 8 = 3,200になる可能性があり、これは大きな数ではありません。
- Scenario #2: TRILL campus boundary starts at the aggregation switches:
- シナリオ＃2：TRILLキャンパス境界は集約スイッチから始まります。
With the same assumptions as before, the number of nodes in the TRILL campus will be less than 100, and aggregation switches don't have to handle IS-IS link state advertisements among hundreds of parallel ports.
以前と同じ前提で、TRILLキャンパスのノード数は100未満になり、集約スイッチは数百のパラレルポート間でIS-ISリンクステートアドバタイズを処理する必要がありません。
However, the number of MAC&Label <-> Egress RBridge mapping entries to be learned and managed by the RBridge edge node can be very large. In the example above, each edge RBridge has 200 edge ports facing the ToR switches. If each ToR has 40 downstream ports facing servers and each server has 10 VMs, there could be 200*40*10 = 80,000 end stations attached. If all those end stations belong to 1,600 Labels (50 per Data Label) and each Data Label has 200 end stations, then under the worst-case scenario, the total number of MAC&Label entries to be learned by each edge RBridge can be 1,600*200=320,000, which is very large.
ただし、RBridgeエッジノードによって学習および管理されるMAC＆Label <-> Egress RBridgeマッピングエントリの数は非常に多くなる可能性があります。上記の例では、各エッジRBridgeに、ToRスイッチに面する200のエッジポートがあります。各ToRにサーバーに面する40個のダウンストリームポートがあり、各サーバーに10個のVMがある場合、200 * 40 * 10 = 80,000のエンドステーションが接続される可能性があります。これらすべてのエンドステーションが1,600のラベル（データラベルごとに50）に属し、各データラベルに200のエンドステーションがある場合、最悪のシナリオでは、各エッジRBridgeによって学習されるMAC＆Labelエントリの総数は1,600 * 200になります。 = 320,000、これは非常に大きいです。
In some environments, particularly data centers, the assignment of applications to servers, including rack and row selection, is orchestrated by Server (or VM) Management System(s). That is, there is a database or multiple databases that have the knowledge of where each application is placed. If the application location information can be fed to RBridge edge nodes through some form of directory service, then there is much less chance of RBridge edge nodes receiving unknown MAC destination addresses, therefore less chance of flooding.
一部の環境、特にデータセンターでは、サーバーへのアプリケーションの割り当て（ラックや列の選択を含む）は、サーバー（またはVM）管理システムによって調整されます。つまり、各アプリケーションの配置場所を認識している1つまたは複数のデータベースがあります。アプリケーションの場所情報をなんらかの形のディレクトリサービスを通じてRBridgeエッジノードに提供できる場合、RBridgeエッジノードが不明なMAC宛先アドレスを受信する可能性がはるかに低くなるため、フラッディングの可能性が低くなります。
Avoiding unknown unicast address flooding to the TRILL campus is especially valuable in the data center environment, because there is a higher chance of an edge RBridge receiving packets with an unknown unicast destination address and broadcast/multicast messages due to VM migration and servers being loaded with different applications. When a VM is moved to a new location or a server is loaded with a new application with a different IP/MAC addresses, it is more likely that the destination address of data packets sent out from those VMs is unknown to their attached edge RBridges. In addition, gratuitous ARP (IPv4 [RFC826]) or Unsolicited Neighbor Advertisement (IPv6 [RFC4861]) sent out from those newly migrated or activated VMs have to be flooded to other edge RBridges that have VMs in the same subnets.
未知のユニキャストアドレスがTRILLキャンパスにフラッディングすることを回避することは、データセンター環境で特に価値があります。これは、エッジRBridgeが、未知のユニキャスト宛先アドレスとブロードキャスト/マルチキャストメッセージを含むパケットを受信する可能性が高くなるためです。さまざまなアプリケーション。 VMを新しい場所に移動するか、サーバーに別のIP / MACアドレスを持つ新しいアプリケーションをロードすると、それらのVMから送信されるデータパケットの宛先アドレスが、接続されているエッジRBridgeに認識されない可能性が高くなります。さらに、新しく移行またはアクティブ化されたVMから送信されたGratuitous ARP（IPv4 [RFC826]）またはUnsolicited Neighbor Advertisement（IPv6 [RFC4861]）は、同じサブネット内のVMを持つ他のエッジRBridgeにフラッディングする必要があります。
The benefits of using directory assistance include:
ディレクトリアシスタントを使用する利点は次のとおりです。
- Avoids flooding an unknown unicast destination address across the TRILL campus. The directory-enforced MAC&Label <-> Egress RBridge mapping table can determine if a data packet needs to be forwarded across the TRILL campus.
- 未知のユニキャスト宛先アドレスがTRILLキャンパス全体にフラッディングするのを防ぎます。ディレクトリ強制のMAC＆Label <-> Egress RBridgeマッピングテーブルは、データパケットをTRILLキャンパス全体に転送する必要があるかどうかを判断できます。
When multiple RBridge edge ports are connected to end stations (servers/VMs), possibly via bridged LANs, a directory-assisted edge RBridge won't need to flood unknown unicast destination data frames to all ports of the edge RBridges in the frame's Data Label when it ingresses a frame. It can depend on the directory to locate the destination. When the directory doesn't have the needed information, the frames can be dropped or flooded depending on the policy configured.
複数のRBridgeエッジポートがエンドステーション（サーバー/ VM）に、おそらくブリッジLAN経由で接続されている場合、ディレクトリアシストのエッジRBridgeは、不明なユニキャスト宛先データフレームをフレームのデータラベル内のエッジRBridgeのすべてのポートにフラッディングする必要はありません。フレームに入ったとき。それは宛先を見つけるためにディレクトリに依存することができます。ディレクトリに必要な情報がない場合、構成されたポリシーに応じて、フレームがドロップまたはフラッディングする可能性があります。
- Reduces flooding of decapsulated Ethernet frames with an unknown MAC destination address to a bridged LAN connected to RBridge edge ports.
- RBridgeエッジポートに接続されたブリッジLANへの、MAC宛先アドレスが不明なカプセル化解除されたイーサネットフレームのフラッディングを削減します。
When an RBridge receives a unicast TRILL data packet whose destination Nickname matches with its own, the normal procedure is for the RBridge to decapsulate it and forward the decapsulated Ethernet frame to the directly attached bridged LAN. If the destination MAC is unknown, the RBridge floods the decapsulated Ethernet frame out all ports in the frame's Data Label. With directory assistance, the egress RBridge can determine if the MAC destination address in a frame matches any end stations attached via the bridged LAN. Frames can be discarded if their destination addresses do not match.
RBridgeが、宛先ニックネームが自身と一致するユニキャストTRILLデータパケットを受信した場合、通常の手順では、RBridgeがカプセル化を解除し、カプセル化解除されたイーサネットフレームを直接接続されたブリッジLANに転送します。宛先MACが不明の場合、RBridgeはカプセル化解除されたイーサネットフレームをフレームのデータラベル内のすべてのポートからフラッディングします。ディレクトリ支援により、出力RBridgeは、フレーム内のMAC宛先アドレスがブリッジLAN経由で接続されたエンドステーションと一致するかどうかを判断できます。宛先アドレスが一致しない場合、フレームは破棄されることがあります。
- Reduces the amount of MAC&Label <-> Egress RBridge mapping maintained by edge RBridges. There is no need for an edge RBridge to keep MAC entries of remote end stations that don't communicate with the end stations locally attached.
- エッジRBridgeによって維持されるMAC＆Label <-> Egress RBridgeマッピングの量を減らします。ローカルに接続されたエンドステーションと通信しないリモートエンドステーションのMACエントリを保持するためのエッジRBridgeは必要ありません。
- Eliminates ARP/ND being broadcast or multicast through the TRILL core.
- TRILLコアを介してブロードキャストまたはマルチキャストされるARP / NDを排除します。
- Provides some protection against spoofing of source addresses (see Section 7).
- 送信元アドレスのスプーフィングに対する保護を提供します（セクション7を参照）。
There are two different models for directory assistance to edge RBridges: Push Model and Pull Model. The directory information is described in Section 5.1 below, while Section 5.2 discusses Push Model requirements, and Section 5.3 Pull Model requirements.
エッジRBridgeへのディレクトリアシスタンスには、プッシュモデルとプルモデルの2つの異なるモデルがあります。ディレクトリ情報については以下のセクション5.1で説明し、セクション5.2ではプッシュモデルの要件、セクション5.3プルモデルの要件について説明します。
To achieve the benefits of directory assistance for TRILL, the corresponding Directory Server entries will need, at a minimum, the following logical data structure:
TRILLのディレクトリ支援の利点を実現するには、対応するDirectory Serverエントリに、少なくとも次の論理データ構造が必要です。
[IP, MAC, Data Label, {list of attached RBridge nicknames}, {list of
interested RBridges}]
The {list of attached RBridges} are the edge RBridges to which the host (or VM) is attached as specified by the [IP, MAC, Data Label] in the entry. The {list of interested RBridges} are the remote RBridges that might have attached hosts that communicate with the host in this entry.
{接続されているRBridgeのリスト}は、エントリの[IP、MAC、データラベル]で指定されているように、ホスト（またはVM）が接続されているエッジRBridgeです。 {関心のあるRBridgeのリスト}は、このエントリのホストと通信するホストが接続されている可能性があるリモートRBridgeです。
When a host has multiple IP addresses, there will be multiple entries.
ホストに複数のIPアドレスがある場合、複数のエントリがあります。
The {list of interested RBridges} could get populated when an RBridge queries for information, or information is pushed from a Directory Server. The list is used to notify those RBridges when the host (specified by the [IP, MAC, Data Label]) in the entry changes its RBridge attachment. An explicit list in the directory is not needed as long as the interested RBridges can be determined.
{関心のあるRBridgeのリスト}は、RBridgeが情報を照会したり、情報がDirectory Serverからプッシュされたりしたときに生成される可能性があります。このリストは、エントリ内のホスト（[IP、MAC、データラベル]で指定）がRBridge接続を変更したときに、それらのRBridgeに通知するために使用されます。関係するRBridgeを決定できる限り、ディレクトリ内の明示的なリストは必要ありません。
Under this model, Directory Server(s) push the MAC&Label <-> Egress RBridge mapping for all the end stations that might communicate with end stations attached to an RBridge edge node. If the packet's destination address can't be found in the MAC&Label <-> Egress RBridge table, the Ingress RBridge could be configured to:
このモデルでは、Directory Serverは、RBridgeエッジノードに接続されたエンドステーションと通信する可能性のあるすべてのエンドステーションのMAC＆Label <-> Egress RBridgeマッピングをプッシュします。パケットの宛先アドレスがMAC＆Label <-> Egress RBridgeテーブルで見つからない場合、Ingress RBridgeを次のように構成できます。
simply drop a data packet,
単にデータパケットをドロップし、
flood it to the TRILL campus, or
それをTRILLキャンパスに氾濫させる、または
start the pull process to get information from the Pull Directory Server(s).
プルプロセスを開始して、プルディレクトリサーバーから情報を取得します。
It may not be necessary for every edge RBridge to get the entire mapping table for all the end stations in a campus. There are many ways to narrow the full set down to a smaller set of remote end stations that communicate with end stations attached to an edge RBridge. A simple approach is to only push the mapping for the Data Labels that have active end stations under an edge RBridge. This approach can reduce the number of mapping entries being pushed.
キャンパス内のすべてのエンドステーションのマッピングテーブル全体をすべてのエッジRBridgeで取得する必要はありません。完全なセットを、エッジRBridgeに接続されたエンドステーションと通信するリモートエンドステーションのより小さなセットに絞り込む多くの方法があります。単純なアプローチは、エッジRBridgeの下にアクティブなエンドステーションがあるデータラベルのマッピングのみをプッシュすることです。このアプローチにより、プッシュされるマッピングエントリの数を減らすことができます。
However, the Push Model will usually push more entries of MAC&Label <-> Egress RBridge mapping to an edge RBridges than needed. Under the normal process of edge RBridge cache aging and unknown destination address flooding, rarely used mapping entries would have been removed. But it can be difficult for Directory Servers to predict the communication patterns among applications within one Data Label. Therefore, it is likely that the Directory Servers will push down all the MAC&Label entries if there are end stations in the Data Label attached to the edge RBridge. This is a disadvantage of the Push Model compared with the Pull Model described below.
ただし、プッシュモデルは通常、MAC＆Label <-> Egress RBridgeマッピングのエントリを必要以上にエッジRBridgeにプッシュします。エッジRBridgeキャッシュのエージングと不明な宛先アドレスのフラッディングの通常のプロセスでは、ほとんど使用されないマッピングエントリが削除されていました。ただし、Directory Serverが1つのデータラベル内のアプリケーション間の通信パターンを予測するのは難しい場合があります。したがって、エッジRBridgeに接続されたデータラベルに端末がある場合、Directory ServerはすべてのMAC＆Labelエントリをプッシュダウンする可能性があります。これは、以下で説明するプルモデルと比較したプッシュモデルの欠点です。
In the Push Model, it is necessary to have a way for an RBridge node to request Directory Server(s) to push the mapping entries. This method should at least include the Data Labels enabled on the RBridge, so that the Directory Server doesn't need to push down the entire set of mapping entries for all the end stations in the campus. An RBridge must be able to get mapping entries when it is initialized or restarted.
プッシュモデルでは、RBridgeノードがDirectory Serverにマッピングエントリをプッシュするように要求する方法が必要です。この方法には、少なくともRBridgeで有効になっているデータラベルを含める必要があります。これにより、Directory Serverは、キャンパス内のすべてのエンドステーションのマッピングエントリセット全体をプッシュダウンする必要がなくなります。 RBridgeは、初期化または再起動されたときにマッピングエントリを取得できる必要があります。
The Push Model's detailed method and any handshake mechanism between an RBridge and Directory Server(s) is beyond the scope of this framework document.
プッシュモデルの詳細な方法と、RBridgeとDirectory Server間のハンドシェイクメカニズムは、このフレームワークドキュメントの範囲を超えています。
When a Directory Server needs to push a large number of entries to edge RBridges, efficient data organization should be considered, for example, with one edge RBridge nickname being associated with all the attached end stations' MAC addresses and Data Labels. As shown in Table 1 below, to make the data more compact, a representation can be used where a nickname need only occur once for a set of Labels, each of which occurs only once and each of which is associated with a set of multiple IP and MAC address pairs. It would be much more bulky to have each IP and MAC address pair separately accompanied by its Label and by the nickname of the RBridge by which it is reachable.
Directory Serverが多数のエントリをエッジRBridgeにプッシュする必要がある場合は、たとえば、1つのエッジRBridgeニックネームを、接続されているすべてのエンドステーションのMACアドレスとデータラベルに関連付けることで、効率的なデータ編成を検討する必要があります。以下の表1に示すように、データをよりコンパクトにするために、ニックネームがラベルのセットに対して1回だけ発生する必要がある表現を使用できます。ラベルはそれぞれ1回だけ発生し、それぞれが複数のIPのセットに関連付けられています。およびMACアドレスのペア。各IPとMACアドレスのペアに、ラベルと到達可能なRBridgeのニックネームを個別に付けると、はるかに大きくなります。
+------------+---------+--------------------------------+
| Nickname1 |Label-1 | IP/MAC1, IP/MAC2, ,, IP/MACn |
| |-------- +--------------------------------+
| |Label-2 | IP/MAC1, IP/MAC2, ,, IP/MACn |
| |-------- +--------------------------------+
| | ...... | IP/MAC1, IP/MAC2, ,, IP/MACn |
+------------+-------- +--------------------------------+
| Nickname2 |Label-1 | IP/MAC1, IP/MAC2, ,, IP/MACn |
| |-------- +--------------------------------+
| |Label-2 | IP/MAC1, IP/MAC2, ,,IP/MACn |
| |-------- +--------------------------------+
| | | IP/MAC1, IP/MAC2, ,, IP/MACn |
+------------+-------- +--------------------------------+
| ------- |-------- +--------------------------------+
| | | IP/MAC1, IP/MAC2, ,, IP/MACn |
+------------+-------- +--------------------------------+
Table 1: Summarized Table Pushed Down from Directory
表1：ディレクトリからプッシュダウンされた要約テーブル
Whenever there is any change in MAC&Label <-> Egress RBridge mapping that can be triggered by end stations being added, moved, or decommissioned, an incremental update can be sent to the edge RBridges that are impacted by the change. Therefore, something like a sequence number has to be maintained by Directory Servers and RBridges. Detailed mechanisms will be specified in a separate document.
MAC、ラベル<->出力RBridgeマッピングに変更があり、エンドステーションが追加、移動、または廃止されたことによってトリガーされる可能性がある場合は常に、変更の影響を受けるエッジRBridgeに増分更新を送信できます。したがって、シーケンス番号のようなものは、Directory ServerとRBridgeによって維持される必要があります。詳細なメカニズムは、別のドキュメントで指定されます。
Under this model, an RBridge pulls the MAC&Label <-> Egress RBridge mapping entry from the Directory Server when its cache doesn't have the entry. There are a couple of possibilities for triggering the pulling process:
このモデルでは、RBridgeは、キャッシュにエントリがない場合、MAC＆Label <->出力RBridgeマッピングエントリをDirectory Serverからプルします。プルプロセスをトリガーする方法はいくつかあります。
- The RBridge edge node can send a pull request whenever it receives an unknown MAC destination, or
- RBridgeエッジノードは、不明なMAC宛先を受信するたびにプル要求を送信できます。または
- The RBridge edge node can intercept all ARP/ND requests and forward them or appropriate requests to the Directory Server(s) that has the information on where the target end stations are located.
- RBridgeエッジノードは、すべてのARP / ND要求をインターセプトし、それらまたは適切な要求を、ターゲットエンドステーションの場所に関する情報を持つDirectory Serverに転送できます。
The Pull Directory response could indicate that the address being queried is unknown or that the requestor is administratively prohibited from getting an informative response.
プルディレクトリの応答は、照会されているアドレスが不明であるか、または要求者が通知応答を受け取ることを管理上禁止されていることを示している可能性があります。
By using a Pull Directory, a frame with an unknown MAC destination address doesn't have to be flooded across the TRILL campus and the ARP/ND requests don't have to be broadcast or multicast across the TRILL campus.
プルディレクトリを使用すると、MAC宛先アドレスが不明なフレームをTRILLキャンパス全体にフラッディングする必要がなくなり、ARP / ND要求をTRILLキャンパス全体にブロードキャストまたはマルチキャストする必要がなくなります。
The ingress RBridge can cache the response pulled from the directory. The timer for such a cache should be short in an environment where VMs move frequently. The cache timer could be configured by the Management System or sent along with the Pulled reply by the Directory Server(s). It is important that the cached information be kept consistent with the actual placement of addresses in the campus; therefore, there needs to be some mechanism by which RBridges that have pulled information that has not expired can be informed when that information changes or becomes invalid for other reasons.
入力RBridgeは、ディレクトリから取得した応答をキャッシュできます。このようなキャッシュのタイマーは、VMが頻繁に移動する環境では短くする必要があります。キャッシュタイマーは、管理システムによって構成するか、またはディレクトリサーバーによってプルされた応答と共に送信できます。キャッシュされた情報は、キャンパス内のアドレスの実際の配置と一貫性を保つことが重要です。したがって、期限切れになっていない情報をプルしたRBridgeに、その情報が他の理由で変更または無効になった場合に通知できるメカニズムが必要です。
One advantage of the Pull Model is that edge RBridges can age out MAC&Label entries if they haven't been used for a certain configured period of time or a period of time provided by the directory. Therefore, each edge RBridge will only keep the entries that are frequently used, so its mapping table size will be smaller. Edge RBridges would query the Directory Server(s) for unknown MAC destination addresses in data frames or ARP/ND and cache the response. When end stations attached to remote edge RBridges rarely communicate with the locally attached end stations, the corresponding MAC&VLAN entries would be aged out from the RBridge's cache.
プルモデルの利点の1つは、エッジRBridgeがMAC＆Labelエントリを特定の構成された期間またはディレクトリによって提供された期間使用されなかった場合、それらを期限切れにできることです。したがって、各エッジRBridgeは頻繁に使用されるエントリのみを保持するため、そのマッピングテーブルのサイズは小さくなります。エッジRBridgeは、データフレームまたはARP / ND内の不明なMAC宛先アドレスをディレクトリサーバーに照会し、応答をキャッシュします。リモートエッジのRBridgeに接続されている端末がローカルに接続されている端末とめったに通信しない場合、対応するMAC＆VLANエントリはRBridgeのキャッシュから期限切れになります。
An RBridge waiting for a response from Directory Servers upon receiving a data frame with an unknown destination address is similar to an Layer-3/Layer-2 boundary router waiting for an ARP or ND response upon receiving an IP data packet whose destination IP is not in the router's IP/MAC cache table. Most deployed routers today do hold the packet and send ARP/ND requests to the target upon receiving a packet with a destination IP not in its IP-to-MAC cache. When ARP/ND replies are received, the router will send the data packet to the target. This practice minimizes flooding when targets don't exist in the subnet.
宛先アドレスが不明なデータフレームを受信したときにDirectory Serverからの応答を待機しているRBridgeは、宛先IPがないIPデータパケットを受信したときにARPまたはND応答を待機しているLayer-3 / Layer-2境界ルーターに似ています。ルータのIP / MACキャッシュテーブル。今日配備されているほとんどのルーターは、パケットを保持し、IP-to-MACキャッシュにない宛先IPを持つパケットを受信すると、ターゲットにARP / ND要求を送信します。 ARP / ND応答が受信されると、ルーターはデータパケットをターゲットに送信します。これにより、サブネットにターゲットが存在しない場合のフラッディングが最小限に抑えられます。
When the target doesn't exist in the subnet, routers generally resend an ARP/ND request a few more times before dropping the packets. So, if the target doesn't exist in the subnet, the router's holding time to wait for an ARP/ND response can be longer than the time taken by the Pull Model to get IP-to-MAC mapping from a Directory Server.
ターゲットがサブネットに存在しない場合、ルーターは通常、パケットをドロップする前にARP / ND要求をさらに数回再送信します。したがって、ターゲットがサブネットに存在しない場合、ARP / ND応答を待つルーターの保持時間は、プルモデルがIPからMACへのマッピングをディレクトリサーバーから取得するのにかかる時間よりも長くなる可能性があります。
RBridges with mapping entries being pushed from a Directory Server can be configured to use the Pull Model for targets that don't exist in the mapping data being pushed.
Directory Serverからプッシュされるマッピングエントリを持つRBridgeは、プッシュされるマッピングデータに存在しないターゲットに対してプルモデルを使用するように構成できます。
A separate document will specify the detailed messages and mechanism for RBridges to pull information from Directory Server(s).
別のドキュメントで、RBridgesがDirectory Serverから情報をプルするための詳細なメッセージとメカニズムを指定します。
TRILL should provide a directory-assisted approach. This document describes a basic framework for directory assistance to RBridge edge nodes. More detailed mechanisms will be described in a separate document or documents.
TRILLはディレクトリ支援アプローチを提供する必要があります。このドキュメントでは、RBridgeエッジノードに対するディレクトリアシスタンスの基本的なフレームワークについて説明します。より詳細なメカニズムについては、別のドキュメントで説明します。
For general TRILL security considerations, see Section 6 of [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]のセクション6をご覧ください。
Accurate mapping of IP addresses into MAC addresses and of MAC addresses to the RBridges from which they are reachable is important to the correct delivery of information. The security of specific directory-assisted mechanisms for delivering such information will be discussed in the document or documents specifying those mechanisms.
IPアドレスをMACアドレスに、MACアドレスを到達可能なRBridgeに正確にマッピングすることは、情報を正しく配信するために重要です。このような情報を配信するための特定のディレクトリ支援メカニズムのセキュリティについては、それらのメカニズムを指定するドキュメントで説明します。
A directory-assisted TRILL edge can be used to substantially improve the security of a TRILL campus over TRILL's default MAC address learning from the data plane. Assume S is an end station attached to RB1 trying to spoof a target end station T and that T is attached to RB2. Perhaps S wants to steal traffic intended for T or forge traffic as if it was from T.
ディレクトリ支援のTRILLエッジを使用して、データプレーンから学習するTRILLのデフォルトMACアドレスよりもTRILLキャンパスのセキュリティを大幅に向上させることができます。 SがRB1に接続されている端末で、ターゲット端末Tを偽装しようとしていること、およびTがRB2に接続されていると仮定します。おそらく、SはT宛てのトラフィックを盗んだり、Tからのトラフィックであるかのようにトラフィックを偽造したりします。
With that default TRILL data-plane learning as described in [RFC6325], S can impersonate T or any other end station in the same Data Label (VLAN or FGL [FGL]) as S and possibly other Data Labels, depending on how tightly VLAN admission and Appointed Forwarders [RFC6439] are configured at the port by which S is connected to RB1. S can just send native frames with the forged source MAC addresses of T, perhaps broadcast frames for maximum effectiveness. With this technique, S will frequently receive traffic intended for T and S can easily forge traffic as being from T.
[RFC6325]で説明されているデフォルトのTRILLデータプレーン学習を使用すると、Sは、Sと同じデータラベル（VLANまたはFGL [FGL]）でTまたは他の端末を偽装できます。アドミッションおよびAppointed Forwarders [RFC6439]は、SがRB1に接続されるポートで構成されます。 Sは、偽造された送信元MACアドレスがTのネイティブフレーム、おそらく最大の効果を得るためにブロードキャストフレームを送信できます。この手法を使用すると、SはT宛のトラフィックを頻繁に受信し、SはTからのトラフィックを簡単に偽造できます。
Such spoofing can be prevented to the extent that the network RBridges (1) use trusted directory services as described above in this document, (2) discard native frames received from a local end station when the directory says that end stations should be remote, and, (3) when appropriate, intercept ARP and ND messages and respond locally. Under these circumstances, S would be limited to spoofing targets on the same RBridge as the ingress RBridge for S (that is, RB1 = RB2). RB1 would still need to learn which local end stations were attached to which port, and S could confuse RB1 by sending frames with the forged source MAC address of other end stations on RB1. Although it would also still be restricted to frames in a VLAN that would both be admitted by S's port of attachment and for which that port is an Appointed Forwarder.
このようなスプーフィングは、ネットワークRBridgesが（1）このドキュメントで前述した信頼できるディレクトリサービスを使用する、（2）ディレクトリがエンドステーションがリモートである必要があると言ったときにローカルエンドステーションから受信したネイティブフレームを破棄することで防止できます。 （3）必要に応じて、ARPおよびNDメッセージを傍受し、ローカルで応答します。これらの状況では、Sは、Sの入力RBridgeと同じRBridgeのスプーフィングターゲットに制限されます（つまり、RB1 = RB2）。 RB1は、どのローカルエンドステーションがどのポートに接続されているかを学習する必要があります。Sは、RB1上の他のエンドステーションの偽造された送信元MACアドレスでフレームを送信することにより、RB1を混乱させる可能性があります。ただし、Sの接続ポートによって許可され、そのポートがAppointed ForwarderであるVLANのフレームにも制限されます。
Security against spoofing could be even further strengthened by adding port of attachment information to the directory and discarding native frames that are received on the wrong port. This would limit S to spoofing targets that were on the same link as S and in a VLAN admitted by the port of that link's attachment to RB1 and for which that port is an Appointed Forwarder (or, if the link is multiply connected, in the same way at all of the ports by which the link is attached to an RBridge).
スプーフィングに対するセキュリティは、添付ファイルのポートをディレクトリに追加し、間違ったポートで受信されたネイティブフレームを破棄することでさらに強化できます。これにより、SがSと同じリンク上にあり、RB1へのそのリンクのアタッチメントのポートによって許可され、そのポートがAppointed ForwarderであるVLAN内にあるスプーフィングターゲットに制限されます（または、リンクが複数接続されている場合は、リンクがRBridgeに接続されているすべてのポートで同じ方法）。
Even without directory services, secure ND [RFC3971] or use of secure ESADI (as described in [ESADI]) may also be helpful to security.
ディレクトリサービスがなくても、安全なND [RFC3971]または安全なESADI（[ESADI]で説明）の使用もセキュリティに役立ちます。
Thanks for comments and review from the following:
以下からのコメントとレビューをありがとう：
Sam Aldrin, David Black, Charlie Kaufman, Yizhou Li, and Erik Nordmark
サムアルドリン、デビッドブラック、チャーリーカウフマン、イージョウリー、エリックノードマーク
[802.1Q] IEEE Std 802.1Q-2011, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", May 2011.
[802.1Q] IEEE Std 802.1Q-2011、「IEEE Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks」、2011年5月。
[IS-IS] ISO/IEC, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002.
[IS-IS] ISO / IEC、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムのドメイン内ルーティング情報交換プロトコル」、ISO / IEC 10589：2002。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D.、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326] Eastlake、D.、Banerjee、A.、Dutt、D.、Perlman、R。、およびA. Ghanwani、「リンクの多くの透過的な相互接続（TRILL）IS-ISの使用」、RFC 6326、2011年7月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A。、およびF. Hu、「Routing Bridges（RBridges）：Appointed Forwarders」、RFC 6439、2011年11月。
[ESADI] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "TRILL (Transparent Interconnection of Lots of Links): ESADI (End Station Address Distribution Information) Protocol", Work in Progress, July 2013.
[ESADI] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「TRILL（多数のリンクの透過的相互接続）：ESADI（End Station Address Distribution Information）Protocol」 、Work in Progress、2013年7月。
[FGL] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling", Work in Progress, May 2013.
[FGL] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "TRILL（Transparent Interconnection of Lots of Links）：きめの細かいラベル付け"、進行中の作業、 2013年5月。
Authors' Addresses
著者のアドレス
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024, USA
Linda Dunbar Huawei Technologies 5430 Legacy Drive、Suite＃175 Plano、TX 75024、USA
Phone: +1-469-277-5840
EMail: ldunbar@huawei.com
Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald Eastlake Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、カリフォルニア州95054-1549米国
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York, NY 10011 USA
Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York、NY 10011 USA
EMail: igor@yahoo-inc.com