Internet Engineering Task Force (IETF) D. Eastlake
Request for Comments: 6326 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 D. Dutt
Cisco
R. Perlman
Intel
A. Ghanwani
Brocade
July 2011
Internet Engineering Task Force (IETF) D. Eastlake
Request for Comments: 6326 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 D. Dutt
Cisco
R. Perlman
Intel
A. Ghanwani
Brocade
July 2011
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
大量链路的透明互连（TRILL）使用IS-IS
Abstract
摘要
The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL.
IETF已经标准化了大量链路的透明互连（TRILL）协议，该协议使用带有跳数的封装和IS-IS链路状态路由提供透明的第2层转发。本文档指定了支持TRILL的IS-IS扩展的数据格式和代码点。
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/rfc6326.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6326.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括简化的BSD许可证文本，如本规范第4.e节所述
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
如简化的BSD许可证所述，信托法律条款和许可证不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................3
2.1. The Group Address TLV ......................................3
2.1.1. The Group MAC Address Sub-TLV .......................4
2.2. Multi-Topology-Aware Port Capability Sub-TLVs ..............5
2.2.1. The Special VLANs and Flags Sub-TLV .................6
2.2.2. Enabled-VLANs Sub-TLV ...............................7
2.2.3. Appointed Forwarders Sub-TLV ........................8
2.3. Sub-TLVs for the Router Capability TLV .....................9
2.3.1. The TRILL Version Sub-TLV ...........................9
2.3.2. The Nickname Sub-TLV ...............................10
2.3.3. The Trees Sub-TLV ..................................11
2.3.4. The Tree Identifiers Sub-TLV .......................11
2.3.5. The Trees Used Identifiers Sub-TLV .................12
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...12
2.3.7. The VLAN Group Sub-TLV .............................15
2.4. MTU Sub-TLV of the Extended Reachability TLV ..............15
2.5. TRILL Neighbor TLV ........................................16
3. The MTU PDUs ...................................................18
4. Use of Existing PDUs and TLVs ..................................19
4.1. TRILL IIH PDUs ............................................19
4.2. Area Address ..............................................19
4.3. Protocols Supported .......................................19
5. IANA Considerations ............................................20
5.1. Allocations from Existing Registries ......................20
5.2. New Sub-Registries Created ................................21
6. Security Considerations ........................................22
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................23
8. Acknowledgements ...............................................23
Appendix A. Initial IS-IS PDU Registry ............................24
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................3
2.1. The Group Address TLV ......................................3
2.1.1. The Group MAC Address Sub-TLV .......................4
2.2. Multi-Topology-Aware Port Capability Sub-TLVs ..............5
2.2.1. The Special VLANs and Flags Sub-TLV .................6
2.2.2. Enabled-VLANs Sub-TLV ...............................7
2.2.3. Appointed Forwarders Sub-TLV ........................8
2.3. Sub-TLVs for the Router Capability TLV .....................9
2.3.1. The TRILL Version Sub-TLV ...........................9
2.3.2. The Nickname Sub-TLV ...............................10
2.3.3. The Trees Sub-TLV ..................................11
2.3.4. The Tree Identifiers Sub-TLV .......................11
2.3.5. The Trees Used Identifiers Sub-TLV .................12
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...12
2.3.7. The VLAN Group Sub-TLV .............................15
2.4. MTU Sub-TLV of the Extended Reachability TLV ..............15
2.5. TRILL Neighbor TLV ........................................16
3. The MTU PDUs ...................................................18
4. Use of Existing PDUs and TLVs ..................................19
4.1. TRILL IIH PDUs ............................................19
4.2. Area Address ..............................................19
4.3. Protocols Supported .......................................19
5. IANA Considerations ............................................20
5.1. Allocations from Existing Registries ......................20
5.2. New Sub-Registries Created ................................21
6. Security Considerations ........................................22
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................23
8. Acknowledgements ...............................................23
Appendix A. Initial IS-IS PDU Registry ............................24
The IETF has standardized the TRILL protocol [RFC6325], which provides transparent Layer 2 forwarding using encapsulation 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 as well as supporting VLANs. Intermediate Systems (ISs) implementing TRILL can incrementally replace IEEE [802.1Q-2005] bridges.
IETF已经标准化了TRILL协议[RFC6325]，该协议使用带有跳数和链路状态路由的封装来提供透明的第2层转发。TRILL提供无需配置的最佳成对转发、即使在临时循环期间也能安全转发、支持单播和多播流量的多路径传输以及支持VLAN。实现TRILL的中间系统（ISs）可以逐渐取代IEEE[802.1Q-2005]网桥。
This document, in conjunction with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions to support TRILL.
本文件与[RFC6165]一起规定了支持TRILL的IS-IS[ISO-10589][RFC1195]扩展的数据格式和代码点。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning.
[RFC6325]中定义的术语和首字母缩略词在此具有相同的含义。
Additional acronyms used in this document are:
本文件中使用的其他首字母缩略词包括：
IIH - IS-IS Hello
你好
IS - Intermediate System (for this document, all relevant intermediate systems are RBridges)
IS-中间系统（对于本文件，所有相关的中间系统均为RBridges）
NLPID - Network Layer Protocol Identifier
NLPID-网络层协议标识符
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 added to IS-IS to support the TRILL standard. 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 provided in Section 5.
本节结合[RFC6165]规定了为支持TRILL标准而添加到IS-IS的TLV和子TLV的数据格式和代码点。第5节提供了关于允许出现次数的信息，例如PDU或PDU组中的TLV或TLV中的子TLV。
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried only in an LSP PDU and carries sub-TLVs that in turn advertise multicast group listeners. Section 2.1.1 below specifies a sub-TLV that advertises listeners by MAC address. It is anticipated that
组地址（GADDR）TLV，IS-IS TLV类型142，仅在LSP PDU中承载，并且承载子TLV，子TLV反过来播发多播组侦听器。下面第2.1.1节指定了一个子TLV，该子TLV通过MAC地址向侦听器播发消息。预计
additional sub-TLVs for additional address types such as IP addresses will be specified in other documents. The sub-TLVs under GADDR constitute a new series of sub-TLV types (see Section 5.2).
其他文件中将指定其他地址类型（如IP地址）的附加子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 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节中规定的多播侦听器。其格式如下：
+-+-+-+-+-+-+-+-+
|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 (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 (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
如果每组记录的格式为：
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o 类型：GADDR子TLV类型，设置为1（GMAC-ADDR）。
o Length: Variable, minimum 5.
o 长度：可变，最小5。
o RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored on receipt.
o RESV：保留。必须作为零发送并在接收时忽略的4位字段。
o Topology-ID: This field is not used in TRILL, where it is sent as zero and ignored on receipt, but is included for use by other technologies.
o 拓扑ID：该字段不在TRILL中使用，在TRILL中它作为零发送，在接收时被忽略，但包含在其他技术中使用。
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 Number of Group Records: A 1-byte integer that is the number of group records in this sub-TLV.
o 组记录数：1字节整数，表示此子TLV中的组记录数。
o Group Record: Each group record carries the number of sources. It then has a 48-bit multicast address followed by 48-bit 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 组记录：每个组记录包含源的数量。然后它有一个48位的多播地址，后跟48位的源MAC地址。如果源不适合于单个子TLV，则相同的组地址可以在组地址TLV的另一实例的另一个子TLV中使用不同的源地址重复。
TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT-CAP) TLV as specified in [RFC6165]. The remainder of this section specifies the sub-TLVs that TRILL uses the MT-PORT-CAP TLV to transport.
TRILL使用[RFC6165]中规定的多拓扑感知端口能力（MT-Port-CAP）TLV。本节剩余部分指定TRILL使用MT-PORT-CAP TLV传输的子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标志）子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 | Desig.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 | Desig.VLAN | (2 bytes)
+--+--+--+--+-------------------+
o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1.
o 类型：子TLV类型，设置为MT-PORT-CAP VLAN标志子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 encapsulated data frame. See [RFC6325], Section 4.6.2, point 8.
o 发送方昵称：如果发送方持有[RFC6325]第3.7节中讨论的任何昵称，则此处必须包括一个昵称。否则，该字段将设置为零。该字段用于支持智能终端站，智能终端站通过目录服务等确定单播数据的出口is（RBridge），并且需要为其第一跳插入昵称作为入口昵称，以正确格式化TRILL封装的数据帧。见[RFC6325]，第4.6.2节，第8点。
o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV when that frame was sent, as specified in [RFC6325], Section 4.4.5.
o Outer.VLAN：根据[RFC6325]第4.4.5节的规定，发送包含此子TLV的TRILL IIH帧的12位外部VLAN ID的副本。
o Desig.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 for end station service at the port of the originating IS on which the 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 Enabled-VLANs sub-TLV 2.
o 类型：子TLV类型，设置为启用MT-PORT-CAP的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 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 Section 4.2.4 of [RFC6325]. It has the following format:
链路上的DRB使用指定的转发器子TLV通知链路上的其他ISs，他们是[RFC6325]第4.2.4节规定的一个或多个VLAN ID范围的指定VLAN-x转发器。其格式如下：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (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 AppointedFwrdrs sub-TLV 3.
o 类型：子TLV类型，设置为MT-PORT-CAP指定的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: These fields are the VLAN IDs of the appointment range, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. As specified in Section 4.4 of [RFC6325], appointing an IS forwarder on a port for a VLAN not enabled on that port has no effect.
o Start.VLAN，End.VLAN：这些字段是约会范围的VLAN ID，包括在内。要指定单个VLAN，VLAN的ID将同时显示为起始VLAN和结束VLAN。如[RFC6325]第4.4节所述，在端口上为该端口上未启用的VLAN指定IS转发器无效。
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.
IS的昵称可以作为多个VLAN范围的指定转发器出现，其方式是在IIH PDU中相同或不同的MT端口能力TLV中出现此子TLV。
The Router Capability TLV is specified in [RFC4971]. All of the sub-sections of this Section 2.3 below specify sub-TLVs that can be carried in the Router Capability TLV for TRILL.
[RFC4971]中规定了路由器能力TLV。下面第2.3节的所有小节都指定了TRILL路由器功能TLV中可携带的子TLV。
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported. By implication, lower versions are also supported. If this sub-TLV is missing, the originating IS only supports the base version of the protocol [RFC6325].
TRILL版本（TRILL-VER）子TLV表示支持的TRILL标准的最大版本。言下之意，也支持较低版本。如果缺少此子TLV，则原始is仅支持协议的基本版本[RFC6325]。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+
o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).
o 类型：路由器能力子TLV类型，设置为13（TRILL-VER）。
o Length: 1.
o 长度：1。
o Max-version: Set to maximum version supported.
o 最大版本：设置为支持的最大版本。
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 as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may be carried.
昵称（昵称）路由器功能子TLV携带有关始发IS昵称的信息，以及关于其持有这些昵称的优先级的信息，如[RFC6325]第3.7.3节所述。可携带该子TLV的多个实例。
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 sub-TLV type, set to 6 (NICKNAME).
o 类型：路由器能力子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 sub-TLV type, set to 7 (TREES).
o 类型：路由器能力子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 tree root, it lists the distribution trees that the other ISs are required to compute as specified in Section 4.5 of [RFC6325]. If 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:
树标识符（树RT ID）子TLV是一个有序的昵称列表。当由具有最高优先级树根的IS发起时，它列出了其他ISs需要按照[RFC6325]第4.5节的规定计算的分布树。如果此信息分布在多个子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 sub-TLV type, set to 8 (TREE-RT-IDs).
o 类型：路由器能力子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 a 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 Router Capability 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 precisely 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 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提供不同的昵称，则未指定哪个昵称优先。-使用最大的指定货代状态丢失计数器。-如果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 sub-TLV type, set to 10 (INT-VLAN).
o 类型：路由器能力子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. A range of one VLAN ID is indicated by setting them both to that VLAN ID value.
- VLAN.start和VLAN.end：此VLAN ID范围包括在内。一个VLAN ID的范围通过将两者都设置为该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 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, only one spanning tree root could be seen on any particular port, there may be multiple ports in the same VLAN 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 Router Capability 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 announcing 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 sub-TLV type, set to 14 (VLAN-GROUP).
o 类型：路由器能力子TLV类型，设置为14（VLAN-GROUP）。
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields, which may be zero.
o 长度：4+2*n，其中n是辅助VLAN ID字段的数量，可以为零。
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。
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 TLV (type 22).
MTU子TLV用于选择性地宣布[RFC6325]第4.2.4.4节中规定的链路的MTU。它发生在扩展可达性TLV（类型22）中。
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| Reserved | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| Reserved | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability sub-TLV type, set to MTU sub-TLV 28.
o 类型：扩展可达性子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 Reserved: 7 bits that MUST be sent as zero and ignored on receipt.
o 保留：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 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 [RFC6327]. The structure of the TRILL Neighbor TLV is as follows:
按照[RFC6325]第4.4.2.1节和[RFC6327]中的规定，TRILL IIH PDU（见下文第4.1节）中使用TRILL相邻TLV代替is相邻TLV。颤音相邻TLV的结构如下所示：
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information present for each neighbor is as follows:
每个邻居的信息如下所示：
+-+-+-+-+-+-+-+-+
|F| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
| MAC Address | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|F| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
| MAC Address | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
o Type: TLV Type, set to TRILL Neighbor TLV 145.
o 类型：TLV类型，设置为颤音邻接TLV 145。
o Length: 1 + 9*n, where n is the number of neighbor records which may be zero.
o 长度：1+9*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 RESV: These 7 bits are reserved use and MUST be sent as zero and ignored on receipt.
o RESV：这7位是保留使用的，必须作为零发送，并在收到时忽略。
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 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 MAC Address: The MAC address of the neighbor as in the IS Neighbor TLV (6).
o MAC地址：在IS邻居TLV（6）中，邻居的MAC地址。
As specified in [RFC6327] 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 RBridge 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.
按照[RFC6327]和[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中）。如果RBridge认为它没有邻居，它必须发送一个TRILL Neighbor TLV，其中包含一个空的邻居记录列表，该列表将同时启用S位和L位。
Two PDUs are added to IS-IS, the MTU-probe and MTU-ack PDUs. They are used to optionally determine the MTU on a link between ISs as specified in [RFC6325], Section 4.3.2.
IS-IS中添加了两个PDU，即MTU探测和MTU确认PDU。它们用于根据[RFC6325]第4.3.2节的规定，选择性地确定ISs之间链路上的MTU。
The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with two new PDU Type numbers, one each, as listed in Section 6. They also have a 20-byte common fixed MTU PDU header as shown below.
MTU PDU具有IS-IS PDU公共标头（最多可达最大区域地址字节），带有两个新的PDU类型编号，每个编号一个，如第6节所列。它们还有一个20字节的公共固定MTU PDU头，如下所示。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (6 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 arbitrary 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字段是由发出MTU探测并由响应is复制到相应MTU ack中的任意48位数量。例如，正在创建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.
探测源ID由发出MTU探测到其系统ID的is设置，并由响应is复制到相应的MTU ack中。
The Ack Source ID is set to zero in MTU-probe PDUs. An IS issuing an MTU-ack sets this field to its System ID.
在MTU探测PDU中，Ack源ID设置为零。正在发出MTU确认将此字段设置为其系统ID。
The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded to the exact size being tested with the Padding TLV. 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 will be quite small compared with their minimum length (minimum 1470-byte MTU on an 802.3 link, for example), so this will not be a problem.
TLV区域位于MTU PDU标头区域之后。此区域可能包含验证TLV，并且必须填充到使用填充TLV测试的准确大小。由于填充TLV的最小大小为2字节，因此如果包含固定字段和TLV的所需信息的总长度加起来比所需长度少1字节，则不可能填充到精确的大小。然而，与MTU PDU的最小长度（例如，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 LAN IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] specifies 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 Section 4.4 of [RFC6325] and in [RFC6327].
TRILL IIH PDU是TRILL协议使用的LAN IIH PDU的变体。TRILL标准[RFC6325]第4.4节规定了TRILL IIH的内容及其在TRILL中的使用与第3层LAN IIH PDU使用的区别。[RFC6325]第4.4节和[RFC6327]中规定了颤音邻域的邻接状态机制。
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses octet in the common header MUST be set to 0x01.
在TRILL IIH PDU中，IS-IS公共头和固定PDU头与1级LAN IIH PDU相同。公共标头中的最大区域地址八位字节必须设置为0x01。
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor TLV (see Section 2.5).
IS-IS相邻TLV（6）未在颤音IIH中使用，如果它出现在那里，则会被忽略。相反，TRILL 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 (1) as follows:
TRILL使用[RFC6325]第4.2.3节规定的固定零区地址。这在4字节区域地址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 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (129, [RFC1195]) including that value MUST appear in TRILL IIH PDUs and LSP number zero PDUs.
NLPID 0xC0已分配给TRILL[RFC6328]。协议支持的TLV（129，[RFC1195]）包括该值必须出现在TRILL IIH PDU和LSP编号为零的PDU中。
IANA has allocated the existing registry code points listed in Section 5.1 and created two new registries with the initial contents as described in Section 5.2.
IANA已分配第5.1节中列出的现有注册码点，并创建了两个新的注册码，初始内容如第5.2节所述。
This document specifies two new 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 LSP, 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 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”和“NUMBER”列）。
Section TLV# IIH LSP SNP NUMBER
第TLV#IIH节LSP SNP编号
GADDR-TLV 2.1 142 - X - *
TRILL Neighbor TLV 2.5 145 X - - *
GADDR-TLV 2.1 142 - X - *
TRILL Neighbor TLV 2.5 145 X - - *
This document specifies eleven new sub-TLVs from existing sub-TLV sequences -- namely, VLAN-FLAGS, Enabled-VLANs, AppointedFwrdrs, TRILL Version (TRILL-VER), NICKNAME, TREES, TREE-RT-IDs, TREE-USE-IDs, INT-VLAN, VLAN-GROUP, and MTU. The TLVs in which these sub-TLVs occur are shown in the table below along with the section of this document where they are discussed.
本文档从现有子TLV序列中指定了11个新的子TLV，即VLAN-FLAGS、启用的VLAN、指定的DFWRDRS、TRILL版本（TRILL-VER）、昵称、树、树RT ID、树使用ID、INT-VLAN、VLAN-GROUP和MTU。下表显示了出现这些子TLV的TLV以及本文件中讨论它们的章节。
Those sub-TLVs with an "X" in the column labeled "MT Port Capabil." are sub-TLVs of TLV 143 [RFC6165], the MT-PORT-CAP-TLV. Those sub-TLVs with an "X" in the column labeled "Router Capabil." are sub-TLVs of TLV 242, the IS-IS Router CAPABILITY TLV. Those sub-TLVs with an "X" in the column labeled "Extended IS Reach" are sub-TLVs of TLV 22, the Extended IS reachability TLV.
标记为“MT Port Capabil”的列中带有“X”的子TLV是TLV 143[RFC6165]的子TLV，即MT-Port-CAP-TLV。在标有“路由器能力”的列中带有“X”的子TLV是TLV 242（IS-IS路由器能力TLV）的子TLV。标记为“扩展IS可达性”的列中带有“X”的子TLV是TLV 22的子TLV，扩展IS可达性TLV。
The final "NUM" column indicates the permitted number of occurrences of the sub-TLV cumulatively within all occurrences of their TLV in that TLV's carrying PDU (or set of PDUs in the case of LSP), as follows:
最后一个“NUM”列表示子TLV在该TLV携带PDU（或LSP情况下的PDU集）的所有TLV事件中累积的允许事件数，如下所示：
0-1 = MAY occur zero or one times. If it occurs more than once, results are unspecified. 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 "NUM" columns are irrelevant to the IANA sub-registries.
“Section”和“NUM”列中的值与IANA子注册表无关。
Section sub- MT Port Router Extended NUM
TLV# Capabil. Capabil. IS Reach
VLAN-FLAGS 2.2.1 1 X - - 1
Enabled-VLANs 2.2.2 2 X - - *
AppointedFwrdrs 2.2.3 3 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 - *
MTU 2.4 28 - - X 0-1
Section sub- MT Port Router Extended NUM
TLV# Capabil. Capabil. IS Reach
VLAN-FLAGS 2.2.1 1 X - - 1
Enabled-VLANs 2.2.2 2 X - - *
AppointedFwrdrs 2.2.3 3 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 - *
MTU 2.4 28 - - X 0-1
This document creates two new IS-IS PDUs -- namely, the MTU-PROBE-PDU and MTU-ACK-PDU, as described in Section 3. IANA assigned new PDU types to these PDUs and reflect them in a newly created PDU registry (see Appendix A).
本文档创建了两个新的IS-IS PDU，即MTU-PROBE-PDU和MTU-ACK-PDU，如第3节所述。IANA为这些PDU分配了新的PDU类型，并将其反映在新创建的PDU注册表中（见附录a）。
MTU-PROBE-PDU PDU Number: 23 MTU-ACK-PDU PDU Number: 28
MTU-PROBE-PDU PDU编号：23 MTU-ACK-PDU PDU编号：28
IANA created a new sub-TLV IS-IS sub-registry for sub-TLVs within the Group Address (GADDR) TLV and specified an initial sub-TLV within that registry -- namely, the Group MAC Address (GMAC-ADDR) sub-TLV (1). The GMAC-ADDR sub-TLV may occur 0, 1, or more times in a GADDR TLV.
IANA为组地址（GADDR）TLV内的子TLV创建了一个新的子TLV IS-IS子注册表，并在该注册表内指定了一个初始子TLV，即组MAC地址（GMAC-ADDR）子TLV（1）。GMAC-ADDR子TLV可能在GADDR TLV中出现0、1或更多次。
The initial sub-registry is shown below.
初始子注册表如下所示。
Registry Name: IS-IS Group Address Type Codes for TLV 10 Reference: This document Registration Procedures: Expert Review [RFC5226]
注册名称：TLV 10的IS-IS组地址类型代码参考：本文件注册程序：专家评审[RFC5226]
Registry:
Value Group Address Type Code Reference
------- ----------------------------- ---------
0 Reserved This document
1 GMAC-ADDR This document
2-254 Unassigned This document
255 Reserved This document
Registry:
Value Group Address Type Code Reference
------- ----------------------------- ---------
0 Reserved This document
1 GMAC-ADDR This document
2-254 Unassigned This document
255 Reserved This document
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节中讨论的问题类似，可以采用相同的缓解措施。
[ISO-10589] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
[ISO-10589]ISO/IEC 10589:2002，第二版，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473）”，2002年。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990.
[RFC1195]Callon，R.“OSI IS-IS在TCP/IP和双环境中的路由使用”，1990年。
[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. and N. Shen, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", 2007.
[RFC4971]Vasseur，JP。和N.Shen，“广告路由器信息的中间系统到中间系统（IS-IS）扩展”，2007年。
[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", 2008.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，2008年。
[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, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.
[RFC6325]佩尔曼，R.，东湖，D.，杜特，D.，盖伊，S.，和A.加瓦尼，“RBridges:基本协议规范”，RFC 63252011年7月。
[RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", RFC 6327, July 2011.
[RFC6327]伊斯特莱克、佩尔曼、加瓦尼、杜特和V.曼拉尔，“RBridges:邻接”，RFC 6327，2011年7月。
[RFC6328] Eastlake, D., "IANA Considerations for Network Layer Protocol Identifiers", RFC 6328, July 2011.
[RFC6328]Eastlake，D.，“网络层协议标识符的IANA考虑”，RFC 63282011年7月。
[802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.1Q-2005]“局域网和城域网/虚拟桥接局域网的IEEE标准”，802.1Q-2005，2006年5月19日。
[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月。
The authors gratefully acknowledge the contributions and review by the following: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for the detailed and helpful comments.
作者感谢以下作者的贡献和评论：迈克·山德、斯图尔特·布莱恩特、迪诺·法里纳奇、莱斯·金斯伯格、萨姆·哈特曼、丹·罗马斯坎努、戴夫·沃德和罗斯·怀特。特别感谢Mike Shand的详细和有益的评论。
The following is the suggested initial IS-IS PDU registry before MTU-PROBE-PDU and MTU-ACK-PDU, which should be added with this document as REFERENCE:
以下是MTU-PROBE-PDU和MTU-ACK-PDU之前建议的初始is-is PDU注册表，应与本文档一起添加作为参考：
Registry Name: IS-IS PDUs Reference: This document Registration Procedures: IETF Review [RFC5226]
注册名称：IS-IS PDU参考：本文件注册程序：IETF审查[RFC5226]
MNEMONIC PDU# REFERENCE
助记PDU#参考
Unassigned 0-14
L1-LAN-HELLO-PDU 15 [ISO-10589]
L2-LAN-HELLO-PDU 16 [ISO-10589]
P2P-HELLO-PDU 17 [ISO-10589]
L1-LSP-PDU 18 [ISO-10589]
Unassigned 19
L2-LSP-PDU 20 [ISO-10589]
Unassigned 21-23
L1-CSNP-PDU 24 [ISO-10589]
L2-CSNP-PDU 25 [ISO-10589]
L1-PSNP-PDU 26 [ISO-10589]
L2-PSNP-PDU 27 [ISO-10589]
Unassigned 28-31
Unassigned 0-14
L1-LAN-HELLO-PDU 15 [ISO-10589]
L2-LAN-HELLO-PDU 16 [ISO-10589]
P2P-HELLO-PDU 17 [ISO-10589]
L1-LSP-PDU 18 [ISO-10589]
Unassigned 19
L2-LSP-PDU 20 [ISO-10589]
Unassigned 21-23
L1-CSNP-PDU 24 [ISO-10589]
L2-CSNP-PDU 25 [ISO-10589]
L1-PSNP-PDU 26 [ISO-10589]
L2-PSNP-PDU 27 [ISO-10589]
Unassigned 28-31
Authors' Addresses
作者地址
Donald Eastlake Huawei 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
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号Ayan Banerjee Cisco Systems，邮编95134
EMail: ayabaner@cisco.com
EMail: ayabaner@cisco.com
Dinesh Dutt Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA
Radia Perlman英特尔实验室使命学院大道2200号。美国加利福尼亚州圣克拉拉95054-1549
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
美国加利福尼亚州圣何塞霍尔格大道130号Anoop Ghanwani Brocade，邮编95134
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu