Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8384 Dell EMC
Category: Standards Track F. Hu
ISSN: 2070-1721 ZTE Corporation
D. Eastlake 3rd
T. Liao
Huawei Technologies
July 2018
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8384 Dell EMC
Category: Standards Track F. Hu
ISSN: 2070-1721 ZTE Corporation
D. Eastlake 3rd
T. Liao
Huawei Technologies
July 2018
Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes
多链路透明互连（TRILL）智能终端节点
Abstract
摘要
This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware.
本文档通过允许端节点自愿进行端节点学习和封装/去封装，解决了边缘路由桥（RBridges）中端节点学习表的大小和新鲜度问题。这种端节点称为“智能端节点”。只有附加的边RBridge才能区分“智能端节点”和“普通端节点”。Smart Endnode使用附加边缘RBridge的昵称，因此此解决方案不使用额外的昵称。该解决方案还支持支持细粒度标签（FGL）感知的端节点。
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 https://www.rfc-editor.org/info/rfc8384.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8384.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 6
4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 6
4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 8
4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 8
5. Processing Data Packets . . . . . . . . . . . . . . . . . . . 10
5.1. Data-Packet Processing for Smart Endnodes . . . . . . . . 10
5.2. Data-Packet Processing for Edge RBridge . . . . . . . . . 11
6. Multihoming Scenario . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 6
4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 6
4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 8
4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 8
5. Processing Data Packets . . . . . . . . . . . . . . . . . . . 10
5.1. Data-Packet Processing for Smart Endnodes . . . . . . . . 10
5.2. Data-Packet Processing for Edge RBridge . . . . . . . . . 11
6. Multihoming Scenario . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] [RFC7176] link state routing and encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges) or "TRILL Switches".
IETF TRILL（大量链路的透明互连）协议[RFC6325][RFC7780]提供无需配置的最佳成对数据帧转发，即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。TRILL通过使用IS-IS[IS-IS][RFC7176]链路状态路由和使用包含跃点计数的报头封装流量来实现这一点。实现TRILL的设备称为“RBridges”（路由桥）或“TRILL交换机”。
An RBridge that attaches to endnodes is called an "edge RBridge" or "edge TRILL Switch", whereas one that exclusively forwards encapsulated frames is known as a "transit RBridge" or "transit TRILL Switch". An edge RBridge traditionally is the one that encapsulates a native Ethernet frame with a TRILL header or that receives a TRILL-encapsulated packet and decapsulates the TRILL header. To encapsulate efficiently, the edge RBridge must keep an "endnode table" consisting of (Media Access Control (MAC), Data Label, TRILL egress switch nickname) sets, for those remote MAC addresses in Data Labels currently communicating with endnodes to which the edge RBridge is attached.
连接到端节点的RBridge称为“edge RBridge”或“edge TRILL Switch”，而专门转发封装帧的RBridge称为“transit RBridge”或“transit TRILL Switch”。传统上，边缘RBridge是用TRILL报头封装本机以太网帧或接收TRILL封装的数据包并对TRILL报头进行去封装的边缘RBridge。为了有效封装，边缘RBridge必须为当前与边缘RBridge连接的端节点通信的数据标签中的远程MAC地址保留一个“端节点表”，该表由（媒体访问控制（MAC）、数据标签、TRILL出口交换机昵称）集组成。
These table entries might be configured, received from End Station Address Distribution Information (ESADI) [RFC7357], looked up in a directory [RFC7067], or learned from decapsulating received traffic. If the edge RBridge has attached endnodes communicating with many remote endnodes, this table could become very large. Also, if a MAC address / Data Label pair in the table have moved to a different remote TRILL switch, it might be difficult for the edge RBridge to notice this quickly; and because the edge RBridge is encapsulating to the incorrect egress RBridge, the traffic will get lost.
这些表项可以配置、从端站地址分布信息（ESADI）[RFC7357]接收、在目录[RFC7067]中查找或从对接收到的流量进行解封装中学习。如果edge RBridge具有与许多远程端节点通信的附加端节点，则此表可能会变得非常大。此外，如果表中的MAC地址/数据标签对已移动到不同的远程TRILL交换机，则边缘RBridge可能很难快速注意到这一点；由于边缘RBridge封装到不正确的出口RBridge，流量将丢失。
BUM: Broadcast, Unknown unicast, and Multicast.
BUM：广播、未知单播和多播。
Edge RBridge: An RBridge providing endnode service on at least one of its ports. It is also called an edge TRILL Switch.
边缘RBridge：在其至少一个端口上提供端节点服务的RBridge。它也被称为边缘颤音开关。
Data Label: VLAN or FGL.
数据标签：VLAN或FGL。
DRB: Designated RBridge [RFC6325].
DRB：指定RBridge[RFC6325]。
ESADI: End Station Address Distribution Information [RFC7357].
ESADI：端站地址分布信息[RFC7357]。
FGL: Fine-Grained Label [RFC7172].
FGL：细粒度标签[RFC7172]。
IS-IS: Intermediate System to Intermediate System [IS-IS].
IS-IS：中间系统到中间系统[IS-IS]。
LSP: Link State PDU.
LSP：链路状态PDU。
PDU: Protocol Data Unit.
协议数据单元。
RBridge: Routing Bridge, an alternative name for a TRILL switch.
RBridge：路由桥，TRILL交换机的另一个名称。
Smart Endnode: An endnode that has the capability specified in this document including learning and maintaining (MAC, Data Label, nickname) entries and encapsulating/decapsulating TRILL frame.
智能端节点：具有本文件规定功能的端节点，包括学习和维护（MAC、数据标签、昵称）条目以及封装/解封颤音帧。
Transit RBridge: An RBridge that exclusively forwards encapsulated frames. It is also called a transit TRILL Switch.
Transit RBridge：专门转发封装帧的RBridge。它也被称为传输颤音开关。
TRILL: Transparent Interconnection of Lots of Links [RFC6325][RFC7780].
TRILL：大量链路的透明互连[RFC6325][RFC7780]。
TRILL ES-IS: TRILL End System to Intermediate System, is a variation of TRILL IS-IS designed to operate on a TRILL link among and between one or more TRILL switches and end stations on that link [RFC8171].
TRILL ES-IS：TRILL终端系统到中间系统，是TRILL IS的变体，设计用于在一个或多个TRILL交换机和该链路上的终端站之间的TRILL链路上运行[RFC8171]。
TRILL Switch: a device that implements the TRILL protocol; an alternative term for an RBridge.
颤音开关：实现颤音协议的设备；RBridge的替代术语。
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 Smart Endnode solution defined in this document addresses the problem of the size and freshness of the endnode learning table in edge RBridges. An endnode E, attached to an edge RBridge R, tells R that E would like to be a "Smart Endnode", which means that E will encapsulate and decapsulate the TRILL frame, using R's nickname. Because E uses R's nickname, this solution does not consume extra nicknames.
本文档中定义的智能端节点解决方案解决了edge RBridges中端节点学习表的大小和新鲜度问题。连接到边缘RBridge R的端节点E告诉R E希望成为“智能端节点”，这意味着E将使用R的昵称封装和解除封装颤音帧。因为E使用R的昵称，所以此解决方案不使用额外的昵称。
Take Figure 1 as the example Smart Endnode scenario: RB1, RB2, and RB3 are the RBridges in the TRILL domain and SE1 and SE2 are the Smart Endnodes that can encapsulate and decapsulate the TRILL packets. RB1 is the edge RB to which SE1 and SE2 have attached. RB1 assigns one of its nicknames to be used by SE1 and SE2.
以图1为例，智能端节点场景：RB1、RB2和RB3是TRILL域中的RBridge，SE1和SE2是可以封装和解除封装TRILL数据包的智能端节点。RB1是SE1和SE2连接到的边缘RB。RB1分配其一个昵称供SE1和SE2使用。
Each Smart Endnode, SE1 and SE2, uses RB1's nickname when encapsulating and maintains an endnode table of (MAC, Data Label, TRILL egress switch nickname) for remote endnodes that it (SE1 or SE2) is corresponding with. RB1 does not decapsulate packets destined for SE1 or SE2 and does not learn (MAC, Data Label, TRILL egress switch nickname) for endnodes corresponding with SE1 or SE2, but RB1 does decapsulate and does learn (MAC, Data Label, TRILL egress switch nickname) for any endnodes attached to RB1 that have not declared themselves to be Smart Endnodes.
每个智能端节点SE1和SE2在封装和维护其（SE1或SE2）所对应的远程端节点的端节点表（MAC、数据标签、TRILL出口开关昵称）时使用RB1的昵称。RB1不会对发往SE1或SE2的数据包进行解封，也不会对与SE1或SE2相对应的端节点进行学习（MAC、数据标签、TRILL出口交换机昵称），但RB1会对连接到RB1且未声明自己为智能端节点的任何端节点进行解封和学习（MAC、数据标签、TRILL出口交换机昵称）。
Just as an RBridge learns and times out (MAC, Data Label, TRILL egress switch nickname), Smart Endnodes SE1 and SE2 also learn and time out endnode entries. However, SE1 and SE2 might also determine, through ICMP messages or other techniques that an endnode entry is not successfully reaching the destination endnode, and it can be deleted, even if the entry has not timed out.
正如RBridge学习并超时（MAC、数据标签、TRILL出口开关昵称），智能端节点SE1和SE2也学习并超时端节点条目。但是，SE1和SE2还可以通过ICMP消息或其他技术确定某个端节点条目未成功到达目标端节点，并且即使该条目未超时，也可以将其删除。
If SE1 wishes to correspond with destination MAC D, and no endnode entry exists, SE1 will encapsulate the packet as an unknown destination, or consult a directory [RFC7067] (just as an RBridge would do if there was no endnode entry).
如果SE1希望与目的地MAC D相对应，并且不存在任何endnode条目，则SE1会将数据包封装为未知目的地，或查阅目录[RFC7067]（就像没有endnode条目时RBridge所做的那样）。
+----------+
|SE1(Smart |
|Endnode1) | \ +------------------------------+
+----------+ \ / \
\ /+------+ +------+ +-----+ \ +-----------+
/-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 |
/ | +------+ +------+ +-----+ | |MAC=D |
+----------+ / \ / +-----------+
|SE2(Smart | \ /
| Endnode2)| +------------------------------+
+----------+
+----------+
|SE1(Smart |
|Endnode1) | \ +------------------------------+
+----------+ \ / \
\ /+------+ +------+ +-----+ \ +-----------+
/-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 |
/ | +------+ +------+ +-----+ | |MAC=D |
+----------+ / \ / +-----------+
|SE2(Smart | \ /
| Endnode2)| +------------------------------+
+----------+
Figure 1: Smart Endnode Scenario
图1：智能端节点场景
The mechanism in this document is that the Smart Endnode SE1 issues a Smart-Hello, indicating SE1's desire to act as a Smart Endnode, together with the set of MAC addresses and Data Labels that SE1 owns. The Smart-Hello is used to announce the Smart Endnode capability and parameters (such as MAC address, Data Label, etc.). The Smart-Hello is a type of TRILL ES-IS PDU, which is specified in Section 5 of [RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is defined in Section 4.
本文档中的机制是智能终端节点SE1发出智能Hello，表示SE1希望充当智能终端节点，以及SE1拥有的MAC地址和数据标签集。Smart Hello用于宣布Smart Endnode功能和参数（如MAC地址、数据标签等）。智能Hello是TRILL ES-is PDU的一种，在[RFC8171]的第5节中有详细说明。Smart Endnode的Smart Hello的详细内容在第4节中定义。
If RB1 supports having a Smart Endnode neighbor, it also sends Smart-Hellos. The Smart Endnode learns from RB1's Smart-Hellos what RB1's nickname is and which trees RB1 can use when RB1 ingresses multi-destination frames. Although Smart Endnode SE1 transmits Smart-Hellos, it does not transmit or receive Link State PDUs (LSPs) or Extended Level 1 Flooding Scope (E-L1FS) FS LSPs [RFC7780].
如果RB1支持智能端节点邻居，它也会发送智能Hello。Smart Endnode从RB1的Smart Hellos学习RB1的昵称是什么，以及当RB1进入多个目标帧时RB1可以使用哪些树。尽管Smart Endnode SE1发送Smart Hello，但它不发送或接收链路状态PDU（LSP）或扩展的1级泛洪作用域（E-L1FS）FS LSP[RFC7780]。
Since a Smart Endnode can encapsulate TRILL Data packets, it can cause the Inner.Label to be a Fine-Grained Label [RFC7172]; thus, this method supports FGL-aware endnodes. When and how a Smart Endnode decides to use the FGL instead of VLANs to encapsulate the TRILL Data packet is out of scope in this document.
由于智能端节点可以封装TRILL数据包，因此可以使内部.Label成为细粒度标签[RFC7172]；因此，该方法支持FGL感知端节点。Smart Endnode何时以及如何决定使用FGL而不是VLAN来封装TRILL数据包超出了本文档的范围。
The subsections below describe Smart-Hello messages.
下面的小节描述了智能Hello消息。
Although a Smart Endnode is not an RBridge, does not send LSPs or maintain a copy of the link state database, and does not perform routing calculations, it is required to have a "Hello" mechanism (1) to announce to edge RBridges that it is a Smart Endnode and (2) to tell them what MAC addresses it is handling in what Data Labels. Similarly, an edge RBridge that supports Smart Endnodes needs a message (1) to announce that support, (2) to inform Smart Endnodes what nickname to use for ingress and what nickname(s) can be used as egress nickname in a multi-destination TRILL Data packet, and (3) the list of Smart Endnodes it knows about on that link.
尽管智能端节点不是RBridge，不发送LSP或维护链路状态数据库的副本，也不执行路由计算，但需要有一个“Hello”机制（1）向边缘RBridge宣布它是智能端节点，以及（2）告诉它们在什么数据标签中处理什么MAC地址。类似地，支持智能端节点的边缘RBridge需要一条消息（1）来宣布该支持，（2）通知智能端节点在多目的地TRILL数据包中使用什么样的昵称进入，什么样的昵称可以用作出口昵称，以及（3）它知道的该链路上的智能端节点列表。
The messages sent by Smart Endnodes and by edge RBridges that support Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type of TRILL ES-IS PDU, which is specified in [RFC8171].
智能端节点和支持智能端节点的边缘RBridge发送的消息称为“Smart Hellos”。智能Hello是TRILL ES-is PDU的一种类型，在[RFC8171]中指定。
The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes and for Smart-Hellos sent by edge RBridges, consists of TRILL IS-IS TLVs as described in the following two subsections. The non-extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 8-bit size and type field. Both types of Smart-Hellos MUST include a Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
Smart Hello有效负载（用于Smart Endnodes发送的Smart Hello和edge RBridges发送的Smart Hello）由TRILL IS-IS TLV组成，如下两小节所述。使用非扩展格式，以便TLV、sub TLV和APPsub TLV具有8位大小和类型字段。两种类型的智能Hello都必须在TRILL GENINFO TLV中包含智能参数APPsub TLV，如下所示：
+-+-+-+-+-+-+-+-+-
|Smart-Parameters| (1 byte)
+-+-+-+-+-+-+-+-+-
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-
|Smart-Parameters| (1 byte)
+-+-+-+-+-+-+-+-+-
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Smart-Parameters APPsub-TLV
图2：智能参数APPsub TLV
o Type: APPsub-TLV type Smart-Parameters, value is 22.
o 类型：APPsub TLV类型智能参数，值为22。
o Length: 4.
o 长度：4。
o Holding Time: A time in seconds as an unsigned integer. It has the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]. A Smart Endnode and an edge RBridge supporting Smart Endnodes MUST send a Smart-Hello at least three times during their Holding Time. If no Smart-Hellos are received from a Smart Endnode or edge RBridge within the most recent Holding Time it sent, it is assumed that it is no longer available.
o 保持时间：以秒为单位的无符号整数时间。其含义与IS-IS Hellos[IS-IS]中的等待时间字段相同。智能端节点和支持智能端节点的边缘RBridge必须在其保持时间内至少发送三次智能Hello。如果在智能端节点或边缘RBridge最近发送的保持时间内未收到来自智能端节点或边缘RBridge的智能Hello，则假定该智能Hello不再可用。
o Flags: At this time, all of the Flags are reserved and MUST be sent as zero and ignored on receipt.
o 标志：此时，所有标志都是保留的，必须作为零发送，并在收到时忽略。
o If more than one Smart-Parameters APPsub-TLV appears in a Smart-Hello, the first one is used and any following ones are ignored. If no Smart-Parameters APPsub-TLVs appear in a Smart-Hello, that Smart-Hello is ignored.
o 如果Smart Hello中出现多个Smart Parameters APPsub TLV，则将使用第一个参数，并忽略以下任何参数。如果智能Hello中未显示智能参数APPsub TLV，则忽略该智能Hello。
The edge RBridge's Smart-Hello contains the following information in addition to the Smart-Parameters APPsub-TLV:
除智能参数APPsub TLV外，edge RBridge的智能Hello还包含以下信息：
o RBridge's nickname. The nickname sub-TLV, specified in Section 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS router capability) in a Smart-Hello frame. If more than one nickname appears in the Smart-Hello, the first one is used and the following ones are ignored.
o 瑞奇的绰号。[RFC7176]第2.3.2节中规定的昵称sub-TLV在这里被重用，并在智能Hello帧中的TLV 242（is-is路由器功能）中携带。如果智能Hello中出现多个昵称，则使用第一个昵称，忽略以下昵称。
o Trees that RB1 can use when ingressing multi-destination frames. The Tree Identifiers sub-TLV, specified in Section 2.3.4 in [RFC7176], is reused here.
o RB1在进入多目标帧时可以使用的树。此处重复使用[RFC7176]第2.3.4节中规定的树标识符子TLV。
o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in section 2.5 in [RFC7176], is reused for this purpose.
o 智能端节点邻居列表。[RFC7176]第2.5节中规定的颤音相邻TLV可用于此目的。
o An Authentication TLV MAY also be included.
o 还可以包括认证TLV。
A new APPsub-TLV (Smart-MAC TLV) for use by Smart Endnodes is as defined below. In addition, there will be a Smart-Parameters APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode Smart-Hello.
智能终端节点使用的新APPsub TLV（智能MAC TLV）定义如下。此外，智能终端节点智能Hello中将有智能参数APPsub TLV和身份验证TLV。
If there are several VLANs/FGL Data Labels for that Smart Endnode, the Smart-MAC APPsub-TLV is included several times in the Smart Endnode's Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV.
如果该智能终端节点有多个VLAN/FGL数据标签，则智能MAC APPsub TLV会多次包含在智能终端节点的智能Hello中。此APPsub TLV显示在TRILL GENINFO TLV中。
+-+-+-+-+-+-+-+-+
|Type=Smart-MAC | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|M| RSV | VLAN/FGL Data Label | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type=Smart-MAC | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|M| RSV | VLAN/FGL Data Label | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Smart-MAC APPsub-TLV
图3：智能MAC APPsub TLV
o Type: TRILL APPsub-TLV Type Smart-MAC, value is 23.
o 类型：TRILL APPsub TLV类型智能MAC，值为23。
o Length: Total number of bytes contained in the value field of the TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label fields and six times the number of MAC addresses present. So, if there are n MAC addresses, this is 4+6*n.
o 长度：TLV值字段中包含的总字节数，即F/M/RSV/FGL数据标签字段的长度和MAC地址数的六倍之和。所以，如果有n个MAC地址，这是4+6*n。
o F: 1 bit. If it is set to 1, it indicates that the endnode supports FGL Data Labels [RFC7172], and that this Smart-MAC APPsub-TLV has an FGL in the following VLAN/FGL field. Otherwise, the VLAN/FGL Data Label field is a VLAN ID. (See below for the format of the VLAN/FGL Data Label field).
o F:1位。如果设置为1，则表示endnode支持FGL数据标签[RFC7172]，并且此智能MAC APPsub TLV在以下VLAN/FGL字段中具有FGL。否则，VLAN/FGL数据标签字段是VLAN ID（请参阅下文了解VLAN/FGL数据标签字段的格式）。
o M: 1 bit. If it is set to 1, it indicates multihoming (see Section 6). If it is set to 0, it indicates that the Smart Endnodes are not using multihoming.
o M：1位。如果设置为1，则表示多归宿（参见第6节）。如果将其设置为0，则表示Smart Endnodes未使用多宿主。
o RSV: 6 bits; reserved for the future use.
o RSV:6位；保留供将来使用。
o VLAN/FGL Data Label: 24 bits. If F is 1, this field is a 24-bit FGL Data Label for all subsequent MAC addresses in this APPsub-TLV. Otherwise, if F is 0, the lower 12 bits are the VLAN of all subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits are not used (sent as zero and ignored on receipt). If there is no VLAN/FGL Data Label specified, the VLAN/FGL Data Label is zero.
o VLAN/FGL数据标签：24位。如果F为1，则此字段是此APPsub TLV中所有后续MAC地址的24位FGL数据标签。否则，如果F为0，则低12位是此APPsub TLV中所有后续MAC地址的VLAN，而高12位不使用（作为零发送，在收到时忽略）。如果未指定VLAN/FGL数据标签，则VLAN/FGL数据标签为零。
o MAC(i): This is a 48-bit MAC address reachable in the Data Label sent by the Smart Endnode that is announcing this APPsub-TLV.
o MAC（i）：这是一个48位MAC地址，可在宣布此APPsub TLV的智能终端节点发送的数据标签中访问。
The subsections below specify the processing of Smart Endnode data packets. All TRILL Data packets sent to or from Smart Endnodes are sent in the Designated VLAN [RFC6325] of the local link but do not necessarily have to be VLAN tagged.
下面的小节指定了智能端节点数据包的处理。发送到智能终端节点或从智能终端节点发送的所有TRILL数据包都在本地链路的指定VLAN[RFC6325]中发送，但不一定要进行VLAN标记。
A Smart Endnode does not issue or receive LSPs or E-L1FS FS LSPs or calculate topology. It does the following:
智能端节点不会发出或接收LSP或E-L1FS LSP，也不会计算拓扑。它做了以下工作：
o A Smart Endnode maintains an endnode table of (the MAC address of remote endnode, Data Label, the nickname of the edge RBridge's attached) entries of end nodes with which the Smart Endnode is communicating. Entries in this table are populated the same way that an edge RBridge populates the entries in its table:
o 智能端节点维护智能端节点与之通信的端节点条目的端节点表（远程端节点的MAC地址、数据标签、连接的边缘RBridge的昵称）。此表中的条目的填充方式与边缘RBridge填充其表中的条目的方式相同：
* learning from (source MAC address ingress nickname) on packets it decapsulates.
* 从（源MAC地址入口昵称）对其解密的数据包进行学习。
* by querying a directory [RFC7067].
* 通过查询目录[RFC7067]。
* by having some entries configured.
* 通过配置一些条目。
o When Smart Endnode SE1 wishes to send unicast frame to remote node D, if the (MAC address of remote endnode D, Data Label, nickname) entry is in SE1's endnode table, SE1 encapsulates the ingress nickname as the nickname of the RBridge (RB1), egress nickname as indicated in D's table entry. If D is unknown, SE1 either queries a directory or encapsulates the packet as a multi-destination frame, using one of the trees that RB1 has specified in RB1's Smart-Hello. The mechanism for querying a directory is given in [RFC8171].
o 当智能端节点SE1希望向远程节点D发送单播帧时，如果（远程端节点D的MAC地址、数据标签、昵称）条目在SE1的端节点表中，SE1将入口昵称封装为RBridge（RB1）的昵称，出口昵称如D的表条目中所示。如果D未知，SE1使用RB1在RB1的智能Hello中指定的树之一查询目录或将数据包封装为多目标帧。[RFC8171]中给出了查询目录的机制。
o When SE1 wishes to send a Broadcast, Unknown Unicast, and Multicast (BUM) packet to the TRILL campus, SE1 encapsulates the packet using one of the trees that RB1 has specified.
o 当SE1希望向TRILL校园发送广播、未知单播和多播（BUM）数据包时，SE1使用RB1指定的树之一封装该数据包。
If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, the destination MAC of the outer Ethernet is the All-RBridges multicast address.
如果智能终端节点SE1发送多目的地TRILL数据包，则外部以太网的目的地MAC是所有RBridges多播地址。
The Smart Endnode SE1 need not send Smart-Hellos as frequently as normal RBridges. These Smart-Hellos could be periodically unicast to the Appointed Forwarder RB1. In case RB1 crashes and restarts, or the DRB changes and SE1 receives the Smart-Hello without mentioning
Smart Endnode SE1不需要像普通RBridge那样频繁地发送Smart Hello。这些智能问候可以定期单播到指定的转发器RB1。如果RB1崩溃并重新启动，或者DRB发生变化，SE1收到Smart Hello而未提及
SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in its Smart-Hellos as a Smart Endnode neighbor.
SE1，SE1应该立即发送智能问候。如果RB1被指定为SE1声明的任何VLAN的转发器，RB1必须在其Smart Hello中将SE1列为Smart Endnode邻居。
The attached edge RBridge processes and forwards TRILL Data packets based on the endnode property rather than for encapsulation and forwarding the native frames the same way as the traditional RBridges. There are several situations for the edge RBridges as follows:
附加的边缘RBridge基于endnode属性处理和转发TRILL数据包，而不是以与传统RBridge相同的方式封装和转发本机帧。边缘RBridges有以下几种情况：
o If receiving an encapsulated unicast TRILL Data packet from a port with a Smart Endnode, with RB1's nickname as ingress, the edge RBridge RB1 forwards the frame to the specified egress nickname, as with any encapsulated frame. However, RB1 SHOULD filter the encapsulation frame based on the inner source MAC and Data Label as specified for the Smart Endnode. If the MAC (or Data Label) is not among the expected entries of the Smart Endnode, the frame would be dropped by the edge RBridge. If the edge RBridge does not perform this check, it makes it easier for a rogue end station to inject bogus TRILL Data packets into the TRILL campus.
o 如果从具有智能终端节点的端口接收封装的单播TRILL数据分组，并且RB1的昵称为入口，则边缘RBridge RB1将帧转发到指定的出口昵称，如同任何封装的帧一样。但是，RB1应根据为Smart Endnode指定的内部源MAC和数据标签过滤封装帧。如果MAC（或数据标签）不在智能终端节点的预期条目中，则边缘RBridge将丢弃该帧。如果边缘RBridge不执行此检查，则流氓终端站更容易将虚假的颤音数据包注入颤音校园。
o If receiving a unicast TRILL Data packet with RB1's nickname as egress from the TRILL campus, and the destination MAC address in the enclosed packet is a MAC address that has been listed by a Smart Endnode, RB1 leaves the packet encapsulated to that Smart Endnode. The outer Ethernet destination MAC is the destination Smart Endnode's MAC address, the inner destination MAC address is either the Smart Endnode's MAC address or some other MAC address that the Smart Endnode advertised in its Smart Hello, and the outer Ethernet source MAC address is the RB1's port MAC address. The edge RBridge still decreases the Hop count value by 1, for there is one hop between the RB1 and Smart Endnode.
o 如果从TRILL园区接收到带有RB1昵称的单播TRILL数据包作为出口，并且所附包中的目标MAC地址是智能端节点列出的MAC地址，则RB1将包封装到该智能端节点。外部以太网目的地MAC是目的地智能终端节点的MAC地址，内部目的地MAC地址是智能终端节点的MAC地址或智能终端节点在其智能Hello中公布的其他MAC地址，外部以太网源MAC地址是RB1的端口MAC地址。边缘RBridge仍然将跃点计数值减少1，因为RB1和Smart Endnode之间有一个跃点。
o If receiving a multi-destination TRILL Data packet from a port with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation to the TRILL campus based on the distribution tree indicated by the egress nickname. If the egress nickname does not correspond to a distribution tree, the packet is discarded. If there are any normal endnodes (i.e., endnodes that are not Smart Endnodes) attached to the edge RBridge RB1, RB1 decapsulates the frame and sends the native frame to these ports possibly pruned based on multicast listeners, in addition to forwarding the multi-destination TRILL frame to the rest of the campus.
o 如果从带有智能终端节点的端口接收到多目的地TRILL数据包，RBridge RB1会根据出口昵称指示的分发树将TRILL封装转发到TRILL园区。如果出口昵称与分发树不对应，则丢弃该数据包。如果有任何正常端节点（即，非智能端节点的端节点）连接到边缘RBridge RB1，RB1除将多目标TRILL帧转发到校园的其余部分外，还将解除帧封装并将本机帧发送到这些可能基于多播侦听器修剪的端口。
o If RB1 receives a native multi-destination data frame, which is sent by an endnode that is not a Smart Endnode, from a port, including hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), RB1 will encapsulate it as multi-destination TRILL Data packet, and send the encapsulated multi-destination TRILL Data packet out that same port to the Smart Endnodes attached to the port, and also send the encapsulated multi-destination TRILL Data packet to the TRILL campus through other ports.
o 如果RB1从端口（包括混合端节点（智能端节点和非智能端节点的端节点））接收由非智能端节点的端节点发送的本机多目标数据帧，RB1将其封装为多目标TRILL数据包，并将封装的多目的地TRILL数据包从该端口发送到连接到该端口的智能终端节点，并且还通过其他端口将封装的多目的地TRILL数据包发送到TRILL校园。
o If RB1 receives a multi-destination TRILL Data packet from a remote RBridge, and the exit port includes hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), it sends two copies of multicast frames out the port, one as native and the other as a TRILL-encapsulated frame. When a Smart Endnode receives a multi-destination TRILL Data packet, it learns the remote (MAC address, Data Label, nickname) entry. A Smart Endnode ignores native data frames. A normal (non-Smart) endnode receives the native frame and learns the remote MAC address and ignores the TRILL Data packet. This transit solution may bring some complexity for the edge RBridge and waste network bandwidth resource, so avoiding the hybrid endnodes scenario by attaching the endnodes that are Smart and non-Smart to different ports is RECOMMENDED.
o 如果RB1从远程RBridge接收到多目的地TRILL数据包，并且出口端口包括混合端节点（智能端节点和非智能端节点的端节点），则RB1将多播帧的两个副本发送出端口，一个作为本机，另一个作为TRILL封装帧。当智能终端节点接收到多目标TRILL数据包时，它学习远程（MAC地址、数据标签、昵称）条目。智能端节点忽略本机数据帧。正常（非智能）端节点接收本机帧并学习远程MAC地址，并忽略TRILL数据包。此传输解决方案可能会给边缘RBridge带来一些复杂性，并浪费网络带宽资源，因此建议通过将智能和非智能端节点连接到不同端口来避免混合端节点场景。
Multihoming is a common scenario for the Smart Endnode. The Smart Endnode is on a link attached to the TRILL domain in two places: edge RBridges RB1 and RB2. Take Figure 4 as an example. The Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 separately. Both RB1 and RB2 could announce their nicknames to SE1.
多宿主是智能端节点的常见场景。智能端节点位于连接到颤音域的两个位置的链接上：边缘RB1和RB2。以图4为例。智能端节点SE1通过RB1和RB2分别连接到TRILL域。RB1和RB2都可以向SE1公布他们的昵称。
. .....................
. +------+ .
. | RB1 | .
. /+------+ .
+----------+ ./ +-----+ . +----------+
|SE1(Smart |/. | RB3 |......| Smart |
| Endnode1)| .\ +-----+ . | Endnode2 |
+----------+ . \ . +----------+
. +-----+ .
. | RB2 | TRILL .
. +-----+ Domain .
.......................
. .....................
. +------+ .
. | RB1 | .
. /+------+ .
+----------+ ./ +-----+ . +----------+
|SE1(Smart |/. | RB3 |......| Smart |
| Endnode1)| .\ +-----+ . | Endnode2 |
+----------+ . \ . +----------+
. +-----+ .
. | RB2 | TRILL .
. +-----+ Domain .
.......................
Figure 4: Multihoming Scenario
图4：多主场景
Smart Endnode SE1 can choose either the nickname of RB1 or RB2 when encapsulating and forwarding a TRILL Data packet. If the active-active load balance is considered for the multihoming scenario, the
在封装和转发TRILL数据包时，Smart Endnode SE1可以选择RB1或RB2的昵称。如果在多主场景中考虑主动负载平衡，则
Smart Endnode SE1 could use both the nickname of RB1 and RB2 to encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname when forwarding through RB1 and RB2's nickname when forwarding through RB2. This will cause MAC flip-flopping (see [RFC7379]) of the endnode table entry in the remote RBridges (or Smart Endnodes). The solution for the MAC flip-flopping issue is to set a multihoming bit in the RSV field of the TRILL Data packet. When remote RBridge RB3 or Smart Endnodes receive a data packet with the multihomed bit set, the endnode entries (SE1's MAC address, label, RB1's nickname) and (SE1's MAC address, label, RB2's nickname) will coexist as endnode entries in the remote RBridge. (An alternative solution would be to use the ESADI protocol to distribute multiple attachments of a MAC address of a multihoming group. The ESADI is deployed among the edge RBridges (see Section 5.3 of [RFC7357]).
智能终端节点SE1可以使用RB1和RB2的昵称来封装和转发TRILL数据包。SE1在通过RB1转发时使用RB1的昵称，在通过RB2转发时使用RB2的昵称。这将导致远程RBridge（或智能Endnodes）中endnode表项的MAC触发器（请参阅[RFC7379]）。MAC触发器问题的解决方案是在TRILL数据包的RSV字段中设置多归位。当远程RBridge RB3或智能端节点接收到具有多宿位集的数据包时，端节点条目（SE1的MAC地址、标签、RB1的昵称）和（SE1的MAC地址、标签、RB2的昵称）将作为端节点条目在远程RBridge中共存。（另一种解决方案是使用ESADI协议分发多归属组MAC地址的多个附件。ESADI部署在边缘RBridge之间（请参见[RFC7357]第5.3节）。
Smart-Hellos can be secured by using Authentication TLVs based on [RFC5310]. If they are not secured, then it is easier for a rogue end station that does not posses the required keying material to be falsely recognized as a valid Smart Endnode.
通过使用基于[RFC5310]的认证TLV，可以保护智能Hello。如果它们不安全，则不具备所需密钥材料的恶意端站更容易被错误识别为有效的智能端节点。
For general TRILL Security Considerations, see [RFC6325]. As stated there, since end stations are connected to edge RBridge ports by Ethernet, those ports MAY require end stations to authenticate themselves using [IEEE802.1X] and authenticate and encrypt traffic to/from the RBridge port with [IEEE802.1AE].
有关一般TRILL安全注意事项，请参阅[RFC6325]。如上所述，由于终端站通过以太网连接到边缘RBridge端口，这些端口可能需要终端站使用[IEEE802.1X]进行自我验证，并使用[IEEE802.1AE]对进出RBridge端口的流量进行验证和加密。
If they misbehave, Smart Endnodes can forge arbitrary ingress and egress nicknames in the TRILL headers of the TRILL Data packets they construct. Decapsulating at egress RBridges or remote Smart Endnodes that believe such a forged ingress nickname would send future traffic destined for the inner-source MAC address of the TRILL data frame to the wrong edge RBridge if data-plane learning is in use. Because of this, an RBridge port should not be configured to support Smart Endnodes unless the end stations on that link are trusted or can be adequately authenticated.
如果它们行为不当，智能端节点可以在它们构造的TRILL数据包的TRILL报头中伪造任意入口和出口昵称。如果正在使用数据平面学习，则在出口RBridge或远程智能终端节点处解封装，这些节点认为这种伪造的入口昵称将把将来发送到TRILL数据帧的内部源MAC地址的流量发送到错误的边缘RBridge。因此，不应将RBridge端口配置为支持智能终端节点，除非该链路上的终端站是可信的或可以充分验证。
As with any end station, Smart Endnodes can forge the outer MAC addresses of packets they send (see Section 6 of [RFC6325].) Because they encapsulate TRILL Data packets, they can also forge inner MAC addresses. The encapsulation performed by Smart Endnodes also means they can send data in any Data Label, which means they must be trusted in order to enforce a security policy based on Data Labels.
与任何终端站一样，智能终端节点可以伪造它们发送的数据包的外部MAC地址（参见[RFC6325]第6节）。因为它们封装了TRILL数据包，所以它们还可以伪造内部MAC地址。Smart Endnodes执行的封装还意味着它们可以在任何数据标签中发送数据，这意味着必须信任它们，以便基于数据标签实施安全策略。
The TRILL-Hello is a type of TRILL ES-IS and is defined in [RFC8171]. Receiving and processing TRILL-Hello for RBridges and Smart Endnodes would not bring more security and vulnerability issues than the TRILL ES-IS security defined in [RFC8171].
TRILL Hello是TRILL ES-is的一种类型，在[RFC8171]中定义。与[RFC8171]中定义的TRILL ES-IS安全性相比，接收和处理RBridges和Smart Endnodes的TRILL Hello不会带来更多的安全性和漏洞问题。
For added security against the compromise of data due to its misdelivery for any reason, including the above, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station.
为了增加安全性，防止由于任何原因（包括上述原因）导致的数据误发，应考虑端到端加密和身份验证；即，从源端站到目标端站的加密和身份验证。
The mechanism described in this document requires Smart Endnodes to be aware of the MAC address(es) of the TRILL edge RBridge(s) to which they are attached and the egress RBridge nickname from which the destination of the packets is reachable. With that information, Smart Endnodes can learn a substantial amount about the topology of the TRILL domain. Therefore, there could be a potential security risk when the Smart Endnodes are not trusted or are compromised.
本文档中描述的机制要求智能终端节点知道它们所连接到的TRILL-edge-RBridge的MAC地址，以及可从中到达数据包目的地的出口RBridge昵称。有了这些信息，智能终端节点可以了解大量关于TRILL域拓扑的信息。因此，当智能终端节点不受信任或受到破坏时，可能存在潜在的安全风险。
IANA has allocated APPsub-TLV type numbers for the Smart-MAC and Smart-Parameters APPsub-TLVs. The "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry has been updated as follows.
IANA已为智能MAC和智能参数APPsub TLV分配了APPsub TLV类型号。“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表已更新如下。
+-----------+-------------------+------------+
| Protocol | Description | Reference |
+-----------+-------------------+------------+
| 22 | Smart-Parameters | RFC 8384 |
| 23 | Smart-MAC | RFC 8384 |
+-----------+-------------------+------------+
+-----------+-------------------+------------+
| Protocol | Description | Reference |
+-----------+-------------------+------------+
| 22 | Smart-Parameters | RFC 8384 |
| 23 | Smart-MAC | RFC 8384 |
+-----------+-------------------+------------+
Table 1
表1
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS]国际标准化组织，“信息技术——系统间电信和信息交换——与提供无连接模式网络服务协议（ISO 8473）结合使用的中间系统到中间系统域内路由信息交换协议”，ISO/IEC 10589:2002，第二版，2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc5310>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc6325>.
[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, <https://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月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc7176>.
[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, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc7780>.
[RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms", RFC 8171, DOI 10.17487/RFC8171, June 2017, <https://www.rfc-editor.org/info/rfc8171>.
[RFC8171]Eastlake 3rd，D.，Dunbar，L.，Perlman，R.，和Y.Li，“大量链接的透明互连（TRILL）：边缘目录协助机制”，RFC 8171，DOI 10.17487/RFC8171，2017年6月<https://www.rfc-editor.org/info/rfc8171>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[IEEE802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE 802.1AE.
[IEEE802.1AE]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）安全”，IEEE 802.1AE。
[IEEE802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X.
[IEEE802.1X]IEEE，“局域网和城域网的IEEE标准——基于端口的网络访问控制”，IEEE 802.1X。
[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, <https://www.rfc-editor.org/info/rfc7067>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<https://www.rfc-editor.org/info/rfc7067>.
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <https://www.rfc-editor.org/info/rfc7379>.
[RFC7379]Li，Y.，Hao，W.，Perlman，R.，Hudson，J.，和H.Zhai，“大量链路透明互连（TRILL）边缘主动连接的问题陈述和目标”，RFC 7379，DOI 10.17487/RFC7379，2014年10月<https://www.rfc-editor.org/info/rfc7379>.
Acknowledgements
致谢
The contributions of the following persons are gratefully acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya Krupakaran, and Andrew Qu.
感谢以下人士的贡献：张明贵、郝伟国、琳达·邓巴、克萨瓦·维贾亚·克鲁帕卡兰和安德鲁·曲。
Authors' Addresses
作者地址
Radia Perlman Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
美国马萨诸塞州霍普金顿南街176号Radia Perlman Dell EMC 01748
Phone: +1-206-291-367
Email: radiaperlman@gmail.com
Phone: +1-206-291-367
Email: radiaperlman@gmail.com
Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China
中国上海碧波路889号方伟胡中兴通讯股份有限公司201203
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Donald Eastlake Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 United States of America
美国佛罗里达州达文波特市东湖华为技术有限公司1424 Pro Shop Court，邮编：33896
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Ting Liao Huawei Technologies Nanjing, Jiangsu 210012 China
中国江苏南京华为科技有限公司，邮编：210012
Email: liaoting1@huawei.com
Email: liaoting1@huawei.com