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
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.
Edge TRILL（大量链路的透明互连）交换机目前通过观察它们进入或离开的数据包或通过TRILL ESADI（端站地址分布信息）协议来学习MAC（媒体访问控制）地址与其出口TRILL交换机之间的映射。当入口颤音交换机接收到交换机不知道的目标地址（MAC和标签）的数据帧时，该数据帧在颤音校园内的帧数据标签内被淹没。
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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（端站地址分布信息）协议学习目标MAC地址与其出口TRILL交换机之间的映射。当入口RBridge（路由网桥）接收到RBridge不知道的目标地址（MAC和标签）的数据帧时，该数据帧在TRILL校园内被淹没在该数据标签内。（数据标签是VLAN或FGL（细粒度标签[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).
本文档描述了一个框架，用于在提供目录服务的环境中（如典型的数据中心）使用目录服务来帮助edge 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. 数据中心中的快速工作负载转移可以加快物理服务器重新加载不同应用程序的频率。有时，在不同时间加载到一台物理服务器的应用程序可能属于不同的子网。当虚拟机移动到新位置或服务器加载了具有不同IP/MAC地址的新应用程序时，从这些虚拟机发送的数据包的目标地址很可能对其连接的边缘不知道。
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
3. 通过服务器虚拟化，在资源需求发生变化时动态创建或删除虚拟机、将虚拟机从过载的服务器移动到负载较低的服务器或在需求较少时将虚拟机聚合到较少的服务器上的趋势越来越大。这会导致多个故障的更频繁发生
subnets on the same port at the same time and a higher change rate for VMs than for physical servers.
同一端口上的子网在同一时间，并且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项都可能导致一个子网中的应用程序被放置在不同的位置（机架或行），或者一个机架中的应用程序属于不同的子网。
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”和“数据标签”可与“子网”互换使用，因为通常将一个子网映射到一个VLAN或FGL。
Bridge: Device compliant with IEEE Std 802.1Q-2011 [802.1Q].
桥接器：符合IEEE标准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.
终端站：在物理服务器或虚拟机上运行的来宾操作系统。本文档中的终端站至少有一个IP地址、至少一个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：中间系统到中间系统路由协议。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].
颤音开关：实现颤音协议的设备[RFC6325]。
VM: Virtual Machine
虚拟机
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）有一个或两个接入交换机，某些行（或EoR交换机）有聚合交换机，一些核心交换机连接聚合交换机。部署在数据中心的许多聚合交换机具有高端口密度。聚合交换机将数百个ToR交换机互连的情况并不少见。
+-------+ +------+
+/------+ | +/-----+ |
| Aggr11| + ----- |AggrN1| + EoR switches
+---+---+/ +------+/
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|T11|... |T1x| |T21| .. |T2y| ToR switches
+---+ +---+ +---+ +---+
| | | |
+-|-+ +-|-+ +-|-+ +-|-+
| |... | | | | .. | |
+---+ +---+ +---+ +---+ Server racks
| |... | | | | .. | |
+---+ +---+ +---+ +---+
| |... | | | | .. | |
+---+ +---+ +---+ +---+
+-------+ +------+
+/------+ | +/-----+ |
| 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部署在具有大量终端站的数据中心时，以及当一个子网/标签中的终端站放置在多个边缘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从其他边缘RBridge下的终端站接收广播/多播流量（例如，ARP/ND、集群多播等），因此边缘RBridge（例如，RBridge T11）的MAC地址学习表中不必要地填充时隙，这些边缘RBridge实际上没有与连接到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地址中时，数据包会被淹没在TRILL校园中，并被发送到出口RBridge缓存。
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:
考虑一个有1600个服务器机架的数据中心。每个服务器机架至少有一个ToR交换机。ToR交换机进一步分为8个组，每个组由一组聚合交换机连接。每组中可能有4到8个聚合交换机，以实现进出服务器机架的流量的负载共享。如果Trip部署在这个数据中心环境中，我们考虑以下两个场景：
- 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.
如果每个服务器机架有一个ToR，则有1600个边缘RBridge。如果每个机架有两个ToR交换机，则将有3200个边缘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园区将有超过1600（或3200）+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和标签条目的总数可能是400×8＝3200，这不是一个大数字。
- 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
然而，要由RBridge边缘节点学习和管理的MAC&Label<->出口RBridge映射条目的数量可能非常大。在上面的示例中，每个边缘RBridge都有200个面向ToR交换机的边缘端口。如果每个ToR有40个面向服务器的下游端口，并且每个服务器有10个VM，那么可能会连接200*40*10=80000个终端站。如果所有这些端点桩号都属于1600个标签（每个数据标签50个），并且每个数据标签有200个端点桩号，则在
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和标签条目的总数可能是1600*200=320000，这是非常大的。
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）管理系统协调的。也就是说，有一个或多个数据库知道每个应用程序的位置。如果可以通过某种形式的目录服务将应用程序位置信息提供给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校园在数据中心环境中尤其重要，因为由于VM迁移和服务器加载了不同的应用程序，边缘RBridge接收具有未知单播目标地址的数据包和广播/多播消息的机会更高。当VM移动到新位置或服务器加载了具有不同IP/MAC地址的新应用程序时，从这些VM发送的数据包的目标地址很可能对其连接的边缘不知道。此外，从这些新迁移或激活的VM发出的免费ARP（IPv4[RFC826]）或未经请求的邻居播发（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<->出口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边缘端口可能通过桥接LAN连接到终端站（服务器/VM）时，目录辅助边缘RBridge在进入帧时不需要将未知的单播目的地数据帧洪泛到帧数据标签中边缘RBridge的所有端口。它可以依赖于目录来定位目标。当目录没有所需信息时，根据配置的策略，可以丢弃或淹没帧。
- Reduces flooding of decapsulated Ethernet frames with an unknown MAC destination address to a bridged LAN connected to RBridge edge ports.
- 减少具有未知MAC目标地址的未封装以太网帧涌入连接到RBridge边缘端口的桥接LAN。
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.
- 减少由边缘RBridges维护的MAC&Label<->出口RBridges映射的数量。不需要边缘RBridge来保持与本地连接的终端站不通信的远程终端站的MAC条目。
- 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.
有两种不同的模式用于边缘RBridges的目录辅助：推模式和拉模式。目录信息在下面的第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目录协助的好处，相应的目录服务器条目至少需要以下逻辑数据结构：
[IP, MAC, Data Label, {list of attached RBridge nicknames}, {list of
interested RBridges}]
[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.
{attached RBridges list}是由条目中的[IP、MAC、数据标签]指定的主机（或VM）连接到的边缘RBridges。{感兴趣的RBridges列表}是远程RBridges，这些远程RBridges可能连接了在此条目中与主机通信的主机。
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列表}。该列表用于在条目中的主机（由[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:
在此模型下，目录服务器为可能与连接到RBridge边缘节点的终端站通信的所有终端站推送MAC&Label<->出口RBridge映射。如果在MAC&Label<->出口RBridge表中找不到数据包的目的地地址，则可以将入口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.
可能没有必要让每个edge 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<->出口RBridge映射条目推送到边缘RBridge，而不是需要的。在边缘RBridge缓存老化和未知目标地址洪泛的正常过程中，很少使用的映射项将被删除。但是，目录服务器很难在一个数据标签内预测应用程序之间的通信模式。因此，如果连接到边缘RBridge的数据标签中有终端站，则目录服务器可能会下推所有MAC和标签条目。这是推模式与下面描述的拉模式相比的一个缺点。
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
在推送模型中，RBridge节点需要有一种方法来请求目录服务器推送映射项。此方法至少应包括在RBridge上启用的数据标签，以便目录服务器不需要按下
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在初始化或重新启动时必须能够获取映射项。
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和目录服务器之间的任何握手机制超出了本框架文档的范围。
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.
当目录服务器需要将大量条目推送到边缘RBridge时，应考虑有效的数据组织，例如，一个边缘RBridge昵称与所有连接的终端站的MAC地址和数据标签相关联。如下面的表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 |
+------------+-------- +--------------------------------+
+------------+---------+--------------------------------+
| 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&Label<->出口RBridge映射发生任何变化，且该变化可由正在添加、移动或停用的终端站触发，则可向受该变化影响的边缘RBridge发送增量更新。因此，目录服务器和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映射条目时，RBridge会从目录服务器中提取该条目。触发拉动过程有两种可能性：
- 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请求，并将它们或适当的请求转发给目录服务器，该目录服务器具有目标终端站所在位置的信息。
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.
Pull目录响应可能表示所查询的地址未知，或者请求者在管理上被禁止获得信息性响应。
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.
通过使用Pull目录，具有未知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.
拉模式的一个优点是，如果MAC和标签条目在特定配置的时间段内或目录提供的时间段内未被使用，边缘RBridges可以将其淘汰。因此，每个边缘RBridge将只保留经常使用的条目，因此其映射表的大小将更小。Edge RBridges将在数据帧或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
RBridge在接收到目标地址未知的数据帧时等待目录服务器的响应，类似于第三层/第二层边界路由器等待ARP或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.
接收到目标IP不在路由器IP/MAC缓存表中的IP数据包时的响应。如今大多数部署的路由器都会保存数据包，并在接收到目标IP不在其IP到MAC缓存中的数据包时向目标发送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响应的等待时间可能会比Pull模型从目录服务器获取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.
从目录服务器推送映射项的RBridge可以配置为对推送的映射数据中不存在的目标使用拉模型。
A separate document will specify the detailed messages and mechanism for RBridges to pull information from Directory Server(s).
单独的文档将指定RBridges从目录服务器获取信息的详细消息和机制。
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 edge可用于在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可以模拟T或与S相同数据标签（VLAN或FGL[FGL]）中的任何其他终端站以及可能的其他数据标签，这取决于在S连接到RB1的端口上配置VLAN准入和指定转发器[RFC6439]的紧密程度。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.
如果网络RBridge（1）使用本文档中所述的受信任目录服务，（2）当目录说终端站应该是远程的时丢弃从本地终端站接收的本机帧，以及（3）在适当的情况下截获ARP和ND消息并在本地响应，则可以防止此类欺骗。在这些情况下，S将被限制在与S的入口RBridge相同的RBridge上欺骗目标（即，RB1=RB2）。RB1仍然需要了解哪些本地终端站连接到哪个端口，S可能会通过发送帧与RB1上其他终端站的伪造源MAC地址混淆RB1。尽管它也将被限制在VLAN中的帧，这些帧将被S的连接端口所接纳，并且该端口是指定的转发器。
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的端口所允许的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标准802.1Q-2011，“局域网和城域网IEEE标准-虚拟桥接局域网”，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.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[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，“IP版本6（IPv6）的邻居发现”，RFC 48612007年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]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，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]伊斯特莱克，班纳吉，A.，杜特，D.，帕尔曼，R.，和A.加瓦尼，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 63262011年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，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年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]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“TRILL（大量链路的透明互连）：ESADI（端站地址分配信息）协议”，正在进行的工作，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.，和D.Dutt，“TRILL（大量链接的透明互连）：细粒度标记”，正在进行的工作，2013年5月。
Authors' Addresses
作者地址
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024, USA
Linda Dunbar华为技术5430传统硬盘，美国德克萨斯州普莱诺175号套房，邮编75024
Phone: +1-469-277-5840
EMail: ldunbar@huawei.com
Phone: +1-469-277-5840
EMail: ldunbar@huawei.com
Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德市海狸街155号唐纳德东湖华为技术有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
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英特尔实验室使命学院大道2200号。美国加利福尼亚州圣克拉拉95054-1549
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Igor Gashinsky Yahoo 45 West 18th Street 6th floor New York, NY 10011 USA
美国纽约州纽约市西18街45号6楼Igor Gashinsky Yahoo 10011
EMail: igor@yahoo-inc.com
EMail: igor@yahoo-inc.com