Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7176 Huawei
Obsoletes: 6326 T. Senevirathne
Category: Standards Track Cisco
ISSN: 2070-1721 A. Ghanwani
Dell
D. Dutt
Cumulus Networks
A. Banerjee
Insieme Networks
May 2014
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7176 Huawei
Obsoletes: 6326 T. Senevirathne
Category: Standards Track Cisco
ISSN: 2070-1721 A. Ghanwani
Dell
D. Dutt
Cumulus Networks
A. Banerjee
Insieme Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
大量链路的透明互连（TRILL）使用IS-IS
Abstract
摘要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326.
IETF多链路透明互连（TRILL）协议在具有任意拓扑结构和链路技术的多跳网络中提供最佳的成对数据帧转发，无需配置；它还支持单播和多播流量的多路径传输。本文档指定了支持TRILL的IS-IS扩展的数据格式和代码点。这些数据格式和代码点也可由TRILL以外的技术使用。本文件淘汰RFC 6326。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7176.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7176.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Conventions Used in This Document ..........................4
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
2.1. Group Address TLV ..........................................5
2.1.1. Group MAC Address Sub-TLV ...........................5
2.1.2. Group IPv4 Address Sub-TLV ..........................7
2.1.3. Group IPv6 Address Sub-TLV ..........................8
2.1.4. Group Labeled MAC Address Sub-TLV ...................9
2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
2.2.1. Special VLANs and Flags Sub-TLV ....................12
2.2.2. Enabled-VLANs Sub-TLV ..............................13
2.2.3. Appointed Forwarders Sub-TLV .......................14
2.2.4. Port TRILL Version Sub-TLV .........................15
2.2.5. VLANs Appointed Sub-TLV ............................17
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
2.3.1. TRILL Version Sub-TLV ..............................18
2.3.2. Nickname Sub-TLV ...................................19
2.3.3. Trees Sub-TLV ......................................20
2.3.4. Tree Identifiers Sub-TLV ...........................20
2.3.5. Trees Used Identifiers Sub-TLV .....................21
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
2.3.7. VLAN Group Sub-TLV .................................24
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
2.3.9. RBridge Channel Protocols Sub-TLV ..................27
2.3.10. Affinity Sub-TLV ..................................29
2.3.11. Label Group Sub-TLV ...............................30
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
2.5. TRILL Neighbor TLV ........................................31
3. MTU PDUs .......................................................33
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
2.1. Group Address TLV ..........................................5
2.1.1. Group MAC Address Sub-TLV ...........................5
2.1.2. Group IPv4 Address Sub-TLV ..........................7
2.1.3. Group IPv6 Address Sub-TLV ..........................8
2.1.4. Group Labeled MAC Address Sub-TLV ...................9
2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
2.2.1. Special VLANs and Flags Sub-TLV ....................12
2.2.2. Enabled-VLANs Sub-TLV ..............................13
2.2.3. Appointed Forwarders Sub-TLV .......................14
2.2.4. Port TRILL Version Sub-TLV .........................15
2.2.5. VLANs Appointed Sub-TLV ............................17
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
2.3.1. TRILL Version Sub-TLV ..............................18
2.3.2. Nickname Sub-TLV ...................................19
2.3.3. Trees Sub-TLV ......................................20
2.3.4. Tree Identifiers Sub-TLV ...........................20
2.3.5. Trees Used Identifiers Sub-TLV .....................21
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
2.3.7. VLAN Group Sub-TLV .................................24
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
2.3.9. RBridge Channel Protocols Sub-TLV ..................27
2.3.10. Affinity Sub-TLV ..................................29
2.3.11. Label Group Sub-TLV ...............................30
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
2.5. TRILL Neighbor TLV ........................................31
3. MTU PDUs .......................................................33
4. Use of Existing PDUs and TLVs ..................................35
4.1. TRILL IIH PDUs ............................................35
4.2. Area Address ..............................................35
4.3. Protocols Supported .......................................35
4.4. Link State PDUs (LSPs) ....................................35
4.5. Originating LSP Buffer Size ...............................36
5. IANA Considerations ............................................36
5.1. TLVs ......................................................36
5.2. Sub-TLVs ..................................................36
5.3. PDUs ......................................................38
5.4. Reserved and Capability Bits ..............................38
5.5. TRILL Neighbor Record Flags ...............................39
6. Security Considerations ........................................39
7. Changes from RFC 6326 ..........................................39
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................43
9. Acknowledgements ...............................................44
4. Use of Existing PDUs and TLVs ..................................35
4.1. TRILL IIH PDUs ............................................35
4.2. Area Address ..............................................35
4.3. Protocols Supported .......................................35
4.4. Link State PDUs (LSPs) ....................................35
4.5. Originating LSP Buffer Size ...............................36
5. IANA Considerations ............................................36
5.1. TLVs ......................................................36
5.2. Sub-TLVs ..................................................36
5.3. PDUs ......................................................38
5.4. Reserved and Capability Bits ..............................38
5.5. TRILL Neighbor Record Flags ...............................39
6. Security Considerations ........................................39
7. Changes from RFC 6326 ..........................................39
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................43
9. Acknowledgements ...............................................44
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] [RFC7177] provides transparent forwarding in multi-hop networks with arbitrary topology and link technologies using a header with a hop count and link-state routing. TRILL provides optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. Intermediate Systems (ISs) implementing TRILL are called Routing Bridges (RBridges) or TRILL Switches.
IETF多链路透明互连（TRILL）协议[RFC6325][RFC7177]使用具有跳数和链路状态路由的报头，在具有任意拓扑和链路技术的多跳网络中提供透明转发。TRILL提供无需配置的最佳成对转发，即使在临时循环期间也能安全转发，并支持单播和多播流量的多路径传输。实现TRILL的中间系统（ISs）称为路由桥（RBridges）或TRILL交换机。
This document, in conjunction with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL.
本文件与[RFC6165]一起规定了支持TRILL的IS-IS[ISO-10589][RFC1195]扩展的数据格式和代码点。这些数据格式和代码点也可由TRILL以外的技术使用。
This document obsoletes [RFC6326], which generally corresponded to the base TRILL protocol [RFC6325]. There has been substantial development of TRILL since the publication of those documents. The main changes from [RFC6326] are summarized below, and a full list is given in Section 7.
本文档淘汰了[RFC6326]，它通常对应于基本TRILL协议[RFC6325]。自从这些文件出版以来，TRILL有了实质性的发展。[RFC6326]的主要变化总结如下，完整列表见第7节。
1. Added multicast group announcements by IPv4 and IPv6 address.
1. 按IPv4和IPv6地址添加了多播组公告。
2. Added facilities for announcing capabilities supported.
2. 添加了用于宣布支持的功能的工具。
3. Added a tree affinity sub-TLV whereby ISs can request distribution tree association.
3. 添加了一个树关联子TLV，ISs可以通过该子TLV请求分发树关联。
4. Added multi-topology support.
4. 增加了多拓扑支持。
5. Added control-plane support for TRILL Data frame fine-grained labels. This support is independent of the data-plane representation.
5. 添加了对TRILL数据帧细粒度标签的控制平面支持。此支持独立于数据平面表示。
6. Fixed the verified erratum [Err2869] in [RFC6326].
6. 修正了[RFC6326]中已验证的勘误表[Err2869]。
Changes herein to TLVs and sub-TLVs specified in [RFC6326] are backward compatible.
此处对[RFC6326]中规定的TLV和子TLV的更改是向后兼容的。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning.
[RFC6325]中定义的术语和首字母缩略词在此具有相同的含义。
Additional acronyms and phrases used in this document are:
本文件中使用的其他首字母缩略词和短语包括：
BVL - Bit Vector Length
位向量长度
BVO - Bit Vector Offset
位向量偏移
IIH - IS-IS Hello
你好
IS - Intermediate System. For this document, all relevant intermediate systems are RBridges [RFC6325].
IS-中间系统。对于本文件，所有相关中间系统均为RBRIGES[RFC6325]。
MAC - Media Access Control
媒体访问控制
MT - Multi-Topology
多拓扑
NLPID - Network Layer Protocol Identifier
NLPID-网络层协议标识符
SNPA - Subnetwork Point of Attachment (MAC Address)
SNPA-子网连接点（MAC地址）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section, in conjunction with [RFC6165], specifies the data formats and code points for the TLVs and sub-TLVs for IS-IS to support the IETF TRILL protocol. Information as to the number of occurrences allowed, such as for a TLV in a PDU or set of PDUs or for a sub-TLV in a TLV, is summarized in Section 5.
本节结合[RFC6165]规定了IS-IS的TLV和子TLV的数据格式和代码点，以支持IETF TRILL协议。第5节总结了关于允许出现次数的信息，例如PDU或PDU集合中的TLV或TLV中的子TLV。
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an LSP PDU and carries sub-TLVs that in turn advertise multicast group listeners. The sub-TLVs that advertise listeners are specified below. The sub-TLVs under GADDR constitute a new series of sub-TLV types (see Section 5.2).
组地址（GADDR）TLV，IS-IS TLV类型142，在LSP PDU中承载，并承载子TLV，子TLV依次播发多播组侦听器。下面指定了播发侦听器的子TLV。GADDR下的子TLV构成了一系列新的子TLV类型（见第5.2节）。
GADDR has the following format:
GADDR具有以下格式：
+-+-+-+-+-+-+-+-+
|Type=GADDR-TLV | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
+-+-+-+-+-+-+-+-+
|Type=GADDR-TLV | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: TLV type, set to GADDR-TLV 142.
o 类型：TLV类型，设置为GADDR-TLV 142。
o Length: variable depending on the sub-TLVs carried.
o 长度：根据所携带的子TLV而变化。
o sub-TLVs: The Group Address TLV value consists of sub-TLVs formatted as described in [RFC5305].
o 子TLV：组地址TLV值由按照[RFC5305]中所述格式化的子TLV组成。
The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 within the GADDR TLV. In TRILL, it is used to advertise multicast listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. It has the following format:
组MAC地址（GMAC-ADDR）子TLV是GADDR TLV中的子TLV类型1。在TRILL中，它用于按照[RFC6325]第4.5.5节规定的MAC地址公布多播侦听器。其格式如下：
+-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6:
其中，每组记录采用以下形式，k=6：
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o 类型：GADDR子TLV类型，设置为1（GMAC-ADDR）。
o Length: 5 + m + k*n = 5 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：5+m+k*n=5+m+6*n，其中m是组记录数，n是组地址数和源地址数之和。
o RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored on receipt.
o RESV：保留。必须作为零发送并在接收时忽略的4位字段。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑ID：此字段携带拓扑ID[RFC5120]，如果未使用拓扑，则为零。
o VLAN ID: This carries the 12-bit VLAN identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：它携带此子TLV中所有后续MAC地址的12位VLAN标识符，如果未指定VLAN，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast MAC address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个6字节（48位）的多播MAC地址，后跟6字节的源MAC地址。如果源不适合于单个子TLV，则相同的组地址可以在组地址TLV的另一实例的另一个子TLV中使用不同的源地址重复。
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.
GMAC-ADDR子TLV仅在GADDR TLV内携带。
The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2 within the GADDR TLV. It has the same format as the Group MAC Address sub-TLV described in Section 2.1.1 except that k=4. The fields are as follows:
组IPv4地址（GIP-ADDR）子TLV是GADDR TLV中的子TLV类型2。其格式与第2.1.1节中描述的组MAC地址子TLV相同，但k=4除外。字段如下所示：
o Type: sub-TLV type, set to 2 (GIP-ADDR).
o 类型：子TLV类型，设置为2（GIP-ADDR）。
o Length: 5 + m + k*n = 5 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：5+m+k*n=5+m+4*n，其中m是组记录数，n是组地址数和源地址数之和。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑ID：此字段携带拓扑ID[RFC5120]，如果未使用拓扑，则为零。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV:在传输时必须作为零发送，在接收时被忽略。
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：它携带一个12位VLAN标识符，该标识符对该子TLV中的所有后续地址有效，如果未指定VLAN，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个4字节（32位）的IPv4组地址，后跟4字节的源IPv4地址。如果源的数量不适合单个子TLV，则允许在组地址TLV的另一个实例的另一个子TLV中使用不同的源地址重复相同的组地址。
The GIP-ADDR sub-TLV is carried only within a GADDR TLV.
GIP-ADDR子TLV仅在GADDR TLV内携带。
The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3 within the GADDR TLV. It has the same format as the Group MAC Address sub-TLV described in Section 2.1.1 except that k=16. The fields are as follows:
组IPv6地址（GIPV6-ADDR）子TLV是GADDR TLV中的子TLV类型3。其格式与第2.1.1节中描述的组MAC地址子TLV相同，但k=16除外。字段如下所示：
o Type: sub-TLV type, set to 3 (GIPV6-ADDR).
o 类型：子TLV类型，设置为3（GIPV6-ADDR）。
o Length: 5 + m + k*n = 5 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：5+m+k*n=5+m+16*n，其中m是组记录数，n是组地址数和源地址数之和。
o Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑Id：此字段携带拓扑Id[RFC5120]，如果未使用拓扑，则为零。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV:在传输时必须作为零发送，在接收时被忽略。
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：它携带一个12位VLAN标识符，该标识符对该子TLV中的所有后续地址有效，如果未指定VLAN，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个16字节（128位）的IPv6组地址，后跟16字节的源IPv6地址。如果源的数量不适合单个子TLV，则允许在组地址TLV的另一个实例的另一个子TLV中使用不同的源地址重复相同的组地址。
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
GIPV6-ADDR子TLV仅在GADDR TLV内携带。
The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in Section 2.1.1 provides for a VLAN ID. The Group Labeled MAC Address sub-TLV, below, extends this to a fine-grained label.
第2.1.1节中规定的组地址（GADDR）TLV的GMAC-ADDR子TLV提供VLAN ID。下面标记为MAC地址子TLV的组将其扩展为细粒度标签。
+-+-+-+-+-+-+-+-+
|Type=GLMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fine-Grained Label | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type=GLMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fine-Grained Label | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6:
其中，每组记录采用以下形式，k=6：
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 4 (GLMAC-ADDR).
o 类型：GADDR子TLV类型，设置为4（GLMAC-ADDR）。
o Length: 6 + m + k*n = 6 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：6+m+k*n=6+m+6*n，其中m是组记录数，n是组地址数和源地址数之和。
o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored on receipt.
o RESV：保留。4位字段，必须作为零发送并在接收时忽略。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑ID：此字段携带拓扑ID[RFC5120]，如果未使用拓扑，则为零。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no label is specified.
o 标签：它携带此子TLV中所有后续MAC地址的细粒度标签[RFC7172]标识符，如果未指定标签，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个6字节（48位）的多播地址，后跟6字节的源MAC地址。如果源不适合于单个子TLV，则相同的组地址可以在组地址TLV的另一实例的另一个子TLV中使用不同的源地址重复。
The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.
GLMAC-ADDR子TLV仅在GADDR TLV内携带。
The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV type 5 within the GADDR TLV. It has the same format as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 except that k=4. The fields are as follows:
标记为IPv4地址（GLIP-ADDR）子TLV的组是GADDR TLV中的子TLV类型5。其格式与第2.1.4节所述标记为MAC地址子TLV的组相同，但k=4除外。字段如下所示：
o Type: sub-TLV type, set to 5 (GLIP-ADDR).
o 类型：子TLV类型，设置为5（GLIP-ADDR）。
o Length: 6 + m + k*n = 6 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：6+m+k*n=6+m+4*n，其中m是组记录数，n是组地址数和源地址数之和。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑ID：此字段携带拓扑ID[RFC5120]，如果未使用拓扑，则为零。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV:在传输时必须作为零发送，在接收时被忽略。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv4 addresses in this sub-TLV, or the value zero if no label is specified.
o 标签：它携带此子TLV中所有后续IPv4地址的细粒度标签[RFC7172]标识符，如果未指定标签，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个4字节（32位）的IPv4组地址，后跟4字节的源IPv4地址。如果源的数量不适合单个子TLV，则允许在组地址TLV的另一个实例的另一个子TLV中使用不同的源地址重复相同的组地址。
The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.
GLIP-ADDR子TLV仅在GADDR TLV内携带。
The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 6 within the GADDR TLV. It has the same format as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 except that k=16. The fields are as follows:
标记为IPv6地址（GLIPV6-ADDR）子TLV的组在GADDR TLV中为子TLV类型6。其格式与第2.1.4节所述标记为MAC地址子TLV的组相同，但k=16除外。字段如下所示：
o Type: sub-TLV type, set to 6 (GLIPV6-ADDR).
o 类型：子TLV类型，设置为6（GLIPV6-ADDR）。
o Length: 6 + m + k*n = 6 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 长度：6+m+k*n=6+m+16*n，其中m是组记录数，n是组地址数和源地址数之和。
o Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o 拓扑Id：此字段携带拓扑Id[RFC5120]，如果未使用拓扑，则为零。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV:在传输时必须作为零发送，在接收时被忽略。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv6 addresses in this sub-TLV, or the value zero if no label is specified.
o 标签：它携带此子TLV中所有后续IPv6地址的细粒度标签[RFC7172]标识符，如果未指定标签，则值为零。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：一个1字节无符号整数，表示此子TLV中的组记录数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o 组记录：每个组记录包含源的数量。如果此字段为零，则表示（*，G）的侦听器，即不受源限制的侦听器。然后它有一个16字节（128位）的IPv6组地址，后跟16字节的源IPv6地址。如果源的数量不适合单个子TLV，则允许在组地址TLV的另一个实例的另一个子TLV中使用不同的源地址重复相同的组地址。
The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
GLIPV6-ADDR子TLV仅在GADDR TLV内携带。
TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT-Port-Cap-TLV) as specified in [RFC6165]. The following subsections specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL.
TRILL使用[RFC6165]中规定的多拓扑感知端口能力TLV（MT Port Cap TLV）。以下小节规定了MT Port Cap TLV为TRILL运输的子TLV。
In TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV is carried in every IIH PDU. It has the following format:
在TRILL中，每个IIH PDU中都带有一个特殊的VLAN和标志（VLAN-Flags）子TLV。其格式如下：
+--+--+--+--+--+--+--+--+
| Type | (1 byte)
+--+--+--+--+--+--+--+--+
| Length | (1 byte)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Port ID | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sender Nickname | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TR|R |R |R | Designated-VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+
| Type | (1 byte)
+--+--+--+--+--+--+--+--+
| Length | (1 byte)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Port ID | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sender Nickname | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TR|R |R |R | Designated-VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV 1.
o 类型：子TLV类型，设置为MT端口Cap TLV VLAN-FLAGS子TLV 1。
o Length: 8.
o 长度：8。
o Port ID: An ID for the port on which the enclosing TRILL IIH PDU is being sent as specified in [RFC6325], Section 4.4.2.
o 端口ID：根据[RFC6325]第4.4.2节的规定，发送封装TRILL IIH PDU的端口的ID。
o Sender Nickname: If the sending IS is holding any nicknames as discussed in [RFC6325], Section 3.7, one MUST be included here. Otherwise, the field is set to zero. This field is to support intelligent end stations that determine the egress IS (RBridge) for unicast data through a directory service or the like and that need a nickname for their first hop to insert as the ingress nickname to correctly format a TRILL Data frame (see [RFC6325], Section 4.6.2, point 8). It is also referenced in connection with the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as the egress on one-hop RBridge Channel messages [RFC7178], for example, those use for BFD over TRILL [RFC7175].
o 发送方昵称：如果发送方持有[RFC6325]第3.7节中讨论的任何昵称，则此处必须包括一个昵称。否则，该字段将设置为零。该字段用于支持智能终端站，智能终端站通过目录服务等确定单播数据的出口is（RBridge），并且需要为其第一跳插入昵称作为入口昵称，以正确格式化TRILL数据帧（参见[RFC6325]，第4.6.2节，第8点）。它还与VLAN指定的子TLV（见第2.2.5节）相关，并可用作单跳RBridge通道消息[RFC7178]上的出口，例如，用于TRILL上的BFD[RFC7175]。
o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV, as specified in [RFC6325], Section 4.4.5.
o Outer.VLAN：包含此子TLV的TRILL IIH帧的12位外部VLAN ID的副本，如[RFC6325]第4.4.5节所述。
o Designated-VLAN: The 12-bit ID of the Designated VLAN for the link, as specified in [RFC6325], Section 4.2.4.2.
o 指定VLAN：链路指定VLAN的12位ID，如[RFC6325]第4.2.4.2节所述。
o AF, AC, VM, BY, and TR: These flag bits have the following meanings when set to one, as specified in the listed section of [RFC6325]:
o AF、AC、VM、BY和TR：如[RFC6325]中列出的部分所述，当设置为1时，这些标志位具有以下含义：
RFC 6325
Bit Section Meaning if bit is one
--------------------------------------
RFC 6325
Bit Section Meaning if bit is one
--------------------------------------
AF 4.4.2 Originating IS believes it is Appointed Forwarder for the VLAN and port on which the containing IIH PDU was sent.
AF 4.4.2始发IS认为其是VLAN和发送包含IIH PDU的端口的指定转发器。
AC 4.9.1 Originating port configured as an access port (TRILL traffic disabled).
AC 4.9.1配置为接入端口的始发端口（TRILL通信禁用）。
VM 4.4.5 VLAN mapping detected on this link.
在此链接上检测到VM 4.4.5 VLAN映射。
BY 4.4.2 Bypass pseudonode.
通过4.4.2旁路伪节点。
TR 4.9.1 Originating port configured as a trunk port (end-station service disabled).
TR 4.9.1配置为中继端口的始发端口（终端站服务禁用）。
o R: Reserved bit. MUST be sent as zero and ignored on receipt.
o R：保留位。必须作为零发送，并在收到时忽略。
The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the port of the originating IS on which the containing Hello was sent, as specified in [RFC6325], Section 4.4.2. It has the following format:
可选的Enabled VLAN子TLV指定了在发送包含Hello的始发IS的端口上启用的VLAN，如[RFC6325]第4.4.2节所述。其格式如下：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV 2.
o 类型：子TLV类型，设置为MT端口Cap启用TLV的VLAN子TLV 2。
o Length: Variable, minimum 3.
o 长度：可变，最小3。
o RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt.
o RESV:4个保留位，必须作为零发送，并在收到时忽略。
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-order bit of the first byte of the VLAN bit-map.
o 起始VLAN ID：由VLAN位映射的第一个字节的高位表示的12位VLAN ID。
o VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field.
o VLAN位映射：最高位表示等于起始VLAN ID的VLAN，下一高位表示等于起始VLAN ID+1的VLAN，继续到VLAN位映射字段的末尾。
If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the sets of VLANs indicated by each of the Enabled-VLAN sub-TLVs in the Hello.
如果此子TLV在Hello中出现多次，则启用的VLAN集是Hello中每个启用的VLAN子TLV指示的VLAN集的并集。
The Designated RBridge (DRB) on a link uses the Appointed Forwarders sub-TLV to inform other ISs on the link that they are the designated VLAN-x forwarder for one or more ranges of VLAN IDs as specified in [RFC6439]. It has the following format:
链路上的指定RBridge（DRB）使用指定转发器子TLV通知链路上的其他ISs，他们是[RFC6439]中规定的一个或多个VLAN ID范围的指定VLAN-x转发器。其格式如下：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each appointment is of the form:
如果每次任命的形式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV 3.
o 类型：子TLV类型，设置为MT端口盖TLV指定DFWRDRS子TLV 3。
o Length: 6*n bytes, where there are n appointments.
o 长度：6*n字节，其中有n个约会。
o Appointee Nickname: The nickname of the IS being appointed a forwarder.
o 被任命人昵称：被任命为货运代理的公司的昵称。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV:4位，必须作为零发送，并在接收时忽略。
o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting both Start.VLAN and VLAN.end to the same value indicates a range of one VLAN ID. If Start.VLAN is not equal to VLAN.end and Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN was 0x001. If Start.VLAN is not equal to VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than Start.VLAN, the sub-TLV is ignored. If both Start.VLAN and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be enabled for them.
o Start.VLAN，End.VLAN：此VLAN ID范围包括在内。将Start.VLAN和VLAN.end设置为相同的值表示一个VLAN ID的范围。如果Start.VLAN不等于VLAN.end，并且Start.VLAN为0x000，则子TLV将被解释为Start.VLAN为0x001。如果Start.VLAN不等于VLAN.end，且VLAN.end为0xFFF，则子TLV将被解释为VLAN.end为0xFFE。如果VLAN.end小于Start.VLAN，则忽略子TLV。如果Start.VLAN和VLAN.end均为0x000或均为0xFFF，则忽略子TLV。值0x000或0xFFF不是有效的VLAN ID，无法为其启用端口。
An IS's nickname may occur as Appointed Forwarder for multiple VLAN ranges by occurrences of this sub-TLV within the same or different MT Port Capability TLVs within an IIH PDU. See [RFC6439].
IS的昵称可以作为多个VLAN范围的指定转发器出现，其方式是在IIH PDU中相同或不同的MT端口能力TLV中出现此子TLV。见[RFC6439]。
The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported and the support of optional hop-by-hop capabilities. By implication, lower versions are also supported. If this sub-TLV is missing from an IIH, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325] and supports no optional capabilities indicated by this sub-TLV.
Port TRILL Version（Port-TRILL-VER）子TLV表示支持的TRILL标准的最大版本以及可选逐跳功能的支持。言下之意，也支持较低版本。如果IIH中缺少此子TLV，则假定原始is仅支持协议[RFC6325]的基本版本（版本0），并且不支持此子TLV指示的可选功能。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
o Type: MT-Port-Cap-TLV sub-TLV type, set to 7 (PORT-TRILL-VER).
o 类型：MT Port Cap TLV sub TLV类型，设置为7（Port-TRILL-VER）。
o Length: 5.
o 长度：5。
o Max-version: A one-byte unsigned integer set to the maximum version supported.
o 最大版本：一个单字节无符号整数，设置为支持的最大版本。
o Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 3 through 13 indicate that the corresponding TRILL Header hop-by-hop extended flags [RFC7179] are supported. Bits 0 through 2 and 14 to 31 are reserved to indicate support of optional capabilities. A one bit indicates that the flag or capability is supported by the sending IS. Bits in this field MUST be set to zero except as permitted for a capability being advertised or if a hop-by-hop extended header flag is supported.
o 支持的功能和头标志：32位的位向量，按网络顺序编号为0到31。位3到13表示支持相应的TRILL报头逐跳扩展标志[RFC7179]。保留位0至2和14至31以表示支持可选功能。一位表示发送is支持该标志或功能。此字段中的位必须设置为零，除非允许播发功能或支持逐跳扩展头标志。
This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL IIH. If there is more than one occurrence, the minimum of the supported versions is assumed to be correct and a capability or header flag is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the TRILL-VER sub-TLV (Section 2.3.1) so they cannot conflict. The flags and capabilities indicated in this sub-TLV relate to hop-by-hop processing that can differ between the ports of an IS (RBridge) and thus must be advertised in IIHs. For example, a capability requiring cryptographic hardware assist might be supported on some ports and not others. However, the TRILL version is the same as that in the PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of TRILL version sub-TLV(s), uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s).
此子TLV（如果存在）必须出现在颤音IIH中的MT端口帽TLV中。如果出现多个事件，则假定支持的最低版本是正确的，并且仅当所有事件指示时，才假定支持功能或标题标志。本子TLV中可指示支持的标志和功能与TRILL-VER子TLV（第2.3.1节）中的标志和功能不相交，因此它们不会冲突。此子TLV中指示的标志和功能与逐跳处理相关，在IS（RBridge）端口之间可能有所不同，因此必须在IIHs中公布。例如，某些端口可能支持需要加密硬件协助的功能，而其他端口则不支持。但是，TRILL版本与PORT-TRILL-VER子TLV中的版本相同。如果IS与TRILL版本子TLV的发送IS相邻，则使用其在PORT-TRILL-VER子TLV中接收的TRILL版本优先于在TRILL-VER子TLV中接收的版本。
The optional VLANs Appointed sub-TLV specifies, for the port of the originating IS on which the containing Hello was sent, the VLANs for which it is Appointed Forwarder. This sub-TLV has the following format:
可选的VLAN指定子TLV为发送包含Hello的始发IS的端口指定其被指定为转发器的VLAN。此子TLV具有以下格式：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV 8.
o 类型：子TLV类型，设置为MT端口Cap TLV VLAN指定子TLV 8。
o Length: Variable, minimum 3.
o 长度：可变，最小3。
o RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt.
o RESV:4个保留位，必须作为零发送，并在收到时忽略。
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-order bit of the first byte of the VLAN bit-map.
o 起始VLAN ID：由VLAN位映射的第一个字节的高位表示的12位VLAN ID。
o VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field.
o VLAN位映射：最高位表示等于起始VLAN ID的VLAN，下一高位表示等于起始VLAN ID+1的VLAN，继续到VLAN位映射字段的末尾。
If this sub-TLV occurs more than once in a Hello, the originating IS is declaring that it believes itself to be Appointed Forwarder on the port on which the enclosing IIH was sent for the union of the sets of VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.
如果此子TLV在Hello中出现不止一次，则发起方声明其认为自己是发送封闭IIH的端口上的指定转发器，用于Hello中指定子TLV的每个VLAN指示的VLAN集的联合。
The Router Capability TLV is specified in [RFC4971] and the MT-Capability TLV in [RFC6329]. All of the following sub-sections specify sub-TLVs that can be carried in the Router Capability TLV (#242) and the MT-Capability TLV (#144) with the same sub-TLV number for both TLVs. These TLVs are in turn carried only by LSPs.
[RFC4971]中规定了路由器能力TLV，而[RFC6329]中规定了MT能力TLV。以下所有小节都指定了可在路由器能力TLV（#242）和MT能力TLV（#144）中承载的子TLV，这两个TLV具有相同的子TLV编号。这些TLV反过来只能由LSP携带。
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported and the support of optional capabilities by the originating IS. By implication, lower versions are also supported. If this sub-TLV is missing, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325], and no optional capabilities indicated by this sub-TLV are supported.
TRILL版本（TRILL-VER）子TLV表示受支持的TRILL标准的最大版本，以及原始IS对可选功能的支持。言下之意，也支持较低版本。如果缺少此子TLV，则假定原始is仅支持协议[RFC6325]的基本版本（零版本），并且不支持此子TLV指示的可选功能。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).
o 类型：路由器能力子TLV类型，设置为13（TRILL-VER）。
o Length: 5.
o 长度：5。
o Max-version: A one-byte unsigned integer set to the maximum version supported.
o 最大版本：一个单字节无符号整数，设置为支持的最大版本。
o Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 14 through 31 indicate that the corresponding TRILL Header extended flags [RFC7179] are supported. Bits 0 through 13 are reserved to indicate support of optional capabilities. A one bit indicates that the originating IS supports the flag or capability. For example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in this field MUST be set to zero except as permitted for a capability being advertised or an extended header flag supported.
o 支持的功能和头标志：32位的位向量，按网络顺序编号为0到31。位14到31表示支持相应的TRILL头扩展标志[RFC7179]。保留位0至13以表示支持可选功能。一位表示始发IS支持该标志或功能。例如，支持多级颤音IS-IS[多级]。此字段中的位必须设置为零，除非允许播发功能或支持扩展头标志。
This sub-TLV, if present in a Router Capability TLV, MUST occur in the LSP number zero for the originating IS. If found in a Router Capability TLV in other fragments, it is ignored. If there is more than one occurrence in LSP number zero, the minimum of the supported versions is assumed to be correct, and an extended header flag or capability is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the PORT-TRILL-VER sub-TLV (Section 2.2.4) so they cannot conflict. However, the
如果存在于路由器能力TLV中，则该子TLV必须出现在发起IS的LSP编号0中。如果在其他片段中的路由器功能TLV中找到，则忽略它。如果在零号LSP中出现多个事件，则假定支持的最低版本是正确的，并且仅当所有事件都指示时，才假定支持扩展头标志或功能。此子TLV中可指示支持的标志和功能与PORT-TRILL-VER子TLV（第2.2.4节）中的标志和功能不相交，因此它们不会冲突。但是,
TRILL version is the same as that in the PORT-TRILL-VER sub-TLV, and an IS that is adjacent to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s).
TRILL版本与PORT-TRILL-VER子TLV中的版本相同，并且与TRILL-VER子TLV的原始is相邻的is优先使用在PORT-TRILL-VER子TLV中接收的TRILL版本，而不是在TRILL-VER子TLV中接收的版本。
For multi-topology-aware TRILL Switches, the TRILL version and capabilities announced for the base topology are assumed to apply to all topologies for which a separate TRILL version announcement does not occur in an MT-Capability TLV. Such announcements for non-zero topologies need not occur in fragment zero.
对于多拓扑感知TRILL交换机，假定为基本拓扑发布的TRILL版本和功能适用于MT功能TLV中没有单独发布TRILL版本的所有拓扑。非零拓扑的此类公告不需要在零片段中出现。
The Nickname (NICKNAME) Router Capability sub-TLV carries information about the nicknames of the originating IS, along with information about its priority to hold those nicknames and the priority for each nickname to be a tree root as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may occur.
昵称（昵称）路由器功能子TLV包含有关始发IS的昵称的信息，以及关于其保存这些昵称的优先级以及每个昵称作为树根的优先级的信息，如[RFC6325]第3.7.3节所述。此子TLV可能会出现多个实例。
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each nickname record is of the form:
其中，每个昵称记录的形式如下：
+-+-+-+-+-+-+-+-+
| Nickname.Pri | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Nickname.Pri | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 6 (NICKNAME).
o 类型：路由器能力和MT能力子TLV类型，设置为6（昵称）。
o Length: 5*n, where n is the number of nickname records present.
o 长度：5*n，其中n是存在的昵称记录数。
o Nickname.Pri: An 8-bit unsigned integer priority to hold a nickname as specified in Section 3.7.3 of [RFC6325].
o 昵称.Pri：8位无符号整数优先级，用于保存[RFC6325]第3.7.3节中指定的昵称。
o Tree Root Priority: This is an unsigned 16-bit integer priority to be a tree root as specified in Section 4.5 of [RFC6325].
o 树根优先级：这是[RFC6325]第4.5节中指定的树根的无符号16位整数优先级。
o Nickname: This is an unsigned 16-bit integer as specified in Section 3.7 of [RFC6325].
o 昵称：这是[RFC6325]第3.7节中指定的无符号16位整数。
Each IS providing TRILL service uses the TREES sub-TLV to announce three numbers related to the computation of distribution trees as specified in Section 4.5 of [RFC6325]. Its format is as follows:
每个IS提供TRILL服务使用TREES子TLV宣布与[RFC6325]第4.5节中规定的分布树计算相关的三个数字。其格式如下：
+-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 7 (TREES).
o 类型：路由器能力和MT能力子TLV类型，设置为7（树）。
o Length: 6.
o 长度：6。
o Number of trees to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 要计算的树数：如[RFC6325]第4.5节所述的无符号16位整数。
o Maximum trees able to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 能够计算的最大树数：[RFC6325]第4.5节中规定的无符号16位整数。
o Number of trees to use: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 要使用的树数：[RFC6325]第4.5节中规定的无符号16位整数。
The Tree Identifiers (TREE-RT-IDs) sub-TLV is an ordered list of nicknames. When originated by the IS that has the highest priority to be a tree root, it lists the distribution trees that the other ISs are required to compute as specified in Section 4.5 of [RFC6325]. If
树标识符（树RT ID）子TLV是一个有序的昵称列表。当由具有最高优先级的IS作为树根发起时，它列出了其他ISs需要按照[RFC6325]第4.5节的规定计算的分布树。如果
this information is spread across multiple sub-TLVs, the starting tree number is used to allow the ordered lists to be correctly concatenated. The sub-TLV format is as follows:
此信息分布在多个子TLV上，起始树编号用于正确连接有序列表。子TLV格式如下所示：
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 8 (TREE-RT-IDs).
o 类型：路由器能力和MT能力子TLV类型，设置为8（树RT ID）。
o Length: 2 + 2*n, where n is the number of nicknames listed.
o 长度：2+2*n，其中n是列出的昵称数。
o Starting Tree Number: This identifies the starting tree number of the nicknames that are trees for the domain. This is set to 1 for the sub-TLV containing the first list. Other Tree-Identifiers sub-TLVs will have the number of the starting list they contain. In the event the same tree identifier can be computed from two such sub-TLVs and they are different, then it is assumed that this is a transient condition that will get cleared. During this transient time, such a tree SHOULD NOT be computed unless such computation is indicated by all relevant sub-TLVs present.
o 起始树编号：标识作为域树的昵称的起始树编号。对于包含第一个列表的子TLV，该值设置为1。其他树标识符子TLV将具有它们包含的起始列表的编号。如果可以从两个这样的子TLV计算相同的树标识符，并且它们是不同的，则假定这是一个将被清除的瞬态条件。在这一过渡时间内，不应计算此类树，除非所有相关子TLV都指示了此类计算。
o Nickname: The nickname at which a distribution tree is rooted.
o 昵称：分发树的根所在的昵称。
This Router Capability sub-TLV has the same structure as the Tree Identifiers sub-TLV specified in Section 2.3.4. The only difference is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees listed are those that the originating IS wishes to use as specified in [RFC6325], Section 4.5.
该路由器能力子TLV的结构与第2.3.4节中规定的树标识符子TLV相同。唯一的区别是，其子TLV类型设置为9（树使用ID），并且列出的树是原始用户希望使用的树，如[RFC6325]第4.5节所述。
The value of this sub-TLV consists of a VLAN range and information in common to all of the VLANs in the range for the originating IS. This information consists of flags, a variable length list of spanning tree root bridge IDs, and an Appointed Forwarder status lost counter, all as specified in the sections of [RFC6325] listed with the respective information items below.
此子TLV的值由VLAN范围和发起IS范围内所有VLAN的公共信息组成。该信息由标志、生成树根网桥ID的可变长度列表和指定的转发器状态丢失计数器组成，所有这些都在[RFC6325]的章节中指定，并在下面列出相应的信息项。
In the set of LSPs originated by an IS, the union of the VLAN ranges in all occurrences of this sub-TLV MUST be the set of VLANs for which the originating IS is Appointed Forwarder on at least one port, and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap unless the information provided about a VLAN is the same in every instance. However, as a transient state, these conditions may be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, that IS is assumed to be uninterested in receiving traffic for that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS with different information in the different instances, the following apply:
在由IS发起的LSP集合中，此子TLV的所有实例中的VLAN范围的并集必须是发起IS在至少一个端口上被指定为转发器的VLAN集合，并且IS的多个VLAN子TLV中的VLAN范围不得重叠，除非提供的关于VLAN的信息在每个实例中都相同。但是，作为瞬态，这些条件可能会被违反。如果某个VLAN未列在is的任何INT-VLAN子TLV中，则假定该VLAN对接收该VLAN的流量不感兴趣。如果一个VLAN出现在一个IS的多个INT-VLAN子TLV中，并且在不同的实例中具有不同的信息，则以下情况适用：
- If those sub-TLVs provide different nicknames, it is unspecified which nickname takes precedence. - The largest Appointed Forwarder status lost counter, using serial number arithmetic [RFC1982], is used. - The originating IS is assumed to be attached to a multicast IPv4 router for that VLAN if any of the INT-VLAN sub-TLVs assert that it is so connected and similarly for IPv6 multicast router attachment. - The root bridge lists from all of the instances of the VLAN for the originating IS are merged.
- 如果这些子TLV提供不同的昵称，则未指定哪个昵称优先。-使用使用序列号算术[RFC1982]的最大指定转发器状态丢失计数器。-如果INT-VLAN子TLV中的任何一个断言它是如此连接的，并且类似于IPv6多播路由器连接，则假定始发连接到该VLAN的多播IPv4路由器。-合并源IS的所有VLAN实例的根网桥列表。
To minimize such occurrences, wherever possible, an implementation SHOULD advertise the update to an interested VLAN and Spanning Tree Roots sub-TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action. An IS that receives an update to an existing interested VLAN and Spanning Tree Roots sub-TLV can minimize the potential disruption associated with the update by employing a hold-down timer prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
为了尽可能减少此类事件的发生，实现应在与其替换的公告相同的LSP片段中向感兴趣的VLAN和生成树根子TLV公告更新。在不可能的情况下，两个受影响的LSP片段应作为原子动作被淹没。接收对现有感兴趣的VLAN的更新的IS和生成树根子TLV可以通过在处理更新之前采用抑制定时器来最小化与更新相关联的潜在中断，从而允许在开始处理之前接收与相同更新相关联的多个LSP片段。
The sub-TLV layout is as follows:
子TLV布局如下所示：
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 10 (INT-VLAN).
o 类型：路由器能力和MT能力子TLV类型，设置为10（INT-VLAN）。
o Length: 10 + 6*n, where n is the number of root bridge IDs.
o 长度：10+6*n，其中n是根网桥ID的数量。
o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field may be used to associate a nickname held by the originating IS with the VLAN range indicated. When not used in this way, it is set to zero.
o 昵称：根据[RFC6325]第4.2.4.4节的规定，此字段可用于将发起IS持有的昵称与所示VLAN范围相关联。如果不以这种方式使用，则将其设置为零。
o Interested VLANS: The Interested VLANs field is formatted as shown below.
o 感兴趣的VLAN：感兴趣的VLAN字段的格式如下所示。
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+
- M4, M6: These bits indicate, respectively, that there is an IPv4 or IPv6 multicast router on a link for which the originating IS is Appointed Forwarder for every VLAN in the indicated range as specified in [RFC6325], Section 4.2.4.4, item 5.1.
- M4、M6：这些位分别表示在[RFC6325]，第4.2.4.4节，第5.1项中规定的指定范围内，对于每个VLAN，发起is被指定为转发器的链路上存在IPv4或IPv6多播路由器。
- R, RESV: These reserved bits MUST be sent as zero and are ignored on receipt.
- R、 RESV：这些保留位必须作为零发送，并且在接收时被忽略。
- VLAN.start and VLAN.end: This VLAN ID range is inclusive. Setting both VLAN.start and VLAN.end to the same value indicates a range of one VLAN ID. If VLAN.start is not equal to VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as if VLAN.start was 0x001. If VLAN.start is not equal to
- VLAN.start和VLAN.end：此VLAN ID范围包括在内。将VLAN.start和VLAN.end设置为相同的值表示一个VLAN ID的范围。如果VLAN.start不等于VLAN.end且VLAN.start为0x000，则子TLV将被解释为VLAN.start为0x001。如果VLAN.start不等于
VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be enabled for them.
VLAN.end和VLAN.end是0xFFF，子TLV被解释为VLAN.end是0xFFE。如果VLAN.end小于VLAN.start，则忽略子TLV。如果VLAN.start和VLAN.end均为0x000或均为0xFFF，则忽略子TLV。值0x000或0xFFF不是有效的VLAN ID，无法为其启用端口。
o Appointed Forwarder Status Lost Counter: This is a count of how many times a port that was Appointed Forwarder for the VLANs in the range given has lost the status of being an Appointed Forwarder for some port as discussed in Section 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the zeroth LSP sequence number is initialized. No special action need be taken at rollover; the counter just wraps around.
o 指定转发器状态丢失计数器：这是指定范围内VLAN的指定转发器端口丢失某些端口的指定转发器状态的次数计数，如[RFC6325]第4.8.3节所述。当第0个LSP序列号初始化时，它在is处初始化为零。翻车时无需采取特殊措施；柜台就在附近。
o Root Bridges: The list of zero or more spanning tree root bridge IDs is the set of root bridge IDs seen for all ports for which the IS is Appointed Forwarder for the VLANs in the specified range as discussed in [RFC6325], Section 4.9.3.2. While, of course, at most one spanning tree root could be seen on any particular port, there may be multiple ports in the same VLANs connected to different bridged LANs with different spanning tree roots.
o 根网桥：零个或多个生成树根网桥ID的列表是为指定范围内的VLAN指定转发器的所有端口的根网桥ID集，如[RFC6325]第4.9.3.2节所述。当然，在任何特定端口上最多可以看到一个生成树根，但同一VLAN中可能有多个端口连接到具有不同生成树根的不同桥接LAN。
An INT-VLAN sub-TLV asserts that the information provided (multicast router attachment, Appointed Forwarder status lost counter, and root bridges) is the same for all VLANs in the range specified. If this is not the case, the range MUST be split into subranges meeting this criteria. It is always safe to use sub-TLVs with a "range" of one VLAN ID, but this may be too verbose.
INT-VLAN子TLV声明所提供的信息（多播路由器连接、指定转发器状态丢失计数器和根网桥）对于指定范围内的所有VLAN都是相同的。如果不是这样，则必须将范围拆分为满足此条件的子范围。使用具有一个VLAN ID的“范围”的子TLV总是安全的，但这可能过于冗长。
The VLAN Group sub-TLV consists of two or more VLAN IDs as specified in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN learning is occurring at the originating IS between the listed VLANs. It is structured as follows:
VLAN组子TLV由[RFC6325]第4.8.4节规定的两个或多个VLAN ID组成。此子TLV表示共享VLAN学习在所列VLAN之间的起始位置发生。其结构如下：
+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 14 (VLAN-GROUP).
o 类型：路由器能力和MT能力子TLV类型，设置为14（VLAN-GROUP）。
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero.
o 长度：4+2*n，其中n是第一个以外的辅助VLAN ID字段数。n可以是零。
o RESV: a 4-bit field that MUST be sent as zero and ignored on receipt.
o RESV：一个4位字段，必须作为零发送，并在接收时忽略。
o Primary VLAN ID: This identifies the primary VLAN ID.
o 主VLAN ID：标识主VLAN ID。
o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN Group.
o 辅助VLAN ID：标识VLAN组中的辅助VLAN。
o more Secondary VLAN IDs: zero or more byte pairs, each with the top 4 bits as a RESV field and the low 12 bits as a VLAN ID.
o 更多辅助VLAN ID：零个或多个字节对，每个字节对的前4位作为RESV字段，低12位作为VLAN ID。
An IS that can handle fine-grained labeling [RFC7172] announces its fine-grained label connectivity and related information in the Interested Labels and Spanning Tree Roots sub-TLV (INT-LABEL). It is a variation of the Interested VLANs and Spanning Tree Roots sub-TLV (INT-VLAN) and is structured as follows.
可以处理细粒度标签的IS[RFC7172]在相关标签和生成树根子TLV（INT-label）中宣布其细粒度标签连接性和相关信息。它是感兴趣的VLAN和生成树根子TLV（INT-VLAN）的变体，其结构如下。
+-+-+-+-+-+-+-+-+
|Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
+-+-+-+-+-+-+-+-+
|Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 15 (INT-LABEL).
o 类型：路由器能力和MT能力子TLV类型，设置为15（INT-LABEL）。
o Length: 11 + 6*n, where n is the number of root bridge IDs.
o 长度：11+6*n，其中n是根网桥ID的数量。
o Nickname: This field may be used to associate a nickname held by the originating IS with the Interested Labels indicated. When not used in this way, it is set to zero.
o 昵称：此字段可用于将原始IS持有的昵称与指定的感兴趣标签相关联。如果不以这种方式使用，则将其设置为零。
o Interested Labels: The Interested Labels field is seven bytes long and formatted as shown below.
o 感兴趣的标签：感兴趣的标签字段有七个字节长，格式如下所示。
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- M4, M6: These bits indicate, respectively, that there is an IPv4 or IPv6 multicast router on a link to which the originating IS is Appointed Forwarder for the VLAN corresponding to every label in the indicated range.
- M4、M6：这些位分别表示在一条链路上有一个IPv4或IPv6多播路由器，发端被指定为VLAN的转发器，对应于指示范围内的每个标签。
- BM: If the BM (bit-map) bit is zero, the last three bytes of the Interested Labels is a Label.end label number. If the BM bit is one, those bytes are a bit-map as described below.
- BM：如果BM（位图）位为零，则感兴趣标签的最后三个字节是Label.end标签号。如果BM位为1，则这些字节为如下所述的位映射。
- R: These reserved bits MUST be sent as zero and are ignored on receipt.
- R：这些保留位必须作为零发送，并且在接收时被忽略。
- Label.start and Label.end: If the BM bit is zero, this fine-grained label [RFC7172] ID range is inclusive. These fields are treated as unsigned integers. Setting them both to the same label ID value indicates a range of one label ID. If Label.end is less than Label.start, the sub-TLV is ignored.
- Label.start和Label.end：如果BM位为零，则此细粒度标签[RFC7172]ID范围包括在内。这些字段被视为无符号整数。将两者设置为相同的标签ID值表示一个标签ID的范围。如果label.end小于label.start，则忽略子TLV。
- Label.start and bit-map: If the BM bit is one, the fine-grained labels that the IS is interested in are indicated by a 24-bit bit-map. The interested labels are the Label.start number plus the bit number of each one bit in the bit-map. So, if bit zero of the bit-map is a one, the IS is interested in the label with value Label.start, and if bit 23 of the bit-map is a one, the IS is interested in the label with value Label.start+23.
- Label.start和位图：如果BM位为1，则感兴趣的细粒度标签由24位位图指示。感兴趣的标签是Label.start number加上位图中每一位的位号。因此，如果位图的位0为1，则is感兴趣的是带有值label.start的标签，如果位图的位23为1，则is感兴趣的是带有值label.start+23的标签。
o Appointed Forwarder Status Lost Counter: This is a count of how many times a port that was Appointed Forwarder for a VLAN mapping to the fine-grained label in the range or bit-map given has lost the status of being an Appointed Forwarder as discussed in Section 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the zeroth LSP sequence number is initialized. No special action need be taken at rollover; the counter just wraps around.
o 指定转发器状态丢失计数器：这是指定转发器用于VLAN映射到给定范围或位图中细粒度标签的端口丢失指定转发器状态的次数，如[RFC6325]第4.8.3节所述。当第0个LSP序列号初始化时，它在is处初始化为零。翻车时无需采取特殊措施；柜台就在附近。
o Root Bridges: The list of zero or more spanning tree root bridge IDs is the set of root bridge IDs seen for all ports for which the IS is Appointed Forwarder for a VLAN mapping to the fine-grained label in the specified range or bit-map. (See [RFC6325], Section 4.9.3.2.) While, of course, at most one spanning tree root could be seen on any particular port, there may be multiple relevant ports connected to different bridged LANs with different spanning tree roots.
o 根网桥：零个或多个生成树根网桥ID的列表是所有端口的根网桥ID集，为指定范围或位图中的细粒度标签指定了VLAN映射的转发器。（参见[RFC6325]，第4.9.3.2节。）当然，尽管在任何特定端口上最多可以看到一个生成树根，但可能有多个相关端口连接到具有不同生成树根的不同桥接LAN。
An INT-LABEL sub-TLV asserts that the information provided (multicast router attachment, Appointed Forwarder status lost counter, and root bridges) is the same for all labels specified. If this is not the case, the sub-TLV MUST be split into subranges and/or separate bit maps meeting this criteria. It is always safe to use sub-TLVs with a "range" of one VLAN ID, but this may be too verbose.
INT-LABEL子TLV声明所提供的信息（多播路由器附件、指定的转发器状态丢失计数器和根网桥）对于所有指定的标签都是相同的。如果情况并非如此，则必须将子TLV拆分为子范围和/或满足此标准的单独位图。使用具有一个VLAN ID的“范围”的子TLV总是安全的，但这可能过于冗长。
An IS announces the RBridge Channel protocols [RFC7178] it supports through use of this sub-TLV.
IS通过使用此子TLV宣布其支持的RBridge信道协议[RFC7178]。
+-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Zero or more bit vectors (variable)
+-+-+-+-...
+-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Zero or more bit vectors (variable)
+-+-+-+-...
o Type: Router Capability and MT-Capability RBridge Channel Protocols sub-TLV, set to 16 (RBCHANNELS).
o 类型：路由器能力和MT能力RBridge通道协议子TLV，设置为16（RBCHANNELS）。
o Length: variable.
o 长度：可变。
o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit indicates support of a particular RBridge Channel protocol. Each byte-aligned bit vector is formatted as follows:
o 位向量：零个或多个字节对齐的位向量，其中一位表示支持特定的RBridge通道协议。每个字节对齐位向量的格式如下：
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...
The Bit Vector Length (BVL) is a seven-bit unsigned integer field giving the number of bytes of bit vector. The Bit Vector Offset (BVO) is a nine-bit unsigned integer field.
位向量长度（BVL）是一个七位无符号整数字段，给出位向量的字节数。位向量偏移量（BVO）是一个9位无符号整数字段。
The bits in each bit vector are numbered in network order, the high-order bit of the first byte of bits being bit 0 + 8*BVO, the low-order bit of that byte being 7 + 8*BVO, the high order bit of the second byte being 8 + 8*BVO, and so on for BVL bytes. A bit vector of RBridge Channel protocols supported MUST NOT extend beyond the end of the value in the sub-TLV in which it occurs. If it does, it is ignored. If multiple byte-aligned bit vectors are present in one such sub-TLV, their representations are contiguous, the BVL field for the next starting immediately after the last byte of bits for the previous bit vector. The one or more bit vectors present MUST exactly fill the sub-TLV value. If there are one or two bytes of value left over, they are ignored; if more than two, an attempt is made to parse them as one or more bit vectors.
每个位向量中的位按网络顺序编号，位的第一个字节的高阶位为位0+8*BVO，该字节的低阶位为7+8*BVO，第二个字节的高阶位为8+8*BVO，对于BVL字节依此类推。受支持的RBridge信道协议的位向量不得超出其所在子TLV中的值的末尾。如果是，则忽略它。如果在一个子TLV中存在多字节对齐的位向量，则它们的表示是连续的，即在前一位向量的最后一个位字节之后立即开始的下一个BVL字段。存在的一个或多个位向量必须完全填充子TLV值。如果剩下一个或两个字节的值，则忽略它们；如果超过两个，则尝试将它们解析为一个或多个位向量。
If different bit vectors overlap in the protocol number space they refer to and they have inconsistent bit values for a channel protocol, support for the protocol is assumed if any of these bit vectors has a 1 for that protocol.
如果不同的位向量在它们所引用的协议编号空间中重叠，并且它们对于信道协议具有不一致的位值，则假定如果这些位向量中的任何一个对于该协议具有1，则对该协议的支持。
The absence of any occurrences of this sub-TLV in the LSP for an IS implies that the IS does not support the RBridge Channel facility. To avoid wasted space, trailing bit vector zero bytes SHOULD be eliminated by reducing BVL, any null bit vectors (ones with BVL equal to zero) eliminated, and generally the most compact encoding used. For example, support for channel protocols 1 and 32 could be encoded as
IS的LSP中未出现此子TLV意味着IS不支持RBridge信道设施。为避免浪费空间，应通过减少BVL消除尾随位向量零字节，消除任何空位向量（BVL等于零的向量），并且通常使用最紧凑的编码。例如，对信道协议1和32的支持可以编码为
BVL = 5 BVO = 0 0b01000000 0b00000000 0b00000000 0b00000000 0b10000000
BVL=5 BVO=0 0b01000000 0b00000000 0b00000000 0b00000000 0b10000000
or as
或作为
BVL = 1 BVO = 0 0b01000000 BLV = 1 BVO = 4 0b1000000
BVL=1 BVO=0 0b01000000 BLV=1 BVO=4 0b1000000
The first takes 7 bytes while the second takes only 6; thus, the second would be preferred.
第一个需要7个字节，而第二个只需要6个字节；因此，第二种方法更可取。
In multi-topology-aware RBridges, RBridge Channel protocols for which support is announced in the base topology are assumed to be supported in all topologies for which there is no separate announcement for RBridge Channel protocol support.
在多拓扑感知的RBridge中，假定在基本拓扑中宣布支持的RBridge信道协议在没有单独宣布RBridge信道协议支持的所有拓扑中都受支持。
Association of an IS to a multi-destination distribution tree through a specific path is accomplished by using the Affinity sub-TLV. The announcement of an Affinity sub-TLV by RB1 with the nickname of RB2 as the first part of an Affinity Record in the sub-TLV value is a request by RB1 that all ISs in the campus connect RB2 as a child of RB1 when calculating any of the trees listed in that Affinity Record. Examples of use include [Affinity] and [Resilient].
IS通过特定路径与多目标分发树的关联是通过使用关联子TLV实现的。RB1宣布一个昵称为RB2的关联子TLV作为子TLV值中关联记录的第一部分，这是RB1在计算该关联记录中列出的任何树时请求校园中的所有ISs将RB2连接为RB1的子树。使用示例包括[亲和力]和[弹性]。
The structure of the Affinity sub-TLV is shown below.
亲和子TLV的结构如下所示。
+-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each AFFINITY RECORD is structured as follows:
其中，每个关联记录的结构如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 17 (AFFINITY).
o 类型：路由器能力和MT能力子TLV类型，设置为17（关联）。
o Length: size of all Affinity Records included, where an Affinity Record listing n tree roots is 4+2*n bytes long.
o 长度：包含的所有关联记录的大小，其中列出n个树根的关联记录的长度为4+2*n字节。
o Nickname: 16-bit nickname of the IS whose associations to the multi-destination trees listed in the Affinity Record are through the originating IS.
o 昵称：IS的16位昵称，其通过原始IS与关联记录中列出的多目标树关联。
o Affinity Flags: 8 bits reserved for future needs to provide additional information about the affinity being announced. MUST be sent as zero and ignored on receipt.
o 关联标志：为将来需要保留8位，以提供有关所宣布关联的附加信息。必须作为零发送，并在收到时忽略。
o Number of trees: A one-byte unsigned integer giving the number of trees for which affinity is being announced by this Affinity Record.
o 树数：一个单字节无符号整数，给出此关联记录为其宣布关联的树数。
o Tree-num of roots: The tree numbers of the distribution trees this Affinity Record is announcing.
o Tree num of roots：此关联记录宣布的分发树的树编号。
There is no need for a field giving the number of Affinity Records as this can be determined by processing those records.
不需要提供关联记录数量的字段，因为这可以通过处理这些记录来确定。
The Label Group sub-TLV consists of two or more fine-grained label [RFC7172] IDs. This sub-TLV indicates that shared label MAC address learning is occurring at the announcing IS between the listed labels. It is structured as follows:
标签组子TLV由两个或多个细粒度标签[RFC7172]ID组成。此子TLV表示共享标签MAC地址学习在所列标签之间的时间发生。其结构如下：
+-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 18 (LABEL-GROUP).
o 类型：路由器能力和MT能力子TLV类型，设置为18（标签组）。
o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero.
o 长度：6+3*n，其中n是第一个以外的辅助VLAN ID字段数。n可以是零。
o Primary Label ID: This identifies the primary Label ID.
o 主标签ID：标识主标签ID。
o Secondary Label ID: This identifies a secondary Label ID in the Label Group.
o 辅助标签ID：标识标签组中的辅助标签ID。
o more Secondary Label IDs: zero or more byte triples, each with a Label ID.
o 更多次要标签ID：零个或多个字节三元组，每个字节都有一个标签ID。
The MTU sub-TLV is used to optionally announce the MTU of a link as specified in [RFC6325], Section 4.2.4.4. It occurs within the Extended Reachability (#22) and MT-ISN (Intermediate System Neighbors) (#222) TLVs.
MTU子TLV用于选择性地宣布[RFC6325]第4.2.4.4节中规定的链路的MTU。它发生在扩展可达性（#22）和MT-ISN（中间系统邻居）（#222）TLV中。
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability and MT-ISN sub-TLV type, set to MTU sub-TLV 28.
o 类型：扩展可达性和MT-ISN子TLV类型，设置为MTU子TLV 28。
o Length: 3.
o 长度：3。
o F: Failed. This bit is a one if MTU testing failed on this link at the required campus-wide MTU.
o F:失败了。如果在所需校园范围的MTU上，此链路上的MTU测试失败，则此位为1。
o RESV: 7 bits that MUST be sent as zero and ignored on receipt.
o RESV:7位，必须作为零发送，并在接收时忽略。
o MTU: This field is set to the largest successfully tested MTU size for this link or zero if it has not been tested, as specified in Section 4.3.2 of [RFC6325].
o MTU：根据[RFC6325]第4.3.2节的规定，此字段设置为该链路的最大成功测试MTU大小，如果未测试，则设置为零。
The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see Section 4.1 below) in place of the IS Neighbor TLV, as specified in Section 4.4.2.1 of [RFC6325] and in [RFC7177]. The structure of the TRILL Neighbor TLV is as follows:
按照[RFC6325]第4.4.2.1节和[RFC7177]中的规定，颤音相邻TLV用于颤音广播链路IIH PDU（见下文第4.1节）中，以代替is相邻TLV。颤音相邻TLV的结构如下所示：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information present for each neighbor is as follows:
每个邻居的信息如下所示：
+-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
o Type: TLV type, set to TRILL Neighbor TLV 145.
o 类型：TLV类型，设置为颤音邻接TLV 145。
o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records, which may be zero.
o 长度：1+（大小+3）*n，其中n是相邻记录数，可以为零。
o S: Smallest flag. If this bit is a one, then the list of neighbors includes the neighbor with the smallest MAC address considered as an unsigned integer.
o S:最小的旗帜。如果该位为1，则邻居列表包括MAC地址最小的邻居，该邻居被视为无符号整数。
o L: Largest flag. If this bit is a one, then the list of neighbors includes the neighbor with the largest MAC address considered as an unsigned integer.
o L:最大的旗帜。如果该位为1，则邻居列表包括MAC地址最大的邻居，该邻居被视为无符号整数。
o R, RESV: These bits are reserved and MUST be sent as zero and ignored on receipt.
o R、 RESV：这些位是保留的，必须作为零发送，并在收到时忽略。
o SIZE: The SNPA size as an unsigned integer in bytes except that 6 is encoded as zero. An actual size of zero is meaningless and cannot be encoded. The meaning of the value 6 in this field is reserved, and TRILL Neighbor TLVs received with a SIZE of 6 are ignored. The SIZE is inherent to the technology of a link and is fixed for all TRILL Neighbor TLVs on that link but may vary
o 大小：SNPA大小是一个以字节为单位的无符号整数，但6编码为零。实际大小为零是没有意义的，无法编码。保留该字段中值6的含义，忽略接收到的大小为6的颤音相邻TLV。该尺寸是链路技术固有的，对于该链路上的所有颤音相邻TLV是固定的，但可能会有所不同
between different links in the campus if those links are different technologies, for example, 6 for EUI-48 SNPAs or 8 for EUI-64 SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL campus is independent of the System ID size.)
校园内不同链路之间，如果这些链路是不同的技术，例如，6个用于EUI-48 SNPA或8个用于EUI-64 SNPA[RFC7042]。（TRILL校园中各个链路上的SNPA大小与系统ID大小无关。）
o F: Failed. This bit is a one if MTU testing to this neighbor failed at the required campus-wide MTU (see [RFC6325], Section 4.3.1).
o F:失败了。如果对该邻居的MTU测试在所需的校园范围MTU上失败，则该位为1（见[RFC6325]，第4.3.1节）。
o O: OOMF. This bit is a one if the IS sending the enclosing TRILL Neighbor TLV is willing to offer the Overload Originated Multi-destination Frame (OOMF) service [RFC7180] to the IS whose port has the SNPA in the enclosing Neighbor RECORD.
o O:OOMF。如果发送封闭的TRILL邻居TLV愿意向其端口在封闭的邻居记录中具有SNPA的is提供源自过载的多目标帧（OOMF）服务[RFC7180]，则该位为1。
o MTU: This field is set to the largest successfully tested MTU size for this neighbor or to zero if it has not been tested.
o MTU：此字段设置为该邻居成功测试的最大MTU大小，如果未测试，则设置为零。
o SNPA (MAC Address): Subnetwork Point of Attachment of the neighbor.
o SNPA（MAC地址）：邻居的子网连接点。
As specified in [RFC7177] and Section 4.4.2.1 of [RFC6325], all MAC addresses may fit into one TLV, in which case both the S and L flags would be set to one in that TLV. If the MAC addresses don't fit into one TLV, the highest MAC address in a TRILL Neighbor TLV with the L flag zero MUST also appear as a MAC address in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST also appear in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will have both the S and L bits on.
如[RFC7177]和[RFC6325]第4.4.2.1节所述，所有MAC地址都可以放入一个TLV，在这种情况下，该TLV中的S和L标志都将设置为一个。如果MAC地址不适合一个TLV，则L标志为零的TRILL邻居TLV中的最高MAC地址也必须在其他一些TRILL邻居TLV（可能在不同的TRILL IIH PDU中）中显示为MAC地址。此外，S标志为零的TRILL邻居TLV中的最低MAC地址也必须出现在其他一些TRILL邻居TLV中（可能出现在不同的TRILL IIH PDU中）。如果IS认为它没有邻居，它必须发送一个TRILL Neighbor TLV，其中包含一个空的邻居记录列表，该列表将同时启用S位和L位。
The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine the MTU on a link between ISs as specified in Section 4.3.2 of [RFC6325] and in [RFC7177].
IS-IS MTU探头和MTU ack PDU用于选择性地确定[RFC6325]第4.3.2节和[RFC7177]中规定的ISs之间链路上的MTU。
The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with PDU Type numbers as indicated in Section 5. They also have a common fixed MTU PDU header as shown below that is 8 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes System IDs.
MTU PDU具有IS-IS PDU公共标头（最多为最大区域地址字节），带有第5节中所示的PDU类型编号。它们还有一个公共的固定MTU PDU头，如下所示，其长度为8+2*（ID长度）字节，在通常的6字节系统ID中为20字节。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
As with other IS-IS PDUs, the PDU Length gives the length of the entire IS-IS packet starting with and including the IS-IS common header.
与其他IS-IS PDU一样，PDU长度给出了整个IS-IS数据包的长度，该数据包从IS-IS公共报头开始并包括IS-IS公共报头。
The Probe ID field is an opaque 48-bit quantity set by the IS issuing an MTU-probe and copied by the responding IS into the corresponding MTU-ack. For example, an IS creating an MTU-probe could compose this quantity from a port identifier and probe sequence number relative to that port.
探测ID字段是一个不透明的48位数量，由发出MTU探测的is设置，并由响应is复制到相应的MTU ack中。例如，正在创建MTU探针的用户可以根据端口标识符和相对于该端口的探针序列号组成该数量。
The Probe Source ID is set by an IS issuing an MTU-probe to its System ID and copied by the responding IS into the corresponding MTU-ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to its System ID. The System ID length is usually 6 bytes but could be a different value as indicated by the ID Length field in the IS-IS PDU Header.
探测源ID由发出MTU探测到其系统ID的is设置，并由响应is复制到相应的MTU ack中。在MTU探测PDU中，Ack源ID设置为零，并在接收时忽略。正在发出MTU ack将ack源ID字段设置为其系统ID。系统ID长度通常为6字节，但可能是IS-IS PDU标头中ID长度字段指示的不同值。
The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded with the Padding TLV to the exact size being tested. Since the minimum size of the Padding TLV is 2 bytes, it would be impossible to pad to exact size if the total length of the required information-bearing fixed fields and TLVs added up to 1 byte less than the desired length. However, the length of the fixed fields and substantive TLVs for MTU PDUs is expected to be quite small compared with their minimum length (minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this should not be a problem.
TLV区域位于MTU PDU标头区域之后。此区域可能包含验证TLV，并且必须使用填充TLV填充到测试的确切大小。由于填充TLV的最小大小为2字节，因此如果包含固定字段和TLV的所需信息的总长度加起来比所需长度少1字节，则不可能填充到精确的大小。然而，与MTU PDU的最小长度（例如，IEEE 802.3链路上的最小1470字节MTU）相比，MTU PDU的固定字段和实质TLV的长度预计将非常小，因此这不应该是一个问题。
The sub-sections below provide details of TRILL use of existing PDUs and TLVs.
以下小节提供了现有PDU和TLV的TRILL使用详情。
The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC7177] specify the contents of the TRILL IIH and how its use in TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state machinery for TRILL neighbors is specified in detail in [RFC7177].
TRILL IIH PDU是TRILL协议使用的IIH PDU的变体。TRILL标准[RFC6325]和[RFC7177]的第4.4节规定了TRILL IIH的内容及其在TRILL中的使用与第3层LAN IIH PDU使用的区别。[RFC7177]中详细说明了颤音邻域的邻接状态机制。
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 IIH PDU.
在TRILL IIH PDU中，IS-IS公共头和固定PDU头与级别1 IIH PDU相同。
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL Neighbor TLV (see Section 2.5).
IS-IS相邻TLV（6）未在颤音IIH中使用，如果它出现在那里，则会被忽略。相反，TRILL LAN IIH PDU使用TRILL邻居TLV（参见第2.5节）。
TRILL uses a fixed zero Area Address as specified in [RFC6325], Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) as follows:
TRILL使用[RFC6325]第4.2.3节规定的固定零区地址。这在4字节区域地址TLV（TLV#1）中编码如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Area Address Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02, Length of Value | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Length of Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00, zero Area Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Area Address Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02, Length of Value | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Length of Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00, zero Area Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that value appears in TRILL IIH PDUs and LSP number zero PDUs.
NLPID（网络层协议ID）0xC0已分配给TRILL[RFC6328]。协议支持的TLV（#129，[RFC1195]）包括该值出现在TRILL IIH PDU和LSP编号为零的PDU中。
An LSP number zero MUST NOT be originated larger than 1470 bytes, but a larger LSP number zero successfully received MUST be processed and forwarded normally.
LSP零号的起始字节不得大于1470字节，但成功接收到的较大LSP零号必须正常处理和转发。
The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; however, if found in other LSP fragments, it is processed normally. Should there be more than one originatingLSPBufferSize TLV for an IS, the minimum size, but not less than 1470, is used.
起始LSPBufferSize TLV（#14）必须为零号LSP；但是，如果在其他LSP片段中发现，则会正常处理。如果IS有多个原始LSPBufferSize TLV，则使用最小尺寸，但不小于1470。
This section gives IANA considerations for the TLVs, sub-TLVs, and PDUs specified herein. A number of new code points are assigned, and those that were assigned by [RFC6326] are included here for convenience. IANA has replaced all [RFC6326] references in the IANA registries with references to this document.
本节给出了本文规定的TLV、子TLV和PDU的IANA注意事项。分配了许多新的代码点，为了方便起见，[RFC6326]分配的代码点包括在这里。IANA已将IANA登记册中的所有[RFC6326]参考文献替换为本文件的参考文献。
This document specifies two IS-IS TLV types -- namely, the Group Address TLV (GADDR-TLV; type 142) and the TRILL Neighbor TLV (type 145). The PDUs in which these TLVs are permitted for TRILL are shown in the table below along with the section of this document where they are discussed. The final "NUMBER" column indicates the permitted number of occurrences of the TLV in their PDU, or set of PDUs in the case of LSPs, which in these two cases is "*" indicating that the TLV MAY occur 0, 1, or more times.
本文档指定了两种IS-IS TLV类型——即组地址TLV（GADDR-TLV；类型142）和TRILL邻居TLV（类型145）。下表显示了允许这些TLV用于TRILL的PDU以及本文件中讨论这些TLV的章节。最后一个“数字”列表示TLV在其PDU中的允许出现次数，或LSP情况下的一组PDU，在这两种情况下为“*”表示TLV可能出现0、1或更多次。
IANA has registered these two code points in the IANA IS-IS TLV registry (ignoring the "Section" and "NUMBER" columns, which are irrelevant to that registry).
IANA已在IANA IS-IS TLV注册表中注册了这两个代码点（忽略与该注册表无关的“部分”和“编号”列）。
Section TLV IIH LSP SNP Purge NUMBER
======= === === === === ===== ======
GADDR-TLV 2.1 142 n y n n *
TRILL Neighbor TLV 2.5 145 y n n n *
Section TLV IIH LSP SNP Purge NUMBER
======= === === === === ===== ======
GADDR-TLV 2.1 142 n y n n *
TRILL Neighbor TLV 2.5 145 y n n n *
This document specifies a number of sub-TLVs. The TLVs in which these sub-TLVs occur are shown in the second table below along with the section of this document where they are discussed. The TLVs within which these sub-TLVs can occur are determined by the presence of an "X" in the relevant column; the column headers are described in the first table below. In some cases, the column header corresponds to two different TLVs in which the sub-TLV can occur.
本文件规定了若干子TLV。下表二显示了这些子TLV所在的TLV以及本文件中讨论它们的章节。这些子TLV可能出现的TLV由相关列中的“X”确定；列标题在下面的第一个表中描述。在某些情况下，列标题对应于两个不同的TLV，其中可以出现子TLV。
Column Head TLV RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
Column Head TLV RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
MT Port 143 6165 MT-Port-Cap-TLV
MT端口143 6165 MT端口盖TLV
MT Cap. 242 4971 Router CAPABILITY 144 6329 MT-Capability
山帽。242 4971路由器能力144 6329 MT能力
Ext. Reach 22 5305 Extended IS Reachability 222 5120 MT-ISN
分机Reach 22 5305扩展为可达性222 5120 MT-ISN
The final "NUMBER" column below indicates the permitted number of occurrences of the sub-TLV cumulatively within all occurrences of their TLV(s) in those TLVs' carrying a PDU (or set of PDUs in the case of LSPs), as follows:
下面的最后一个“数字”列指出了子TLV在其TLV的所有事件中累积出现的允许次数，这些TLV在携带PDU（或LSP情况下的PDU集）的TLV中出现的次数如下：
0-1 = MAY occur zero or one times. 1 = MUST occur exactly once. If absent, the PDU is ignored. If it occurs more than once, results are unspecified. * = MAY occur 0, 1, or more times.
0-1=可能出现零次或一次。1=必须恰好发生一次。如果不存在，则忽略PDU。如果发生多次，则未指定结果。*=可能发生0次、1次或更多次。
The values in the "Section" and "NUMBER" columns are irrelevant to the IANA sub-registries.
“部分”和“数字”列中的值与IANA子注册表无关。
sub- Grp. MT MT Ext.
Name Section TLV# Adr. Port Cap. Reach NUMBER
=================================================================
GMAC-ADDR 2.1.1 1 X - - - *
GIP-ADDR 2.1.2 2 X - - - *
GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 6 X - - - *
VLAN-FLAGS 2.2.1 1 - X - - 1
Enabled-VLANs 2.2.2 2 - X - - *
AppointedFwrdrs 2.2.3 3 - X - - *
PORT-TRILL-VER 2.2.4 7 - X - - 0-1
VLANs-Appointed 2.2.5 8 - X - - *
NICKNAME 2.3.2 6 - - X - *
TREES 2.3.3 7 - - X - 0-1
TREE-RT-IDs 2.3.4 8 - - X - *
TREE-USE-IDs 2.3.5 9 - - X - *
INT-VLAN 2.3.6 10 - - X - *
TRILL-VER 2.3.1 13 - - X - 0-1
VLAN-GROUP 2.3.7 14 - - X - *
INT-LABEL 2.3.8 15 - - X - *
RBCHANNELS 2.3.9 16 - - X - *
sub- Grp. MT MT Ext.
Name Section TLV# Adr. Port Cap. Reach NUMBER
=================================================================
GMAC-ADDR 2.1.1 1 X - - - *
GIP-ADDR 2.1.2 2 X - - - *
GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 6 X - - - *
VLAN-FLAGS 2.2.1 1 - X - - 1
Enabled-VLANs 2.2.2 2 - X - - *
AppointedFwrdrs 2.2.3 3 - X - - *
PORT-TRILL-VER 2.2.4 7 - X - - 0-1
VLANs-Appointed 2.2.5 8 - X - - *
NICKNAME 2.3.2 6 - - X - *
TREES 2.3.3 7 - - X - 0-1
TREE-RT-IDs 2.3.4 8 - - X - *
TREE-USE-IDs 2.3.5 9 - - X - *
INT-VLAN 2.3.6 10 - - X - *
TRILL-VER 2.3.1 13 - - X - 0-1
VLAN-GROUP 2.3.7 14 - - X - *
INT-LABEL 2.3.8 15 - - X - *
RBCHANNELS 2.3.9 16 - - X - *
AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1
=================================================================
Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. Reach
AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1
=================================================================
Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. Reach
IANA has entered the newly assigned sub-TLV numbers in the above table in the relevant existing sub-TLV registries, as determined by which column has an X for that sub-TLV. For the sub-TLVs from NICKNAME through and including VLAN-GROUP, which previously existed only in the registry of sub-TLVs under TLV 242, IANA has added each sub-TLV with the same sub-TLV number to the existing registry for sub-TLVs under TLV 144.
IANA已将新分配的子TLV编号输入上表中的相关现有子TLV登记册中，这取决于该子TLV的列具有X。对于从昵称到VLAN-GROUP的子TLV（以前仅存在于TLV 242下的子TLV注册表中），IANA已将具有相同子TLV编号的每个子TLV添加到TLV 144下的子TLV的现有注册表中。
The IS-IS PDUs registry remains as established in [RFC6326] except that the references to [RFC6326] are updated to reference this document.
IS-IS PDU注册表与[RFC6326]中所述保持一致，除非对[RFC6326]的引用更新为引用本文件。
Any reserved bits (R), bits in reserved fields (RESV), or capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which are specified herein as "MUST be sent as zero and ignored on receipt" or the like, are allocated based on IETF Review [RFC5226].
任何保留位（R）、保留字段中的位（RESV）或PORT-TRILL-VER和TRILL-VER子TLV中的功能位（此处指定为“必须作为零发送，并在接收时忽略”等）均根据IETF评审[RFC5226]进行分配。
Two sub-registries have been created within the TRILL Parameters Registry as follows:
TRILL参数注册表中创建了两个子注册表，如下所示：
Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags Registration Procedures: IETF Review Reference: (This document)
子注册表名称：TRILL-VER子TLV能力标志注册程序：IETF审查参考：（本文件）
Bit Description Reference
===== ============= ===========
0 Affinity sub-TLV support. [Affinity]
1 FGL-safe [RFC7172]
2-13 Unassigned
14-31 Extended header flag support. [RFC7179]
Bit Description Reference
===== ============= ===========
0 Affinity sub-TLV support. [Affinity]
1 FGL-safe [RFC7172]
2-13 Unassigned
14-31 Extended header flag support. [RFC7179]
Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags Registration Procedures: IETF Review Reference: (This document)
子注册表名称：PORT-TRILL-VER子TLV能力标志注册程序：IETF审查参考：（本文件）
Bit Description Reference
===== ============= ===========
0 Hello reduction support. [RFC7180]
1-2 Unassigned
3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned
Bit Description Reference
===== ============= ===========
0 Hello reduction support. [RFC7180]
1-2 Unassigned
3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned
A sub-registry has been created within the TRILL Parameters Registry as follows:
TRILL参数注册表中已创建一个子注册表，如下所示：
Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags Registration Procedures: Standards Action Reference: (This document)
子注册表名称：TRILL Neighbor TLV Neighbor记录标志注册程序：标准操作参考：（本文档）
Bit Short Name Description Reference
============== ============= ===========================
0 Fail Failed MTU test [RFC6325][RFC7176][RFC7177]
1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned
Bit Short Name Description Reference
============== ============= ===========================
0 Fail Failed MTU test [RFC6325][RFC7176][RFC7177]
1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned
For general TRILL protocol security considerations, see the TRILL base protocol standard [RFC6325].
有关TRILL协议的一般安全注意事项，请参阅TRILL基本协议标准[RFC6325]。
This document raises no new security issues for IS-IS. IS-IS security may be used to secure the IS-IS messages discussed here. See [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, replays of Hello packets can create denial-of-service conditions; see [RFC6039] for details. These issues are similar in scope to those discussed in Section 6.2 of [RFC6325], and the same mitigations may apply.
本文档没有为IS-IS提出新的安全问题。IS-IS安全性可用于保护此处讨论的IS-IS消息。参见[RFC5304]和[RFC5310]。即使使用IS-IS身份验证，Hello数据包的重播也会造成拒绝服务条件；详见[RFC6039]。这些问题在范围上与[RFC6325]第6.2节中讨论的问题类似，可以采用相同的缓解措施。
Non-editorial changes from [RFC6326] are summarized in the list below:
[RFC6326]的非编辑性变更汇总如下：
1. Added five sub-TLVs under the Group Address (GADDR) TLV covering VLAN-labeled IPv4 and IPv6 addresses and fine-grained-labeled MAC, IPv4, and IPv6 addresses (Sections 2.1.2, 2.1.3, 2.1.4, 2.1.5, and 2.1.6).
1. 在组地址（GADDR）TLV下添加了五个子TLV，涵盖标记为IPv4和IPv6地址的VLAN以及标记为MAC、IPv4和IPv6地址的细粒度TLV（第2.1.2、2.1.3、2.1.4、2.1.5和2.1.6节）。
2. Added the PORT-TRILL-VER sub-TLV (Section 2.2.4).
2. 增加了PORT-TRILL-VER子TLV（第2.2.4节）。
3. Added the VLANs-Appointed sub-TLV (Section 2.2.5).
3. 增加了VLAN指定子TLV（第2.2.5节）。
4. Changed the TRILL-VER sub-TLV as listed below.
4. 更改了TRILL-VER子TLV，如下所示。
a. Added 4 bytes of TRILL Header extended flags and capabilities supported information.
a. 添加了4字节的TRILL标头扩展标志和支持的功能信息。
b. Required that the TRILL-VER sub-TLV appear in LSP number zero.
b. 要求颤音子TLV显示在零号LSP中。
The above changes to TRILL-VER are backward compatible because
the [RFC6326]-conformant implementations of TRILL thus far have
only supported version zero and not supported any optional
capabilities or extended flags, the level of support indicated by
the absence of the TRILL-VER sub-TLV. Thus, if an
[RFC6326]-conformant implementation of TRILL rejects this sub-TLV
due to the changes specified in this document, it will, at worst,
decide that support of version zero and no extended flags or
capabilities is indicated, which is the best an
[RFC6326]-conformant implementation of TRILL can do anyway.
Similarly, a TRILL implementation that supports TRILL-VER as
specified herein and rejects TRILL-VER sub-TLVs in an
[RFC6326]-conformant TRILL implementation because they are not in
LSP number zero will decide that the implementation supports only
version zero with no extended flag or capabilities support, which
will be correct (Section 2.3.1).
The above changes to TRILL-VER are backward compatible because
the [RFC6326]-conformant implementations of TRILL thus far have
only supported version zero and not supported any optional
capabilities or extended flags, the level of support indicated by
the absence of the TRILL-VER sub-TLV. Thus, if an
[RFC6326]-conformant implementation of TRILL rejects this sub-TLV
due to the changes specified in this document, it will, at worst,
decide that support of version zero and no extended flags or
capabilities is indicated, which is the best an
[RFC6326]-conformant implementation of TRILL can do anyway.
Similarly, a TRILL implementation that supports TRILL-VER as
specified herein and rejects TRILL-VER sub-TLVs in an
[RFC6326]-conformant TRILL implementation because they are not in
LSP number zero will decide that the implementation supports only
version zero with no extended flag or capabilities support, which
will be correct (Section 2.3.1).
5. Clarified the use of invalid VLAN IDs (0x000 and 0xFFF) in the Appointed Forwarders sub-TLV and the Interested VLANs and Spanning Tree Roots sub-TLV (Sections 2.2.3 and 2.3.6).
5. 澄清了指定转发器子TLV和相关VLAN和生成树根子TLV（第2.2.3节和第2.3.6节）中无效VLAN ID（0x000和0xFFF）的使用。
6. Added the Interested Labels and Spanning Tree Roots sub-TLV to indicate attachment of an IS to a fine-grained label [RFC7172] analogous to the existing Interested VLANs and Spanning Tree Roots sub-TLV for VLANs (Section 2.3.8).
6. 添加了感兴趣的标签和生成树根子TLV，以指示IS连接到细粒度标签[RFC7172]，类似于现有感兴趣的VLAN和VLAN的生成树根子TLV（第2.3.8节）。
7. Added the RBridge Channel Protocols sub-TLV so ISs can announce the RBridge Channel protocols they support (Section 2.3.9).
7. 增加了RBridge信道协议子TLV，以便ISs可以宣布其支持的RBridge信道协议（第2.3.9节）。
8. Permitted specification of the length of the link SNPA field in TRILL Neighbor TLVs. This change is backward compatible because the size of 6 bytes is specially encoded as zero, the previous value of the bits in the new SIZE field (Section 2.5).
8. 允许指定TRILL相邻TLV中链路SNPA字段的长度。此更改是向后兼容的，因为6字节的大小专门编码为零，即新大小字段中位的先前值（第2.5节）。
9. Made the size of the MTU PDU Header Probe Source ID and Ack Source ID fields be the ID Length from the IS-IS PDU Header rather than the fixed value 6 (Section 3).
9. 使MTU PDU头探测源ID和Ack源ID字段的大小为IS-IS PDU头的ID长度，而不是固定值6（第3节）。
10. For robustness, required that LSP number zero PDUs be originated as no larger than 1470 bytes but processed regardless of size (Section 4.4).
10. 为确保健壮性，要求LSP编号为零的PDU的初始值不超过1470字节，但无论大小如何处理（第4.4节）。
11. Required that the originatingLSPBufferSize TLV, if present, appear in LSP number zero (Section 4.5).
11. 要求原始LSPBufferSize TLV（如果存在）出现在零号LSP中（第4.5节）。
12. Created sub-registries for and specified the IANA Considerations policy for reserved and capability bits in the TRILL version sub-TLVs (Section 5.4).
12. 为TRILL版本子TLV中的保留位和功能位创建子注册表，并指定IANA注意事项策略（第5.4节）。
13. Added the distribution tree Affinity sub-TLV so ISs can request distribution tree attachments (Section 2.3.10).
13. 添加了分发树关联子TLV，以便ISs可以请求分发树附件（第2.3.10节）。
14. Added the LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV (Section 2.3.11).
14. 添加了与VLAN-GROUP子TLV类似的标签组子TLV（第2.3.11节）。
15. Added multi-topology to permit sub-TLVs previously only in the Router Capability TLV to also appear in the MT-Capability TLV and to permit the MTU sub-TLV previously limited to the Extended Reachability TLV to also appear in the MT-ISN TLV.
15. 添加了多拓扑，以允许先前仅在路由器能力TLV中的子TLV也出现在MT能力TLV中，并允许先前仅限于扩展可达性TLV的MTU子TLV也出现在MT-ISN TLV中。
16. Added a sub-registry for Neighbor TLV Neighbor RECORD flag bits (Section 5.5).
16. 为相邻TLV相邻记录标志位添加了子注册表（第5.5节）。
17. Explicitly stated that if the number of sources in a GADDR-TLV sub-TLV is zero, it indicates a listener for (*,G), that is, a listener not restricted by source (Section 2.1).
17. 明确规定，如果GADDR-TLV子TLV中的源数量为零，则表示（*，G）的侦听器，即不受源限制的侦听器（第2.1节）。
[ISO-10589] International Organization for Standardization, "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)", Second Edition, November 2002.
[ISO-10589]国际标准化组织，“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，第二版，2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[RFC4971]Vasseur，JP.，Ed.，Shen，N.，Ed.，和R.Aggarwal，Ed.，“广告路由器信息的中间系统到中间系统（IS-IS）扩展”，RFC 49712007年7月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，2008年10月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165]Banerjee，A.和D.Ward，“第2层系统的IS-IS扩展”，RFC 61652011年4月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]帕尔曼，R.，伊斯特莱克第三，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“路由桥（RBridges）：基本协议规范”，RFC6325，2011年7月。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328]Eastlake 3rd，D.，“网络层协议标识符的IANA考虑”，BCP 164，RFC 63282011年7月。
[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, April 2012.
[RFC6329]Fedyk，D.，Ed.，Ashwood Smith，P.，Ed.，Allan，D.，Bragg，A.，和P.Unbehagen，“支持IEEE 802.1aq最短路径桥接的IS-IS扩展”，RFC 63292012年4月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439]Perlman，R.，Eastlake，D.，Li，Y.，Banerjee，A.，和F.Hu，“路由桥（RBridges）：指定的货运代理”，RFC 64392011年11月。
[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, May 2014.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链路的透明互连（TRILL）：细粒度标记”，RFC 7172，2014年5月。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, Y., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177]Eastlake 3rd，D.，Perlman，R.，Ghanwani，A.，Yang，Y.，和V.Manral，“大量链路的透明互连（TRILL）：邻接”，RFC 7177，2014年5月。
[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, May 2014.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge信道支持”，RFC 7178，2014年5月。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014.
[RFC7179]Eastlake 3rd，D.，Ghanwani，A.，Manral，V.，Li，Y.，和C.Bestler，“大量链路的透明互连（TRILL）：报头扩展”，RFC 7179，2014年5月。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180]Eastlake 3rd，D.，Zhang，M.，Ghanwani，A.，Manral，V.，和A.Banerjee，“大量链路的透明互连（TRILL）：澄清、更正和更新”，RFC 7180，2014年5月。
[Err2869] RFC Errata, Errata ID 2869, RFC 6326, <http://www.rfc-editor.org>.
[Err2869]RFC勘误表，勘误表ID 2869，RFC 6326<http://www.rfc-editor.org>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 53102009年2月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039]Manral，V.，Bhatia，M.，Jaeggli，J.，和R.White，“路由协议现有加密保护方法的问题”，RFC 6039，2010年10月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326]伊斯特莱克，班纳吉，A.，杜特，D.，帕尔曼，R.，和A.加瓦尼，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 63262011年7月。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，2013年10月。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014.
[RFC7175]Manral，V.，Eastlake 3rd，D.，Ward，D.，和A.Banerjee，“大量链路的透明互连（TRILL）：双向转发检测（BFD）支持”，RFC 7175，2014年5月。
[Affinity] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for TRILL", Work in Progress, April 2014.
[Affinity]Senevirathne，T.，Pathangi，J.，和J.Hudson，“TRILL的协调多播树（CMT）”，正在进行的工作，2014年4月。
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[多层次]帕尔曼，R.，东湖第三大道，加瓦尼，A.，和H.翟，“灵活多层次颤音（大量链接的透明互连）”，正在进行的工作，2014年1月。
[Resilient] Zhang, M. Senevirathne, T., Pathangi, J., Banerjee, A., and A. Ghanwani, "TRILL Resilient Distribution Trees", Work in Progress, December 2013.
[弹性]张，M.Senevirathne，T.，Pathangi，J.，Banerjee，A.，和A.Ghanwani，“颤音弹性分布树”，正在进行的工作，2013年12月。
The authors gratefully acknowledge the contributions and reviews by the following individuals: Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, Radia Perlman, Carlos Pignataro, and Joe Touch.
作者衷心感谢以下个人的贡献和评论：罗斯·卡隆、斯宾塞·道金斯、阿德里安·法雷尔、阿列克谢·梅尔尼科夫、拉迪亚·帕尔曼、卡洛斯·皮格纳塔罗和乔·图奇。
The authors also acknowledge the contributions to [RFC6326] by the following individuals: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for his detailed and helpful comments.
作者还感谢以下个人对[RFC6326]的贡献：迈克·山德、斯图尔特·布莱恩特、迪诺·法里纳奇、莱斯·金斯伯格、萨姆·哈特曼、丹·罗马斯坎努、戴夫·沃德和罗斯·怀特。特别感谢Mike Shand的详细和有益的评论。
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
美国马萨诸塞州米尔福德市比弗街155号唐纳德东湖第三华为技术有限公司01757
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Tissa Senevirathne Cisco Systems 375 East Tasman Drive, San Jose, CA 95134 USA
美国加利福尼亚州圣何塞东塔斯曼大道375号，邮编95134
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450美国加利福尼亚州圣克拉拉大美洲公园路95054
EMail: anoop@alumni.duke.edu
EMail: anoop@alumni.duke.edu
Dinesh Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
美国加利福尼亚州桑尼维尔西伊夫林大道1089号迪内什-杜特积云网络公司，邮编94086
EMail: ddutt.ietf@hobbesdutt.com
EMail: ddutt.ietf@hobbesdutt.com
Ayan Banerjee Insieme Networks 210 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道210号Ayan Banerjee Inseme Networks，邮编95134
EMail: ayabaner@gmail.com
EMail: ayabaner@gmail.com