Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8171 L. Dunbar
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
EMC
Y. Li
Huawei
June 2017
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8171 L. Dunbar
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
EMC
Y. Li
Huawei
June 2017
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
大量链接的透明互连（TRILL）：边缘目录协助机制
Abstract
摘要
This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.
本文档描述了向TRILL（大量链路的透明互连）边缘交换机提供目录服务的机制。提供的目录信息可用于减少多目的地流量，特别是ARP/邻居发现（ND）和未知单播泛洪。它还可用于检测伪造源地址的流量。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8171.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8171.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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
1.1. Uses of Directory Information ..............................5
1.2. Terminology ................................................6
2. Push Model Directory Assistance Mechanisms ......................7
2.1. Requesting Push Service ....................................7
2.2. Push Directory Servers .....................................8
2.3. Push Directory Server State Machine ........................9
2.3.1. Push Directory States ...............................9
2.3.2. Push Directory Events and Conditions ...............11
2.3.3. State Transition Diagram and Table .................13
2.4. End Stations and Push Directories .........................15
2.5. Additional Push Details ...................................15
2.6. Providing Secondary Servers with Data from a
Primary Server ............................................16
2.7. Push Directory Configuration ..............................17
3. Pull Model Directory Assistance Mechanisms .....................17
3.1. Pull Directory Message: Common Format .....................19
3.1.1. Version Negotiation ................................20
3.2. Pull Directory Query and Response Messages ................21
3.2.1. Pull Directory Query Message Format ................21
3.2.2. Pull Directory Responses ...........................24
3.2.2.1. Pull Directory Response Message Format ....24
3.2.2.2. Pull Directory Forwarding .................27
3.3. Cache Consistency .........................................28
3.3.1. Update Message Format ..............................32
3.3.2. Acknowledge Message Format .........................33
3.4. Summary of Record Formats in Messages .....................34
1. Introduction ....................................................3
1.1. Uses of Directory Information ..............................5
1.2. Terminology ................................................6
2. Push Model Directory Assistance Mechanisms ......................7
2.1. Requesting Push Service ....................................7
2.2. Push Directory Servers .....................................8
2.3. Push Directory Server State Machine ........................9
2.3.1. Push Directory States ...............................9
2.3.2. Push Directory Events and Conditions ...............11
2.3.3. State Transition Diagram and Table .................13
2.4. End Stations and Push Directories .........................15
2.5. Additional Push Details ...................................15
2.6. Providing Secondary Servers with Data from a
Primary Server ............................................16
2.7. Push Directory Configuration ..............................17
3. Pull Model Directory Assistance Mechanisms .....................17
3.1. Pull Directory Message: Common Format .....................19
3.1.1. Version Negotiation ................................20
3.2. Pull Directory Query and Response Messages ................21
3.2.1. Pull Directory Query Message Format ................21
3.2.2. Pull Directory Responses ...........................24
3.2.2.1. Pull Directory Response Message Format ....24
3.2.2.2. Pull Directory Forwarding .................27
3.3. Cache Consistency .........................................28
3.3.1. Update Message Format ..............................32
3.3.2. Acknowledge Message Format .........................33
3.4. Summary of Record Formats in Messages .....................34
3.5. End Stations and Pull Directories .........................34
3.5.1. Pull Directory Hosted on an End Station ............35
3.5.2. Use of Pull Directory by End Stations ..............36
3.5.3. Native Pull Directory Messages .....................37
3.6. Pull Directory Message Errors .............................38
3.6.1. Error Codes ........................................39
3.6.2. Sub-errors under Error Codes 1 and 3 ...............39
3.6.3. Sub-errors under Error Codes 128 and 131 ...........40
3.7. Additional Pull Details ...................................40
3.8. The "No Data" Flag ........................................40
3.9. Pull Directory Service Configuration ......................42
4. Directory Use Strategies and Push-Pull Hybrids .................42
5. TRILL ES-IS ....................................................44
5.1. PDUs and System IDs .......................................45
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46
5.3. Link State ................................................47
6. Security Considerations ........................................47
6.1. Directory Information Security ............................47
6.2. Directory Confidentiality and Privacy .....................47
6.3. Directory Message Security Considerations .................48
7. IANA Considerations ............................................48
7.1. ESADI-Parameter Data Extensions ...........................48
7.2. RBridge Channel Protocol Numbers ..........................49
7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49
7.4. TRILL Pull Directory QTYPEs ...............................50
7.5. Pull Directory Error Code Registries ......................50
7.6. TRILL-ES-IS MAC Address ...................................51
8. References .....................................................51
8.1. Normative References ......................................51
8.2. Informative References ....................................54
Acknowledgments ...................................................55
Authors' Addresses ................................................55
3.5. End Stations and Pull Directories .........................34
3.5.1. Pull Directory Hosted on an End Station ............35
3.5.2. Use of Pull Directory by End Stations ..............36
3.5.3. Native Pull Directory Messages .....................37
3.6. Pull Directory Message Errors .............................38
3.6.1. Error Codes ........................................39
3.6.2. Sub-errors under Error Codes 1 and 3 ...............39
3.6.3. Sub-errors under Error Codes 128 and 131 ...........40
3.7. Additional Pull Details ...................................40
3.8. The "No Data" Flag ........................................40
3.9. Pull Directory Service Configuration ......................42
4. Directory Use Strategies and Push-Pull Hybrids .................42
5. TRILL ES-IS ....................................................44
5.1. PDUs and System IDs .......................................45
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46
5.3. Link State ................................................47
6. Security Considerations ........................................47
6.1. Directory Information Security ............................47
6.2. Directory Confidentiality and Privacy .....................47
6.3. Directory Message Security Considerations .................48
7. IANA Considerations ............................................48
7.1. ESADI-Parameter Data Extensions ...........................48
7.2. RBridge Channel Protocol Numbers ..........................49
7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49
7.4. TRILL Pull Directory QTYPEs ...............................50
7.5. Pull Directory Error Code Registries ......................50
7.6. TRILL-ES-IS MAC Address ...................................51
8. References .....................................................51
8.1. Normative References ......................................51
8.2. Informative References ....................................54
Acknowledgments ...................................................55
Authors' Addresses ................................................55
[RFC7067] gives a problem statement and high-level design for using directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in reducing multi-destination ARP / Neighbor Discovery (ND) [ARPND], reducing unknown unicast flooding traffic, and improving security against address spoofing within a TRILL campus. Because multi-destination traffic becomes an increasing burden as a network scales up in number of nodes, reducing ARP/ND and unknown unicast flooding improves TRILL network scalability. This document describes specific mechanisms for TRILL directory servers.
[RFC7067]给出了使用目录服务器帮助TRILL[RFC6325][RFC7780]边缘节点减少多目标ARP/邻居发现（ND）[ARPND]，减少未知单播泛洪流量，以及提高TRILL园区内地址欺骗安全性的问题陈述和高级设计。由于随着网络节点数量的增加，多目的地流量成为一个越来越大的负担，因此减少ARP/ND和未知单播洪泛提高了TRILL网络的可扩展性。本文档描述TRILL目录服务器的特定机制。
The information held by the directory or directories is address mapping and reachability information -- most commonly, what MAC (Media Access Control) address [RFC7042] corresponds to an IP address within a Data Label (VLAN or FGL (Fine-Grained Label) [RFC7172]) and the egress TRILL switch (RBridge), and, optionally, what specific port on that TRILL switch, from which that MAC address is reachable. But it could be what IP address corresponds to a MAC address or possibly other address mapping or reachability information.
一个或多个目录所持有的信息是地址映射和可达性信息——最常见的是，哪个MAC（媒体访问控制）地址[RFC7042]对应于数据标签（VLAN或FGL（细粒度标签）[RFC7172]）和出口TRILL交换机（RBridge）内的IP地址，并且，可选地，TRILL交换机上的哪个特定端口可以访问MAC地址。但它可能是IP地址对应于MAC地址的内容，也可能是其他地址映射或可达性信息。
The mechanism used to initially populate directory data in primary servers is beyond the scope of this document. A primary server can use the Push Directory service to provide directory data to secondary servers, as described in Section 2.6. In the data-center environment, it is common for orchestration software to know and control where all the IP addresses, MAC addresses, and VLANs/tenants are in a data center. Thus, such orchestration software can be appropriate for providing the directory function or for supplying the directory or directories with directory information.
最初用于在主服务器中填充目录数据的机制超出了本文档的范围。主服务器可以使用推送目录服务向辅助服务器提供目录数据，如第2.6节所述。在数据中心环境中，编排软件通常知道并控制所有IP地址、MAC地址和VLAN/租户在数据中心的位置。因此，这样的编排软件可以适合于提供目录功能或为一个或多个目录提供目录信息。
Efficient routing of unicast traffic in a TRILL campus assumes that the mapping of destination MAC addresses to edge RBridges is stable enough that the default data-plane learning of TRILL and/or the use of directories reduces to an acceptable level the need to flood packets where the location of the destination is unknown. Although not prohibited, "ephemeral" MAC addresses are unlikely to be used in such an environment. Directories need not be complete, and in the case that any ephemeral MAC addresses were in use, they would probably not be included in directory information.
TRILL校园中单播通信量的有效路由假设目标MAC地址到边缘RBridge的映射足够稳定，以使TRILL的默认数据平面学习和/或目录的使用将在目标位置未知的情况下泛洪数据包的需要降低到可接受的水平。虽然没有被禁止，“短暂的”MAC地址不太可能在这样的环境中使用。目录不需要是完整的，并且在使用任何短暂的MAC地址的情况下，它们可能不会包含在目录信息中。
Directory services can be offered in a Push Mode, Pull Mode, or both [RFC7067] at the discretion of the server. Push Mode, in which a directory server pushes information to TRILL switches indicating interest, is specified in Section 2. Pull Mode, in which a TRILL switch queries a server for the information it wants, is specified in Section 3. More detail on modes of operation, including hybrid Push/Pull, are provided in Section 4.
目录服务可以按推送模式、拉送模式或两者[RFC7067]提供，具体由服务器决定。第2节指定了推送模式，其中目录服务器将信息推送到表示感兴趣的TRILL开关。第3节中指定了拉动模式，即TRILL开关向服务器查询它想要的信息。第4节提供了有关操作模式（包括混合推/拉）的更多详细信息。
A TRILL switch can consult directory information whenever it wants by (1) searching through information that has been retained after being pushed to it or pulled by it or (2) requesting information from a Pull Directory. However, the following are expected to be the most common circumstances leading to the use of directory information. All of these are cases of ingressing (or originating) a native frame.
TRILL开关可以随时查阅目录信息，方法是：（1）搜索推送或拉取后保留的信息，或（2）从拉取目录请求信息。但是，以下情况可能是导致使用目录信息的最常见情况。所有这些都是进入（或发起）本机帧的情况。
1. ARP requests and replies [RFC826] are normally broadcast. But a directory-assisted edge TRILL switch could intercept ARP messages and reply if the TRILL switch has the relevant information [ARPND].
1. ARP请求和回复[RFC826]通常是广播的。但目录辅助的边缘颤音交换机可以截获ARP消息，并在颤音交换机具有相关信息[ARPND]时进行回复。
2. IPv6 ND [RFC4861] requests and replies are normally multicast. Except in the case of Secure Neighbor Discovery (SEND) [RFC3971], where possession of the right keying material might be required, a directory-assisted edge TRILL switch could intercept ND messages and reply if the TRILL switch has the relevant information [ARPND].
2. IPv6 ND[RFC4861]请求和回复通常是多播的。除了安全邻居发现（SEND）[RFC3971]的情况外，可能需要拥有正确的键控材料，目录辅助边缘颤音开关可以拦截ND消息，并在颤音开关具有相关信息[ARPND]时进行回复。
3. Unknown destination MAC addresses normally cause a native frame to be flooded. An edge TRILL switch ingressing a native frame necessarily has to determine if it knows the egress RBridge from which the destination MAC address of the frame (in the frame's VLAN or FGL) is reachable. It might have learned that information from the directory or could query the directory if it does not know it. Furthermore, if the edge TRILL switch has complete directory information, it can detect a forged source MAC or IP address in any native frame and discard the frame if it finds such a forged address.
3. 未知的目标MAC地址通常会导致本机帧被淹没。进入本机帧的边缘TRILL交换机必须确定它是否知道可以从哪个出口RBridge访问帧的目标MAC地址（在帧的VLAN或FGL中）。它可能已经从目录中了解到该信息，或者如果不知道该信息，则可以查询该目录。此外，如果edge TRILL交换机具有完整的目录信息，它可以在任何本机帧中检测到伪造的源MAC或IP地址，并在发现此类伪造地址时丢弃该帧。
4. RARP [RFC903] (Reverse ARP) is similar to ARP (item 1 above).
4. RARP[RFC903]（反向ARP）与ARP（上文第1项）类似。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The terminology and abbreviations of [RFC6325] are used herein, along with the following:
此处使用[RFC6325]的术语和缩写，以及以下内容：
AFN: Address Family Number (http://www.iana.org/assignments/address-family-numbers/).
地址家庭号码(http://www.iana.org/assignments/address-family-numbers/).
CSNP Time: Complete Sequence Number Protocol Data Unit (PDU) time. See ESADI [RFC7357] and Section 7.1 below.
CSNP时间：完整序列号协议数据单元（PDU）时间。见ESADI[RFC7357]和下文第7.1节。
Data Label: VLAN or FGL.
数据标签：VLAN或FGL。
ESADI: End Station Address Distribution Information [RFC7357].
ESADI：端站地址分布信息[RFC7357]。
FGL: Fine-Grained Label [RFC7172].
FGL：细粒度标签[RFC7172]。
FR: Flood Record flag bit. See Section 3.2.1.
FR：洪水记录标志位。见第3.2.1节。
Host: A physical server or a virtual machine. A host must have a MAC address and usually has at least one IP address.
主机：物理服务器或虚拟机。主机必须有MAC地址，并且通常至少有一个IP地址。
Interested Labels sub-TLV: Short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176].
感兴趣标签子TLV：简称“感兴趣标签和生成树根子TLV”[RFC7176]。
Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176].
感兴趣的VLAN子TLV：缩写为“感兴趣的VLAN和生成树根子TLV”[RFC7176]。
IP: Internet Protocol. In this document, IP includes both IPv4 and IPv6.
IP：互联网协议。在本文档中，IP包括IPv4和IPv6。
MAC address: Media Access Control address [RFC7042].
MAC地址：媒体访问控制地址[RFC7042]。
MacDA: Destination MAC address.
MacDA：目标MAC地址。
MacSA: Source MAC address.
MacSA：源MAC地址。
OV: Overflow flag bit. See Section 3.2.2.1.
OV：溢出标志位。见第3.2.2.1节。
PDSS: Push Directory Server Status. See Sections 2 and 7.1.
PDSS:推送目录服务器状态。见第2节和第7.1节。
Primary server: A directory server that obtains the information it is providing by a reliable mechanism designed to assure the freshness of that information. This mechanism is outside the scope of this document. (See "Secondary server" below.)
主服务器：一个目录服务器，它通过一种可靠的机制获取它所提供的信息，该机制旨在确保信息的新鲜性。此机制不在本文件的范围内。（请参阅下面的“辅助服务器”。）
PUL: Pull Directory flag bit. See Sections 3 and 7.3.
PUL：拉目录标志位。见第3节和第7.3节。
RBridge: An alternative name for a TRILL switch.
RBridge：颤音开关的另一个名称。
Secondary server: A directory server that obtains the information it is providing from one or more primary servers.
辅助服务器：从一个或多个主服务器获取所提供信息的目录服务器。
TLV: Type, Length, Value.
TLV：类型、长度、值。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL：大量链路的透明互连或链路层中的隧道路由。
TRILL switch: A device that implements the TRILL protocol.
颤音开关：实现颤音协议的设备。
In the Push Model [RFC7067], one or more Push Directory servers reside at TRILL switches and "push down" the address mapping information for the various addresses associated with end-station interfaces and the TRILL switches from which those interfaces are reachable [RFC7961]. This service is scoped by Data Label (VLAN or FGL [RFC7172]). A Push Directory advertises when, for a Data Label, it is configured to be a directory having complete information and also has actually pushed all the information it has. It might be pushing only a subset of the mapping and/or reachability information for a Data Label. The Push Model uses the ESADI [RFC7357] protocol as its distribution mechanism.
在推送模式[RFC7067]中，一个或多个推送目录服务器驻留在TRILL交换机上，并“下推”与终端站接口相关的各种地址的地址映射信息，以及可从中访问这些接口的TRILL交换机[RFC7961]。此服务的范围由数据标签（VLAN或FGL[RFC7172]）确定。对于数据标签，推送目录被配置为具有完整信息的目录，并且实际上已经推送了它所具有的所有信息时，就会进行播发。它可能只是推送数据标签的映射和/或可达性信息的子集。推送模型使用ESADI[RFC7357]协议作为其分发机制。
With the Push Model, if complete address mapping information for a Data Label is being pushed, a TRILL switch (RBridge) that has that complete information and is ingressing a native frame can simply drop the frame if the destination unicast MAC address can't be found in the mapping information available, instead of flooding the frame (ingressing it as an unknown MAC destination TRILL Data frame). But this will result in lost traffic if the ingress TRILL switch's directory information is incomplete.
在推送模式下，如果正在推送数据标签的完整地址映射信息，则如果在可用的映射信息中找不到目标单播MAC地址，则具有该完整信息并正在进入本机帧的TRILL交换机（RBridge）可以简单地丢弃该帧，而不是淹没该帧（将其作为未知的MAC目标TRILL数据帧进入）。但如果ingress TRILL交换机的目录信息不完整，这将导致通信量丢失。
In the Push Model, it is necessary to have a way for a TRILL switch to subscribe to information from the directory server(s). TRILL switches simply use the ESADI [RFC7357] protocol mechanism to announce, in their core IS-IS Link State PDUs (LSPs), the Data Labels
在推送模式中，有必要为TRILL交换机提供一种从目录服务器订阅信息的方式。TRILL交换机仅使用ESADI[RFC7357]协议机制在其核心IS-IS链路状态PDU（LSP）中宣布数据标签
for which they are participating in ESADI by using the Interested VLANs sub-TLV [RFC7176] and/or the Interested Labels sub-TLV [RFC7176]. This will cause the directory information to be pushed to them for all such Data Labels that are being served by the one or more Push Directory servers.
他们通过使用相关VLAN子TLV[RFC7176]和/或相关标签子TLV[RFC7176]参与ESADI。这将导致一个或多个推送目录服务器提供的所有此类数据标签的目录信息被推送到它们。
Push Directory servers advertise, through ESADI, their availability to push the mapping information for a particular Data Label by setting the PDSS in their ESADI-Parameter APPsub-TLV for that ESADI instance (see [RFC7357] and Section 7.1) to a non-zero value. This PDSS field setting is visible to other ESADI participants, including other Push Directory servers, for that Data Label. Each Push Directory server MUST participate in ESADI for the Data Labels for which it will push mappings and set the PDSS field in its ESADI-Parameter APPsub-TLV for that Data Label. For increased robustness, increased bandwidth capability, and improved locality, it is useful to have multiple Push Directory servers for each Data Label. Each Push Directory server is configured with a number N, which is in the range 1 through 8 and defaults to 2, for each Data Label for which it can push directory information (see "PushDirServers" in Section 2.7). If the Push Directory servers for a Data Label are configured consistently with the same N and at least N servers are available, then N copies of that directory will be pushed.
推送目录服务器通过ESADI公布其可用性，通过将ESADI参数APPsub TLV中该ESADI实例的PDS（请参见[RFC7357]和第7.1节）设置为非零值，推送特定数据标签的映射信息。对于该数据标签，此PDSS字段设置对其他ESADI参与者可见，包括其他推送目录服务器。每个推送目录服务器必须为其将推送映射的数据标签参与ESADI，并在其ESADI参数APPsub TLV中为该数据标签设置PDSS字段。为了增强健壮性、增加带宽能力和改进局部性，为每个数据标签提供多个推目录服务器是很有用的。每个推送目录服务器都配置了一个数字N，其范围为1到8，默认为2，用于它可以推送目录信息的每个数据标签（请参阅第2.7节中的“推送目录服务器”）。如果数据标签的推送目录服务器配置一致，且至少有N台服务器可用，则将推送该目录的N个副本。
Each Push Directory server also has a configurable 8-bit priority (PushDirPriority) to be Active, which defaults to 0x3F (see Section 2.7). This priority is treated as an unsigned integer, where the larger magnitude means higher priority. This priority appears in its ESADI-Parameter APPsub-TLV (see Section 7.1). In the case of a tie in this configurable priority, the System ID of the TRILL switch acting as the server is used as a tiebreaker and is treated as an unsigned 6-byte integer, where the larger magnitude indicates higher priority.
每个推送目录服务器也有一个可配置的8位优先级（PushDirPriority）处于活动状态，默认为0x3F（参见第2.7节）。此优先级被视为无符号整数，其中较大的幅值意味着更高的优先级。该优先级出现在其ESADI参数APPsub TLV中（见第7.1节）。在这种可配置优先级的情况下，充当服务器的TRILL开关的系统ID用作断开连接的开关，并被视为无符号6字节整数，其中较大的大小表示较高的优先级。
For each Data Label it can serve, each Push Directory server checks to see if there appear to be enough higher-priority servers to push the desired number of copies. It does this by ordering, by priority, the Push Directory servers whose advertisements are present in the ESADI link-state database for that Data Label and that are data reachable [RFC7780] as indicated by its IS-IS link-state database. The Push Directory server then determines its own position in that order. If a Push Directory server's configuration indicates that N copies of the mappings for a Data Label should be pushed and the server finds that it is number K in the priority ordering (where number 1 in the ordered list is highest priority and the last is
对于它可以提供的每个数据标签，每个推送目录服务器都会检查是否有足够的高优先级服务器来推送所需数量的副本。它通过按优先级排序推送目录服务器来实现这一点，推送目录服务器的播发位于该数据标签的ESADI链路状态数据库中，并且其IS-IS链路状态数据库指示其数据可访问[RFC7780]。然后，推目录服务器按该顺序确定自己的位置。如果推送目录服务器的配置指示应推送数据标签映射的N个副本，并且服务器发现它是优先级排序中的数字K（其中排序列表中的数字1是最高优先级，最后一个是
lowest priority), then if K is less than or equal to N, the Push Directory server is Active. If K is greater than N, it is Stand-By. Active and Stand-By behavior are specified below in Section 2.3.
最低优先级），则如果K小于或等于N，则推送目录服务器处于活动状态。如果K大于N，则为备用。第2.3节规定了主动和备用行为。
For a Push Directory to reside on an end station, one or more TRILL switches locally connected to that end station must proxy for the Push Directory server and advertise themselves in ESADI as Push Directory servers. It appears to the rest of the TRILL campus that these TRILL switches (that are proxying for the end station) are the Push Directory server(s). The protocol between such a Push Directory end station and the one or more proxying TRILL switches acting as Push Directory servers is beyond the scope of this document.
要使推送目录驻留在终端站上，本地连接到该终端站的一个或多个TRILL交换机必须代理推送目录服务器，并在ESADI中作为推送目录服务器进行宣传。在TRILL园区的其余部分看来，这些TRILL交换机（为终端站代理）是推送目录服务器。此类推送目录终端站与作为推送目录服务器的一个或多个代理TRILL交换机之间的协议超出了本文档的范围。
The subsections below describe the states, events, and corresponding actions for Push Directory servers.
下面的小节描述推送目录服务器的状态、事件和相应操作。
The meanings of possible values of the PDSS field in a Push Directory's ESADI-Parameter APPsub-TLV are summarized in the table below.
下表总结了推送目录的ESADI参数APPsub TLV中PDSS字段可能值的含义。
PDSS Meaning
---- ------------------------------------------------------
0 Not a Push Directory server
1 Push Directory server in Stand-By Mode
2 Push Directory server in Active Mode but not complete
3 Push Directory server in Active Mode that has pushed
complete data
PDSS Meaning
---- ------------------------------------------------------
0 Not a Push Directory server
1 Push Directory server in Stand-By Mode
2 Push Directory server in Active Mode but not complete
3 Push Directory server in Active Mode that has pushed
complete data
A Push Directory server is in one of seven states, as listed below, for each Data Label it can serve. The name of each state is followed by a symbol that starts and ends with an angle bracket (for example, "<S1>") and represents the state. The value that the Push Directory server advertises in the PDSS is determined by the state. In addition, it has an internal State-Transition-Time variable for each Data Label it serves that is set at each state transition and that enables it to determine how long it has been in its current state for that Data Label.
对于推送目录服务器可以服务的每个数据标签，推送目录服务器处于以下七种状态之一。每个状态的名称后面都有一个符号，该符号以尖括号（例如“<S1>”）开头和结尾，表示该状态。推送目录服务器在PDS中播发的值由状态确定。此外，对于它所服务的每个数据标签，它都有一个内部状态转换时间变量，该变量在每个状态转换时设置，使它能够确定该数据标签处于当前状态的时间。
Down <S1>: A completely shut down virtual state, defined for convenience in specifying state diagrams. A Push Directory server in this state does not advertise any Push Directory data. It may be participating in ESADI [RFC7357] with the PDSS field set to 0 in its ESADI-Parameter APPsub-TLV, or it might not be participating in ESADI at all. All states other than the Down state are considered to be Up states and imply a non-zero PDSS field.
Down<S1>：完全关闭的虚拟状态，为方便指定状态图而定义。处于此状态的推送目录服务器不会播发任何推送目录数据。它可能正在参与ESADI[RFC7357]，其ESADI参数APPsub TLV中的PDSS字段设置为0，或者它可能根本没有参与ESADI。除Down状态外的所有状态都被视为Up状态，并表示一个非零PDSS字段。
Stand-By <S2>: No Push Directory data is advertised. Any outstanding ESADI-LSP fragments containing directory data are updated to remove that data, and if the result is an empty fragment (contains nothing except possibly an Authentication TLV), the fragment is purged. The Push Directory participates in ESADI [RFC7357] and advertises its ESADI fragment zero that includes an ESADI-Parameter APPsub-TLV with the PDSS field set to 1.
待机<S2>：不播发推送目录数据。任何包含目录数据的未完成ESADI-LSP片段都会被更新以删除该数据，如果结果是空片段（可能除了认证TLV之外不包含任何内容），则该片段将被清除。推送目录参与ESADI[RFC7357]并播发其ESADI片段0，该片段包括ESADI参数APPsub TLV，PDSS字段设置为1。
Active <S3>: The Push Directory participates in ESADI [RFC7357] and advertises its ESADI fragment zero that includes an ESADI-Parameter APPsub-TLV with the PDSS field set to 2. It also advertises its directory data and any changes through ESADI [RFC7357] in its ESADI-LSPs, using the Interface Addresses APPsub-TLV [RFC7961], and updates that information as it changes.
Active<S3>：推送目录参与ESADI[RFC7357]并播发其ESADI片段零，该片段包括ESADI参数APPsub TLV，PDSS字段设置为2。它还通过ESADI LSP中的ESADI[RFC7357]，使用接口地址APPsub TLV[RFC7961]公布其目录数据和任何更改，并在更改时更新该信息。
Active Completing <S4>: The same behavior as the Active state, except that the server responds differently to events. The purpose of this state is to be sure that there has been enough time for directory information to propagate to subscribing edge TRILL switches (see "Time Condition", as defined in Section 2.3.2) before the directory server advertises that the information is complete.
活动完成<S4>：与活动状态相同的行为，只是服务器对事件的响应不同。此状态的目的是确保在目录服务器宣布信息完整之前，有足够的时间将目录信息传播到订阅边缘颤音交换机（请参阅第2.3.2节中定义的“时间条件”）。
Active Complete <S5>: The same behavior as Active, except that the PDSS field in the ESADI-Parameter APPsub-TLV is set to 3 and the server responds differently to events.
Active Complete<S5>：除了ESADI参数APPsub TLV中的PDSS字段设置为3且服务器对事件的响应不同外，其他行为与Active相同。
Going Stand-By Was Complete <S6>: The same behavior as Active, except that the server responds differently to events. The purpose of this state is to be sure that the information indicating that the directory will no longer be complete has enough time to propagate to edge TRILL switches (see "Time Condition" in Section 2.3.2) before the directory server stops advertising updates to the information. (See note below.)
待机已完成<S6>：除了服务器对事件的响应不同之外，与活动的行为相同。此状态的目的是确保在目录服务器停止发布信息更新之前，指示目录将不再完整的信息有足够的时间传播到边缘颤音开关（请参阅第2.3.2节中的“时间条件”）。（见下文注释。）
Active Uncompleting <S7>: The same behavior as Active, except that it responds differently to events. The purpose of this state is to be sure that the information indicating that the directory will no longer be complete has enough time to propagate to edge TRILL
主动未完成<S7>：与主动相同的行为，只是它对事件的响应不同。此状态的目的是确保指示目录将不再完整的信息有足够的时间传播到edge TRILL
switches (see "Time Condition" in Section 2.3.2) before the directory server might stop advertising updates to the information. (See note below.)
在目录服务器可能停止发布信息更新之前切换（请参阅第2.3.2节中的“时间条件”）。（见下文注释。）
Note: It might appear that a Push Directory could transition directly from Active Complete to Active, since the Active state continues to advertise updates, eliminating the need for the Active Uncompleting transition state. But consider the case of the Push Directory that was complete being configured to be incomplete and then the Stand-By Condition (see Section 2.3.2) occurring shortly thereafter. If the first of these two events caused the server to transition directly to the Active state, then later, when the Stand-By Condition occurred, it would immediately transition to Stand-By and stop advertising updates even though there might not have been enough time for knowledge of its incompleteness to have propagated to all edge TRILL switches.
注意：推送目录似乎可以直接从Active Complete转换为Active，因为Active状态会继续播发更新，因此不需要Active Uncompleting转换状态。但是考虑推送目录的情况，该目录被完整地配置为不完整，然后是待机状态（见第2.3.2节）。如果这两个事件中的第一个事件导致服务器直接转换为活动状态，那么稍后，当备用条件发生时，它将立即过渡到待机状态并停止广告更新，即使可能没有足够的时间将其不完整的信息传播到所有edge TRILL交换机。
The following table lists each state and its corresponding PDSS value:
下表列出了每个状态及其对应的PDSS值：
State PDSS
-------------------------------- ------
Down <S1> 0
Stand-By <S2> 1
Active <S3> 2
Active Completing <S4> 2
Active Complete <S5> 3
Going Stand-By Was Complete <S6> 2
Active Uncompleting <S7> 2
State PDSS
-------------------------------- ------
Down <S1> 0
Stand-By <S2> 1
Active <S3> 2
Active Completing <S4> 2
Active Complete <S5> 3
Going Stand-By Was Complete <S6> 2
Active Uncompleting <S7> 2
Three auxiliary conditions, referenced later in this subsection, are defined as follows:
本小节后面引用的三个辅助条件定义如下：
The Activate Condition: In order to have the desired number of Push Directory servers pushing data for Data Label X, this Push Directory server should be active. This is determined by the server finding that (a) it is priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it is configured that there should be N copies pushed for Data Label X, and (c) K is less than or equal to N. For example, the Push Directory server is configured so that two copies should be pushed and finds that it is priority 1 or 2 among the Push Directory servers that are visible in its ESADI link-state database and that are data reachable, as indicated by its IS-IS link-state database.
激活条件：为了使所需数量的推送目录服务器为数据标签X推送数据，此推送目录服务器应处于活动状态。这是由服务器发现（a）数据标签X的数据可访问推送目录服务器（其中最高优先级服务器为1）中的优先级为K，（b）配置为数据标签X应推送N个副本，以及（c）K小于或等于N来确定的。例如，推送目录服务器的配置应确保推送两个副本，并发现在其ESADI链路状态数据库中可见且数据可访问的推送目录服务器中，其优先级为1或2，如其is-is链路状态数据库所示。
The Stand-By Condition: In order to have the desired number of Push Directory servers pushing data for Data Label X, this Push Directory server should be Stand-By (not Active). This is determined by the server finding that (a) it is priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it is configured that there should be N copies pushed for Data Label X, and (c) K is greater than N. For example, the Push Directory server is configured so that two copies should be pushed and finds that it is priority 3 or lower priority (higher number) among the available Push Directory servers.
待机条件：为了让所需数量的推送目录服务器为数据标签X推送数据，此推送目录服务器应处于待机状态（非活动状态）。这是由服务器发现（a）数据标签X的数据可访问推送目录服务器（其中最高优先级服务器为1）中的优先级为K，（b）配置为数据标签X应推送N个副本，以及（c）K大于N来确定的。例如，推送目录服务器的配置应确保推送两个副本，并在可用的推送目录服务器中发现其优先级为3或更低（更高的数量）。
The Time Condition: The Push Directory server has been in its current state for a configurable amount of time (PushDirTimer) that defaults to twice its CSNP (Complete Sequence Number PDU) time (see Sections 2.7 and 7.1).
时间条件：推送目录服务器已处于其当前状态一段可配置的时间（PushDirTimer），默认为其CSNP（完整序列号PDU）时间的两倍（见第2.7节和第7.1节）。
The events and conditions listed below cause state transitions in Push Directory servers.
下面列出的事件和条件会导致推送目录服务器中的状态转换。
1. The Push Directory server comes up.
1. 推送目录服务器出现。
2. The Push Directory server or the TRILL switch on which it resides is being shut down. This is a persistent condition, unless the shutdown is canceled. So, for example, a Push Directory server in the Going Stand-By Was Complete state does not transition out of that state due to this condition but, after (1) the Time Condition is met and (2) the directory transitions to Stand-By and then performs the actions required there (such as purging LSPs), continues to the Down state if this condition is still true. Similar comments apply to events/conditions 3, 4, and 5.
2. 推送目录服务器或其所在的TRILL开关正在关闭。这是一种持续状态，除非关闭被取消。因此，例如，处于待命状态的推送目录服务器不会由于此条件而从该状态转换出去，但是，在（1）满足时间条件和（2）目录转换到待命状态后，然后执行此处所需的操作（例如清除LSP），如果此条件仍然为真，则继续到关闭状态。类似的注释适用于事件/条件3、4和5。
3. The Activate Condition is met, and the server's configuration indicates that it does not have complete data.
3. 满足激活条件，并且服务器的配置表明它没有完整的数据。
4. The Stand-By Condition is met.
4. 满足备用条件。
5. The Activate Condition is met, and the server's configuration indicates that it has complete data.
5. 满足激活条件，并且服务器的配置表明其具有完整的数据。
6. The server's configuration is changed to indicate that it does not have complete data.
6. 服务器的配置已更改，以指示它没有完整的数据。
7. The Time Condition is met.
7. 满足时间条件。
The state transition table is as follows:
状态转换表如下所示：
| | | | Active | Active | Going | Active
State|Down|Stand-By|Active|Completing|Complete| Stand-By |Uncompleting
-----+ | | | | |Was Complete|
Event|<S1>| <S2> | <S3> | <S4> | <S5> | <S6> | <S7>
-----+----+--------+------+----------+--------+------------+------------
1 |<S2>| N/A | N/A | N/A | N/A | N/A | N/A
2 |<S1>| <S1> | <S2> | <S2> | <S6> | <S6> | <S7>
3 |<S1>| <S3> | <S3> | <S3> | <S7> | <S3> | <S7>
4 |<S1>| <S2> | <S2> | <S2> | <S6> | <S6> | <S6>
5 |<S1>| <S4> | <S4> | <S4> | <S5> | <S5> | <S5>
6 |<S1>| <S2> | <S3> | <S3> | <S7> | <S6> | <S7>
7 |<S1>| <S2> | <S3> | <S5> | <S5> | <S2> | <S3>
| | | | Active | Active | Going | Active
State|Down|Stand-By|Active|Completing|Complete| Stand-By |Uncompleting
-----+ | | | | |Was Complete|
Event|<S1>| <S2> | <S3> | <S4> | <S5> | <S6> | <S7>
-----+----+--------+------+----------+--------+------------+------------
1 |<S2>| N/A | N/A | N/A | N/A | N/A | N/A
2 |<S1>| <S1> | <S2> | <S2> | <S6> | <S6> | <S7>
3 |<S1>| <S3> | <S3> | <S3> | <S7> | <S3> | <S7>
4 |<S1>| <S2> | <S2> | <S2> | <S6> | <S6> | <S6>
5 |<S1>| <S4> | <S4> | <S4> | <S5> | <S5> | <S5>
6 |<S1>| <S2> | <S3> | <S3> | <S7> | <S6> | <S7>
7 |<S1>| <S2> | <S3> | <S5> | <S5> | <S2> | <S3>
The above state table is equivalent to the following transition diagram:
上述状态表相当于以下转换图：
+-----------+
| Down <S1> |<---------+
+-----------+ |
|1 ^ | 3,4,5,6,7 |
| | +------------+
V |2
+---------------+
| Stand-By <S2> |<--------------------------------------+
+---------------+ ^ ^ ^ |
|5 |3 |1,4,6,7 | | | |
| | +---------+ | | |
| V |2,4 | |
| +---------------------+ | |
| | Active <S3> |<---------|-------------+ |
| +---------------------+ ^ | | |
| |5 ^ |1,3,6,7 ^ | | | |
| | | | | | | | |
| | | +---------+ | | | |
| | | | | | |
V V |3,6 | | | |
+------------------------+ | | | |
| Active Completing <S4> |------------+ | |
+------------------------+ 2,4 | | |
|7 |1,5 ^ | | |
| | | | | |
| +-------+ | | |
| | | |
| +------------------------------------+ | |
| | | | | |
V V |7 |5 |3 |7
+-------------+ 3,6 +----------------+ 4 +----------------+
| Active |------->| Active |--->| Going Stand-By |
| Complete | | Uncompleting | | Was Complete |
| <S5> |<-------| <S7> | | <S6> |
+-------------+ 5 +----------------+ +----------------+
|1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^
| | | | | | | |
+-------+ | +------------+ | +--------+
| |
+----------------------------------+
+-----------+
| Down <S1> |<---------+
+-----------+ |
|1 ^ | 3,4,5,6,7 |
| | +------------+
V |2
+---------------+
| Stand-By <S2> |<--------------------------------------+
+---------------+ ^ ^ ^ |
|5 |3 |1,4,6,7 | | | |
| | +---------+ | | |
| V |2,4 | |
| +---------------------+ | |
| | Active <S3> |<---------|-------------+ |
| +---------------------+ ^ | | |
| |5 ^ |1,3,6,7 ^ | | | |
| | | | | | | | |
| | | +---------+ | | | |
| | | | | | |
V V |3,6 | | | |
+------------------------+ | | | |
| Active Completing <S4> |------------+ | |
+------------------------+ 2,4 | | |
|7 |1,5 ^ | | |
| | | | | |
| +-------+ | | |
| | | |
| +------------------------------------+ | |
| | | | | |
V V |7 |5 |3 |7
+-------------+ 3,6 +----------------+ 4 +----------------+
| Active |------->| Active |--->| Going Stand-By |
| Complete | | Uncompleting | | Was Complete |
| <S5> |<-------| <S7> | | <S6> |
+-------------+ 5 +----------------+ +----------------+
|1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^
| | | | | | | |
+-------+ | +------------+ | +--------+
| |
+----------------------------------+
Figure 1: Push Server State Diagram
图1：推送服务器状态图
End-station hosting and end-station use of Push Directories are outside the scope of this document. Push Directory information distribution is accomplished using ESADI [RFC7357], which does not operate to end stations. In the future, ESADI might be extended to operate to end stations, or some other method, such as BGP, might be specified as a way to support end-station hosting or end-station use of Push Directories.
端站托管和端站推送目录的使用不在本文档的范围内。推送目录信息分发是使用ESADI[RFC7357]完成的，ESADI不操作到终端站。将来，ESADI可能会扩展到终端站，或者某些其他方法（如BGP）可能会被指定为支持终端站托管或终端站使用推送目录的方法。
Push Directory mappings can be distinguished from other data distributed through ESADI, because mappings are distributed only with the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that APPsub-TLV as being Push Directory data.
推送目录映射可以与通过ESADI分发的其他数据区分开来，因为映射仅使用接口地址APPsub TLV[RFC7961]分发，并且在该APPsub TLV中标记为推送目录数据。
TRILL switches, whether or not they are Push Directory servers, MAY continue to advertise any locally learned MAC attachment information in ESADI [RFC7357] using the MAC-Reachability TLV [RFC6165]. However, if a Data Label is being served by complete Push Directory servers, advertising such a locally learned MAC attachment generally SHOULD NOT be done, as it would not add anything and would just waste bandwidth and ESADI link-state space. An exception might be when a TRILL switch learns local MAC connectivity and that information appears to be missing from the directory mapping.
TRILL交换机，无论是否为推送目录服务器，都可以使用MAC可达性TLV[RFC6165]继续在ESADI[RFC7357]中公布任何本地学习到的MAC连接信息。但是，如果数据标签由完整的推送目录服务器提供，则通常不应宣传这种本地学习的MAC附件，因为它不会添加任何内容，只会浪费带宽和ESADI链路状态空间。例外情况可能是TRILL交换机了解本地MAC连接，并且目录映射中似乎缺少该信息。
Because a Push Directory server needs to advertise interest in one or more Data Labels even though it might not want to receive multi-destination TRILL Data packets in those Data Labels, the "No Data" (NOD) flag bit is provided, as discussed in Section 3.8.
由于推送目录服务器需要公布对一个或多个数据标签的兴趣，即使它可能不希望在这些数据标签中接收多目标TRILL数据包，因此提供了“无数据”（NOD）标志位，如第3.8节所述。
When a Push Directory server is no longer data reachable [RFC7780], as indicated by the IS-IS link-state database, other TRILL switches MUST ignore any Push Directory data from that server, because it is no longer being updated and may be stale.
如is-is链路状态数据库所示，当推送目录服务器不再具有数据可访问性[RFC7780]时，其他TRILL开关必须忽略来自该服务器的任何推送目录数据，因为它不再被更新并且可能已过时。
The nature of dynamic distributed asynchronous systems is such that it is impossible for a TRILL switch receiving Push Directory information to be absolutely certain that it has complete information. However, it can obtain a reasonable assurance of complete information by requiring that two conditions be met:
动态分布式异步系统的本质是，接收推送目录信息的TRILL交换机不可能绝对确定它拥有完整的信息。但是，它可以通过要求满足两个条件来获得完整信息的合理保证：
1. The PDSS field is 3 in the ESADI fragment zero from the server for the relevant Data Label.
1. 相关数据标签服务器的ESADI片段0中的PDSS字段为3。
2. As far as it can tell, it has had continuous data connectivity to the server for a configurable amount of time that defaults to twice the server's CSNP time (see "PushDirTimer" in Section 2.7).
2. 据它所知，它与服务器的连续数据连接时间可配置，默认为服务器CSNP时间的两倍（见第2.7节中的“PushDirTimer”）。
Condition 2 is necessary because a client TRILL switch might be just coming up and receive an ESADI-LSP meeting the requirement in condition 1 above but has not yet received all of the ESADI-LSP fragments from the Push Directory server.
条件2是必要的，因为客户端TRILL交换机可能刚刚启动并接收到满足上述条件1要求的ESADI-LSP，但尚未从推目录服务器接收到所有ESADI-LSP片段。
Likewise, due to various delays, when an end station connects to or disconnects from the campus, there are timing differences between such a connection or disconnection, the update of directory information at the directory, and the update of directory information at any particular RBridge in the TRILL campus. Thus, there is commonly a small window during which an RBridge using directory information might either (1) drop or unnecessarily flood a frame as having an unknown unicast destination or (2) encapsulate a frame to an edge RBridge where the end station is no longer connected when the frame arrives at that edge RBridge.
类似地，由于各种延迟，当终端站连接到园区或从园区断开连接时，这种连接或断开、目录处目录信息的更新和TRILL园区中任何特定RBridge处目录信息的更新之间存在时序差异。因此，通常存在一个小窗口，在此期间，使用目录信息的RBridge可能（1）丢弃或不必要地淹没具有未知单播目的地的帧，或者（2）将帧封装到边缘RBridge，其中当帧到达该边缘RBridge时端站不再连接。
There may be conflicts between mapping information from different Push Directory servers or conflicts between locally learned information and information received from a Push Directory server. In cases of such conflicts, information with a higher confidence value [RFC6325] [RFC7961] is preferred over information with a lower confidence value. In cases of equal confidence values, Push Directory information is preferred to locally learned information, and if information from Push Directory servers conflicts, the information from the higher-priority Push Directory server is preferred.
来自不同推送目录服务器的映射信息之间可能存在冲突，或者本地获取的信息与从推送目录服务器接收的信息之间可能存在冲突。在此类冲突的情况下，具有较高置信值[RFC6325][RFC7961]的信息优先于具有较低置信值的信息。在置信值相等的情况下，推送目录信息优先于本地学习的信息，并且如果来自推送目录服务器的信息冲突，则来自更高优先级的推送目录服务器的信息优先。
A secondary Push or Pull Directory server is one that obtains its data from a primary directory server. Such systems, where some directory servers can be populated from others, have been found useful for multiple-server directory applications -- for example, in the DNS, where it is the normal case that some authoritative servers (secondary servers) are populated with data from other authoritative servers (primary servers).
辅助推或拉目录服务器是从主目录服务器获取其数据的服务器。这样的系统，其中一些目录服务器可以从其他目录服务器填充，对于多个服务器目录应用程序非常有用——例如，在DNS中，一些权威服务器（辅助服务器）通常由来自其他权威服务器（主服务器）的数据填充。
Other techniques MAY be used, but by default, this data transfer occurs through the primary server acting as a Push Directory server for the Data Labels involved, while the secondary directory server takes the pushed data it receives from the highest-priority Push Directory server and re-originates it. Such a secondary server may be a Push Directory server, a Pull Directory server, or both for any particular Data Label. Because the data from a secondary server
可以使用其他技术，但默认情况下，此数据传输通过主服务器进行，主服务器充当所涉及数据标签的推送目录服务器，而次目录服务器从最高优先级的推送目录服务器接收推送数据并重新发起。对于任何特定的数据标签，这样的辅助服务器可以是推目录服务器、拉目录服务器或两者。因为数据来自辅助服务器
will necessarily be at least a little less fresh than that from a primary server, it is RECOMMENDED that the re-originated secondary server's data be given a confidence level at least one less than that of the data as received from the primary server (or unchanged if it is already of minimum confidence).
将必然比主服务器的数据新鲜一点，建议重新生成的辅助服务器的数据的置信度至少比从主服务器接收的数据的置信度低一级（或者，如果已经是最小置信度，则保持不变）。
The following configuration parameters, per Data Label, are available for controlling Push Directory behavior:
每个数据标签的以下配置参数可用于控制推送目录行为：
Name Range/Setting Default Section
--------------- ------------- --------- ------------
PushDirService true/false false 2.2
PushDirServers 1-8 2 2.2
PushDirPriority 0-255 0x3F 2.2
PushDirComplete true/false false 2.3.1, 2.3.2
PushDirTimer 1-511 2 * CSNP 2.3.2, 2.5
Name Range/Setting Default Section
--------------- ------------- --------- ------------
PushDirService true/false false 2.2
PushDirServers 1-8 2 2.2
PushDirPriority 0-255 0x3F 2.2
PushDirComplete true/false false 2.3.1, 2.3.2
PushDirTimer 1-511 2 * CSNP 2.3.2, 2.5
PushDirService is a boolean. When false, Push Directory service is not provided; when true, it is.
PushDirService是一个布尔值。如果为false，则不提供推送目录服务；如果是真的，那就是真的。
PushDirComplete is a boolean. When false, the server never indicates that the information it has pushed is complete; when true, it does so indicate after pushing all the information it knows.
PushDirComplete是一个布尔值。如果为false，则服务器从不表示其推送的信息已完成；如果为true，则在推送它知道的所有信息后，它会这样做。
PushDirTimer defaults to two times the ESADI-CSNP configuration value but not less than 1 second.
PushDirTimer默认为ESADI-CSNP配置值的两倍，但不少于1秒。
In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory information from an appropriate directory server when needed.
在Pull模型[RFC7067]中，TRILL开关（RBridge）在需要时从适当的目录服务器中提取目录信息。
A TRILL switch that makes use of Pull Directory services must implement appropriate connections between its directory utilization and its link-state database and link-state updating. For example, Pull Directory servers for a particular Data Label X are found by looking in the core TRILL IS-IS link-state database for data-reachable [RFC7780] TRILL switches that advertise themselves by setting the Pull Directory flag (PUL) to 1 in their Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label. The set of such switches can change with configuration changes by network management, such as the following:
使用Pull目录服务的TRILL交换机必须在其目录利用率和链接状态数据库以及链接状态更新之间实现适当的连接。例如，通过在核心TRILL IS-IS链路状态数据库中查找可访问数据的[RFC7780]TRILL交换机，可以找到特定数据标签X的拉目录服务器，这些交换机通过在其感兴趣的VLAN子TLV或该数据标签的感兴趣的标签子TLV（见第7.3节）中将拉目录标志（PUL）设置为1来宣传自己。这组交换机可以通过网络管理随配置更改而更改，例如：
o the startup or shutdown of Pull Directory servers
o 拉目录服务器的启动或关闭
o changes in network topology, such as the connection or disconnection of TRILL switches that are Pull Directory servers
o 网络拓扑的更改，例如连接或断开作为拉目录服务器的TRILL交换机
o network partition or merger
o 网络分割或合并
As described in Section 3.7, a TRILL switch MUST be able to detect that a Pull Directory from which it has cached data is no longer data reachable so that it can discard such cached data.
如第3.7节所述，TRILL开关必须能够检测到其缓存数据所在的Pull目录不再是可访问的数据，以便可以丢弃此类缓存数据。
If multiple data-reachable TRILL switches indicate in the link-state database that they are Pull Directory servers for a particular Data Label, pull requests can be sent to any one or more of them, but it is RECOMMENDED that pull requests be preferentially sent to the server or servers that are lowest cost from the requesting TRILL switch.
如果链接状态数据库中的多个数据可访问TRILL交换机指示它们是特定数据标签的拉目录服务器，则可以向其中任何一个或多个发送拉请求，但建议优先将拉请求发送到请求TRILL交换机成本最低的一个或多个服务器。
Pull Directory requests are sent by encapsulating them in an RBridge Channel [RFC7178] message using the Pull Directory channel protocol number (see Section 7.2). Responses are returned in an RBridge Channel message using the same channel protocol number. See Section 3.2 for Query and Response Message formats. For cache consistency or notification purposes, Pull Directory servers, under certain conditions, MUST send unsolicited Update Messages to client TRILL switches they believe may be holding old data. Those clients can acknowledge such updates, as described in Section 3.3. All these messages have a common header, as described in Section 3.1. Errors are returned as described in Section 3.6.
拉目录请求通过使用拉目录通道协议号将它们封装在RBridge通道[RFC7178]消息中来发送（参见第7.2节）。使用相同的通道协议号在RBridge通道消息中返回响应。查询和响应消息格式见第3.2节。出于缓存一致性或通知目的，拉目录服务器在某些情况下必须向其认为可能保存旧数据的客户端TRILL交换机发送未经请求的更新消息。如第3.3节所述，这些客户可以确认此类更新。所有这些消息都有一个共同的标题，如第3.1节所述。如第3.6节所述，返回错误。
The requests to Pull Directory servers are typically derived from ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages, or data frames with unknown unicast destination MAC addresses, intercepted by an ingress TRILL switch, as described in Section 1.1.
如第1.1节所述，拉入目录服务器的请求通常来自入口ARP[RFC826]、ND[RFC4861]、RARP[RFC903]或发送[RFC3971]消息，或具有未知单播目标MAC地址的数据帧，由入口TRILL交换机截获。
Pull Directory responses include an amount of time for which the response should be considered valid. This includes negative responses that indicate that no data is available. It is RECOMMENDED that both positive responses with data and negative responses be cached and used to locally handle ARP, ND, RARP, unknown destination MAC frames, or the like [ARPND], until the responses expire. If information previously pulled is about to expire, a TRILL switch MAY try to refresh it by issuing a new pull request but, to avoid unnecessary requests, SHOULD NOT do so unless it has been recently used. The validity timer of cached Pull Directory responses is NOT reset or extended merely because that cache entry is used.
拉目录响应包括响应应被视为有效的时间量。这包括表明没有可用数据的否定回答。建议缓存带数据的肯定响应和否定响应，并用于本地处理ARP、ND、RARP、未知目标MAC帧等[ARPND]，直到响应过期。如果以前提取的信息即将过期，TRILL开关可以通过发出新的提取请求来尝试刷新它，但为了避免不必要的请求，除非最近使用过它，否则不应该这样做。缓存的拉目录响应的有效性计时器不会仅因为使用了该缓存项而重置或扩展。
All Pull Directory messages are transmitted as the Channel Protocol-specific payload of RBridge Channel messages [RFC7178]. Pull Directory messages are formatted as described herein, starting with the following common 8-byte header:
所有拉目录消息都作为RBridge通道消息的通道协议特定有效负载进行传输[RFC7178]。拉动目录消息的格式如本文所述，从以下常见的8字节头开始：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Specific Payload - variable length
+-+-+- ...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Specific Payload - variable length
+-+-+- ...
Ver: Version of the Pull Directory protocol. An unsigned integer. Version 0 (zero) is specified in this document. See Section 3.1.1 for a discussion of version negotiation.
版本：拉目录协议的版本。无符号整数。本文档中指定了版本0（零）。有关版本协商的讨论，请参见第3.1.1节。
Type: The Pull Directory message type, as follows:
类型：拉目录消息类型，如下所示：
Type Section Name
---- ------- ------------
0 - Reserved
1 3.2.1 Query
2 3.2.2 Response
3 3.3.1 Update
4 3.3.2 Acknowledge
5-14 - Unassigned
15 - Reserved
Type Section Name
---- ------- ------------
0 - Reserved
1 3.2.1 Query
2 3.2.2 Response
3 3.3.1 Update
4 3.3.2 Acknowledge
5-14 - Unassigned
15 - Reserved
Flags: Four flag bits whose meaning depends on the Pull Directory message type. Flags whose meanings are not specified are reserved, MUST be sent as zero, and MUST be ignored on receipt.
标志：四个标志位，其含义取决于拉目录消息类型。未指定含义的标志是保留的，必须作为零发送，并且在收到时必须忽略。
Count: Some Pull Directory message types specified herein have zero or more occurrences of a Record as part of the type-specific payload. The Count field is the number of occurrences of that Record and is expressed as an unsigned integer. For any Pull Directory messages not structured with such occurrences, this field MUST be sent as zero and ignored on receipt.
计数：此处指定的某些拉目录消息类型在特定于类型的有效负载中，记录的出现次数为零或更多。Count字段是该记录的出现次数，表示为无符号整数。对于任何未使用此类事件构造的Pull Directory消息，此字段必须作为零发送，并在收到时忽略。
Err, SubErr: A two-part error code. These fields are only used in Reply Messages. In messages that are requests or updates, these fields MUST be sent as zero and ignored on receipt. An Err field containing the value zero means no error. The meaning of values in the SubErr field depends on the value of the Err field, but in all cases, a zero SubErr field is allowed and provides no additional information beyond the value of the Err field.
Err，SubErr：由两部分组成的错误代码。这些字段仅用于回复消息。在属于请求或更新的邮件中，这些字段必须作为零发送，并且在收到时忽略。包含值为零的Err字段表示无错误。SubErr字段中值的含义取决于Err字段的值，但在所有情况下，都允许零SubErr字段，并且不提供Err字段值以外的其他信息。
Sequence Number: An identifying 32-bit quantity set by the TRILL switch sending a request or other unsolicited message and returned in every corresponding reply or acknowledgment. It is used to match up responses with the message to which they respond.
序列号：由TRILL开关发送请求或其他未经请求的消息并在每个相应的回复或确认中返回的识别32位数量。它用于将响应与其响应的消息进行匹配。
Type Specific Payload: Format depends on the Pull Directory message type.
特定于类型的有效负载：格式取决于拉目录消息类型。
The version number (Ver) in the Pull Directory message header is incremented for a future version with changes such that TRILL directory messages cannot be parsed correctly by an earlier version. Ver is not incremented for minor changes such as defining a new field value for an existing field.
对于未来版本，拉动目录消息头中的版本号（Ver）会随着更改而增加，从而早期版本无法正确解析TRILL目录消息。对于较小的更改（例如为现有字段定义新字段值），版本不会增加。
Pull Directory messages come in pairs (Request-Response, Update-Acknowledgment). The version number in the Request/Update (Ver1) indicates the format of that message and the format of the corresponding returned Response/Acknowledgment. The version number in the returned Response/Acknowledgment (Ver2) indicates the highest version number that the sender of that Response/Acknowledgment understands.
拉目录消息成对出现（请求-响应、更新-确认）。请求/更新（Ver1）中的版本号表示该消息的格式以及相应返回的响应/确认的格式。返回的响应/确认（Ver2）中的版本号表示该响应/确认的发送方理解的最高版本号。
In the most common case -- a well-configured network -- Ver1 and Ver2 will be equal.
在最常见的情况下——配置良好的网络——Ver1和Ver2将相等。
If Ver2 is less than Ver1, the returned Response/Acknowledgment will be an error message saying that the version is not understood.
如果Ver2小于Ver1，则返回的响应/确认将是一条错误消息，表明版本不可理解。
If Ver2 is greater than Ver1 and the responder understands Ver1, it responds normally in Ver1 format. However, if the responder does not understand Ver1, it MUST send a "Version not understood" error message (Section 3.6.2) correctly formatted for Ver1. Thus, all implementations that support some version X MUST be able to send a Version not understood error message correctly formatted for all lower versions down to version 0.
如果Ver2大于Ver1，并且响应者理解Ver1，则它将以Ver1格式正常响应。但是，如果响应者不理解Ver1，则必须发送一条针对Ver1正确格式化的“版本不理解”错误消息（第3.6.2节）。因此，所有支持某个版本X的实现必须能够发送一条版本不可理解的错误消息，该消息的格式对于从版本0到所有较低版本都是正确的。
The formats of Pull Directory Query Messages and Pull Directory Response Messages are specified in Sections 3.2.1 and 3.2.2.1, respectively.
拉目录查询消息和拉目录响应消息的格式分别在第3.2.1节和第3.2.2.1节中规定。
A Pull Directory Query Message is sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). The Data Label of the packet is the Data Label in which the query is being made. The priority of the RBridge Channel message is a mapping of the priority of the ingressed frame that caused the query. The default mapping depends, per Data Label, on the strategy (see Section 4) or a configured priority (see "DirGenQPriority" in Section 3.9) for generated queries. (Generated queries are those queries that are not the result of a mapping -- for example, a query to refresh a cache entry.) The Channel Protocol-specific data is formatted as a header and a sequence of zero or more QUERY Records as follows:
拉目录查询消息作为RBridge通道消息[RFC7178]TRILL数据包的通道协议特定内容或本机RBridge通道数据帧发送（见第3.5节）。数据包的数据标签是进行查询的数据标签。RBridge通道消息的优先级是导致查询的进入帧优先级的映射。每个数据标签的默认映射取决于生成查询的策略（请参见第4节）或配置的优先级（请参见第3.9节中的“DirGenQPriority”）。（生成的查询是那些不是映射结果的查询——例如，刷新缓存项的查询。）通道协议特定数据的格式为标头和零个或多个查询记录序列，如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Ver, Sequence Number: See Section 3.1.
版本，序列号：见第3.1节。
Type: 1 for Query. Queries received by a TRILL switch that is not a Pull Directory for the relevant Data Label result in an error response (see Section 3.6) unless inhibited by rate limiting. (See [RFC7178] for information on the Response Message that is generated if the recipient implements the RBridge Channel features but does not implement the Pull Directory RBridge Channel Protocol.)
类型：1用于查询。TRILL开关接收到的查询不是相关数据标签的拉动目录，除非受到速率限制的抑制，否则会导致错误响应（见第3.6节）。（请参阅[RFC7178]了解收件人实现RBridge通道功能但未实现拉目录RBridge通道协议时生成的响应消息的信息。）
Flags, Err, and SubErr: MUST be sent as zero and ignored on receipt.
标志、错误和子错误：必须作为零发送，并在收到时忽略。
Count: Count is the number of QUERY Records present. A Query Message Count of 0 is explicitly allowed, for the purpose of pinging a Pull Directory server to see if it is responding. On receipt of such an empty Query Message, a Response Message that also has a Count of 0 is returned unless inhibited by rate limiting.
Count:Count是存在的查询记录数。为了ping拉目录服务器以查看其是否响应，明确允许查询消息计数为0。收到此类空查询消息时，将返回计数为0的响应消息，除非速率限制禁止。
QUERY: Each QUERY Record within a Pull Directory Query Message is formatted as follows:
查询：Pull目录查询消息中的每个查询记录的格式如下：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |FR| RESV | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If QTYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Address ...
+--+--+--+--+--+--+--+--+--+--+--...
If QTYPE = 2 or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Frame ...
+--+--+--+--+--+--+--+--+--+--+--...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |FR| RESV | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If QTYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Address ...
+--+--+--+--+--+--+--+--+--+--+--...
If QTYPE = 2 or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Frame ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: Size of the QUERY Record in bytes, expressed as an unsigned integer and not including the SIZE field and following byte. A value of SIZE so large that the material doesn't fit in the Query Message indicates a malformed QUERY Record. A QUERY Record with such an illegal SIZE value, and any subsequent QUERY Records, MUST be ignored, and the entire Query Message MAY be ignored.
大小：查询记录的大小（以字节为单位），表示为无符号整数，不包括大小字段和后面的字节。如果大小的值太大，以至于材料不适合查询消息，则表示查询记录的格式不正确。必须忽略具有此类非法大小值的查询记录以及任何后续查询记录，并且可以忽略整个查询消息。
FR: The Flood Record flag. Ignored if QTYPE is 1. If QTYPE is 2 or 5 and the directory information sought is not found, the frame provided is flooded; otherwise, it is not forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or 5, the FR flag has no effect.
FR：洪水记录标志。如果QTYPE为1，则忽略。如果QTYPE为2或5且未找到所需的目录信息，则提供的帧被淹没；否则，它不会被转发。见第3.2.2.2节。对于2或5以外的QType，FR标志无效。
RESV: A block of three reserved bits. MUST be sent as zero and ignored on receipt.
RESV：由三个保留位组成的块。必须作为零发送，并在收到时忽略。
QTYPE: There are several types of QUERY Records currently defined in two classes, as follows: (1) a QUERY Record that provides an explicit address and asks for all addresses for the interface specified by the Query Address and (2) a QUERY Record that includes a frame. The fields of each are specified below. Values of QTYPE are as follows:
QTYPE：目前在两个类中定义了几种类型的查询记录，如下所示：（1）提供显式地址并要求查询地址指定的接口的所有地址的查询记录；（2）包含帧的查询记录。下面指定了每个字段的字段。QTYPE的值如下所示：
QTYPE Description
----- -------------------------------
0 Reserved
1 Address query
2 Frame query
3-4 Unassigned
5 Unknown unicast MAC Query Frame
6-14 Unassigned
15 Reserved
QTYPE Description
----- -------------------------------
0 Reserved
1 Address query
2 Frame query
3-4 Unassigned
5 Unknown unicast MAC Query Frame
6-14 Unassigned
15 Reserved
AFN: Address Family Number of the Query Address.
AFN：查询地址的地址族号。
Query Address: The query is asking for any other addresses, and the nickname of the TRILL switch from which they are reachable, that correspond to the same interface as this address, within the Data Label of the query of the address provided. A typical Query Address would be something like the following:
查询地址：查询是在所提供地址查询的数据标签内，请求与此地址对应的任何其他地址，以及可从中访问这些地址的TRILL开关的昵称。典型的查询地址如下所示：
1. A 48-bit MAC address, with the querying TRILL switch primarily interested in either
1. 一个48位MAC地址，查询TRILL开关主要对其中一个感兴趣
a. the RBridge by which that MAC address is reachable, so that the querying RBridge can forward an unknown (before the query) destination MAC address native frame as a unicast TRILL Data packet rather than flooding it, or
a. 可访问该MAC地址的RBridge，以便查询RBridge可以将未知（在查询之前）目标MAC地址本机帧作为单播TRILL数据包转发，而不是将其淹没，或者
b. the IP address corresponding to the MAC address, so that the RBridge can locally respond to a RARP [RFC903] native frame.
b. 与MAC地址相对应的IP地址，以便RBridge可以本地响应RARP[RFC903]本机帧。
2. An IPv4 or IPv6 address, with the querying RBridge interested in the corresponding MAC address so it can locally respond to an ARP [RFC826] or ND [RFC4861] native frame [ARPND].
2. IPv4或IPv6地址，查询RBridge对相应的MAC地址感兴趣，因此它可以本地响应ARP[RFC826]或ND[RFC4861]本机帧[ARPND]。
But the Query Address could be some other address type for which an AFN has been assigned, such as a 64-bit MAC address [RFC7042] or a CLNS (connectionless-mode network service) [X.233] address.
但查询地址可以是已为其分配AFN的其他地址类型，例如64位MAC地址[RFC7042]或CLNS（无连接模式网络服务）[X.233]地址。
Query Frame: Where a QUERY Record is the result of an ARP, ND, RARP, SEND, or unknown unicast MAC destination address, the ingress TRILL switch MAY send the frame to a Pull Directory server if the frame is small enough that the resulting Query Message fits into a TRILL Data packet within the campus MTU. The full frame is included, starting with the destination and source MAC addresses, but does not include the Frame Check Sequence (FCS).
查询帧：如果查询记录是ARP、ND、RARP、SEND或未知单播MAC目的地地址的结果，则入口TRILL交换机可以将该帧发送到拉目录服务器，前提是该帧足够小，以至于生成的查询消息适合校园MTU内的TRILL数据包。包括完整帧，从目标和源MAC地址开始，但不包括帧检查序列（FCS）。
If no response to a Pull Directory Query Message is received within a configurable timeout (see "DirQueryTimeout" in Section 3.9), then the Query Message should be retransmitted with the same Sequence Number (up to a configurable number of times (see "DirQueryRetries" in Section 3.9)). If there are multiple QUERY Records in a Query Message, responses to various subsets of these QUERY Records can be received before the timeout. In that case, the remaining unanswered QUERY Records should be resent in a new Query Message with a new Sequence Number. If a TRILL switch is not capable of handling partial responses to queries with multiple QUERY Records, it MUST NOT send a Request Message with more than one QUERY Record in it.
如果在可配置超时内未收到对Pull目录查询消息的响应（请参阅第3.9节中的“DirQueryTimeout”），则应使用相同的序列号重新传输查询消息（最多可配置的次数（请参阅第3.9节中的“DirQueryRetries”）。如果查询消息中有多个查询记录，则可以在超时之前接收对这些查询记录的不同子集的响应。在这种情况下，剩余的未应答查询记录应以新的序列号在新的查询消息中重新发送。如果TRILL开关不能处理对具有多条查询记录的查询的部分响应，则它不得发送包含多条查询记录的请求消息。
See Section 3.6 for a discussion of how Query Message errors are handled.
有关如何处理查询消息错误的讨论，请参见第3.6节。
A Pull Directory Query Message results in a Pull Directory Response Message as described in Section 3.2.2.1.
如第3.2.2.1节所述，拉动目录查询消息将产生拉动目录响应消息。
In addition, if the QUERY Record QTYPE was 2 or 5, the frame included in the Query may be modified and forwarded by the Pull Directory server as described in Section 3.2.2.2.
此外，如果查询记录QTYPE为2或5，则查询中包含的帧可以按照第3.2.2.2节所述由Pull Directory server修改和转发。
Pull Directory Response Messages are sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). Responses are sent with the same Data Label and priority as the Query Message to which they correspond, except that the Response Message priority is limited to be no more than the configured value DirRespMaxPriority (Section 3.9).
拉目录响应消息作为RBridge Channel message[RFC7178]TRILL数据包的通道协议特定内容或本机RBridge Channel数据帧发送（参见第3.5节）。响应的数据标签和优先级与其对应的查询消息相同，但响应消息优先级限制为不超过配置值DirRespMaxPriority（第3.9节）。
The RBridge Channel Protocol-specific data format is as follows:
RBridge信道协议特定的数据格式如下：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Ver, Sequence Number: As specified in Section 3.1.
版本，序列号：按照第3.1节的规定。
Type: 2 = Response.
类型：2=响应。
Flags: MUST be sent as zero and ignored on receipt.
标志：必须作为零发送，并在收到时忽略。
Count: Count is the number of RESPONSE Records present in the Response Message.
Count:Count是响应消息中存在的响应记录数。
Err, SubErr: A two-part error code. Zero, unless there was an error in the Query Message (in which case, see Section 3.6).
Err，SubErr：由两部分组成的错误代码。零，除非查询消息中有错误（在这种情况下，请参阅第3.6节）。
RESPONSE: Each RESPONSE Record within a Pull Directory Response Message is formatted as follows:
响应：拉目录响应消息中的每个响应记录的格式如下：
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |OV| RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |OV| RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: The size of the RESPONSE Record is an unsigned integer number of bytes, not including the SIZE field and following byte. A value of SIZE so large that the material doesn't fit in the Query Message indicates a malformed
大小：响应记录的大小是字节数的无符号整数，不包括大小字段和后面的字节。如果大小的值太大，以至于材质不适合查询消息，则表示格式不正确
RESPONSE Record. A RESPONSE Record with such an excessive SIZE value, and any subsequent RESPONSE Records, MUST be ignored, and the entire Response Message MAY be ignored.
答复记录。必须忽略大小值过大的响应记录以及任何后续响应记录，并且可以忽略整个响应消息。
OV: The overflow flag. Indicates, as described below, that there was too much Response Data to include in one Response Message.
OV：溢出标志。如下所述，表示一条响应消息中包含的响应数据太多。
RESV: Three reserved bits that MUST be sent as zero and ignored on receipt.
RESV：三个保留位，必须作为零发送，并在收到时忽略。
Index: The relative index of the QUERY Record in the Query Message to which this RESPONSE Record corresponds. The Index will always be 1 for Query Messages containing a single QUERY Record. If the Index is larger than the Count was in the corresponding Query, that RESPONSE Record MUST be ignored, and subsequent RESPONSE Records or the entire Response Message MAY be ignored.
索引：此响应记录对应的查询消息中查询记录的相对索引。对于包含单个查询记录的查询消息，索引将始终为1。如果索引大于相应查询中的计数，则必须忽略该响应记录，并且可以忽略后续响应记录或整个响应消息。
Lifetime: The length of time, in units of 100 milliseconds, for which the response should be considered valid, except that the values zero and 2**16 - 1 are special. If zero, the response can only be used for the particular query from which it resulted and MUST NOT be cached. If 2**16 - 1, the response MAY be kept indefinitely but not after the Pull Directory server goes down or becomes unreachable. (The maximum definite time that can be expressed is a little over 1.8 hours.)
寿命：响应应被视为有效的时间长度，单位为100毫秒，除非值0和2**16-1是特殊的。如果为零，则响应只能用于产生响应的特定查询，并且不能缓存。如果2**16-1，则响应可能会无限期保留，但不会在拉目录服务器关闭或无法访问后保留。（可以表示的最大确定时间略大于1.8小时。）
Response Data: There are three types of RESPONSE Records:
响应数据：有三种类型的响应记录：
- If the Err field of the encapsulating Response Message has a message-level error code in it, then the RESPONSE Records are omitted and Count will be 0. See Section 3.6 for additional information on errors.
- 如果封装响应消息的Err字段中包含消息级错误代码，则忽略响应记录，计数将为0。有关错误的更多信息，请参见第3.6节。
- If the Err field of the encapsulating Response Message has a record-level error code in it, then the RESPONSE Records are those having that error, as further described in Section 3.6.
- 如果封装响应消息的Err字段中有记录级错误代码，则响应记录就是有该错误的记录，如第3.6节所述。
- If the Err field of the encapsulating Response Message is 0, then the Response Data in each RESPONSE Record is formatted as the value part of an Interface Addresses APPsub-TLV [RFC7961]. The maximum size of such contents is 255 bytes, in which case the RESPONSE Record SIZE field is 255.
- 如果封装响应消息的Err字段为0，则每个响应记录中的响应数据将格式化为接口地址APPsub TLV[RFC7961]的值部分。此类内容的最大大小为255字节，在这种情况下，响应记录大小字段为255。
Multiple RESPONSE Records can appear in a Response Message with the same Index if an answer to the QUERY Record consists of multiple Interface Addresses APPsub-TLV values. This would be necessary if, for example, a MAC address within a Data Label appears to be reachable by multiple TRILL switches. However, all RESPONSE Records to any particular QUERY Record MUST occur in the same Response Message. If a Pull Directory holds more mappings for a queried address than will fit into one Response Message, it selects which mappings to include, by some method outside the scope of this document, and sets the overflow flag (OV) in all of the RESPONSE Records responding to that Query Address.
如果查询记录的答案包含多个接口地址APPsub TLV值，则具有相同索引的响应消息中可能会出现多个响应记录。例如，如果数据标签中的MAC地址似乎可由多个TRILL交换机访问，则这是必要的。但是，任何特定查询记录的所有响应记录必须出现在同一响应消息中。如果一个请求目录为一个查询地址保存的映射比一个响应消息中包含的映射多，那么它会通过本文档范围之外的某种方法选择要包含的映射，并在响应该查询地址的所有响应记录中设置溢出标志（OV）。
See Section 3.6 for a discussion of how errors are handled.
有关如何处理错误的讨论，请参见第3.6节。
Query Messages with QTYPEs 2 and 5 are interpreted and handled as described below. In these cases, if the information implicitly sought is not in the directory and the FR flag in the Query Message was 1 (one), the provided frame is forwarded by the Pull Directory server as a multi-destination TRILL Data packet with the ingress nickname of the Pull Directory server (or proxy, if it is hosted on an end station) in the TRILL Header. If the FR flag is 0, the frame is not forwarded in this case.
QTYPE为2和5的查询消息的解释和处理如下所述。在这些情况下，如果隐式寻求的信息不在目录中，并且查询消息中的FR标志为1（一），则所提供的帧由拉目录服务器作为多目的地TRILL数据包转发，该多目的地TRILL数据包具有拉目录服务器的入口昵称（或代理，如果它位于终端站上）在颤音标题中。如果FR标志为0，则在这种情况下不转发帧。
If there was no error in the handling of the encapsulating Query Message, the Pull Directory server forwards the frame inside that QUERY Record, after modifying it in some cases, as described below:
如果在处理封装查询消息时没有错误，则在某些情况下修改查询记录后，Pull Directory server会转发该查询记录内的帧，如下所述：
ARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an ARP [RFC826] frame is included in the Record: The ar$op field MUST be ares_op$REQUEST, and for the response described in Section 3.2.2.1, this is treated as a query for the target protocol address, where the AFN of that address is given by ar$pro. (ARP fields and value names with embedded dollar signs ("$") are specified in [RFC826].) If (1) ar$op is not ares_op$REQUEST, (2) the ARP is malformed, or (3) the query fails, an error is returned. Otherwise, the ARP is modified into the appropriate ARP response, which is then sent by the Pull Directory server as a TRILL Data packet.
ARP：当QTYPE为2且查询记录中的Ethertype指示ARP[RFC826]帧包含在记录中时：ar$op字段必须是ares_op$请求，对于第3.2.2.1节中描述的响应，这被视为对目标协议地址的查询，其中该地址的AFN由ar$pro给出。（带有嵌入美元符号（$）的ARP字段和值名称在[RFC826]中指定。）如果（1）ar$op不是ares_op$请求，（2）ARP格式错误，或（3）查询失败，则返回错误。否则，ARP将被修改为适当的ARP响应，然后由Pull目录服务器作为TRILL数据包发送。
ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an IPv6 ND [RFC4861] or SEND [RFC3971] frame is included in the Record: Only Neighbor Solicitation ND frames (corresponding to an ARP query) are allowed. An error is returned for other ND frames or if the target address is not found. Otherwise, if the ND is not a
ND/SEND：当QTYPE为2且查询记录中的Ethertype指示记录中包含IPv6 ND[RFC4861]或SEND[RFC3971]帧时：仅允许邻居请求ND帧（对应于ARP查询）。对于其他ND帧或如果未找到目标地址，将返回错误。否则，如果ND不是
SEND, an ND Neighbor Advertisement response is returned by the Pull Directory server as a TRILL Data packet. In the case of SEND, an error is returned indicating that a SEND frame was received by the Pull Directory, and the Pull Directory then either (1) forwards the SEND frame to the holder of the IPv6 address if that information is in the directory or (2) multicasts the SEND frame.
发送时，拉目录服务器将ND邻居播发响应作为TRILL数据包返回。在发送的情况下，将返回一个错误，指示Pull目录接收到发送帧，然后Pull目录（1）将发送帧转发给IPv6地址的持有者（如果该信息在目录中），或者（2）多播发送帧。
RARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that a RARP [RFC903] frame is included in the Record: If the ar$op field is ares_op$REQUEST, the frame is handled as an ARP, as described above. Otherwise, the ar$op field MUST be "reverse request", and for the response described in Section 3.2.2.1, this is treated as a query for the target hardware address, where the AFN of that address is given by ar$hrd. (See [RFC826] for RARP fields.) If (1) ar$op is not one of these values, (2) the RARP is malformed, or (3) the query fails, an error is returned. Otherwise, the RARP is modified into the appropriate RARP response, which is then unicast by the Pull Directory server as a TRILL Data packet to the source hardware MAC address.
RARP：当QTYPE为2且查询记录中的Ethertype指示记录中包含RARP[RFC903]帧时：如果ar$op字段为ares_op$请求，则帧作为ARP处理，如上所述。否则，ar$op字段必须为“反向请求”，对于第3.2.2.1节中描述的响应，这被视为对目标硬件地址的查询，其中该地址的AFN由ar$hrd给出。（有关RARP字段，请参阅[RFC826]）如果（1）ar$op不是这些值之一，（2）RARP格式错误，或（3）查询失败，则返回错误。否则，RARP将被修改为适当的RARP响应，然后拉目录服务器将其作为TRILL数据包单播到源硬件MAC地址。
MacDA: When QTYPE is 5, indicating that a frame is provided in the QUERY Record whose destination MAC address TRILL switch attachment is unknown, the only requirement is that this MAC address has to be unicast. The Ethertype in the QUERY Record is ignored. If this MAC address is a group address, an error is returned. In the case of Pull Directory Response Messages (Section 3.2.2.1), this MAC address is treated as a query for the MacDA. In the creation of the response described in Section 3.2.2.1, the query is treated as a query for this MAC address. If the Pull Directory contains TRILL switch attachment information for the MAC address in the Data Label of the Query Message, it forwards the frame to that switch in a unicast TRILL Data packet.
MacDA：当QTYPE为5时，表示查询记录中提供了一个目标MAC地址TRILL开关附件未知的帧，唯一的要求是该MAC地址必须是单播的。将忽略查询记录中的Ethertype。如果此MAC地址是组地址，则返回错误。对于请求目录响应消息（第3.2.2.1节），此MAC地址被视为对MacDA的查询。在创建第3.2.2.1节中描述的响应时，该查询被视为对该MAC地址的查询。如果Pull目录在查询消息的数据标签中包含MAC地址的TRILL交换机附件信息，则它将帧以单播TRILL数据包的形式转发给该交换机。
Unless it sends all responses with a Lifetime of 0, a Pull Directory MUST take action, by sending Update Messages, to minimize the amount of time that a TRILL switch will continue to use stale information from that Pull Directory. The formats of Update Messages and the Acknowledge Messages used to respond to Update Messages are given in Sections 3.3.1 and 3.3.2, respectively.
除非在生存期为0的情况下发送所有响应，否则拉动目录必须通过发送更新消息来采取措施，以尽量减少TRILL交换机继续使用该拉动目录中过时信息的时间。第3.3.1节和第3.3.2节分别给出了用于响应更新消息的更新消息和确认消息的格式。
A Pull Directory server MUST maintain one of three sets of records concerning possible cached data at clients of that server. These are numbered and listed below in order of increasing specificity:
拉目录服务器必须维护三组记录中的一组，这些记录涉及该服务器客户端上可能缓存的数据。以下按增加特异性的顺序对其进行编号和列出：
Method 1, Least Specific. An overall record, per Data Label, of when the last positive Response Data sent will expire and when the last negative response sent will expire; the records are retained until such expiration.
方法1，最不具体。每个数据标签的总记录，包括上次发送的肯定响应数据何时过期以及上次发送的否定响应何时过期；这些记录将一直保留到到期。
Pro: Minimizes the record-keeping burden on the Pull Directory server.
赞成：最大限度地减少拉目录服务器上的记录保留负担。
Con: Increases the volume of and overhead due to (1) spontaneous Update Messages and (2) unnecessarily invalidating cached information.
缺点：由于（1）自发更新消息和（2）不必要地使缓存信息无效，增加了容量和开销。
Method 2, Medium Specificity. For each unit of data (Interface Addresses APPsub-TLV (IA APPsub-TLV) Address Set [RFC7961]) held by the server, record when the last response sent with that positive Response Data will expire. In addition, record each address about which a negative response was sent by the server and when the last such negative response will expire. Each such record of a positive or negative response is discarded upon expiration.
方法2，中等特异性。对于服务器持有的每个数据单元（接口地址APPsub TLV（IA APPsub TLV）地址集[RFC7961]），记录随该肯定响应数据发送的最后一个响应何时过期。此外，记录服务器发送否定响应的每个地址，以及最后一个否定响应何时过期。每一个这样的积极或消极反应的记录在到期时被丢弃。
Pros/Cons: An intermediate level of detail in server record-keeping; also, an intermediate volume of, and overhead due to, spontaneous Update Messages with some unnecessary invalidation of cached information.
优点/缺点：服务器记录保存的中等详细程度；此外，由于自发更新消息和缓存信息的一些不必要的无效性，会产生中间量和开销。
Method 3, Most Specific. For each unit of data held by the server (IA APPsub-TLV Address Set [RFC7961]) and each address about which a negative response was sent, a list of TRILL switches that were sent that data as a positive response or sent a negative response for the address, and the expected time to expiration for that data or address at each such TRILL switch, assuming that the requester cached the response. Each list entry is retained until such expiration time.
方法3，最具体。对于服务器持有的每个数据单元（IA APPsub TLV地址集[RFC7961]）和发送否定响应的每个地址，作为肯定响应发送该数据或针对该地址发送否定响应的TRILL开关列表，以及该数据或地址在每个此类TRILL开关处的预期到期时间，假设请求者缓存了响应。每个列表条目将保留到该到期时间。
Pros: Minimizes spontaneous Update Messages sent to update pull client TRILL switch caches, and minimizes unnecessary invalidation of cached information.
优点：最小化发送到更新拉式客户端TRILL switch缓存的自发更新消息，并最小化缓存信息的不必要无效性。
Con: Increased record-keeping burden on the Pull Directory server.
缺点：拉目录服务器的记录保留负担增加。
RESPONSE Records sent with a zero Lifetime are considered to have already expired and so do not need to be tracked. In all cases, there may still be brief periods of time when directory information has changed, but information that a pull client has cached has not yet been updated or expunged.
以零生存期发送的响应记录被视为已过期，因此不需要跟踪。在所有情况下，目录信息可能仍有短暂的更改，但拉客户机缓存的信息尚未更新或删除。
A Pull Directory server might have a limit as to (1) how many TRILL switches for which it can maintain detailed expiry information using method 3 or (2) how many data units or addresses for which it can maintain expiry information using method 2 or the like. If such limits are exceeded, it MUST transition to a lower-numbered method but, in all cases, MUST support, at a minimum, method 1 and SHOULD support methods 2 and 3. The use of method 1 may be quite inefficient, due to large amounts of cached positive and negative information being unnecessarily discarded.
拉目录服务器可能有以下限制：（1）使用方法3可以维护详细到期信息的TRILL交换机数量，或（2）使用方法2等可以维护到期信息的数据单元或地址数量。如果超过此类限制，则必须转换为编号较低的方法，但在所有情况下，必须至少支持方法1，并且应支持方法2和3。由于不必要地丢弃了大量缓存的正信息和负信息，因此方法1的使用可能非常低效。
When data at a Pull Directory is changed, deleted, or added and there may be unexpired stale information at a requesting TRILL switch, the Pull Directory MUST send an Update Message as discussed below. The sending of such an Update Message MAY be delayed by a configurable number of milliseconds (see "DirUpdateDelay" in Section 3.9) to await other possible changes that could be included in the same Update Message.
当Pull目录中的数据被更改、删除或添加，并且请求TRILL开关中可能存在未过期的陈旧信息时，Pull目录必须发送更新消息，如下所述。此类更新消息的发送可能会延迟可配置的毫秒数（请参阅第3.9节中的“DirUpdateDelay”），以等待同一更新消息中可能包含的其他更改。
1. If method 1, the least detailed method, is being followed, then when any Pull Directory information in a Data Label is changed or deleted and there are outstanding cached positive data response(s), an all-addresses flush positive data Update Message is flooded within that Data Label as an RBridge Channel message. If data is added and there are outstanding cached negative responses, an all-addresses flush negative message is similarly flooded. A Count field value of 0 in an Update Message indicates "all-addresses". On receiving an all-addresses flooded flush positive Update from a Pull Directory server it has used, indicated by the F (Flood) and P (Positive) bits being 1 and the Count being 0, a TRILL switch discards the cached data responses it has for that Data Label. Similarly, on receiving an all-addresses flush negative Update, indicated by the F and N (Negative) bits being 1 and the Count being 0, it discards all cached negative replies for that Data Label. A combined flush positive and negative can be flooded by having all of the F, P, and N bits (see Section 3.3.1) set to 1 and the Count field 0, resulting in the discard of all positive and negative cached information for the Data Label.
1. 如果遵循方法1（最不详细的方法），则当数据标签中的任何拉目录信息被更改或删除且存在未完成的缓存正数据响应时，所有地址刷新正数据更新消息将作为RBridge通道消息淹没在该数据标签中。如果添加了数据，并且存在未完成的缓存的否定响应，则“所有地址刷新”否定消息同样会被淹没。更新消息中的计数字段值为0表示“所有地址”。当从使用过的Pull Directory server接收到一个all addresses flooded flush正向更新时（由F（Flood）和P（正数）位表示为1，计数为0），TRILL开关将丢弃它对该数据标签的缓存数据响应。类似地，在接收到“全部地址刷新”否定更新（由F和N（否定）位表示为1，计数为0）时，它会丢弃该数据标签的所有缓存否定回复。通过将所有F、P和N位（见第3.3.1节）设置为1，计数字段设置为0，可以对组合刷新正和负进行淹没，从而丢弃数据标签的所有正和负缓存信息。
2. If method 2 is being followed, then a TRILL switch floods address-specific positive Update Messages when data that might be cached by a querying TRILL switch is changed or deleted and floods
2. 如果遵循方法2，那么当查询TRILL开关可能缓存的数据被更改或删除并泛洪时，TRILL开关将泛洪特定于地址的肯定更新消息
address-specific negative Update Messages when data that might be cached by a querying TRILL switch is added. Such messages are sent as RBridge Channel messages. The F bit will be 1; however, the Count field will be non-zero, and either the P bit or the N bit, but not both, will be 1. There are actually four possible message types that can be flooded:
添加查询TRILL开关可能缓存的数据时，会出现特定于地址的负面更新消息。此类消息作为RBridge通道消息发送。F位为1；但是，计数字段将为非零，并且P位或N位（但不是两者）将为1。实际上有四种可能的消息类型可以被淹没：
a. If data that might still be cached is updated: An unsolicited Update Message is sent with the P flag set and the Err field 0. On receipt, the addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached positive information from that server. If they match, the cached information is updated.
a. 如果仍然可以缓存的数据被更新：将发送一条未经请求的更新消息，其中设置了P标志和Err字段0。接收时，将响应记录中的地址与接收TRILL开关保存来自该服务器的缓存肯定信息的地址进行比较。如果它们匹配，则会更新缓存的信息。
b. If data that might still be cached is deleted: An unsolicited Update Message is sent with the P flag set and the Err field non-zero, giving the error that would now be encountered in attempting to pull information for the relevant address from the Pull Directory server. In this non-zero Err field case, the RESPONSE Record(s) differs from non-zero Err Reply Message RESPONSE Records in that they do include an interface address set. Any cached positive information for the addresses given is deleted, and the negative response is cached as per the Lifetime given.
b. 如果删除了可能仍被缓存的数据：将发送一条未经请求的更新消息，其中设置了P标志且Err字段非零，给出了在尝试从pull Directory server中提取相关地址的信息时可能遇到的错误。在这种非零错误字段的情况下，响应记录不同于非零错误回复消息响应记录，因为它们确实包含接口地址集。将删除给定地址的所有缓存的肯定信息，并根据给定的生存期缓存否定响应。
c. If data for an address for which a negative response was sent is added, so that negative response that might still be cached is now incorrect: An unsolicited Update Message is sent with the N flag set to 1 and the Err field 0. The addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached negative information from that server; if they match, the cached negative information is deleted, and the positive information provided is cached as per the Lifetime given.
c. 如果添加了发送了否定响应的地址的数据，则可能仍被缓存的否定响应现在不正确：发送未经请求的更新消息时，N标志设置为1，错误字段为0。将响应记录中的地址与接收TRILL开关为其保存来自该服务器的缓存负面信息的地址进行比较；如果匹配，则删除缓存的负面信息，并根据给定的生存期缓存提供的正面信息。
d. In the rare case where it is desired to change the Lifetime or error associated with negative information that might still be cached: An unsolicited Update Message is sent with the N flag set to 1 and the Err field non-zero. As in case b above, the RESPONSE Record(s) gives the relevant addresses. Any cached negative information for the addresses is updated.
d. 在极少数情况下，需要更改与仍可能被缓存的负面信息相关联的生存期或错误：发送未经请求的更新消息时，N标志设置为1，错误字段非零。与上述案例b一样，响应记录给出了相关地址。任何缓存的地址的负面信息都会被更新。
3. If method 3 is being followed, unsolicited Update Messages of the same sort are sent as with method 2 above, except that they are not normally flooded but unicast only to the specific TRILL switches the directory server believes may be holding the cached
3. 如果遵循方法3，则发送与上述方法2相同种类的未经请求的更新消息，但它们通常不会被淹没，而是仅单播到目录服务器认为可能持有缓存的特定TRILL交换机
positive or negative information that needs deletion or updating. However, a Pull Directory server MAY flood unsolicited updates using method 3 -- for example, if it determines that a sufficiently large fraction of the TRILL switches in some Data Label are requesters that need to be updated so that flooding is more efficient than unicast.
需要删除或更新的正面或负面信息。然而，Pull目录服务器可能会使用方法3淹没未经请求的更新——例如，如果它确定某些数据标签中足够大的TRILL开关部分是需要更新的请求者，那么淹没比单播更有效。
A Pull Directory server tracking cached information with method 3 MUST NOT clear the indication that it needs to update cached information at a querying TRILL switch until it has either (a) sent an Update Message and received a corresponding Acknowledge Message or (b) sent a configurable number of updates at a configurable interval where these parameters default to three updates 100 milliseconds apart (see Section 3.9).
使用方法3跟踪缓存信息的Pull Directory server在（A）发送更新消息并接收到相应的确认消息或（b）之前，不得清除需要在查询TRILL开关处更新缓存信息的指示以可配置的间隔发送可配置数量的更新，其中这些参数默认为间隔100毫秒的三次更新（参见第3.9节）。
A Pull Directory server tracking cached information with method 1 or method 2 SHOULD NOT clear the indication that it needs to update cached information until it has sent an Update Message and received a corresponding Acknowledge Message from all of its ESADI neighbors or it has sent a number of updates at a configurable interval, as specified in the paragraph above.
使用方法1或方法2跟踪缓存信息的Pull Directory server不应清除需要更新缓存信息的指示，除非它已发送更新消息并从其所有ESADI邻居处收到相应的确认消息，或者它已以可配置的间隔发送了多个更新，如上文段落所述。
An Update Message is formatted as a Response Message, with the differences described in Section 3.3 above and the following:
更新消息的格式为响应消息，其区别如上文第3.3节所述，如下所示：
o The Type field in the message header is set to 3.
o 消息头中的类型字段设置为3。
o The Index field in the RESPONSE Record(s) is set to 0 on transmission and ignored on receipt (but the Count field in the Update Message header MUST still correctly indicate the number of RESPONSE Records present).
o 响应记录中的索引字段在传输时设置为0，在接收时被忽略（但更新消息头中的计数字段仍必须正确指示存在的响应记录数）。
o The priority with which the message is sent, DirUpdatePriority, is configurable and defaults to 5 (see Section 3.9).
o 发送消息的优先级DirUpdatePriority是可配置的，默认为5（参见第3.9节）。
Update Messages are initiated by a Pull Directory server. The Sequence Number space used is controlled by the originating Pull Directory server. This Sequence Number space for Update Messages is different from the Sequence Number space used in a Query and the corresponding Response that are controlled by the querying TRILL switch.
更新消息由拉目录服务器启动。使用的序列号空间由原始Pull目录服务器控制。更新消息的序列号空间不同于查询中使用的序列号空间以及由查询TRILL开关控制的相应响应。
The 4-bit Flags field of the message header for an Update Message is as follows:
更新消息的消息头的4位标志字段如下所示：
+---+---+---+---+
| F | P | N | R |
+---+---+---+---+
+---+---+---+---+
| F | P | N | R |
+---+---+---+---+
F: The Flood bit. If F = 0, the Update Message is unicast. If F = 1, it is multicast to All-Egress-RBridges.
福：洪水位。如果F=0，则更新消息为单播。如果F=1，则多播到所有出口rbridge。
P, N: Flags used to indicate positive or negative Update Messages. P = 1 indicates "positive". N = 1 indicates "negative". Both may be 1 for a flooded all-addresses Update.
P、 N：用于指示正面或负面更新消息的标志。P=1表示“正”。N=1表示“负”。对于泛洪所有地址更新，两者都可能为1。
R: Reserved. MUST be sent as zero and ignored on receipt.
R:保留。必须作为零发送，并在收到时忽略。
For tracking methods 2 and 3 in Section 3.3, a particular Update Message MUST have either the P flag or the N flag set, but not both. If both are set, the Update Message MUST be ignored, as this combination is only valid for method 1.
对于第3.3节中的跟踪方法2和3，特定更新消息必须设置P标志或N标志，但不能同时设置两者。如果两者都设置了，则必须忽略更新消息，因为此组合仅对方法1有效。
An Acknowledge Message is sent in response to an Update Message to confirm receipt or indicate an error, unless response is inhibited by rate limiting. It is formatted as a Response Message, but the Type is set to 4.
除非速率限制禁止响应，否则将发送确认消息以响应更新消息，以确认接收或指示错误。它被格式化为响应消息，但类型设置为4。
If there are no errors in the processing of an Update Message or if there is an overall message-level error or a header error in an Update Message, the message is echoed back with the Err and SubErr fields set appropriately, the Type changed to Acknowledge, and a null Records section with the Count field set to 0.
如果更新消息的处理过程中没有错误，或者更新消息中存在总体消息级别错误或标头错误，则会回显消息，并适当设置Err和SubErr字段，将类型更改为Acknowledge，以及将Count字段设置为0的null Records部分。
If there is a record-level error in an Update Message, one or more Acknowledge Messages may be returned with the erroneous record(s) indicated as discussed in Section 3.6.
如果更新消息中存在记录级错误，则可能会返回一条或多条确认消息，并显示第3.6节中讨论的错误记录。
An Acknowledge Message is sent with the same priority as the Update Message it acknowledges but not more than a configured priority called "DirAckMaxPriority", which defaults to 5 (see Section 3.9).
确认消息的发送优先级与其确认的更新消息相同，但不超过一个名为“DirAckMaxPriority”的配置优先级，该优先级默认为5（见第3.9节）。
As specified in Sections 3.2 and 3.3, the Query, Response, Update, and Acknowledge Messages can have zero or more repeating Record structures under different circumstances, as summarized below. The "Err" column abbreviations in this table have the meanings listed below. "IA APPsub-TLV value" means the value part of the IA APPsub-TLV specified in [RFC7961].
如第3.2节和第3.3节所述，在不同的情况下，查询、响应、更新和确认消息可以具有零个或多个重复记录结构，总结如下。本表中的“Err”列缩写具有下列含义。“IA APPsub TLV值”是指[RFC7961]中规定的IA APPsub TLV的值部分。
MBZ = MUST be zero Z = zero NZ = non-zero NZM = non-zero message-level error NZR = non-zero record-level error
MBZ=必须为零Z=零NZ=非零NZM=非零消息级别错误NZR=非零记录级别错误
Message Err Section Record Structure Response Data
----------- --- ------- ---------------- -------------------
Query MBZ 3.2.1 QUERY Record -
Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value
Response NZM 3.2.2.1 null -
Response NZR 3.2.2.1 RESPONSE Record Records with error
Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value
Acknowledge Z 3.3.2 null -
Acknowledge NZM 3.3.2 null -
Acknowledge NZR 3.3.2 RESPONSE Record Records with error
Message Err Section Record Structure Response Data
----------- --- ------- ---------------- -------------------
Query MBZ 3.2.1 QUERY Record -
Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value
Response NZM 3.2.2.1 null -
Response NZR 3.2.2.1 RESPONSE Record Records with error
Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value
Acknowledge Z 3.3.2 null -
Acknowledge NZM 3.3.2 null -
Acknowledge NZR 3.3.2 RESPONSE Record Records with error
See Section 3.6 for further details on errors.
有关错误的更多详细信息，请参见第3.6节。
A Pull Directory can be hosted on an end station as specified in Section 3.5.1.
按照第3.5.1节的规定，可以在终端站上托管一个Pull目录。
An end station can use a Pull Directory as specified in Section 3.5.2. This capability would be useful in supporting an end station that performs directory-assisted encapsulation [DirAsstEncap] or that is a "Smart Endnode" [SmartEN].
终端站可以使用第3.5.2节中规定的拉动目录。此功能将有助于支持执行目录辅助封装[DirAsstEncap]或“智能端节点”[SmartEN]的端站。
The native Pull Directory messages used in these cases are as specified in Section 3.5.3. In these cases, the edge RBridge(s) and end station(s) involved need to detect each other and exchange some control information. This is accomplished with the TRILL End System to Intermediate System (ES-IS) mechanism specified in Section 5.
这些情况下使用的本机Pull目录消息如第3.5.3节所述。在这些情况下，所涉及的边缘RBridge和终端站需要相互检测并交换一些控制信息。这是通过第5节中规定的颤音端系统到中间系统（ES-is）机制实现的。
Optionally, a Pull Directory actually hosted on an end station MAY be supported. In that case, one or more TRILL switches must act as indirect Pull Directory servers. That is, they host a Pull Directory server, which is seen by other TRILL switches in the campus, and a Pull Directory client, which fetches directory information from one or more end-station Pull Directory servers, where at least some of the information provided by the Pull Directory server may be information fetched from an end station to which it is directly connected by the co-located Pull Directory client. ("Direct connection" means a connection not involving any intermediate TRILL switches.)
或者，可能支持在终端站上实际承载的拉目录。在这种情况下，一个或多个TRILL开关必须充当间接拉目录服务器。也就是说，它们托管一个Pull Directory server（校园中的其他TRILL交换机可以看到），以及一个Pull Directory client（从一个或多个终端站Pull Directory server获取目录信息），其中，由拉目录服务器提供的至少一些信息可以是从由位于同一位置的拉目录客户端直接连接到的终端站获取的信息。（“直接连接”指不涉及任何中间颤音开关的连接。）
End stations hosting a Pull Directory server MUST support TRILL ES-IS (see Section 5) and advertise the Data Labels for which they are providing service in one or more Interested VLANs sub-TLVs or Interested Labels sub-TLVs by setting the PUL flag (see Section 7.3).
承载Pull Directory server的终端站必须支持TRILL ES-IS（参见第5节），并通过设置PUL标志（参见第7.3节），在一个或多个相关VLAN子TLV或相关标签子TLV中公布其提供服务的数据标签。
* * * * * * *
+---------------+ * *
| End Station 1 | +---------------+ *
| Pull Directory+--------------+ RB1, Pull | *
| Server | | Directory| *
+---------------+ +-------+ Client|Server | +----+
| +---------------+ |RB99|
+---------------+ | * +----+
| End Station 2 | +--+---+ +---------------+ *
| Pull Directory+---+Bridge+---+ RB2, Pull | *
| Server | +--+---+ | Directory| *
+---------------+ | | Client|Server | *
| +---------------+ *
| * TRILL *
. * Campus *
. * *
. * * * * * * *
* * * * * * *
+---------------+ * *
| End Station 1 | +---------------+ *
| Pull Directory+--------------+ RB1, Pull | *
| Server | | Directory| *
+---------------+ +-------+ Client|Server | +----+
| +---------------+ |RB99|
+---------------+ | * +----+
| End Station 2 | +--+---+ +---------------+ *
| Pull Directory+---+Bridge+---+ RB2, Pull | *
| Server | +--+---+ | Directory| *
+---------------+ | | Client|Server | *
| +---------------+ *
| * TRILL *
. * Campus *
. * *
. * * * * * * *
Figure 2: End-Station Pull Directory Example
图2：终端站拉目录示例
Figure 2 gives an example where RB1 and RB2 advertise themselves to the rest of the TRILL campus, such as RB99, as Pull Directory servers and obtain at least some of the information they are providing by issuing Pull Directory queries to End Stations 1 and/or 2. This example is specific, but many variations are possible. The box labeled "Bridge" in Figure 2 could be replaced by a complex bridged LAN or could be a bridgeless LAN through the use of a hub or repeater. Or, end stations might be connected via point-to-point links (as shown for End Station 1), including multi-ported
图2给出了一个示例，其中RB1和RB2将自己作为拉目录服务器发布到TRILL园区的其余部分，如RB99，并通过向终端站1和/或2发出拉目录查询来获取至少一些他们提供的信息。此示例是特定的，但可能有许多变化。图2中标记为“网桥”的框可以由复杂的网桥LAN代替，也可以通过使用集线器或中继器而成为无网桥LAN。或者，端站可以通过点对点链路（如端站1所示）连接，包括多端口链路
end stations connected by point-to-point links to multiple RBridges. Although Figure 2 shows two end stations and two RBridges, there could be one or more than two RBridges having such indirect Pull Directory servers. Furthermore, there could be one or more than two end stations with Pull Directory servers on them. Each TRILL switch acting as an indirect Pull Directory server could then be differently configured as to the Data Labels for which it is providing indirect service selected from the union of the Data Labels supported by the end-station hosted servers and could select from among those end-station hosted servers supporting each Data Label the indirect server is configured to provide.
通过点到点链路连接到多个RBridge的端站。尽管图2显示了两个终端站和两个RBridge，但可能有一个或多个RBridge具有此类间接拉目录服务器。此外，可能有一个或两个以上的终端站上有拉目录服务器。然后，每个充当间接拉目录服务器的TRILL交换机可以针对其提供间接服务的数据标签进行不同的配置，这些数据标签是从端站托管服务器支持的数据标签的联合中选择的，并且可以从支持每个数据标签的端站托管服务器中进行选择间接服务器配置为提供。
When an indirect Pull Directory server receives Query Messages from other TRILL switches, it answers from information it has cached or issues Pull Directory requests to end-station Pull Directory servers with which it has TRILL ES-IS adjacency to obtain the information. Any Response sent by an indirect Pull Directory server MUST NOT have a validity time longer than the validity period of the data on which it is based. When an indirect Pull Directory server receives Update Messages, it updates its cached information and MUST originate Update Messages to any clients that may have mirrors of the cached information so updated.
当间接拉动目录服务器从其他TRILL交换机接收查询消息时，它会根据缓存的信息进行应答，或向与TRILL ES-IS相邻的终端站拉动目录服务器发出拉动目录请求以获取信息。间接请求目录服务器发送的任何响应的有效期不得超过其所基于的数据的有效期。当间接拉目录服务器接收到更新消息时，它将更新其缓存信息，并且必须向可能具有如此更新的缓存信息镜像的任何客户端发出更新消息。
Since an indirect Pull Directory server discards information it has cached from queries to an end-station Pull Directory server if it loses adjacency to the server (Section 3.7), if it detects that such information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information. For this reason, indirect Pull Directory servers may wish to query multiple sources, if available, and cache multiple copies of returned information from those multiple sources. Then, if one end-station source becomes inaccessible or withdraws the information but the indirect Pull Directory server has the information from another source, it need not originate Update Messages.
由于间接拉目录服务器在失去与服务器的邻接关系（第3.7节）时，会丢弃从查询中缓存到终端站拉目录服务器的信息，如果它检测到此类信息可能缓存在RBridge客户端，并且没有其他信息源，它必须向撤回信息的客户端发送更新消息。因此，间接拉目录服务器可能希望查询多个源（如果可用），并缓存来自这些多个源的返回信息的多个副本。然后，如果一个终端站源变得不可访问或提取信息，但间接拉目录服务器具有来自另一个源的信息，则它不需要发起更新消息。
Some special end stations, such as those discussed in [DirAsstEncap] and [SmartEN], may need to access directory information. How edge RBridges provide this optional service is specified below.
一些特殊的终端站，如[Dirastencap]和[SmartEN]中讨论的终端站，可能需要访问目录信息。edge RBridges提供此可选服务的方式如下所述。
When Pull Directory support is provided by an edge RBridge to end stations, the messages used are as specified in Section 3.5.3 below. The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises the Data Labels for which it offers this service to end stations by
当边缘RBridge向终端站提供拉目录支持时，使用的消息如下面第3.5.3节所述。edge RBridge必须支持TRILL ES-IS（第5节），并通过以下方式向终端站宣传其提供此服务的数据标签：
setting the Pull Directory flag (PUL) to 1 in its Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label advertised through TRILL ES-IS.
将通过TRILL ES-IS发布的数据标签的相关VLAN子TLV或相关标签子TLV（见第7.3节）中的Pull目录标志（PUL）设置为1。
The Pull Directory messages used between TRILL switches and end stations are native RBridge Channel messages [RFC7178]. These RBridge Channel messages use the same Channel Protocol number as the inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN ID used is the TRILL ES-IS Designated VLAN (see Section 5) on the link to the end station. Since there is no TRILL Header or inner Data Label for native RBridge Channel messages, that information is added to the Pull Directory message header as specified below.
TRILL交换机和终端站之间使用的Pull目录消息是本机RBridge通道消息[RFC7178]。这些RBridge通道消息使用与RBridge间拉目录RBridge通道消息相同的通道协议号。使用的Outer.VLAN ID是指向终端站的链路上的TRILL ES-is指定VLAN（见第5节）。由于本机RBridge通道消息没有TRILL标头或内部数据标签，因此该信息将添加到Pull Directory消息标头，如下所述。
The protocol-dependent data part of the native RBridge Channel message is the same as for inter-RBridge Channel messages, except that the 8-byte header described in Section 3.1 is expanded to 12 or 16 bytes, as follows:
本机RBridge信道消息的协议相关数据部分与RBridge信道间消息的协议相关数据部分相同，只是第3.1节中描述的8字节头扩展为12或16字节，如下所示：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Type Specific Payload - variable length
+-+-+- ...
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Type Specific Payload - variable length
+-+-+- ...
Fields other than the Data Label field are as defined in Section 3.1. The Data Label that normally appears right after the Inner.MacSA of the RBridge Channel Pull Directory message appears in the Data Label field of the Pull Directory message header in the native RBridge Channel message version. This Data Label appears in a native Query Message, to be reflected in a Response Message, or it might appear in a native Update to be reflected in an Acknowledge Message. Since the appropriate VLAN or FGL [RFC7172] Ethertype is included, the length of the Data Label can be determined from the first 2 bytes.
数据标签字段以外的字段定义见第3.1节。通常出现在RBridge Channel Pull Directory消息的Inner.MacSA之后的数据标签出现在本机RBridge Channel消息版本中Pull Directory消息头的数据标签字段中。此数据标签出现在本机查询消息中，将反映在响应消息中，或者可能出现在本机更新中，将反映在确认消息中。由于包含了适当的VLAN或FGL[RFC7172]以太网类型，因此可以从前2个字节确定数据标签的长度。
A non-zero Err field in the Pull Directory Response or Acknowledge Message header indicates an error message.
拉目录响应或确认消息头中的非零错误字段表示错误消息。
If there is an error that applies to an entire Query or Update Message or its header, as indicated by the range of the value of the Err field, then the QUERY Records probably were not even looked at by the Pull Directory server and would provide no additional information in the Response or Acknowledge Message. Therefore, the Records section of the response to a Query Message or Update Message is omitted, and the Count field is set to 0 in the Response or Acknowledge Message.
如果存在适用于整个查询或更新消息或其标头的错误（如Err字段的值范围所示），则请求目录服务器可能甚至没有查看查询记录，并且在响应或确认消息中不会提供其他信息。因此，对查询消息或更新消息的响应的记录部分被省略，并且响应或确认消息中的计数字段被设置为0。
If errors occur at the QUERY Record level for a Query Message, they MUST be reported in a Response Message separate from the results of any successful non-erroneous QUERY Records. If multiple QUERY Records in a Query Message have different errors, they MUST be reported in separate Response Messages. If multiple QUERY Records in a Query Message have the same error, this error response MAY be reported in one or multiple Response Messages. In an error Response Message, the QUERY Record or Records being responded to appear, expanded by the Lifetime for which the server thinks the error might persist (usually 2**16 - 1, which indicates "indefinitely") and with their Index inserted, as the RESPONSE Record or Records.
如果查询消息的查询记录级别出现错误，则必须在响应消息中报告这些错误，并将其与任何成功的非错误查询记录的结果分开。如果查询消息中的多个查询记录具有不同的错误，则必须在单独的响应消息中报告这些错误。如果查询消息中的多个查询记录具有相同的错误，则可以在一个或多个响应消息中报告此错误响应。在错误响应消息中，将显示被响应的查询记录，按服务器认为错误可能持续的生存期（通常为2**16-1，表示“无限期”）展开，并插入索引，作为响应记录。
If errors occur at the RESPONSE Record level for an Update Message, they MUST be reported in an Acknowledge Message separate from the acknowledgment of any non-erroneous RESPONSE Records. If multiple RESPONSE Records in an Update have different errors, they MUST be reported in separate Acknowledge Messages. If multiple RESPONSE Records in an Update Message have the same error, this error response MAY be reported in one or multiple Acknowledge Messages. In an error Acknowledge Message, the RESPONSE Record or Records being responded to appear, expanded by the time for which the server thinks the error might persist and with their Index inserted, as a RESPONSE Record or Records.
如果在更新消息的响应记录级别发生错误，则必须在确认消息中报告错误，与任何非错误响应记录的确认分开。如果更新中的多个响应记录有不同的错误，则必须在单独的确认消息中报告这些错误。如果更新消息中的多个响应记录具有相同的错误，则可以在一条或多条确认消息中报告此错误响应。在错误确认消息中，要响应的一条或多条响应记录显示，按服务器认为错误可能持续的时间展开，并插入索引，作为一条或多条响应记录。
Err values 1 through 126 are available for encoding errors at the Request Message or Update Message level. Err values 128 through 254 are available for encoding errors at the QUERY Record or RESPONSE Record level. The SubErr field is available for providing more detail on errors. The meaning of a SubErr field value depends on the value of the Err field.
Err值1到126可用于在请求消息或更新消息级别编码错误。Err值128到254可用于在查询记录或响应记录级别对错误进行编码。SubErr字段可用于提供有关错误的更多详细信息。子错误字段值的含义取决于错误字段的值。
The following table lists error code values for the Err field, their meanings, and whether they apply at the message level or the record level.
下表列出了Err字段的错误代码值、它们的含义以及它们是应用于消息级别还是记录级别。
Err Level Meaning
------- ------- -----------------------------------------------
0 - No Error
Err Level Meaning
------- ------- -----------------------------------------------
0 - No Error
1 Message Unknown or reserved Query Message field value 2 Message Request Message/data too short 3 Message Unknown or reserved Update Message field value 4 Message Update Message/data too short 5-126 Message Unassigned 127 - Reserved
1消息未知或保留查询消息字段值2消息请求消息/数据太短3消息未知或保留更新消息字段值4消息更新消息/数据太短5-126消息未分配127-保留
128 Record Unknown or reserved QUERY Record field value 129 Record QUERY Record truncated 130 Record Address not found 131 Record Unknown or reserved RESPONSE Record field value 132 Record RESPONSE Record truncated 133-254 Record Unassigned 255 - Reserved
128记录未知或保留查询记录字段值129记录查询记录截断130记录地址未找到131记录未知或保留响应记录字段值132记录响应记录截断133-254记录未分配255-保留
Note that some error codes are for overall message-level errors, while some are for errors in the repeating records that occur in messages.
请注意，有些错误代码用于整个消息级错误，而有些错误代码用于消息中出现的重复记录中的错误。
The following sub-errors are specified under error codes 1 and 3:
以下子错误在错误代码1和3下指定：
SubErr Field with Error
------ -------------------------------------------
0 Unspecified
1 Version not understood (see Section 3.1.1)
2 Unknown Type field value
3 Specified Data Label not being served
4-254 Unassigned
255 Reserved
SubErr Field with Error
------ -------------------------------------------
0 Unspecified
1 Version not understood (see Section 3.1.1)
2 Unknown Type field value
3 Specified Data Label not being served
4-254 Unassigned
255 Reserved
The following sub-errors are specified under error codes 128 and 131:
以下子错误在错误代码128和131下指定：
SubErr Field with Error
------ ----------------------------------------------------
0 Unspecified
1 Unknown AFN field value
2 Unknown or Reserved QTYPE field value
3 Invalid or inconsistent SIZE field value
4 Invalid frame for QTYPE 2 (other than SEND)
5 SEND frame sent as QTYPE 2
6 Invalid frame for QTYPE 5 (such as multicast MacDA)
7-254 Unassigned
255 Reserved
SubErr Field with Error
------ ----------------------------------------------------
0 Unspecified
1 Unknown AFN field value
2 Unknown or Reserved QTYPE field value
3 Invalid or inconsistent SIZE field value
4 Invalid frame for QTYPE 2 (other than SEND)
5 SEND frame sent as QTYPE 2
6 Invalid frame for QTYPE 5 (such as multicast MacDA)
7-254 Unassigned
255 Reserved
A Pull Directory client MUST be able to detect, by tracking link-state changes, when a Pull Directory server is no longer accessible (data reachable [RFC7780] for the inter-RBridge case or TRILL ES-IS (Section 5) adjacent for the end-station-to-RBridge case) and MUST promptly discard all pull responses it is retaining from that server, as it can no longer receive cache consistency Update Messages from the server.
拉入目录客户端必须能够通过跟踪链路状态的变化，在拉入目录服务器不再可访问时进行检测（对于跨RBridge案例，数据可访问[RFC7780]，或者对于RBridge案例的终端站相邻的TRILL ES-is（第5节）），并且必须立即放弃从该服务器保留的所有拉入响应，因为它无法再从服务器接收缓存一致性更新消息。
A secondary Pull Directory server is one that obtains its data from a primary directory server. See the discussion in Section 2.6 regarding the transfer of directory information from the primary server to the secondary server.
辅助拉目录服务器是从主目录服务器获取其数据的服务器。请参阅第2.6节中有关将目录信息从主服务器传输到辅助服务器的讨论。
In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], the mere presence of any Interested VLANs sub-TLVs or Interested Labels sub-TLVs in the LSP of a TRILL switch indicates connection to end stations in the VLAN(s) or FGL(s) listed and thus a need to receive multi-destination traffic in those Data Labels. However, with Pull Directories, advertising that you are a directory server requires using these sub-TLVs to indicate the Data Label(s) you are serving.
在针对FGL[RFC7172]扩展的TRILL基本协议[RFC6325]中，TRILL交换机的LSP中仅存在任何感兴趣的VLAN子TLV或感兴趣的标签子TLV就表示连接到所列VLAN或FGL中的终端站，因此需要在这些数据标签中接收多目的地通信。但是，对于拉式目录，发布您是目录服务器的广告需要使用这些子TLV来指示您所服务的数据标签。
If a directory server does not wish to receive multi-destination TRILL Data packets for the Data Labels it lists in one of the Interested VLANs or Interested Labels (FGLs) sub-TLVs (see Section 1.2), it sets the No Data (NOD) bit to 1 (see Section 7.3). This means that data on a distribution tree may be pruned so as not to reach the "No Data" TRILL switch as long as there are no TRILL
如果目录服务器不希望接收其在感兴趣的VLAN或感兴趣的标签（FGL）子TLV（参见第1.2节）中列出的数据标签的多目标TRILL数据包，则它会将无数据（NOD）位设置为1（参见第7.3节）。这意味着可以修剪分布树上的数据，以便只要没有颤音，就不会到达“无数据”颤音开关
switches interested in the Data Label that are beyond the No Data TRILL switch on that distribution tree. The NOD bit is backward compatible, as TRILL switches ignorant of it will simply not prune when they could; this is safe, although it may cause increased link utilization by some TRILL switches sending multi-destination traffic where it is not needed.
对数据标签感兴趣的开关超出该分发树上的无数据颤音开关。NOD位是向后兼容的，因为不知道它的TRILL开关在可能的时候不会进行修剪；这是安全的，尽管它可能会导致一些TRILL交换机在不需要的地方发送多目标流量，从而提高链路利用率。
Push Directories advertise themselves inside ESADI, which normally requires the ability to send and receive multi-destination TRILL Data packets but can be implemented with serial unicast.
推送目录在ESADI中进行自我宣传，ESADI通常要求能够发送和接收多目标TRILL数据包，但可以通过串行单播实现。
An example of a TRILL switch serving as a directory that might not want multi-destination traffic in some Data Labels would be a TRILL switch that does not offer end-station service for any of the Data Labels for which it is serving as a directory and is
作为目录使用的TRILL交换机可能不希望在某些数据标签中出现多目的地通信，例如，TRILL交换机不为其作为目录使用的任何数据标签提供终端站服务，并且
- a Pull Directory and/or
- 拉目录和/或
- a Push Directory for one or more Data Labels, where all of the ESADI traffic for those Data Labels will be handled by unicast ESADI [RFC7357].
- 一个或多个数据标签的推送目录，其中这些数据标签的所有ESADI通信将由单播ESADI处理[RFC7357]。
A Push Directory MUST NOT set the NOD bit for a Data Label if it needs to communicate via multi-destination ESADI or RBridge Channel PDUs in that Data Label, since such PDUs look like TRILL Data packets to transit TRILL switches and are likely to be incorrectly pruned if the NOD bit was set.
如果推送目录需要通过数据标签中的多目标ESADI或RBridge通道PDU进行通信，则推送目录不得为数据标签设置NOD位，因为此类PDU看起来像传输TRILL交换机的TRILL数据包，并且如果设置了NOD位，则可能会被错误地修剪。
The following per-RBridge scalar configuration parameters are available for controlling Pull Directory service behavior. In addition, there is a configurable mapping, per Data Label, from the priority of a native frame being ingressed to the priority of any Pull Directory query it causes. The default mapping depends on the client strategy, as described in Section 4.
以下每RBridge标量配置参数可用于控制请求目录服务行为。此外，每个数据标签都有一个可配置的映射，从正在进入的本机帧的优先级到它引起的任何拉目录查询的优先级。默认映射取决于客户端策略，如第4节所述。
Name Default Section Note Below
------------------ ---------------- ------- ----------
Name Default Section Note Below
------------------ ---------------- ------- ----------
DirQueryTimeout 100 milliseconds 3.2.1 1 DirQueryRetries 3 3.2.1 1 DirGenQPriority 5 3.2.1 2
DirQueryTimeout 100毫秒3.2.1 1 DirQueryMetries 3.2.1 1 DirGenQPriority 5 3.2.1 2
DirRespMaxPriority 6 3.2.2.1 3
DirRespMaxPriority 6 3.2.2.1 3
DirUpdateDelay 50 milliseconds 3.3 DirUpdatePriority 5 3.3.1 DirUpdateTimeout 100 milliseconds 3.3.3 DirUpdateRetries 3 3.3.3
DirUpdateDisplay 50毫秒3.3 DirUpdatePriority 5 3.3.1 DirUpdateTimeout 100毫秒3.3.3 DirUpdateRetries 3 3.3.3
DirAckMaxPriority 5 3.3.2 4
DirAckMaxPriority 5 3.3.2 4
Note 1: Pull Directory Query client timeout waiting for response and maximum number of retries.
注意1：拉目录查询客户端等待响应超时和最大重试次数。
Note 2: Priority for client-generated requests (such as a query to refresh cached information).
注2：客户端生成的请求的优先级（例如刷新缓存信息的查询）。
Note 3: Pull Directory Response Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity.
注3：拉目录响应消息不应以优先级7发送，因为该优先级应保留给对网络连接至关重要的消息。
Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity.
注4：拉目录确认消息不应以优先级7发送，因为该优先级应保留给对网络连接至关重要的消息。
For some edge nodes that have a great number of Data Labels enabled, managing the MAC and Data Label <-> Edge RBridge mapping for hosts under all those Data Labels can be a challenge. This is especially true for data-center gateway nodes, which need to communicate with many, if not all, Data Labels.
对于启用了大量数据标签的某些边缘节点，管理所有这些数据标签下主机的MAC和数据标签<->边缘RBridge映射可能是一项挑战。数据中心网关节点尤其如此，它们需要与许多（如果不是全部）数据标签通信。
For those edge TRILL switch nodes, a hybrid model should be considered. That is, the Push Model is used for some Data Labels or addresses within a Data Label, while the Pull Model is used for other Data Labels or addresses within a Data Label. The network operator decides, via configuration, which Data Labels' mapping entries are pushed down from directories and which Data Labels' mapping entries are pulled.
对于边缘颤音切换节点，应考虑混合模型。也就是说，推模型用于数据标签中的某些数据标签或地址，而拉模型用于数据标签中的其他数据标签或地址。网络运营商通过配置决定从目录中向下推送哪些数据标签的映射项，以及拉取哪些数据标签的映射项。
For example, assume a data center where hosts in specific Data Labels, say VLANs 1 through 100, communicate regularly with external peers. The mapping entries for those 100 VLANs should probably be pushed down to the data-center gateway routers. For hosts in other Data Labels that only communicate with external peers occasionally for management interfacing, the mapping entries for those VLANs should be pulled down from the directory when needed.
例如，假设一个数据中心，其中具有特定数据标签（如VLAN 1到100）的主机定期与外部对等方通信。这100个VLAN的映射条目可能应该下推到数据中心网关路由器。对于其他数据标签中偶尔仅与外部对等方通信以进行管理接口的主机，应在需要时从目录中下拉这些VLAN的映射项。
Similarly, within a Data Label, it could be that some addresses, such as the addresses of gateways, files, DNS, or database server hosts are commonly referenced by most other hosts but those other hosts, perhaps compute engines, are typically only referenced by a few hosts in that Data Label. In that case, the address information for the commonly referenced hosts could be pushed as an incomplete directory, while the addresses of the others are pulled when needed.
类似地，在一个数据标签内，某些地址（例如网关、文件、DNS或数据库服务器主机的地址）可能通常被大多数其他主机引用，但这些其他主机（可能是计算引擎）通常仅被该数据标签中的少数主机引用。在这种情况下，通常引用的主机的地址信息可以作为不完整的目录推送，而其他主机的地址可以在需要时拉送。
The mechanisms described in this document for Push and Pull Directory services make it easy to use Push for some Data Labels or addresses and Pull for others. In fact, different TRILL switches can even be configured so that some use Push Directory services and some use Pull Directory services for the same Data Label if both Push and Pull Directory services are available for that Data Label. Also, there can be Data Labels for which directory services are not used at all.
本文档中描述的推式和拉式目录服务机制使推式目录服务可以轻松用于某些数据标签或地址，拉式目录服务可以轻松用于其他数据标签或地址。事实上，甚至可以配置不同的TRILL开关，以便在推送和拉送目录服务都可用于同一数据标签的情况下，一些使用推送目录服务，一些使用拉送目录服务。此外，还可能存在根本不使用目录服务的数据标签。
There are a wide variety of strategies that a TRILL switch can adopt for making use of directory assistance. A few suggestions are given below.
颤音开关可以采用多种策略来使用目录辅助。下面给出了一些建议。
- Even if a TRILL switch will normally be operating with information from a complete Push Directory server, there will be a period of time when it first comes up before the information it holds is complete. Or, it could be that the only Push Directories that can push information to it are incomplete or that they are just starting and may not yet have pushed the entire directory. Thus, it is RECOMMENDED that all TRILL switches have a strategy for dealing with the situation where they do not have complete directory information. Examples are to send a Pull Directory query or to revert to the behavior described in [RFC6325].
- 即使TRILL开关通常使用来自完整推送目录服务器的信息进行操作，在它保存的信息完成之前，它第一次出现也会有一段时间。或者，可能是唯一可以向其推送信息的推送目录不完整，或者它们刚刚启动，可能尚未推送整个目录。因此，建议所有TRILL交换机都有一个策略，用于处理它们没有完整目录信息的情况。示例包括发送请求目录查询或恢复到[RFC6325]中描述的行为。
- If a TRILL switch receives a native frame X resulting in seeking directory information, a choice needs to be made as to what to do if it does not already have the directory information it needs. In particular, it could (1) immediately flood the TRILL Data packet resulting from ingressing X in parallel with seeking the directory information, (2) flood that TRILL Data packet after a delay, if it fails to obtain the directory information, or (3) discard X if it fails to obtain the information. The choice might depend on the priority of frame X, since the higher that priority the more urgent the frame typically is, and the greater the probability of harm in delaying it. If a Pull Directory request is sent, it is RECOMMENDED that its priority be derived from the priority of frame X according to the table below; however, it SHOULD be possible, on a per-TRILL-switch basis, to configure the second two columns of this table.
- 如果颤音开关接收到本机帧X导致查找目录信息，则需要选择如果它还没有所需的目录信息该怎么办。具体地说，它可以（1）在搜索目录信息的同时立即淹没由进入X产生的TRILL数据包，（2）如果没有获得目录信息，则在延迟后淹没该TRILL数据包，或者（3）如果没有获得信息，则丢弃X。选择可能取决于帧X的优先级，因为该优先级越高，帧通常越紧急，延迟该帧的伤害概率越大。如果发送了拉目录请求，建议根据下表从帧X的优先级派生其优先级；但是，在每颤音开关的基础上，应该可以配置该表的后两列。
Ingressed If Flooded If Flooded
Priority Immediately After Delay
-------- ----------- -----------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1
Ingressed If Flooded If Flooded
Priority Immediately After Delay
-------- ----------- -----------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1
Note: The odd-looking ordering of numbers towards the bottom of the columns above is because priority 1 is lower than priority zero. That is to say, the values in the first column are in priority order. They will look more logical if you think of "0" as being "1.5".
注：由于优先级1低于优先级0，所以上述列底部的数字顺序看起来很奇怪。也就是说，第一列中的值按优先级顺序排列。如果您将“0”视为“1.5”，则它们看起来更符合逻辑。
Priority 7 is normally only used for urgent messages critical to adjacency and so SHOULD NOT be the default for directory traffic. Unsolicited updates are sent with a priority that is configured per Data Label and that defaults to priority 5.
优先级7通常仅用于对相邻关系至关重要的紧急消息，因此不应作为目录通信的默认值。未经请求的更新以每个数据标签配置的优先级发送，默认优先级为5。
TRILL ES-IS (End System to Intermediate System) is a variation of TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a TRILL link among and between one or more TRILL switches and end stations on that link. TRILL ES-IS is analogous to the ISO/IEC ES-IS standard [ISO9542] but is implemented in a significantly different way as a variation of TRILL IS-IS, as specified in this section. Support of TRILL ES-IS is generally optional for both the TRILL
TRILL ES-IS（终端系统到中间系统）是TRILL IS-IS[RFC7176][RFC7177][RFC7780]的变体，设计用于在一个或多个TRILL交换机和该链路上的终端站之间的TRILL链路上运行。TRILL ES-IS与ISO/IEC ES-IS标准[ISO9542]类似，但作为TRILL IS-IS的一种变体，其实现方式有很大不同，如本节所述。TRILL ES-IS的支持通常是两种TRILL的可选支持
switches and the end stations on a link but may be required to support certain features. At the time of this writing, the only features requiring TRILL ES-IS are those listed in this section.
交换机和链路上的终端站，但可能需要支持某些功能。在撰写本文时，需要TRILL ES-IS的功能只有本节中列出的功能。
TRILL ES-IS
颤音ES-IS
o is useful for supporting Pull Directory hosting on, or use from, end stations (see Section 3.5),
o 有助于支持端站上的Pull目录托管或从端站使用（参见第3.5节），
o is useful for supporting specialized end stations [DirAsstEncap] [SmartEN], and
o 用于支持专用终端站[Dirastencap][SmartEN]，以及
o may have additional future uses.
o 将来可能有其他用途。
The advantages of TRILL ES-IS over simply making an "end station" be a TRILL switch include relieving the end station of having to maintain a copy of the core link-state database (LSPs) and of having to perform routing calculations or having the ability to forward traffic.
TRILL ES-IS的优势在于，简单地将“终端站”设置为TRILL交换机，包括使终端站不必维护核心链路状态数据库（LSP）的副本，也不必执行路由计算或具有转发流量的能力。
Except as provided below in this section, TRILL ES-IS PDUs and TLVs are the same as TRILL IS-IS PDUs and TLVs.
除本节下文所述外，TRILL ES-IS PDU和TLV与TRILL IS-IS PDU和TLV相同。
All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which may be unicast) are multicast using the TRILL-ES-IS multicast MAC address (see Section 7.6). This use of a different multicast address assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused for one another.
所有TRILL ES-IS PDU（某些MTU探测和MTU确认PDU除外，可能是单播的）都是使用TRILL-ES-IS多播MAC地址的多播（见第7.6节）。使用不同的多播地址可以确保TRILL ES-IS和TRILL IS-IS PDU不会相互混淆。
Because end stations do not have IS-IS System IDs, TRILL ES-IS uses port MAC addresses in their place. This is convenient, since MAC addresses are 48-bit and almost all IS-IS implementations use 48-bit System IDs. Logically, TRILL IS-IS operates between the TRILL switches in a TRILL campus as identified by the System ID, while TRILL ES-IS operates between Ethernet ports on an Ethernet link (which may be a bridged LAN) as identified by the MAC address [RFC6325].
由于终端站没有IS-IS系统ID，TRILL ES-IS在其位置使用端口MAC地址。这很方便，因为MAC地址是48位的，并且几乎所有is-is实现都使用48位的系统ID。从逻辑上讲，TRILL IS-IS在系统ID标识的TRILL园区中的TRILL交换机之间运行，而TRILL ES-IS在MAC地址标识的以太网链路（可能是桥接LAN）上的以太网端口之间运行[RFC6325]。
As System IDs of TRILL switches in a campus are required to be unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be unique.
由于校园中TRILL交换机的系统ID要求是唯一的，因此链路上TRILL ES-IS端口的MAC地址必须是唯一的。
TRILL ES-IS adjacency formation and Designated RBridge (DRB) election operate between the ports on the link as specified in [RFC7177] for a broadcast link. The DRB specifies an ES-IS Designated VLAN for the link. Adjacency determination, DRB election, and Designated VLANs as described in this section are distinct from TRILL IS-IS adjacency, DRB election, and Designated VLANs.
TRILL ES-IS邻接形成和指定RBridge（DRB）选择在[RFC7177]中为广播链路规定的链路端口之间运行。DRB为链路指定一个ES-IS指定VLAN。本节所述的邻接确定、DRB选择和指定VLAN不同于TRILL IS-IS邻接、DRB选择和指定VLAN。
Although the "Report state" [RFC7177] exists for TRILL ES-IS adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs, not in any TRILL IS-IS LSPs.
尽管TRILL ES-IS邻接存在“报告状态”[RFC7177]，但此类邻接仅在TRILL ES-IS LSP中报告，而不在任何TRILL IS-IS LSP中报告。
End stations supporting TRILL ES-IS MUST assign a unique Port ID to each of their TRILL ES-IS ports; the Port ID appears in the TRILL ES-IS Hellos they send.
支持TRILL ES-IS的终端站必须为其每个TRILL ES-IS端口分配唯一的端口ID；端口ID显示在它们发送的TRILL ES-IS Hello中。
TRILL ES-IS has nothing to do with Appointed Forwarders. The Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV [RFC7176] are not used and SHOULD NOT be sent in TRILL ES-IS; if such a sub-TLV is received in TRILL ES-IS, it is ignored. (The Appointed Forwarders on a link are determined as specified in [RFC8139], using TRILL IS-IS.)
TRILL ES-IS与指定的货运代理无关。指定转发器子TLV和VLAN指定子TLV[RFC7176]未使用，不应以TRILL ES-IS发送；如果在TRILL ES-is中接收到该子TLV，则忽略该子TLV。（按照[RFC8139]中的规定，使用TRILL IS-IS确定链路上的指定转发器。）
Although some of the ports sending TRILL ES-IS PDUs are on end stations and thus not on routers (TRILL switches), they nevertheless may make use of the Router CAPABILITY (#242) [RFC7981] and MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities as specified in [RFC7176].
尽管发送TRILL ES-IS PDU的一些端口位于终端站上，因此不在路由器（TRILL交换机）上，但它们仍然可以利用路由器能力（#242）[RFC7981]和MT能力（#144）[RFC6329]IS-IS TLV）来指示[RFC7176]中规定的能力。
TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but note the following: in the Special VLANs and Flags sub-TLV [RFC7176], any TRILL switches advertise a nickname they own, but for end stations, that field MUST be sent as zero and ignored on receipt. In addition, in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176]) in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero, the AC flag bit MUST be sent as one (1), and all three are ignored on receipt.
TRILL ES-IS Hello与TRILL IS-IS Hello类似，但请注意以下几点：在特殊VLAN和标志子TLV[RFC7176]中，任何TRILL交换机都会公布其拥有的昵称，但对于终端站，该字段必须作为零发送，并在收到时忽略。此外，在TRILL ES-IS Hello中的特殊VLAN和标志子TLV（RFC7176的第2.2.1节）中，AF和TR标志位必须作为零发送，AC标志位必须作为一（1）发送，并且在接收时忽略所有三个。
The only link-state transmission and synchronization that occur in TRILL ES-IS are for E-L1CS (Extended Level 1 Circuit Scope) PDUs [RFC7356]. In particular, the end-station Ethernet ports supporting TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356] corresponding to either of them). TLVs and sub-TLVs that would otherwise be sent in TRILL IS-IS LSPs or E-L1FS LSPs are instead sent in E-L1CS LSPs.
TRILL ES-IS中发生的唯一链路状态传输和同步用于E-L1CS（扩展1级电路范围）PDU[RFC7356]。特别是，支持TRILL ES-IS的终端站以太网端口不支持核心TRILL IS-IS LSP，也不支持E-L1FS（扩展1级泛洪范围）LSP[RFC7780]（或与之对应的CSNPs或PSNPs（部分序列号PDU）[RFC7356]）。否则将以TRILL IS-IS LSP或E-L1FS LSP发送的TLV和子TLV将改为以E-L1CS LSP发送。
For general TRILL security considerations, see [RFC6325].
有关一般TRILL安全注意事项，请参阅[RFC6325]。
Incorrect directory information can result in a variety of security threats, including those listed below. Directory servers therefore need to take care to implement and enforce access control policies that are not overly permissive.
不正确的目录信息可能导致各种安全威胁，包括下面列出的安全威胁。因此，目录服务器需要注意实施和强制执行不过度许可的访问控制策略。
o Incorrect directory mappings can result in data being delivered to the wrong end stations, or set of end stations in the case of multi-destination packets, violating security policy.
o 不正确的目录映射可能会导致数据被传送到错误的终端站，或者在多目标数据包的情况下传送到一组终端站，从而违反安全策略。
o Missing, incorrect, or inaccessible directory data can result in denial of service due to sending data packets to black holes or discarding data on ingress due to incorrect information that their destinations are not reachable or that their source addresses are forged.
o 丢失、不正确或不可访问的目录数据可能导致拒绝服务，原因是向黑洞发送数据包，或由于无法访问目的地或伪造源地址的错误信息而丢弃入口数据。
For these reasons, whatever server or end station the directory information resides on, it needs to be protected from unauthorized modification. Parties authorized to modify directory data can violate availability and integrity policies.
由于这些原因，无论目录信息驻留在哪个服务器或终端站上，都需要对其进行保护，以防止未经授权的修改。授权修改目录数据的各方可能违反可用性和完整性策略。
In implementations of the base TRILL protocol [RFC6325] [RFC7780], RBridges deal almost exclusively with MAC addresses. The use of directories to map to/from IP addresses means that RBridges deal more actively with IP addresses as well. But RBridges in any case would be exposed to plain-text ARP/ND/SEND/IP traffic and so can see all this addressing metadata. So, this more-explicit dealing with IP addresses has little effect on the privacy of end-station traffic.
在基本TRILL协议[RFC6325][RFC7780]的实现中，RBridges几乎只处理MAC地址。使用目录映射到IP地址或从IP地址映射意味着RBridges也更积极地处理IP地址。但是rbridge在任何情况下都会暴露于纯文本ARP/ND/SEND/IP流量，因此可以看到所有这些寻址元数据。因此，这种更明确的IP地址处理方式对终端站流量的隐私几乎没有影响。
Parties authorized to read directory data can violate privacy policies for such data.
被授权读取目录数据的各方可能会违反此类数据的隐私政策。
Push Directory data is distributed through ESADI-LSPs [RFC7357]. ESADI is built on IS-IS, and such data can thus be authenticated with the widely implemented and deployed IS-IS PDU security. This mechanism provides authentication and integrity protection. See [RFC5304], [RFC5310], and the Security Considerations section of [RFC7357].
推送目录数据通过ESADI LSP[RFC7357]分发。ESADI是建立在is-is之上的，因此可以通过广泛实施和部署的is-is PDU安全性对此类数据进行身份验证。此机制提供身份验证和完整性保护。请参阅[RFC5304]、[RFC5310]和[RFC7357]的安全注意事项部分。
Pull Directory queries and responses are transmitted as RBridge-to-RBridge or native RBridge Channel messages [RFC7178]. Such messages can be secured by the mechanisms specified in [RFC7978]. These mechanisms can provide authentication and confidentiality protection. At the time of this writing, these security mechanisms are believed to be less widely implemented than IS-IS security.
拉目录查询和响应作为RBridge到RBridge或本机RBridge通道消息传输[RFC7178]。此类消息可以通过[RFC7978]中指定的机制进行保护。这些机制可以提供身份验证和机密性保护。在撰写本文时，人们认为这些安全机制的实现不如IS-IS安全机制广泛。
IANA has created a subregistry in the "TRILL Parameters" registry as follows:
IANA在“TRILL参数”注册表中创建了一个子区，如下所示：
Subregistry: ESADI-Parameter APPsub-TLV Flag Bits Registration Procedure(s): Standards Action References: [RFC7357] [RFC8171]
子地区：ESADI参数APPsub TLV标志位注册程序：标准操作参考：[RFC7357][RFC8171]
Bit Mnemonic Description Reference
--- -------- ---------------------------- ---------------
0 UN Supports Unicast ESADI ESADI [RFC7357]
1-2 PDSS Push Directory Server Status [RFC8171]
3-7 - Unassigned
Bit Mnemonic Description Reference
--- -------- ---------------------------- ---------------
0 UN Supports Unicast ESADI ESADI [RFC7357]
1-2 PDSS Push Directory Server Status [RFC8171]
3-7 - Unassigned
In addition, the ESADI-Parameter APPsub-TLV is optionally extended, as provided in its original specification in ESADI [RFC7357], by 1 byte as shown below. Therefore, [RFC8171] has also been added as a second reference to the ESADI-Parameter APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry.
此外，ESADI参数APPsub TLV可选择性地扩展1字节，如ESADI[RFC7357]中原始规范所述，如下所示。因此，[RFC8171]也被添加为“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中ESADI参数APPsub TLV的第二个参考。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for (variable)
| expansion
+-+-+-+-...
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for (variable)
| expansion
+-+-+-+-...
The meanings of all the fields are as specified in ESADI [RFC7357], except that the added PushDirPriority is the priority of the advertising ESADI instance to be a Push Directory as described in Section 2.3. If the PushDirPriority field is not present (Length = 3), it is treated as if it were 0x3F. 0x3F is also the value used and placed here by a TRILL switch whose priority to be a Push Directory has not been configured.
所有字段的含义如ESADI[RFC7357]所述，但添加的PushDirPriority是广告ESADI实例作为推送目录的优先级，如第2.3节所述。如果PushDirPriority字段不存在（长度=3），则将其视为0x3F。0x3F也是TRILL开关在此处使用和放置的值，该开关的优先级尚未配置为推送目录。
IANA has assigned a new RBridge Channel Protocol number (0x005) from the range assignable by Standards Action [RFC5226] and updated the subregistry accordingly in the "TRILL Parameters" registry. The description is "Pull Directory Services". The reference is [RFC8171].
IANA已从标准行动[RFC5226]可分配的范围中分配了一个新的RBridge通道协议号（0x005），并在“TRILL参数”注册表中相应地更新了子区。描述为“拉目录服务”。参考文献为[RFC8171]。
IANA has assigned a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV and the Interested Labels field of the Interested Labels sub-TLV [RFC7176] to indicate a Pull Directory server (PUL). This bit has been added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below.
IANA已在感兴趣的VLAN子TLV的感兴趣的VLAN字段和感兴趣的标签子TLV的感兴趣的标签字段[RFC7176]中分配了先前保留的位，以指示拉目录服务器（PUL）。此位已添加到[RFC7357]创建的“感兴趣的VLAN标志位”和“感兴趣的标签标志位”子区，并以本文档为参考，如下所示。
IANA has assigned a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV and the Interested Labels field of the Interested Labels sub-TLV [RFC7176] to indicate No Data (NOD) (see Section 3.8). This bit has been added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below.
IANA已在相关VLAN子TLV的相关VLAN字段和相关标签子TLV[RFC7176]的相关标签字段中分配了先前保留的位，以指示无数据（NOD）（参见第3.8节）。此位已添加到[RFC7357]创建的“感兴趣的VLAN标志位”和“感兴趣的标签标志位”子区，并以本文档为参考，如下所示。
The bits are as follows:
位如下所示：
Registry: Interested VLANs Flag Bits
注册表：感兴趣的VLAN标志位
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
18 PUL Pull Directory [RFC8171]
19 NOD No Data [RFC8171]
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
18 PUL Pull Directory [RFC8171]
19 NOD No Data [RFC8171]
Registry: Interested Labels Flag Bits
注册表：感兴趣的标签标志位
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
6 PUL Pull Directory [RFC8171]
7 NOD No Data [RFC8171]
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
6 PUL Pull Directory [RFC8171]
7 NOD No Data [RFC8171]
IANA has created a new registry as follows:
IANA创建了一个新的注册表，如下所示：
Name: TRILL Pull Directory Query Types (QTYPEs) Registration Procedure(s): IETF Review Reference: [RFC8171] Initial contents as in Section 3.2.1.
名称：TRILL Pull目录查询类型（QTYPEs）注册程序：IETF审查参考：[RFC8171]初始内容如第3.2.1节所示。
IANA has created a new registry and two new indented subregistries as follows:
IANA已创建了一个新的注册中心和两个新的缩进分区，如下所示：
Registry Name: TRILL Pull Directory Errors Registration Procedure(s): IETF Review Reference: [RFC8171]
注册表名称：TRILL Pull目录错误注册过程：IETF审查参考：[RFC8171]
Initial contents as in Section 3.6.1.
初始内容如第3.6.1节所示。
Subregistry Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 Registration Procedure(s): Expert Review Reference: [RFC8171]
子区域名称：TRILL Pull目录错误1和3的子代码注册程序：专家评审参考：[RFC8171]
Initial contents as in Section 3.6.2.
初始内容如第3.6.2节所示。
Subregistry Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 Registration Procedure(s): Expert Review Reference: [RFC8171]
子区域名称：TRILL Pull目录错误128和131的子代码注册程序：专家评审参考：[RFC8171]
Initial contents as in Section 3.6.3.
初始内容如第3.6.3节所示。
IANA has assigned a TRILL multicast MAC address (01-80-C2-00-00-47) from the "TRILL Multicast Addresses" registry. The description is "TRILL-ES-IS". The reference is [RFC8171].
IANA已从“TRILL多播地址”注册表中分配了TRILL多播MAC地址（01-80-C2-00-00-47）。描述为“颤音-ES-is”。参考文献为[RFC8171]。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, DOI 10.17487/RFC0903, June 1984, <http://www.rfc-editor.org/info/rfc903>.
[RFC903]Finlayson，R.，Mann，T.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，DOI 10.17487/RFC0903，1984年6月<http://www.rfc-editor.org/info/rfc903>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<http://www.rfc-editor.org/info/rfc3971>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，DOI 10.17487/RFC5304，2008年10月<http://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，DOI 10.17487/RFC5310，2009年2月<http://www.rfc-editor.org/info/rfc5310>.
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 6165，DOI 10.17487/RFC6165，2011年4月<http://www.rfc-editor.org/info/rfc6165>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.
[RFC6329]Fedyk，D.，Ed.，Ashwood Smith，P.，Ed.，Allan，D.，Bragg，A.，和P.Unbehagen，“支持IEEE 802.1aq最短路径桥接的IS-IS扩展”，RFC 6329，DOI 10.17487/RFC6329，2012年4月<http://www.rfc-editor.org/info/rfc6329>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<http://www.rfc-editor.org/info/rfc7042>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176]Eastlake 3rd，D.，Senevirathne，T.，Ghanwani，A.，Dutt，D.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，H.，和V.Manral，“大量链路的透明互连（颤音）：邻接”，RFC 7177，DOI 10.17487/RFC7177，2014年5月<http://www.rfc-editor.org/info/rfc7177>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<http://www.rfc-editor.org/info/rfc7178>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<http://www.rfc-editor.org/info/rfc7780>.
[RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, <http://www.rfc-editor.org/info/rfc7961>.
[RFC7961]Eastlake 3rd，D.和L.Yizhou，“大量链路的透明互连（TRILL）：接口地址APPsub TLV”，RFC 7961，DOI 10.17487/RFC7961，2016年8月<http://www.rfc-editor.org/info/rfc7961>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>.
[RFC7981]Ginsberg，L.，Previdi，S.，和M.Chen，“广告路由器信息的IS-IS扩展”，RFC 7981，DOI 10.17487/RFC7981，2016年10月<http://www.rfc-editor.org/info/rfc7981>.
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961, June 2017, <http://www.rfc-editor.org/info/rfc8139>.
[RFC8139]Eastlake 3rd，D.，Li，Y.，Umair，M.，Banerjee，A.，和F.Hu，“大量链接的透明互连（TRILL）：指定的货运代理”，RFC 8139，DOI 10.17487/RFC79612017年6月<http://www.rfc-editor.org/info/rfc8139>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<http://www.rfc-editor.org/info/rfc7067>.
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>.
[RFC7978]Eastlake 3rd，D.，Umair，M.，和Y.Li，“大量链路的透明互连（TRILL）：RBridge信道头扩展”，RFC 7978，DOI 10.17487/RFC7978，2016年9月<http://www.rfc-editor.org/info/rfc7978>.
[ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. Umair, "TRILL: ARP/ND Optimization", Work in Progress, draft-ietf-trill-arp-optimization-08, April 2017.
[ARPND]Li，Y.，Eastlake 3rd，D.，Dunbar，L.，Perlman，R.，和M.Umair，“颤音：ARP/ND优化”，正在进行的工作，草案-ietf-TRILL-ARP-Optimization-082017年4月。
[DirAsstEncap] Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory Assisted TRILL Encapsulation", Work in Progress, draft-ietf-trill-directory-assisted-encap-05, May 2017.
[Dirastencap]Dunbar，L.，Eastlake 3rd，D.，和R.Perlman，“目录辅助TRILL封装”，正在进行的工作，草稿-ietf-TRILL-Directory-Assisted-encap-052017年5月。
[ISO9542] ISO 9542:1988, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473)", August 1988.
[ISO9542]ISO 9542:1988，“信息处理系统——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的端系统到中间系统路由交换协议”，1988年8月。
[SmartEN] Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and T. Liao, "TRILL Smart Endnodes", Work in Progress, draft-ietf-trill-smart-endnodes-05, February 2017.
[SmartEN]Perlman，R.，Hu，F.，Eastlake 3rd，D.，Krupakaran，K.，和T.Liao，“TRILL智能终端节点”，正在进行的工作，草案-ietf-TRILL-Smart-Endnodes-052017年2月。
[X.233] International Telecommunication Union, ITU-T Recommendation X.233: "Information technology - Protocol for providing the connectionless-mode network service: Protocol specification", August 1997, <https://www.itu.int/rec/T-REC-X.233/en>.
[X.233]国际电信联盟，ITU-T建议X.233：“信息技术-提供无连接模式网络服务的协议：协议规范”，1997年8月<https://www.itu.int/rec/T-REC-X.233/en>.
Acknowledgments
致谢
The contributions of the following persons are gratefully acknowledged:
感谢以下人士的贡献：
Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell, Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey Melnikov, Gayle Noble, and Tianran Zhou.
阿曼达·巴伯、马修·博奇、艾莉莎·库珀、斯蒂芬·法雷尔、丹尼尔·弗兰克、伊戈尔·加辛斯基、乔尔·哈尔彭、苏珊·哈雷斯、阿列克西·梅尔尼科夫、盖尔·诺布尔和周天然。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com
Donald Eastlake 3rd华为技术有限公司马萨诸塞州米尔福德海狸街155号01757美利坚合众国电话：+1-508-333-2270电子邮件：d3e3e3@gmail.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024 United States of America Phone: +1-469-277-5840 Email: ldunbar@huawei.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive，德克萨斯州普莱诺175号套房75024美国电话：+1-469-277-5840电子邮件：ldunbar@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America Email: Radia@alum.mit.edu
Radia Perlman EMC 2010美国华盛顿州贝尔维尤200号东北第256大道，邮编：98007电子邮件：Radia@alum.mit.edu
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com
宜州利华为技术有限公司软件大道101号南京210012中国电话：+86-25-56622310电子邮件：liyizhou@huawei.com