Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7961 Y. Li
Category: Standards Track Huawei
ISSN: 2070-1721 August 2016
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7961 Y. Li
Category: Standards Track Huawei
ISSN: 2070-1721 August 2016
Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV
大量链路的透明互连（TRILL）：接口地址APPsub TLV
Abstract
摘要
This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by a TRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, or the flooding of unknown MAC addresses.
本文档规定了TRILL（大量链接的透明互连）IS-IS应用程序子TLV，该子TLV允许通过地址集的TRILL开关进行报告。每一组地址都报告指定同一接口（端口）的所有地址，还报告可访问该接口的TRILL开关。例如，48位MAC（媒体访问控制）地址、IPv4地址和IPv6地址可以报告为与特定TRILL交换机可访问的相同接口对应的所有地址。在某些情况下，这些信息可用于合成对地址解析协议（ARP）、IPv6邻居发现（ND）协议或未知MAC地址泛滥的响应，或绕过对这些协议的需求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7961.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7961.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ..........................3
2. Format of the Interface Addresses APPsub-TLV ....................4
3. IA APPsub-TLV Sub-sub-TLVs ......................................9
3.1. AFN Size Sub-sub-TLV ......................................10
3.2. Fixed Address Sub-sub-TLV .................................11
3.3. Data Label Sub-sub-TLV ....................................12
3.4. Topology Sub-sub-TLV ......................................12
4. Security Considerations ........................................13
5. IANA Considerations ............................................14
5.1. Allocation of AFN Values ..................................14
5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry ...................15
5.3. IA APPsub-TLV Number ......................................16
6. Additional AFN Information .....................................16
7. Processing Address Sets ........................................16
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................20
Appendix A. Examples ..............................................21
A.1. Simple Example ............................................21
A.2. Complex Example ...........................................22
Acknowledgments ...................................................24
Authors' Addresses ................................................24
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Format of the Interface Addresses APPsub-TLV ....................4
3. IA APPsub-TLV Sub-sub-TLVs ......................................9
3.1. AFN Size Sub-sub-TLV ......................................10
3.2. Fixed Address Sub-sub-TLV .................................11
3.3. Data Label Sub-sub-TLV ....................................12
3.4. Topology Sub-sub-TLV ......................................12
4. Security Considerations ........................................13
5. IANA Considerations ............................................14
5.1. Allocation of AFN Values ..................................14
5.2. IA APPsub-TLV Sub-sub-TLVs Sub-registry ...................15
5.3. IA APPsub-TLV Number ......................................16
6. Additional AFN Information .....................................16
7. Processing Address Sets ........................................16
8. References .....................................................18
8.1. Normative References ......................................18
8.2. Informative References ....................................20
Appendix A. Examples ..............................................21
A.1. Simple Example ............................................21
A.2. Complex Example ...........................................22
Acknowledgments ...................................................24
Authors' Addresses ................................................24
This document specifies a TRILL (Transparent Interconnection of Lots of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV) [RFC6823] that enables the convenient representation of sets of addresses where all of the addresses in each set designate the same interface (port). For example, a 48-bit MAC (Media Access Control) [RFC7042] address, IPv4 address, and IPv6 address can be reported as all three designating the same interface. In addition, a Data Label (VLAN or Fine-Grained Label (FGL) [RFC7172]) is specified for the interface, along with the TRILL switch and, optionally, the TRILL switch port from which the interface is reachable. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP) [RFC826], the IPv6 Neighbor Discovery (ND) [RFC4861] protocol, the Reverse Address Resolution Protocol (RARP) [RFC903], or the flooding of unknown destination MAC addresses [ARPND]. If the information reported is complete, it can also be used to detect and discard packets with forged source addresses.
本文件规定了TRILL（大量链路的透明互连）[RFC6325]IS-IS应用子TLV（APPsub TLV）[RFC6823]，它能够方便地表示地址集，其中每组中的所有地址都指定相同的接口（端口）。例如，48位MAC（媒体访问控制）[RFC7042]地址、IPv4地址和IPv6地址可以报告为指定相同接口的所有三个地址。此外，还为接口指定了数据标签（VLAN或细粒度标签（FGL）[RFC7172]），以及TRILL交换机和（可选）可访问接口的TRILL交换机端口。在某些情况下，此类信息可用于合成对地址解析协议（ARP）[RFC826]、IPv6邻居发现（ND）[RFC4861]协议、反向地址解析协议（RARP）[RFC903]或未知目标MAC地址泛滥[ARPND]的响应，或绕过对这些协议的需求。如果报告的信息完整，还可用于检测和丢弃伪造源地址的数据包。
This APPsub-TLV appears inside the TRILL GENINFO TLV specified in the End Station Address Distribution Information (ESADI) RFC [RFC7357] but may also occur in other application contexts. The "directory assistance" TRILL Edge services [DirectoryScheme] are expected to make use of this APPsub-TLV.
此APPsub TLV出现在终端站地址分布信息（ESADI）RFC[RFC7357]中指定的TRILL GENINFO TLV内，但也可能出现在其他应用程序上下文中。“目录协助”TRILL边缘服务[DirectoryScheme]预计将使用此APPsub TLV。
Although in some IETF protocols address field types are represented by an Ethertype [RFC7042] or a hardware address type [RFC5494], only the Address Family Number (AFN) is used in this APPsub-TLV to represent the address field type.
尽管在某些IETF协议中，地址字段类型由Ethertype[RFC7042]或硬件地址类型[RFC5494]表示，但此APPsub TLV中仅使用地址系列号（AFN）来表示地址字段类型。
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]. Capitalized IANA-related terms such as "Expert Review" are to be interpreted as described in [RFC5226].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。大写的IANA相关术语，如“专家评审”应按照[RFC5226]中所述进行解释。
The terminology and acronyms of [RFC6325] are used herein, along with the following additional acronyms and terms:
此处使用[RFC6325]的术语和首字母缩略词，以及以下附加首字母缩略词和术语：
AFN: Address Family Number
(http://www.iana.org/assignments/address-family-numbers/)
AFN: Address Family Number
(http://www.iana.org/assignments/address-family-numbers/)
APPsub-TLV: Application sub-TLV [RFC6823]
APPsub TLV:应用程序子TLV[RFC6823]
Data Label: VLAN or FGL
数据标签：VLAN或FGL
FGL: Fine-Grained Label [RFC7172]
FGL：细粒度标签[RFC7172]
IA: Interface Address(es)
IA：接口地址（es）
MAC: Media Access Control
媒体访问控制
Nickname: A 16-bit TRILL switch identifier, as specified in Section 3.7 of [RFC6325] and as updated by Section 4 of [RFC7780]
昵称：16位颤音开关标识符，如[RFC6325]第3.7节规定，并由[RFC7780]第4节更新
RBridge: An alternative name for a TRILL switch
RBridge：颤音开关的另一个名称
TRILL switch: A device that implements the TRILL protocol
颤音开关：实现颤音协议的设备
The Interface Addresses (IA) APPsub-TLV is used to advertise a set of addresses indicating the same interface (port) within a Data Label (VLAN or FGL). It also associates that interface with the TRILL switch and, optionally, the TRILL switch port by which the interface is reachable. These addresses can be in different address families. For example, the IA APPsub-TLV can be used to declare that a particular interface with specified IPv4, IPv6, and 48-bit MAC addresses in some particular Data Label is reachable from a particular TRILL switch. While those three types of addresses are likely to be the only types of interest, any address type for which an AFN has been assigned by IANA can be represented.
接口地址（IA）APPsub TLV用于公布一组地址，这些地址指示数据标签（VLAN或FGL）内的相同接口（端口）。它还将该接口与TRILL交换机以及（可选）可访问接口的TRILL交换机端口相关联。这些地址可以位于不同的地址族中。例如，IA APPsub TLV可用于声明在特定数据标签中具有指定IPv4、IPv6和48位MAC地址的特定接口可从特定TRILL交换机访问。虽然这三种类型的地址可能是唯一感兴趣的类型，但可以表示IANA为其分配AFN的任何地址类型。
The Template field in a particular IA APPsub-TLV indicates the format of each Address Set it carries. Certain well-known sets of addresses are represented by special values. Other sets of addresses are specified by a list of AFNs. The Template format that uses a list of AFNs provides an explicit pattern for the type and order of addresses in each Address Set in the IA APPsub-TLV that includes that Template.
特定IA APPsub TLV中的模板字段指示其承载的每个地址集的格式。某些众所周知的地址集由特殊值表示。其他地址集由AFN列表指定。使用AFN列表的模板格式为包含该模板的IA APPsub TLV中每个地址集的地址类型和顺序提供了一个显式模式。
A device or application making use of IA APPsub-TLV data is not required to make use of all IA data. For example, a device or application that was only interested in MAC and IPv6 addresses could ignore any IPv4 or other types of address information that was present.
使用IA APPsub TLV数据的设备或应用程序不需要使用所有IA数据。例如，仅对MAC和IPv6地址感兴趣的设备或应用程序可以忽略存在的任何IPv4或其他类型的地址信息。
Figure 1 shows an IA APPsub-TLV as it would appear inside an IS-IS Flooding Scope Link State PDU (FS-LSP) using an extended flooding scope [RFC7356] TLV -- for example, in ESADI [RFC7357]. Within an IS-IS FS-LSP using traditional [ISO-10589] TLVs, the Type and Length would be 1-byte unsigned integers equal to or less than 255, but with an extended TLV, the Type and Length are 2-byte unsigned integers.
图1显示了一个IA APPsub TLV，它将出现在使用扩展泛洪作用域[RFC7356]TLV的IS-IS泛洪作用域链路状态PDU（FS-LSP）中——例如，在ESADI[RFC7357]中。在使用传统[ISO-10589]TLV的IS-IS FS-LSP中，类型和长度为等于或小于255的1字节无符号整数，但在扩展TLV中，类型和长度为2字节无符号整数。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = (10) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Sets End | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-
| Template ... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 1 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 2 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set N (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| optional sub-sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = (10) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Sets End | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+-+-+-+-+-+-+-+-+
| Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-
| Template ... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 1 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set 2 (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Address Set N (size determined by Template) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| optional sub-sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 1: Interface Addresses APPsub-TLV
图1：接口地址APPsub TLV
o Type: Interface Addresses TRILL APPsub-TLV type; set to 10 (IA-SUBTLV).
o 类型：接口地址TRILL APPsub TLV类型；设置为10（IA-SUTLV）。
o Length: Variable; minimum 7. If Length is 6 or less or if the APPsub-TLV extends beyond the size of an encompassing TRILL GENINFO TLV or other context, the APPsub-TLV MUST be ignored. For manageability, a counter reflecting the receipt of such malformed IA APPsub-TLVs should be maintained.
o 长度：可变；最少7个。如果长度等于或小于6，或者如果APPsub TLV超出了包含TRILL GENINFO TLV或其他上下文的大小，则必须忽略APPsub TLV。为了便于管理，应保留一个计数器，以反映收到此类格式错误的IA APPsub TLV。
o Addr Sets End: The unsigned integer byte number, within the IA APPsub-TLV value part, of the last byte of the last Address Set, where the first byte is numbered 1. This will be the number of the byte just before the first sub-sub-TLV if any sub-sub-TLVs are present (see Section 3). The processing is as follows:
o Addr Sets End：最后一个地址集的最后一个字节的IA APPsub TLV值部分内的无符号整数字节数，其中第一个字节编号为1。如果存在任何子TLV，这将是第一个子TLV前的字节数（见第3节）。处理过程如下：
- If this field is greater than Length or points to before the end of the Template, the IA APPsub-TLV is corrupt and MUST be discarded.
- 如果此字段大于长度或指向模板末尾之前，则IA APPsub TLV已损坏，必须丢弃。
- If this field is equal to Length, there are no sub-sub-TLVs.
- 如果此字段等于长度，则不存在子TLV。
- If this field is less than Length, sub-sub-TLVs are parsed as specified in Section 3.
- 如果该字段小于长度，则按照第3节的规定分析子TLV。
Note: This field is always 2 bytes in size.
注意：此字段的大小始终为2字节。
o Nickname: The nickname (see Section 1.1) of the TRILL switch by which the Address Sets are reachable. If 0, the Address Sets are reachable from the TRILL switch originating the message containing the APPsub-TLV (for example, an ESADI [RFC7357] message).
o 昵称：TRILL开关的昵称（见第1.1节），通过它可以访问地址集。如果为0，则可通过发出包含APPsub TLV的消息（例如，ESADI[RFC7357]消息）的TRILL开关访问地址集。
o Flags: A byte of flags, as follows:
o 标志：一个字节的标志，如下所示：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|L| RESV |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D|L| RESV |
+-+-+-+-+-+-+-+-+
D: Directory flag: If D is 1, the APPsub-TLV contains directory information [RFC7067].
D:目录标志：如果D为1，则APPsub TLV包含目录信息[RFC7067]。
L: Local flag: If L is 1, the APPsub-TLV contains information learned locally by observing ingressed frames [RFC6325]. (Both D and L can be set to 1 in the same IA APPsub-TLV if a TRILL switch had learned an address locally and also advertised it as a directory.)
L：本地标志：如果L为1，APPsub TLV包含通过观察进入帧在本地学习的信息[RFC6325]。（如果TRILL开关已在本地读入地址并将其作为目录播发，则在同一IA APPsub TLV中D和L都可以设置为1。）
RESV: Additional reserved flag bits that MUST be sent as zero and ignored on receipt.
RESV：额外的保留标志位，必须作为零发送，并在接收时忽略。
o Confidence: This 8-bit unsigned quantity in the range 0 to 254 indicates the confidence level in the addresses being transported (see Section 4.8.2 of [RFC6325]). A value of 255 is treated as if it was 254.
o 置信度：0到254范围内的8位无符号量表示传输地址的置信度（见[RFC6325]第4.8.2节）。255的值被视为254。
o Template: The initial byte of this field is the unsigned integer K. If K has a value from 1 to 31, it indicates that this initial byte is followed by a list of K AFNs that specify the exact structure and order of each Address Set occurring later in the APPsub-TLV. K can be 1, which is the minimum valid value. If K is 0, the IA APPsub-TLV is ignored. If K is 32 to 254, the length of the Template field is 1 byte, and its value is intended to correspond to a particular ordered set of AFNs, some of which are specified below. The value of 255 for K is reserved for future definition and causes the IA APPsub-TLV to be ignored.
o 模板：此字段的初始字节是无符号整数K。如果K的值为1到31，则表示此初始字节后面是K个AFN的列表，这些AFN指定了APPsub TLV中随后出现的每个地址集的确切结构和顺序。K可以是1，这是最小有效值。如果K为0，则忽略IA APPsub TLV。如果K为32到254，则模板字段的长度为1字节，其值旨在对应于特定的有序AFN集，其中一些AFN如下所述。K的值255保留用于将来的定义，并导致忽略IA APPsub TLV。
If the Template uses explicit AFNs, it looks like the following, with the number of AFNs, up to 31, equal to K.
如果模板使用显式AFN，则如下所示，AFN的数量最多为31，等于K。
+-+-+-+-+-+-+-+-+
| K | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| K | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For K in the range 32 to 39, values indicate a specific sequence, as specified below. The values of K from 40 to 254 are reserved for future specification. If the value of K is not understood by a receiver of the IA-APPsub-TLV, any Address Sets present are ignored.
对于32到39范围内的K，值表示特定顺序，如下所述。从40到254的K值保留用于将来的规范。如果IA APPsub TLV的接收器不理解K的值，则忽略存在的任何地址集。
K Addresses in order of occurrence
--- --------------------------------
32 48-bit MAC
33 48-bit MAC, IPv4
34 48-bit MAC, IPv6
35 48-bit MAC, IPv4, IPv6
36 48-bit MAC, RBridge port
37 48-bit MAC, IPv4, RBridge port
38 48-bit MAC, IPv6, RBridge port
39 48-bit MAC, IPv4, IPv6, RBridge port
K Addresses in order of occurrence
--- --------------------------------
32 48-bit MAC
33 48-bit MAC, IPv4
34 48-bit MAC, IPv6
35 48-bit MAC, IPv4, IPv6
36 48-bit MAC, RBridge port
37 48-bit MAC, IPv4, RBridge port
38 48-bit MAC, IPv6, RBridge port
39 48-bit MAC, IPv4, IPv6, RBridge port
For ease of decoding, note that for values of K between 32 and 39 inclusive, the 0x01 bit indicates that an IPv4 address is present, the 0x02 bit indicates that an IPv6 address is present, and the 0x04 bit indicates that an RBridge Port ID is present.
为便于解码，请注意，对于32和39（含32和39）之间的K值，0x01位表示存在IPv4地址，0x02位表示存在IPv6地址，0x04位表示存在RBridge端口ID。
o AFN: A 2-byte Address Family Number. The number of AFNs present is given by K, except that there are no AFNs if K is greater than 31. The AFN sequence specifies the structure of the Address Sets occurring later in the TLV. For example, if the Template size is 2 and the two AFNs present are the AFNs for a 48-bit MAC and an IPv4 address, in that order, then each Address Set present will consist of a 6-byte MAC address followed by a 4-byte IPv4 address. If any AFNs are present that are unknown to the receiving IS and the length of the corresponding address is not provided by a sub-sub-TLV as specified below, the receiving IS will be unable to parse the Address Sets and MUST ignore the IA APPsub-TLV.
o AFN：一个2字节的地址系列号。存在的AFN数量由K表示，但如果K大于31，则不存在AFN。AFN序列指定TLV中稍后出现的地址集的结构。例如，如果模板大小为2，并且存在的两个AFN是48位MAC和IPv4地址的AFN，则按照该顺序，存在的每个地址集将由一个6字节MAC地址和一个4字节IPv4地址组成。如果存在接收IS未知的任何AFN，并且子TLV未提供以下指定的相应地址长度，则接收IS将无法解析地址集，并且必须忽略IA APPsub TLV。
o Address Set: Each Address Set in the APPsub-TLV consists of exactly the same sequence of addresses and types as specified by the Template earlier in the APPsub-TLV. No alignment, other than to a byte boundary, is provided. The addresses in each Address Set are contiguous with no unused bytes between them, and the Address Sets are contiguous with no unused bytes between successive Address Sets. The Address Sets must fit within the TLV. See Section 7 on interpreting certain Address Sets.
o 地址集：APPsub TLV中的每个地址集由与先前在APPsub TLV中的模板指定的地址和类型完全相同的序列组成。除了字节边界之外，不提供任何对齐方式。每个地址集中的地址是连续的，它们之间没有未使用的字节，并且地址集是连续的，在连续的地址集中没有未使用的字节。地址集必须适合TLV。请参见第7节“解释某些地址集”。
o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do not completely fill the length of the APPsub-TLV (as indicated by the Length field), then per Section 4 of [RFC5305] the remaining bytes are parsed as sub-sub-TLVs. Any such sub-sub-TLVs that are not known to the receiving TRILL switch are ignored. Should this parsing not be possible -- for example, there is only one remaining byte or an apparent sub-sub-TLV extends beyond the end of the TLV -- the containing IA APPsub-TLV is considered corrupt and is ignored. (Several sub-sub-TLV types are specified in Section 3.)
o sub-sub TLV：如果Addr Sets End指示的地址集未完全填充APPsub TLV的长度（如长度字段所示），则根据[RFC5305]的第4节，剩余字节被解析为sub-sub TLV。接收颤音开关不知道的任何此类子TLV将被忽略。如果无法进行此解析（例如，只有一个剩余字节或一个明显的sub-sub TLV超出了TLV的末尾），则包含的IA APPsub TLV将被视为已损坏并被忽略。（第3节规定了几种分TLV类型。）
Different IA APPsub-TLVs within the same or different LSPs or other data structures may have different Templates. The same AFN may occur more than once in a Template, and the same address may occur in different Address Sets. For example, a 48-bit MAC address interface might have three different IPv6 addresses. This could be represented by an IA APPsub-TLV whose Template specifically provided for one EUI-48 address and three IPv6 addresses; this might be an efficient format if there were multiple interfaces with that pattern. Alternatively, a Template with one 48-bit MAC and one IPv6 address could be used in an IA APPsub-TLV with three Address Sets each having the same MAC address but different IPv6 addresses; this might be the most efficient format if only one interface had multiple IPv6 addresses and other interfaces had only one IPv6 address.
相同或不同LSP或其他数据结构中的不同IA APPsub TLV可能具有不同的模板。同一AFN可能在模板中出现多次，同一地址可能出现在不同的地址集中。例如，48位MAC地址接口可能有三个不同的IPv6地址。这可以由IA APPsub TLV表示，其模板专门为一个EUI-48地址和三个IPv6地址提供；如果有多个具有该模式的接口，那么这可能是一种有效的格式。或者，具有一个48位MAC和一个IPv6地址的模板可以在IA-APPsub-TLV中使用，其中三个地址集各自具有相同的MAC地址但不同的IPv6地址；如果只有一个接口有多个IPv6地址，而其他接口只有一个IPv6地址，那么这可能是最有效的格式。
In order to be able to parse the Address Sets, a receiving TRILL switch must know at least the size of the address for each AFN or address type the Template specifies; however, the presence of the Addr Sets End field means that the sub-sub-TLVs, if any, can always be located by a receiver. A TRILL switch can be assumed to know the size of the AFNs mentioned in Section 5. Should a TRILL switch wish to include an AFN that some receiving TRILL switch in the campus may not know, it SHOULD include an AFN Size sub-sub-TLV as described in Section 3.1. If an IA APPsub-TLV is received with one or more AFNs in its Template for which the receiving TRILL switch does not know the length and for which an AFN Size sub-sub-TLV is not present, that IA APPsub-TLV MUST be ignored.
为了能够解析地址集，接收TRILL开关必须至少知道模板指定的每个AFN或地址类型的地址大小；然而，Addr Sets End字段的存在意味着子TLV（如果有）始终可以由接收器定位。可以假设颤音开关知道第5节中提到的AFN的大小。如果TRILL交换机希望包括一个AFN，而校园内的一些接收TRILL交换机可能不知道，它应该包括一个AFN大小的子TLV，如第3.1节所述。如果接收到IA APPsub TLV时，其模板中有一个或多个AFN，且接收颤音开关不知道其长度，且不存在AFN大小的子TLV，则必须忽略该IA APPsub TLV。
For manageability, a counter of ill-formed IA APPsub-TLVs received and ignored due to unknown K, unknown AFN, and the like (as described above) should be maintained.
为了便于管理，应维护由于未知K、未知AFN等（如上所述）而接收和忽略的格式错误的IA APPsub tlv的计数器。
IA APPsub-TLVs can have sub-sub-TLVs (sub-TLVs of sub-TLVs [RFC5305]) at the end, as specified below. These sub-sub-TLVs occur after the Address Sets. The amount of space available for sub-sub-TLVs is determined from the overall IA APPsub-TLV length and the value of the Addr Sets End byte.
IA APPsub TLV可在末端具有子TLV（子TLV的子TLV[RFC5305]），如下所述。这些子TLV发生在地址集之后。子TLV可用的空间量由IA APPsub TLV的总长度和Addr Sets End字节的值确定。
There is no ordering restriction on sub-sub-TLVs. Unless otherwise specified, each sub-sub-TLV type can occur zero, one, or many times in an IA APPsub-TLV. Any sub-sub-TLVs for which the Type is unknown are ignored. For manageability, a counter of sub-sub-TLVs received and ignored due to an unknown Type or other reasons, as described below, should be maintained.
子TLV没有订购限制。除非另有规定，否则每个sub-sub TLV类型在IA APPsub TLV中可以出现零次、一次或多次。忽略类型未知的任何子TLV。为了便于管理，应维护由于未知类型或其他原因（如下所述）而接收和忽略的子TLV计数器。
The data structures of the sub-sub-TLVs shown below, with 2-byte Types and Lengths, assume that the enclosing IA APPsub-TLV is in an extended LSP TLV [RFC7356] or some non-LSP context. If they were used in an IA APPsub-TLV in a non-extended LSP [ISO-10589], then only 1-byte Types and Lengths could be used. As a result, any sub-sub-TLV types greater than 255 could not be used, and Length would be limited to 255.
下面所示的具有2字节类型和长度的子TLV的数据结构假设封闭IA APPsub TLV位于扩展LSP TLV[RFC7356]或某些非LSP上下文中。如果它们在非扩展LSP[ISO-10589]的IA APPsub TLV中使用，则只能使用1字节类型和长度。因此，任何大于255的子TLV类型都无法使用，并且长度将限制为255。
Using this sub-sub-TLV, the originating TRILL switch can specify the size of an address type. This is useful under the following two circumstances:
使用此子TLV，原始TRILL开关可以指定地址类型的大小。这在以下两种情况下很有用：
1. One or more AFNs that are unknown to the receiving TRILL switch appear in the Template. If an AFN Size sub-sub-TLV is present for each such AFN, then at least the IA APPsub-TLV can be parsed, and possibly other addresses in each Address Set can still be used.
1. 模板中会出现一个或多个接收颤音开关未知的AFN。如果针对每个这样的AFN存在AFN大小的子TLV，则至少可以解析IA APPsub TLV，并且可能仍然可以使用每个地址集中的其他地址。
2. If an AFN occurs in the Template that represents a variable-length address, this sub-sub-TLV gives its size for all occurrences in that IA APPsub-TLV.
2. 如果AFN出现在表示可变长度地址的模板中，则此子TLV将给出该IA APPsub TLV中所有出现的AFN的大小。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AFNsz | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record 1 | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record 2 | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record N | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = AFNsz | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record 1 | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record 2 | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN Size Record N | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AFN Size Sub-sub-TLV
图2:AFN尺寸子TLV
Where each AFN Size Record is structured as follows:
其中，每个AFN大小记录的结构如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AdrSize | (1 byte)
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AdrSize | (1 byte)
+-+-+-+-+-+-+-+-+
o Type: AFN Size sub-sub-TLV type; set to 1 (AFNsz).
o 类型：AFN尺寸子TLV类型；设置为1（AFNsz）。
o Length: 3*N, where N is the number of AFN Size Records present. If Length is not a multiple of 3, the sub-sub-TLV MUST be ignored.
o 长度：3*N，其中N是存在的AFN大小记录数。如果长度不是3的倍数，则必须忽略子TLV。
o AFN Size Record(s): Zero or more 3-byte records, each giving the size of an address type identified by an AFN.
o AFN大小记录：零个或多个3字节记录，每个记录给出AFN标识的地址类型的大小。
o AFN: The AFN whose length is being specified by the AFN Size Record.
o AFN：其长度由AFN大小记录指定的AFN。
o AdrSize: The length, in bytes, of addresses specified by the AFN field as an unsigned integer.
o AdrSize：AFN字段指定为无符号整数的地址长度（字节）。
An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL switch is compared with the size known to the TRILL switch. If they differ, the IA APPsub-TLV is assumed to be corrupt and MUST be ignored.
将接收颤音开关已知的任何AFN的AFN大小子TLV与颤音开关已知的大小进行比较。如果它们不同，则假定IA APPsub TLV已损坏，必须忽略。
There may be cases where, in a particular IA APPsub-TLV, the same address would appear in every Address Set across the IA APPsub-TLV. To avoid wasted space, this sub-sub-TLV can be used to indicate such a fixed address. The address or addresses incorporated into the sets by this sub-sub-TLV are NOT mentioned in the IA APPsub-TLV Template.
在某些情况下，在特定IA APPsub TLV中，相同的地址将出现在IA APPsub TLV中的每个地址集中。为了避免浪费空间，此子TLV可用于指示此类固定地址。IA APPsub TLV模板中未提及此子TLV合并到集合中的一个或多个地址。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = FIXEDADR | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fixed Address (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = FIXEDADR | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fixed Address (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 3: Fixed Address Sub-sub-TLV
图3：固定地址子TLV
o Type: Data Label sub-sub-TLV type; set to 2 (FIXEDADR).
o 类型：数据标签子TLV类型；设置为2（FIXEDADR）。
o Length: Variable; minimum 2. If Length is 0 or 1, the sub-sub-TLV MUST be ignored.
o 长度：可变；最少2个。如果长度为0或1，则必须忽略子TLV。
o AFN: Address Family Number of the Fixed Address.
o AFN：固定地址的地址系列号。
o Fixed Address: The address of the Type indicated by the preceding AFN field that is considered to be part of every Address Set in the IA APPsub-TLV.
o 固定地址：前面的AFN字段指示的类型的地址，被视为IA APPsub TLV中每个地址集的一部分。
The Length field implies a size for the Fixed Address. If that size differs from the size of the address type for the given AFN as known by the receiving TRILL switch, the Fixed Address sub-sub-TLV is considered corrupt and MUST be ignored.
长度字段表示固定地址的大小。如果该大小与接收TRILL开关已知的给定AFN地址类型的大小不同，则固定地址子TLV被视为已损坏，必须忽略。
This sub-sub-TLV indicates the Data Label within which the interfaces listed in the IA APPsub-TLV are reachable. It is useful if the IA APPsub-TLV occurs outside of the context of a message specifying the Data Label or if it is desired and permitted to override that specification. Multiple occurrences of this sub-sub-TLV indicate that the interfaces are reachable in all of the Data Labels given.
此子TLV表示可访问IA APPsub TLV中列出的接口的数据标签。如果IA APPsub TLV发生在指定数据标签的消息上下文之外，或者如果需要并允许覆盖该规范，则此选项非常有用。此子TLV的多次出现表明在给定的所有数据标签中都可以访问接口。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = DATALEN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = DATALEN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-...
Figure 4: Data Label Sub-sub-TLV
图4：数据标签子TLV
o Type: Data Label sub-TLV type; set to 3 (DATALEN).
o 类型：数据标签子TLV类型；设置为3（数据长度）。
o Length: 2 or 3. If Length is some other value, the sub-sub-TLV MUST be ignored.
o 长度：2或3。如果长度是其他值，则必须忽略子TLV。
o Data Label: If Length is 2, the bottom 12 bits of the Data Label are a VLAN ID and the top 4 bits are reserved (MUST be sent as zero and ignored on receipt). If Length is 3, the three Data Label bytes contain an FGL [RFC7172].
o 数据标签：如果长度为2，则数据标签的底部12位为VLAN ID，顶部4位为保留位（必须作为零发送，并在收到时忽略）。如果长度为3，则三个数据标签字节包含FGL[RFC7172]。
The presence of this sub-sub-TLV indicates that the interfaces given in the IA APPsub-TLV are reachable in the topology given. It is useful if the IA APPsub-TLV occurs outside of the context of a message indicating the topology or if it is desired and permitted to override that specification. If it occurs multiple times, then the Address Sets are in all of the topologies given.
此子TLV的存在表明IA APPsub TLV中给出的接口在给定拓扑中是可访问的。如果IA APPsub TLV发生在指示拓扑的消息上下文之外，或者如果需要并允许覆盖该规范，则此选项非常有用。如果发生多次，则地址集位于给定的所有拓扑中。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = TOPOLOGY | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = TOPOLOGY | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Topology Sub-sub-TLV
图5：拓扑子TLV
o Type: Topology sub-TLV type; set to 4 (TOPOLOGY).
o 类型：拓扑子TLV类型；设置为4（拓扑）。
o Length: 2. If Length is some other value, the sub-sub-TLV MUST be ignored.
o 长度：2。如果长度是其他值，则必须忽略子TLV。
o RESV: 4 reserved bits. MUST be sent as zero and ignored on receipt.
o RESV:4个保留位。必须作为零发送，并在收到时忽略。
o Topology: The 12-bit topology number [RFC5120].
o 拓扑：12位拓扑编号[RFC5120]。
The integrity of address mapping and reachability information as well as the correctness of Data Labels (VLANs or FGLs [RFC7172]) are very important. Forged, altered, or incorrect address mapping or data labeling can lead to delivery of packets to the incorrect party, violating security policy. However, this document merely describes a data format and does not provide any explicit mechanisms for securing that information, other than a few simple consistency checks that might detect some corrupted data. Security on the wire, or in storage, for this data is to be provided by the transport or storage used. For example, when transported with ESADI [RFC7357] or RBridge Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel] security mechanisms can be used, respectively.
地址映射和可达性信息的完整性以及数据标签（VLAN或FGL[RFC7172]）的正确性非常重要。伪造、更改或不正确的地址映射或数据标签可能会导致向不正确的一方传递数据包，从而违反安全策略。但是，本文档仅描述了数据格式，没有提供任何明确的机制来保护该信息，除了一些可能检测某些损坏数据的简单一致性检查之外。该数据的在线或存储安全性由所使用的传输或存储提供。例如，当使用ESADI[RFC7357]或RBridge Channel[RFC7178]传输时，可以分别使用ESADI安全机制或Channel Tunnel[ChannelTunnel]安全机制。
The address mapping and reachability information, if known to be complete and correct, can be used to detect some cases of forged packet source addresses [RFC7067]. In particular, if native traffic from an end station is received by a TRILL switch that would otherwise accept it but authoritative data indicates that the source address should not be reachable from the receiving TRILL switch, that traffic should be discarded. The data format specified in this document may optionally include a TRILL switch Port ID number so that this forged address filtering can be optionally applied with port granularity. For manageability, a counter of frames so discarded should be maintained.
地址映射和可达性信息（如果已知完整且正确）可用于检测伪造数据包源地址的某些情况[RFC7067]。特别是，如果TRILL交换机接收到来自终端站的本机通信量，而TRILL交换机会接受本机通信量，但权威数据表明，从接收TRILL交换机无法访问源地址，则应丢弃该通信量。本文档中指定的数据格式可以选择性地包括TRILL交换机端口ID号，以便可以选择性地应用端口粒度的伪造地址过滤。为了便于管理，应该保留这样丢弃的帧计数器。
See [RFC6325] for general TRILL security considerations.
参见[RFC6325]了解一般TRILL安全注意事项。
The following subsections specify IANA allocations.
以下小节指定IANA分配。
IANA has allocated values in the "Address Family Numbers" registry that may be useful for IA APPsub-TLVs. The values are as follows:
IANA在“地址系列号”注册表中分配了可能对IA APPsub TLV有用的值。数值如下：
Hex Decimal Description References
----- ------- ----------- ----------
0001 1 IPv4
0002 2 IPv6
4005 16389 48-bit MAC Section 2.1 of [RFC7042]
4006 16390 64-bit MAC Section 2.2 of [RFC7042]
4007 16391 OUI Section 6 of RFC 7961
4008 16392 MAC/24 Section 6 of RFC 7961
4009 16393 MAC/40 Section 6 of RFC 7961
400A 16394 IPv6/64 Section 6 of RFC 7961
400B 16395 RBridge Port ID Section 6 of RFC 7961
Hex Decimal Description References
----- ------- ----------- ----------
0001 1 IPv4
0002 2 IPv6
4005 16389 48-bit MAC Section 2.1 of [RFC7042]
4006 16390 64-bit MAC Section 2.2 of [RFC7042]
4007 16391 OUI Section 6 of RFC 7961
4008 16392 MAC/24 Section 6 of RFC 7961
4009 16393 MAC/40 Section 6 of RFC 7961
400A 16394 IPv6/64 Section 6 of RFC 7961
400B 16395 RBridge Port ID Section 6 of RFC 7961
Other AFNs can be found at <http://www.iana.org/assignments/ address-family-numbers>.
其他AFN可在以下网址找到：<http://www.iana.org/assignments/ 地址系列号>。
See Section 7 on interpreting Address Sets.
参见第7节解释地址集。
IANA has established a new sub-registry of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry for sub-sub-TLVs of the Interface Addresses APPsub-TLV, with the following initial contents:
IANA为接口地址APPsub TLV的子TLV建立了“大量链路透明互连（TRILL）参数”注册表的新子注册表，初始内容如下：
Name: Interface Addresses APPsub-TLV Sub-sub-TLVs
名称：接口地址APPsub TLV Sub TLV
Procedure: Expert Review
程序：专家审评
Note: Types greater than 255 are not usable in some contexts.
注意：大于255的类型在某些上下文中不可用。
Reference: RFC 7961
参考：RFC 7961
Type Description Reference
------ ----------- ---------
0 Reserved RFC 7961
1 AFN Size RFC 7961
2 Fixed Address RFC 7961
3 Data Label RFC 7961
4 Topology RFC 7961
5-254 Unassigned
255 Reserved RFC 7961
256-65534 Unassigned
65535 Reserved RFC 7961
Type Description Reference
------ ----------- ---------
0 Reserved RFC 7961
1 AFN Size RFC 7961
2 Fixed Address RFC 7961
3 Data Label RFC 7961
4 Topology RFC 7961
5-254 Unassigned
255 Reserved RFC 7961
256-65534 Unassigned
65535 Reserved RFC 7961
Expert Guidance: A designated expert for this registry should decide whether to permit the assignment of a type based on clear documentation of the proposed type as provided by the requester, such as a complete Internet-Draft. New types should not duplicate existing types. Requests should indicate whether a type less than 255 is desired; such types can be used in contexts where only 1 byte of a type (and usually only 1 byte of the length) is permitted. Types greater than 255 can only be used where 2-byte types are allowed, such as in Extended Level 1 Flooding Scope (E-L1FS) or Extended Level 1 Circuit Scope (E-L1CS) extended FS-LSPs [RFC7356]; in those contexts, lengths up to 65535 bytes can also be expressed, although they may not be usable if the resulting TLV would not fit into a larger context restricted by an MTU setting or the like. Values within the region below 255 and the region above 255 should be allocated sequentially, unless there is an extraordinary reason for a special value.
专家指导：该登记处的指定专家应根据申请人提供的建议类型的明确文件，如完整的互联网草案，决定是否允许分配类型。新类型不应与现有类型重复。请求应指明是否需要小于255的类型；这样的类型可以在只允许类型的1字节（通常只允许长度的1字节）的上下文中使用。大于255的类型只能在允许2字节类型的情况下使用，例如在扩展的1级泛洪范围（E-L1FS）或扩展的1级电路范围（E-L1CS）扩展的FS LSP[RFC7356]中；在这些上下文中，也可以表示高达65535字节的长度，尽管如果生成的TLV不适合由MTU设置等限制的更大上下文，则它们可能不可用。255以下区域和255以上区域内的值应按顺序分配，除非有特殊原因需要特殊值。
IANA has allocated type 10 as the IA APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry from the range under 256. In the registry, the name is "IA" and the reference is this document.
IANA已在“IS-IS TLV 251应用程序标识符1下的TRILL APPsub TLV类型”注册表中将类型10分配为256下的IA APPsub TLV。在注册表中，名称为“IA”，参考文件为本文件。
This section provides additional information concerning AFNs that were allocated in connection with this document. These AFNs are not restricted to use in the IA APPsub-TLV and may be used in other protocols where they would be appropriate.
本节提供了与本文件相关的AFN的其他信息。这些AFN不限于在IA APPsub TLV中使用，也可以在其他协议中使用，如果合适的话。
OUI: A 3-byte (24-bit) Organizationally Unique Identifier used as the initial 3 bytes of a MAC address. See Sections 2.1 and 2.2 of [RFC7042], and Section 7 below.
OUI：一个3字节（24位）的组织唯一标识符，用作MAC地址的初始3字节。见[RFC7042]第2.1节和第2.2节，以及下文第7节。
MAC/24: A 3-byte (24-bit) quantity used as the final 3 bytes of a 48-bit MAC address. See Section 2.1 of [RFC7042] and Section 7 below.
MAC/24：用作48位MAC地址最后3字节的3字节（24位）量。参见[RFC7042]第2.1节和下文第7节。
MAC/40: A 5-byte (40-bit) quantity used as the final 5 bytes of a 64-bit MAC address. See Section 2.2 of [RFC7042] and Section 7 below.
MAC/40：用作64位MAC地址最后5字节的5字节（40位）量。参见[RFC7042]第2.2节和下文第7节。
IPv6/64: An 8-byte (64-bit) quantity used as the initial 8 bytes of an IPv6 address. See Section 7 below.
IPv6/64：用作IPv6地址初始8字节的8字节（64位）数量。见下文第7节。
RBridge Port ID: A 16-bit quantity that uniquely identifies a port on a TRILL switch (RBridge). See Section 4.4.2 of [RFC6325].
RBridge端口ID：唯一标识TRILL交换机（RBridge）上端口的16位数量。见[RFC6325]第4.4.2节。
The following processes should be followed in interpreting sets of AFN values in an IA APPsub-TLV to synthesize addresses. These apply whether the AFN values came from sub-sub-TLVs, appeared within an Address Set, or came from both sources. In general, the processing is applied separately to each Address Set as supplemented by any Fixed Address sub-sub-TLVs that are present.
在解释IA APPsub TLV中的AFN值集以合成地址时，应遵循以下过程。无论AFN值来自子TLV、出现在地址集中，还是来自两个源，这些都适用。通常，该处理单独应用于每个地址集，并由存在的任何固定地址子TLV进行补充。
The OUI AFN value is provided so that MAC addresses can be abbreviated if they have the same upper 24 bits. A MAC/24 is a 24-bit suffix intended to be prefixed by an OUI to create a 48-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/24 entry cannot be used. A MAC/40 is a 40-bit suffix intended to be prefixed by an OUI to create a 64-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/40 entry cannot be used.
提供OUI AFN值，以便如果MAC地址具有相同的高24位，则可以缩短它们。MAC/24是一个24位后缀，用于以OUI为前缀创建48位MAC地址[RFC7042]；如果没有OUI，则不能使用MAC/24条目。MAC/40是一个40位后缀，用于以OUI为前缀创建64位MAC地址[RFC7042]；如果没有OUI，则不能使用MAC/40条目。
Typically, an OUI would be provided as a Fixed Address sub-sub-TLV (see Section 3.2) using the OUI AFN, but there is no prohibition against one or more OUIs appearing in an Address Set.
通常，OUI将使用OUI AFN作为固定地址子TLV（见第3.2节）提供，但不禁止一个或多个OUI出现在地址集中。
Each Address Set, after being supplemented by any Fixed Address sub-sub-TLVs, is processed by combining each OUI in the Address Set with each MAC/24 and each MAC/40 address in the Address Set. Depending on how many of each of these address types are present, zero or more 48-bit and/or 64-bit MAC addresses may be synthesized that are subsequently processed as if they had been part of the Address Set. If there are no MAC/24 or MAC/40 addresses present, any OUIs are ignored. If there are no OUIs, any MAC/24s and/or MAC/40s are ignored. If there are K1 OUIs, K2 MAC/24s, and K3 MAC/40s, K1*K2 48-bit MACs are synthesized and K1*K3 64-bit MACs are synthesized.
每个地址集在被任何固定地址子TLV补充后，通过将地址集中的每个OUI与地址集中的每个MAC/24和每个MAC/40地址组合来处理。根据这些地址类型中的每种存在的数量，可以合成零个或多个48位和/或64位MAC地址，这些地址随后被处理，就像它们是地址集的一部分一样。如果没有MAC/24或MAC/40地址，则忽略任何OUI。如果没有OUI，则忽略任何MAC/24和/或MAC/40。如果存在K1 OUI、K2 MAC/24s和K3 MAC/40s，则合成K1*K2 48位MAC和K1*K3 64位MAC。
IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 address. IPv6/64s are ignored unless, after the processing described above in this subsection, there are one or more 48-bit and/or 64-bit MAC addresses in the Address Set to provide the lower 64 bits of the IPv6 address. For this purpose, a 48-bit MAC address is expanded to 64 bits as described in Section 2.2.1 of [RFC7042]. If there are K4 IPv6/64s present and K5 48-bit and 64-bit MAC addresses present, K4*K5 128-bit IPv6 addresses are synthesized.
IPv6/64是一个8字节的数量，是IPv6地址的前64位。除非在本小节中描述的处理之后，地址集中存在一个或多个48位和/或64位MAC地址，以提供IPv6地址的较低64位，否则将忽略IPv6/64。为此，如[RFC7042]第2.2.1节所述，将48位MAC地址扩展为64位。如果存在K4 IPv6/64，并且存在K5 48位和64位MAC地址，则合成K4*K5 128位IPv6地址。
Synthesized addresses are treated as if they had been members of the Address Set.
合成地址被视为地址集的成员。
[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)", ISO Standard 10589, 2002.
[ISO-10589]国际标准化组织，“与提供无连接模式网络服务协议（ISO 8473）一起使用的中间系统到中间系统域内路由信息交换协议”，ISO标准10589，2002年。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, DOI 10.17487/RFC0903, June 1984, <http://www.rfc-editor.org/info/rfc903>.
[RFC903]Finlayson，R.，Mann，T.，Mogul，J.，和M.Theimer，“反向地址解析协议”，STD 38，RFC 903，DOI 10.17487/RFC0903，1984年6月<http://www.rfc-editor.org/info/rfc903>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>.
[RFC5120]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS：中间系统到中间系统（IS-ISs）的多拓扑（MT）路由”，RFC 5120，DOI 10.17487/RFC5120，2008年2月<http://www.rfc-editor.org/info/rfc5120>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<http://www.rfc-editor.org/info/rfc5305>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<http://www.rfc-editor.org/info/rfc6325>.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, DOI 10.17487/RFC6823, December 2012, <http://www.rfc-editor.org/info/rfc6823>.
[RFC6823]Ginsberg，L.，Previdi，S.，和M.Shand，“IS-IS中的广告通用信息”，RFC 6823，DOI 10.17487/RFC6823，2012年12月<http://www.rfc-editor.org/info/rfc6823>.
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042]Eastlake 3rd，D.和J.Abley，“IEEE802参数的IANA考虑因素和IETF协议及文档使用”，BCP 141，RFC 7042，DOI 10.17487/RFC7042，2013年10月<http://www.rfc-editor.org/info/rfc7042>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<http://www.rfc-editor.org/info/rfc7172>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（LSPs）”，RFC 7356，DOI 10.17487/RFC7356，2014年9月<http://www.rfc-editor.org/info/rfc7356>.
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357]翟，H.，胡，F.，帕尔曼，R.，东湖3号，D.，和O.斯托克斯，“大量链路的透明互连（TRILL）：端站地址分配信息（ESADI）协议”，RFC 7357，DOI 10.17487/RFC7357，2014年9月<http://www.rfc-editor.org/info/rfc7357>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<http://www.rfc-editor.org/info/rfc7780>.
[ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., and R. Perlman, "TRILL: ARP/ND Optimization", Work in Progress, draft-ietf-trill-arp-optimization-06, April 2016.
[ARPND]Li，Y.，Eastlake 3rd，D.，Dunbar，L.，和R.Perlman，“颤音：ARP/ND优化”，正在进行的工作，草稿-ietf-TRILL-ARP-Optimization-062016年4月。
[ChannelTunnel] Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge Channel Header Extension", Work in Progress, draft-ietf-trill-channel-tunnel-11, August 2016.
[ChannelTunnel]Eastlake 3rd，D.，Umair，M.，和Y.Li，“TRILL:RBridge渠首延伸”，在建工程，草案-ietf-TRILL-Channel-tunnel-112016年8月。
[DirectoryScheme] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, "TRILL: Edge Directory Assist Mechanisms", Work in Progress, draft-ietf-trill-directory-assist-mechanisms-07, February 2016.
[DirectoryScheme]Eastlake 3rd，D.，Dunbar，L.，Perlman，R.，和Y.Li，“颤音：边缘目录辅助机制”，正在进行的工作，草稿-ietf-TRILL-Directory-Assist-Mechanism-072016年2月。
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines for the Address Resolution Protocol (ARP)", RFC 5494, DOI 10.17487/RFC5494, April 2009, <http://www.rfc-editor.org/info/rfc5494>.
[RFC5494]Arkko，J.和C.Pignataro，“地址解析协议（ARP）的IANA分配指南”，RFC 5494，DOI 10.17487/RFC5494，2009年4月<http://www.rfc-editor.org/info/rfc5494>.
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067]Dunbar，L.，Eastlake 3rd，D.，Perlman，R.，和I.Gashinsky，“目录协助问题和高层设计方案”，RFC 7067，DOI 10.17487/RFC7067，2013年11月<http://www.rfc-editor.org/info/rfc7067>.
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178]Eastlake 3rd，D.，Manral，V.，Li，Y.，Aldrin，S.，和D.Ward，“大量链路的透明互连（TRILL）：RBridge通道支持”，RFC 7178，DOI 10.17487/RFC7178，2014年5月<http://www.rfc-editor.org/info/rfc7178>.
Below are example IA APPsub-TLVs. "0x" indicates that the quantity is in hexadecimal. "0b" indicates that the quantity is in binary. Leading zeros are retained.
下面是IA APPsub TLV示例。“0x”表示数量是十六进制的。“0b”表示数量是二进制的。保留前导零。
Below is an annotated IA APPsub-TLV carrying two simple pairs of EUI-48 MAC addresses and IPv4 addresses from a Push Directory (a directory conforming to the Push Model [RFC7067]). No sub-sub-TLVs are included.
下面是一个带注释的IA APPsub TLV，其中包含推送目录（符合推送模型[RFC7067]的目录）中的两对简单的EUI-48 MAC地址和IPv4地址。不包括子TLV。
0x0002(10) Type: Interface Addresses
0x001B Length: 27 (= 0x1B)
0x001B Address Sets End: 27 (= 0x1B)
0x1234 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xE3 Confidence = 227
33 Template: 33 (0x21) = 32 + 1(IPv4)
0x0002(10) Type: Interface Addresses
0x001B Length: 27 (= 0x1B)
0x001B Address Sets End: 27 (= 0x1B)
0x1234 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xE3 Confidence = 227
33 Template: 33 (0x21) = 32 + 1(IPv4)
Address Set One 0x00005E0053A9 48-bit MAC address 198.51.100.23 IPv4 address
地址集一个0x00005E0053A9 48位MAC地址198.51.100.23 IPv4地址
Address Set Two 0x00005E00536B 48-bit MAC address 203.0.113.201 IPv4 address
地址集两个0x00005E00536B 48位MAC地址203.0.113.201 IPv4地址
The size includes 7 for the fixed fields through and including the 1-byte Template, plus 2 times the Address Set size. Each Address Set is 10 bytes: 6 for the 48-bit MAC address plus 4 for the IPv4 address. Therefore, the total size is 7 + 2*10 = 27.
该大小包括通过并包括1字节模板的固定字段的7，加上地址集大小的2倍。每个地址集为10字节：48位MAC地址为6字节，IPv4地址为4字节。因此，总尺寸为7+2*10=27。
See Section 2 for more information on the Template.
有关模板的更多信息，请参见第2节。
Below is an annotated IA APPsub-TLV carrying three sets of addresses, each consisting of an EUI-48 MAC address, an IPv4 address, an IPv6 address, and an RBridge Port ID, all from a Push Directory (a directory conforming to the Push Model [RFC7067]). The IPv6 address for each Address Set is synthesized from the MAC address given in that set and the IPv6/64 64-bit prefix provided through a Fixed Address sub-sub-TLV. In addition, a sub-sub-TLV is included that provides an FGL that overrides whatever Data Label may be provided by the envelope (for example, an ESADI-LSP [RFC7357]) within which this IA APPsub-TLV occurs.
下面是一个带注释的IA APPsub TLV，其中包含三组地址，每个地址包括一个EUI-48 MAC地址、一个IPv4地址、一个IPv6地址和一个RBridge端口ID，所有这些地址都来自推送目录（一个符合推送模型[RFC7067]的目录）。每个地址集的IPv6地址由该地址集中给定的MAC地址和通过固定地址子TLV提供的IPv6/64位前缀合成。此外，还包括一个子TLV，该子TLV提供一个FGL，该FGL覆盖发生该IA APPsub TLV的信封（例如，ESADI-LSP[RFC7357]）可能提供的任何数据标签。
0x0002(10) Type: Interface Addresses
0x0036 Length: 64 (= 0x40)
0x0021 Address Sets End: 43 (= 0x2B)
0x4321 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xD3 Confidence = 211
37 Template: 37(0x25) = 32 + 1(IPv4) + 4(Port)
0x0002(10) Type: Interface Addresses
0x0036 Length: 64 (= 0x40)
0x0021 Address Sets End: 43 (= 0x2B)
0x4321 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xD3 Confidence = 211
37 Template: 37(0x25) = 32 + 1(IPv4) + 4(Port)
Address Set One 0x00005E0053DE 48-bit MAC address 198.51.100.105 IPv4 address 0x1DE3 RBridge Port ID
地址集一个0x00005E0053DE 48位MAC地址198.51.100.105 IPv4地址0x1DE3 RBridge端口ID
Address Set Two 0x00005E0053E3 48-bit MAC address 203.0.113.89 IPv4 address 0x1DEE RBridge Port ID
地址集两个0x00005E0053E3 48位MAC地址203.0.113.89 IPv4地址0x1DEE RBridge端口ID
Address Set Three 0x00005E0053D3 48-bit MAC address 192.0.2.139 IPv4 address 0x01DE RBridge Port ID
地址集三个0x00005E0053D3 48位MAC地址192.0.2.139 IPv4地址0x01DE RBridge端口ID
sub-sub-TLV One 0x0003 Type: Data Label 0x0003 Length: Implies FGL 0xD3E3E3 Fine-Grained Label
sub-sub TLV One 0x0003类型：数据标签0x0003长度：表示FGL 0xD3E3E3细粒度标签
sub-sub-TLV Two 0x0002 Type: Fixed Address 0x000A Size: 0x0A = 10 0x400A AFN: IPv6/64 0x20010db800000000 IPv6 Prefix: 2001:db8::
子TLV两个0x0002类型：固定地址0x000A大小：0x0A=10 0x400A AFN:IPv6/64 0x20010DB80000000 IPv6前缀：2001:db8:：
See Section 2 for more information on the Template.
有关模板的更多信息，请参见第2节。
The Fixed Address sub-sub-TLV causes the IPv6/64 value given to be treated as if it occurred as a fourth entry inside each of the three Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry, the MAC value is expanded by inserting 0xfffe immediately after the OUI, and the local/global bit is inverted. The resulting Modified EUI-64-bit value is used as the lower 64 bits of the resulting IPv6 address (Section 2.2.1 of [RFC7042]). As a result, a receiving TRILL switch would treat the three Address Sets shown as if they had an IPv6 address in them, as follows:
固定地址子TLV导致给定的IPv6/64值被视为三个地址集中的第四个条目。当存在IPv6/64条目和48位MAC条目时，通过在OUI之后立即插入0xfffe来扩展MAC值，并反转本地/全局位。生成的修改后的EUI-64位值用作生成的IPv6地址的低64位（RFC7042第2.2.1节）。因此，接收TRILL交换机会将显示的三个地址集视为其中包含IPv6地址，如下所示：
Address Set One 0x20010db80000000002005efffe0053de IPv6 Address
地址设置一个0x20010DB8000002005EFFFE0053DE IPv6地址
Address Set Two 0x20010db80000000002005efffe0053e3 IPv6 Address
地址集两个0x20010DB8000002005EFFFE0053E3 IPv6地址
Address Set Three 0x20010db80000000002005efffe0053d3 IPv6 Address
地址集三个0x20010DB8000002005EFFFE0053D3 IPv6地址
As an alternative to the compact "well-known value" Template encoding used in the example above, the less compact explicit AFN encoding could have been used. In that case, the IA APPsub-TLV would have started as follows:
作为上述示例中使用的紧凑“已知值”模板编码的替代方案，可以使用不太紧凑的显式AFN编码。在这种情况下，IA APPsub TLV将按如下方式启动：
0x0002(10) Type: Interface Addresses
0x003C Length: 60 (= 0x3C)
0x0027 Address Sets End: 39 (= 0x27)
0x4321 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xD3 Confidence = 211
0x3 Template: 3 AFNs
0x4005 AFN: 48-bit MAC
0x0001 AFN: IPv4
0x400B AFN: RBridge Port ID
0x0002(10) Type: Interface Addresses
0x003C Length: 60 (= 0x3C)
0x0027 Address Sets End: 39 (= 0x27)
0x4321 RBridge Nickname from which reachable
0b10000000 Flags: Push Directory data
0xD3 Confidence = 211
0x3 Template: 3 AFNs
0x4005 AFN: 48-bit MAC
0x0001 AFN: IPv4
0x400B AFN: RBridge Port ID
As a final point, since the 48-bit MAC addresses in these three Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would have been possible to just have a MAC/24 value giving the lower 24 bits of the MAC in each Address Set. The OUI would then be supplied by a second Fixed Address sub-sub-TLV providing the OUI. With N Address Sets, this would have saved 3*N or 9 bytes, at a cost of 9 bytes (2 each for the Type and Length of the sub-sub-TLV, 2 for the OUI AFN, and 3 for the OUI). So, with just three Address Sets, there would be no net savings; however, with a larger number of Address Sets, there would be a net savings.
最后一点，由于这三个地址集中的48位MAC地址都具有相同的OUI（IANA OUI[RFC7042]），因此可能只有一个MAC/24值，给出每个地址集中MAC的较低24位。然后，OUI将由提供OUI的第二个固定地址子TLV提供。对于N个地址集，这将节省3*N或9个字节，代价是9个字节（子TLV的类型和长度各2个，OUI AFN 2个，OUI 3个）。因此，只有三个地址集，就不会有净储蓄；然而，如果地址集的数量更多，则会有净节省。
Acknowledgments
致谢
The authors gratefully acknowledge the contributions and review by the following:
作者衷心感谢以下方面的贡献和评论：
Linda Dunbar, Sue Hares, Paul Kyzivat, Danny McPherson, and Gayle Noble
琳达·邓巴、苏·哈尔斯、保罗·基齐瓦特、丹尼·麦克弗森和盖尔·诺布尔
Authors' Addresses
作者地址
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
美国马萨诸塞州米尔福德市海狸街155号唐纳德·伊斯特莱克第三华为技术有限公司01757
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Phone: +86-25-56622310
Email: liyizhou@huawei.com