Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 8383 D. Eastlake, 3rd
Category: Standards Track Y. Li
ISSN: 2070-1721 Huawei
M. Umair
Cisco
May 2018
Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 8383 D. Eastlake, 3rd
Category: Standards Track Y. Li
ISSN: 2070-1721 Huawei
M. Umair
Cisco
May 2018
Transparent Interconnection of Lots of Links (TRILL): Address Flush Message
大量链接的透明互连（TRILL）：地址刷新消息
Abstract
摘要
The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.
默认情况下，TRILL（大量链路的透明互连）协议通过观察数据平面来学习终端站地址。特别是，它从接收本地数据帧中学习本地媒体访问控制（MAC）地址和附件的边缘交换机端口，并从远程源TRILL数据包的去封装中学习远程MAC地址和附件的边缘交换机端口。
This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets. This is a supplement to the TRILL automatic address forgetting (see Section 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change.
本文档指定了一条消息，通过该消息，TRILL交换机可以显式请求其他TRILL交换机刷新通过解除TRILL数据包封装而获得的某些MAC可达性。这是TRILL自动地址遗忘（见RFC 6325第4.8.3节）的补充，有助于在拓扑或配置发生变化时实现更快的收敛。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8383.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8383.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3
2. Address Flush Message Details . . . . . . . . . . . . . . . . 5
2.1. VLAN Block Only Case . . . . . . . . . . . . . . . . . . 6
2.2. Extensible Case . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Blocks of VLANs . . . . . . . . . . . . . . . . . . . 12
2.2.2. Bit Map of VLANs . . . . . . . . . . . . . . . . . . 12
2.2.3. Blocks of FGLs . . . . . . . . . . . . . . . . . . . 13
2.2.4. list of FGLs . . . . . . . . . . . . . . . . . . . . 13
2.2.5. Big Map of FGLs . . . . . . . . . . . . . . . . . . . 14
2.2.6. All Data Labels . . . . . . . . . . . . . . . . . . . 14
2.2.7. MAC Address List . . . . . . . . . . . . . . . . . . 15
2.2.8. MAC Address Blocks . . . . . . . . . . . . . . . . . 16
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
3.1. Address Flush RBridge Channel Protocol Number . . . . . . 17
3.2. TRILL Address Flush TLV Types . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 3
2. Address Flush Message Details . . . . . . . . . . . . . . . . 5
2.1. VLAN Block Only Case . . . . . . . . . . . . . . . . . . 6
2.2. Extensible Case . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Blocks of VLANs . . . . . . . . . . . . . . . . . . . 12
2.2.2. Bit Map of VLANs . . . . . . . . . . . . . . . . . . 12
2.2.3. Blocks of FGLs . . . . . . . . . . . . . . . . . . . 13
2.2.4. list of FGLs . . . . . . . . . . . . . . . . . . . . 13
2.2.5. Big Map of FGLs . . . . . . . . . . . . . . . . . . . 14
2.2.6. All Data Labels . . . . . . . . . . . . . . . . . . . 14
2.2.7. MAC Address List . . . . . . . . . . . . . . . . . . 15
2.2.8. MAC Address Blocks . . . . . . . . . . . . . . . . . 16
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
3.1. Address Flush RBridge Channel Protocol Number . . . . . . 17
3.2. TRILL Address Flush TLV Types . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Normative References . . . . . . . . . . . . . . . . . . 18
5.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
By default, edge TRILL (Transparent Interconnection of Lots of Links) switches [RFC6325] [RFC7780], also called edge Routing Bridges (RBridges), learn end station MAC address reachability from observing the data plane. On receipt of a native frame from an end station, they would learn the local MAC address attachment of the source end station. And on egressing (decapsulating) a remotely originated TRILL Data packet, they learn the remote MAC address and remote attachment TRILL switch. Such learning is all scoped by data label (VLAN or Fine-Grained Label (FGL) [RFC7172]).
默认情况下，edge TRILL（大量链路的透明互连）交换机[RFC6325][RFC7780]，也称为边缘路由桥（RBridges），通过观察数据平面来了解终端站MAC地址的可达性。从终端站接收到本机帧后，他们将了解源终端站的本地MAC地址附件。在对远程生成的TRILL数据包进行出口（解除封装）时，他们学习远程MAC地址和远程连接TRILL交换机。这种学习都是由数据标签（VLAN或细粒度标签（FGL）[RFC7172]）决定的。
TRILL has mechanisms for timing out such learning and appropriately clearing it based on some network connectivity and configuration changes; however, there are circumstances under which it would be helpful for a TRILL switch to be able to explicitly flush (purge) certain learned end station reachability information in remote RBridges to achieve more-rapid convergence. Section 6.2 of [RFC4762] is an example of the use of such a mechanism.
TRILL有一些机制，可以根据一些网络连接和配置的变化来对这种学习进行计时和适当地清除；然而，在某些情况下，TRILL交换机能够明确地刷新（清除）远程RBridge中的某些已学习的终端站可达性信息，以实现更快的收敛是有帮助的。[RFC4762]第6.2节是使用此类机制的示例。
Another example, based on Appendix A.3 of [RFC6325] ("Wiring Closet Topology"), presents a bridged LAN connected to a TRILL network via multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests configuring the RBridge ports to be like one Spanning Tree Protocol (STP) tree root in the bridged LAN. The Address Flush message in this document could also be triggered in this case when one of the edge RBridges receives Topology Change (TC) information (e.g., TC in STP, Topology Change Notification (TCN) in Multiple Spanning Tree Protocol (MSTP)) in order to rapidly flush the MAC addresses for specific VLANs learned at the other edge RBridge ports.
另一个例子，基于[RFC6325]（“布线柜拓扑”）的附录A.3，给出了通过多个RBridge端口连接到TRILL网络的桥接LAN。对于最佳路径，附录A.3.3建议将RBridge端口配置为桥接LAN中的一个生成树协议（STP）树根。在这种情况下，当一个边缘RBridge接收到拓扑更改（TC）信息（例如，STP中的TC、多生成树协议（MSTP）中的拓扑更改通知（TCN））时，也会触发本文档中的地址刷新消息为了快速刷新在其他边缘RBridge端口上学习到的特定VLAN的MAC地址。
A TRILL switch can easily flush any locally learned addresses it wants. This document specifies an RBridge Channel Support protocol [RFC7178] message to request flushing address information for specific VLANs or FGLs ([RFC7172]) learned from decapsulating TRILL Data packets.
TRILL开关可以轻松刷新它想要的任何本地学习地址。本文档指定了一条RBridge Channel Support protocol[RFC7178]消息，以请求从解封装TRILL数据包中获取的特定VLAN或FGL（[RFC7172]）的刷新地址信息。
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] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应在且仅在出现在所有大写字母时按[RFC2119][RFC8174]所述进行解释，如下所示。
This document uses the terms and abbreviations defined in [RFC6325] and [RFC7178] as well as the following:
本文件使用[RFC6325]和[RFC7178]中定义的术语和缩写以及以下内容：
Data Label: A VLAN or FGL
数据标签：VLAN或FGL
Edge TRILL Switch: A TRILL switch attached to one or more links that provide end station service
边缘颤音开关：连接到一个或多个链路的颤音开关，提供终端站服务
FCS: Frame Check Sequence
FCS：帧检查序列
FGL: Fine-Grained Label [RFC7172]
FGL：细粒度标签[RFC7172]
Management VLAN: A VLAN in which all TRILL switches in a campus indicate interest so that multi-destination TRILL Data packets, including RBridge Channel protocol messages [RFC7178], sent with that VLAN as the Inner.VLAN will be delivered to all TRILL switches in the campus. Usually, no end station service is offered in the Management VLAN.
管理VLAN：一种VLAN，其中校园中的所有TRILL交换机都表示感兴趣，因此，将该VLAN作为内部VLAN发送的多目标TRILL数据包（包括RBridge Channel protocol messages[RFC7178]）将传送到校园中的所有TRILL交换机。通常，在管理VLAN中不提供终端站服务。
MAC: Media Access Control
媒体访问控制
RBridge: An alternative name for a TRILL switch
RBridge：颤音开关的另一个名称
STP: Spanning Tree Protocol
生成树协议
TC: Topology Change message
TC：拓扑更改消息
TCN: Topology Change Notification message
TCN：拓扑更改通知消息
TRILL switch: A device implementing the TRILL protocol [RFC6325] [RFC7780]
颤音开关：实现颤音协议的设备[RFC6325][RFC7780]
The Address Flush message is an RBridge Channel protocol message [RFC7178].
地址刷新消息是RBridge通道协议消息[RFC7178]。
The general structure of an RBridge Channel packet on a link between TRILL switches is shown in Figure 1. The Protocol field in the RBridge Channel Header gives the type of RBridge Channel packet and indicates how to interpret the Channel-Protocol-Specific Payload [RFC7178].
TRILL交换机之间链路上RBridge通道数据包的一般结构如图1所示。RBridge Channel Header中的Protocol字段给出RBridge Channel数据包的类型，并指示如何解释特定于通道协议的有效负载[RFC7178]。
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+-----------------------------------+
| Inner Ethernet Addresses |
+-----------------------------------+
| Data Label (VLAN or FGL) |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+-----------------------------------+
| Inner Ethernet Addresses |
+-----------------------------------+
| Data Label (VLAN or FGL) |
+-----------------------------------+
| RBridge Channel Header |
+-----------------------------------+
| Channel-Protocol-Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 1: RBridge Channel Protocol Message Structure
图1:RBridge通道协议消息结构
By default, an Address Flush RBridge Channel protocol message applies to addresses within the Data Label that appear right after the Inner Ethernet Addresses. Address Flush protocol messages are usually sent as multi-destination packets (TRILL Header M bit equal to one) so as to reach all TRILL switches offering end station service in the VLAN or FGL specified by that Data Label. Both multi-destination and unicast Address Flush messages SHOULD be sent at priority 6 since they are important control messages but are lower priority than control messages that establish or maintain adjacency.
默认情况下，Address Flush RBridge Channel protocol（地址刷新RBridge通道协议）消息应用于显示在内部以太网地址之后的数据标签内的地址。地址刷新协议消息通常作为多目标数据包（TRILL头M位等于1）发送，以便到达在该数据标签指定的VLAN或FGL中提供终端站服务的所有TRILL交换机。多目标和单播地址刷新消息都应以优先级6发送，因为它们是重要的控制消息，但优先级低于建立或保持邻接的控制消息。
Nevertheless:
然而：
- There are provisions for optionally indicating the Data Label(s) to be flushed for cases where the Address Flush message is sent over a Management VLAN or the like.
- 对于通过管理VLAN等发送地址刷新消息的情况，存在可选指示要刷新的数据标签的规定。
- An Address Flush message can be sent unicast, if it is desired to clear addresses at one TRILL switch only.
- 如果只希望清除一个TRILL开关上的地址，则可以单播发送地址刷新消息。
- An Address Flush message can be sent selectively to the RBridges that have at least one access port configured as one of the VLANs or FGLs specified in the Address Flush message payload.
- 地址刷新消息可以选择性地发送到RBridge，RBridge至少有一个访问端口配置为地址刷新消息负载中指定的VLAN或FGL之一。
Implementations should consider logging Address Flush messages received with appropriate protections against packet storms.
实现应该考虑通过对分组风暴的适当保护接收日志地址刷新消息。
Figure 2 expands the RBridge Channel Header and Channel-Protocol-Specific Payload from Figure 1 for the case of the VLAN-only-based Address Flush message. This form of the Address Flush message is optimized for flushing MAC addresses based on nickname and blocks of VLANs. 0x8946 is the Ethertype assigned by IEEE for the RBridge Channel protocol [RFC7178].
对于仅基于VLAN的地址刷新消息，图2从图1扩展了RBridge通道头和特定于通道协议的有效负载。这种形式的地址刷新消息针对基于昵称和VLAN块刷新MAC地址进行了优化。0x8946是IEEE为RBridge信道协议[RFC7178]分配的以太网类型。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol= 0x009|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol= 0x009|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN K-VLBs | RESV | End.VLAN K-VLBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Address Flush Message - VLAN Block Case
图2：地址刷新消息-VLAN块情况
The fields in Figure 2 related to the Address Flush message are as follows:
图2中与地址刷新消息相关的字段如下所示：
Channel Protocol: The RBridge Channel Protocol value allocated for Address Flush (see Section 3).
信道协议：为地址刷新分配的RBridge信道协议值（参见第3节）。
K-nicks: The number of nicknames listed as an unsigned integer. If this is zero, the ingress nickname in the TRILL Header [RFC6325] is considered to be the only nickname to which the message applies. If non-zero, it gives the number of nicknames listed right after K-nicks to which the message applies, and, in this non-zero case, the flush does not apply to the ingress nickname in the TRILL Header unless it is also listed. The message flushes address learning due to egressing TRILL Data packets that had an ingress nickname to which the message applies.
K-nicks：作为无符号整数列出的昵称数。如果该值为零，则TRILL头[RFC6325]中的入口昵称被视为消息应用的唯一昵称。如果非零，则给出消息应用的K-nick后面列出的昵称数，在这种非零情况下，刷新不适用于TRILL头中的入口昵称，除非它也列出。该消息刷新地址学习，这是由于该消息应用了具有入口昵称的TRILL数据包的出口。
Nickname: A listed nickname to which it is intended that the Address Flush message apply. If an unknown or reserved nickname occurs in the list, it is ignored, but the address flush operation is still executed with the other nicknames. If an incorrect nickname occurs in the list, so that some address learning is flushed that should not have been flushed, the network will still operate correctly; however, it will be less efficient as the incorrectly flushed learning is relearned.
昵称：地址刷新消息要应用的列出的昵称。如果列表中出现未知或保留的昵称，则忽略该昵称，但地址刷新操作仍与其他昵称一起执行。如果列表中出现不正确的昵称，从而刷新了一些不应该刷新的地址学习，则网络仍将正常运行；但是，随着学习的重新学习，它的效率会降低。
K-VLBs: The number of VLAN blocks present as an unsigned integer. If this byte is zero, the message is the more general format specified in Section 2.2. If it is non-zero, it gives the number of blocks of VLANs present. Thus, in the VLAN Block address flush case, K-VLBs will be at least one.
K-VLBs：以无符号整数表示的VLAN块数。如果该字节为零，则消息为第2.2节中规定的更通用格式。如果非零，则给出存在的VLAN块数。因此，在VLAN块地址刷新情况下，K-VLB将至少是一个。
RESV: 4 reserved bits. MUST be sent as zero and ignored on receipt.
RESV:4个保留位。必须作为零发送，并在收到时忽略。
Start.VLAN, End.VLAN: These 12-bit fields give the beginning and ending VLAN IDs of a block of VLANs. The block includes both the starting and ending values; so, a block of size one is indicated by setting End.VLAN equal to Start.VLAN. If Start.VLAN is 0x000, it is treated as if it was 0x001. If End.VLAN is 0xFFF, it is treated as if it was 0xFFE. If End.VLAN is smaller than Start.VLAN, considering both as unsigned integers, that VLAN block is ignored, but the address flush operation is still executed with other VLAN blocks in the message. VLAN blocks may overlap, in which case, the address flush operation is applicable to a VLAN covered by any one or more of the blocks in the message.
Start.VLAN，End.VLAN：这12位字段给出一个VLAN块的开始和结束VLAN ID。该块包括起始值和结束值；因此，大小为1的块通过将End.VLAN设置为Start.VLAN来表示。如果Start.VLAN为0x000，则将其视为0x001。如果End.VLAN是0xFFF，则将其视为0xFFE。如果End.VLAN小于Start.VLAN，将两者视为无符号整数，则忽略该VLAN块，但仍使用消息中的其他VLAN块执行地址刷新操作。VLAN块可能重叠，在这种情况下，地址刷新操作适用于消息中任何一个或多个块覆盖的VLAN。
This message flushes all addresses in an applicable VLAN learned from egressing TRILL Data packets with an applicable nickname as ingress. To flush addresses for all VLANs, it is easy to specify a block covering all valid VLAN IDs (i.e., from 0x001 to 0xFFE).
此消息刷新从使用适用昵称作为入口的TRILL数据包中传出的适用VLAN中的所有地址。要刷新所有VLAN的地址，很容易指定覆盖所有有效VLAN ID的块（即从0x001到0xFFE）。
A more general form of the Address Flush message is provided to support flushing by FGL and more efficient encodings of VLANs and FGLs where using a set of contiguous blocks is cumbersome. It also supports optionally specifying the MAC addresses to clear. This form is extensible.
提供了一种更通用的地址刷新消息形式，以支持通过FGL进行刷新，并支持对VLAN和FGL进行更有效的编码，其中使用一组连续块很麻烦。它还支持可选地指定要清除的MAC地址。此表单是可扩展的。
The extensible case is indicated by a zero in the byte shown in Figure 2 as "K-VLBs" followed by other information encoded as TLVs.
可扩展情况由图2所示字节中的零表示为“K-VLB”，后面是编码为TLV的其他信息。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol=0x009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 |Channel Protocol=0x009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
+-+-+-+-+-+-+-+-+
| K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 1 | Nickname 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname ... | Nickname K-nicks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 3: Address Flush Message - Extensible Case
图3：地址刷新消息-可扩展案例
Channel Protocol, K-nicks, Nickname: These fields are as specified in Section 2.1.
信道协议、K-Nick、昵称：这些字段如第2.1节所述。
TLVs: If the byte immediately before the TLVs field, which is the byte labeled "K-VLBs" in Figure 2, is zero, as shown in Figure 3, the remainder of the message consists of TLVs encoded as shown in Figure 4.
TLVs：如果紧接TLVs字段之前的字节（图2中标记为“K-VLBs”的字节）为零，如图3所示，则消息的其余部分由图4所示编码的TLVs组成。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Type, Length, Value
图4：类型、长度、值
Type: The 8-bit TLV type as shown in the table below. See subsections of Section 2.2 for details on each type assigned below. If the type is reserved or not known by a receiving RBridge, that receiving RBridge ignores the value and skips to the next TLV by use of the Length byte. There is no provision for a list of VLAN ID TLVs as there are few enough of them that an arbitrary subset of VLAN IDs can be represented as a bit map.
类型：8位TLV类型，如下表所示。有关以下指定的每种类型的详细信息，请参见第2.2节的小节。如果接收RBridge保留或不知道该类型，则该接收RBridge将忽略该值，并使用长度字节跳到下一个TLV。没有提供VLAN ID TLV列表，因为它们很少，VLAN ID的任意子集可以表示为位图。
Type Description Reference
------ ------------------ -----------------
0 Reserved [RFC8383]
1 Blocks of VLANs [RFC8383]
2 Bit Map of VLANs [RFC8383]
3 Blocks of FGLs [RFC8383]
4 List of FGLs [RFC8383]
5 Bit Map of FGLs [RFC8383]
6 All Data Labels [RFC8383]
7 MAC Address List [RFC8383]
8 MAC Address Blocks [RFC8383]
9-254 Unassigned
255 Reserved [RFC8383]
Type Description Reference
------ ------------------ -----------------
0 Reserved [RFC8383]
1 Blocks of VLANs [RFC8383]
2 Bit Map of VLANs [RFC8383]
3 Blocks of FGLs [RFC8383]
4 List of FGLs [RFC8383]
5 Bit Map of FGLs [RFC8383]
6 All Data Labels [RFC8383]
7 MAC Address List [RFC8383]
8 MAC Address Blocks [RFC8383]
9-254 Unassigned
255 Reserved [RFC8383]
Length: The 8-bit unsigned integer length in bytes of the remaining information in the TLV after the Length byte. The Length MUST NOT imply that the value extends beyond the end of the RBridge Channel-Protocol-Specific Payload area. If it does, the Address Flush message is corrupt and MUST be ignored.
长度：TLV中长度字节后剩余信息的8位无符号整数长度（以字节为单位）。长度不得意味着该值超出RBridge信道协议特定有效负载区域的末端。如果是，则地址刷新消息已损坏，必须忽略。
Value: Depends on the TLV type.
值：取决于TLV类型。
In an extensible Address Flush message, when the TLVs are parsed, those TLVs having unknown types are ignored by the receiving RBridge. There may be multiple instances of TLVs with the same Type in the same Address Flush message, and TLVs are not required to be in any particular order.
在可扩展地址刷新消息中，当解析TLV时，接收RBridge将忽略那些具有未知类型的TLV。同一地址刷新消息中可能有多个具有相同类型的TLV实例，并且TLV不需要按任何特定顺序排列。
- All RBridges implementing the Address Flush RBridge Channel protocol message MUST implement types 1 and 2, the VLAN types, and Type 6, which indicates addresses are to be flushed for all Data Labels.
- 实现地址刷新RBridge通道协议消息的所有RBridge都必须实现类型1和2、VLAN类型和类型6，这表示要刷新所有数据标签的地址。
- RBridges that implement the Address Flush message and implement FGL ingress/egress MUST implement types 3, 4, and 5, the FGL types. (An RBridge that is merely FGL safe [RFC7172], but cannot egress FGL TRILL Data packets, SHOULD ignore the FGL types, as it will not learn any FGL-scoped MAC addresses from the data plane.)
- 实现地址刷新消息和FGL入口/出口的RBridge必须实现FGL类型3、4和5。（仅为FGL安全[RFC7172]，但无法退出FGL TRILL数据包的RBridge应忽略FGL类型，因为它不会从数据平面学习任何FGL范围的MAC地址。）
- RBridges that implement the Address Flush message SHOULD implement types 7 and 8 so that specific MAC addresses can be flushed. If they do not, the effect will be to flush all MAC addresses for the indicated Data Labels, which may be inefficient as any MAC addresses not intended to be flushed will have to be relearned.
- 实现地址刷新消息的RBridge应实现类型7和8，以便可以刷新特定的MAC地址。如果不这样做，其效果将是刷新指定数据标签的所有MAC地址，这可能是低效的，因为任何不打算刷新的MAC地址都必须重新学习。
The parsing of the TLVs by a receiving RBridge results in three pieces of information:
接收RBridge对TLV的解析产生三条信息：
1. a flag indicating whether one or more Type 6 TLVs (All Data Labels) were encountered;
1. 指示是否遇到一个或多个类型6 TLV（所有数据标签）的标志；
2. a set of Data Labels accumulated from VLAN and/or FGL specifying TLVs in the message; and,
2. 从VLAN和/或FGL累积的一组数据标签，用于指定消息中的TLV；和
3. if the MAC address TLV types are implemented, a set of MAC addresses accumulated from MAC-address-specifying TLVs in the message.
3. 如果实现了MAC地址TLV类型，则从消息中指定TLV的MAC地址累积的一组MAC地址。
VLANs/FGLs might be indicated more than once due to overlapping blocks or the like, and a VLAN/FGL is included in the above set of VLANs/FGLs if it occurs in any TLV in the Address Flush message. A MAC address might be indicated more than once due to overlapping blocks or the like, and a particular MAC address is included in the above set of MAC addresses if it occurs in any TLV in the Address Flush message.
由于重叠块等原因，VLAN/FGL可能被多次指示，并且如果VLAN/FGL出现在地址刷新消息中的任何TLV中，则该VLAN/FGL包括在上述VLAN/FGL集合中。由于重叠块等，MAC地址可能被多次指示，并且如果特定MAC地址出现在地址刷新消息中的任何TLV中，则其被包括在上述MAC地址集合中。
After the above information has been accumulated by parsing the TLVs, three sets are derived as described below: a set of nicknames, a set of Data Labels, and a set of MAC addresses. The address flush operation at the receiver applies to the cross product of these
在通过解析tlv累积了上述信息之后，如下所述导出三组：一组昵称、一组数据标签和一组MAC地址。接收方的地址刷新操作适用于这些数据的叉积
derived sets. That is, a { Data Label, MAC address, nickname } triple is flushed if and only if the Data Label matches an element in the derived set of Data Labels, the MAC address matches an element in the derived set of MAC address, and the nickname matches an element in the derived set of nicknames. In the case of Data Labels and MAC addresses, a special value of the set, {ALL}, is permitted, which matches all values.
派生集。也就是说，{Data Label，MAC address，昵称}三元组被刷新，当且仅当数据标签匹配派生数据标签集中的一个元素，MAC地址匹配派生MAC地址集中的一个元素，并且昵称匹配派生昵称集中的一个元素。在数据标签和MAC地址的情况下，允许集合的特殊值{ALL}，它匹配所有值。
The sets are derived as follows:
这些集合的推导如下：
Data Labels set: If the Type 6 TLV has been encountered, the set is {ALL}, else, if any Data Labels have been accumulated by processing Data Label TLVs (Types 1, 2, 3, 4, and 5), the set is those accumulated Data Labels, else, the Data Labels set is null and the Address Flush message does nothing.
数据标签集：如果遇到类型6 TLV，则该集为{ALL}，否则，如果通过处理数据标签TLV（类型1、2、3、4和5）累积了任何数据标签，则该集为这些累积的数据标签，否则，数据标签集为null，地址刷新消息不执行任何操作。
MAC Addresses set: In the receiver does not implement the MAC address types (Types 7 and 8) or it does implement those types but no MAC addresses are accumulated in parsing the TLVs, then the MAC Address set is {ALL}, else, the MAC Addresses set is the set of MAC addresses accumulated in processing the TLVs.
MAC地址集：在接收器中，不实现MAC地址类型（类型7和8），或者它实现了这些类型，但在解析TLV时没有累积MAC地址，则MAC地址集为{ALL}，否则，MAC地址集是在处理TLV时累积的MAC地址集。
Nicknames set: If the K-nicks field in the Address Flush message was zero, then the ingress nickname in the TRILL Header of the message is the sole nickname set member, else, the nicknames set members are the K-nicks nicknames listed in the Address Flush message.
昵称集：如果地址刷新消息中的K-nicks字段为零，则消息TRILL头中的ingress昵称是唯一的昵称集成员，否则，昵称集成员是地址刷新消息中列出的K-nicks昵称。
The various formats below are provided for encoding efficiency. A block of values is most efficient when there are a number of consecutive values. A bit map is most efficient if there are scattered values within a limited range. And a list of single values is most efficient if there are widely scattered values.
为了提高编码效率，提供了以下各种格式。当存在多个连续值时，值块的效率最高。如果在有限的范围内存在分散的值，则位图是最有效的。如果存在广泛分散的值，则单个值列表是最有效的。
If the TLV Type is 1, the value is a list of blocks of VLANs as follows:
如果TLV类型为1，则该值为VLAN块列表，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 1 | RESV | End.VLAN 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN 2 | RESV | End.VLAN 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN ... | RESV | End.VLAN ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of Start.VLAN and End.VLAN is as specified in Section 2.1. Length MUST be a multiple of 4. If Length is not a multiple of 4, the TLV is corrupt and the Address Flush message MUST be discarded.
Start.VLAN和End.VLAN的含义如第2.1节所述。长度必须是4的倍数。如果长度不是4的倍数，则TLV已损坏，必须丢弃地址刷新消息。
If the TLV Type is 2, the value is a bit map of VLANs as follows:
如果TLV类型为2，则该值是VLAN的位图，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RESV | Start.VLAN | Bits...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RESV | Start.VLAN | Bits...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The value portion of the TLV begins with two bytes having the 12-bit starting VLAN ID right justified (the top 4 bits are as specified in Section 2.1 RESV). This is followed by bytes with one bit per VLAN ID. The high order bit of the first byte is for VLAN N. The next-to-the-highest order bit is for VLAN N+1. The low order bit of the first byte is for VLAN N+7. The high order bit of the second byte, if there is a second byte, is for VLAN N+8, and so on. If that bit is a one, the Address Flush message applies to that VLAN. If that bit is a zero, then addresses that have been learned in that VLAN are not flushed. Note that Length MUST be at least 2. If Length is 0 or 1, the TLV is corrupt and the Address Flush message MUST be discarded. VLAN IDs do not wrap around. If there are enough bytes so that some bits correspond to VLAN ID 0xFFF or higher, those bits are ignored, but the message is still processed for bits corresponding to valid VLAN IDs.
TLV的值部分以两个字节开始，两个字节的12位起始VLAN ID右对齐（前4位如第2.1节RESV中所述）。然后是每个VLAN ID有一个位的字节。第一个字节的高阶位用于VLAN N。下一个高阶位用于VLAN N+1。第一个字节的低位用于VLAN N+7。如果有第二个字节，则第二个字节的高位用于VLAN N+8，依此类推。如果该位为1，则地址刷新消息将应用于该VLAN。如果该位为零，则不会刷新在该VLAN中读入的地址。请注意，长度必须至少为2。如果长度为0或1，则TLV已损坏，必须丢弃地址刷新消息。VLAN ID不环绕。如果有足够的字节，使得某些位对应于VLAN ID 0xFFF或更高，则忽略这些位，但仍会针对对应于有效VLAN ID的位处理消息。
If the TLV Type is 3, the value is a list of blocks of FGLs as follows:
如果TLV类型为3，则该值为FGL块列表，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End.FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV value consists of sets of Start.FGL and End.FGL numbers. The Address Flush information applies to the FGLs in that range, inclusive. A single FGL is indicated by setting both Start.FGL and End.FGL to the same value. If End.FGL is less than Start.FGL, considering them as unsigned integers, that block is ignored, but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 6; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 3.
TLV值由一组Start.FGL和End.FGL编号组成。地址刷新信息适用于该范围内的FGL，包括。通过将Start.FGL和End.FGL设置为相同的值来指示单个FGL。如果End.FGL小于Start.FGL，将其视为无符号整数，则忽略该块，但仍会对存在的任何其他块处理地址刷新消息。对于这种类型，长度必须是6的倍数；如果不是，则TLV已损坏，如果接收RBridge实现类型3，则必须丢弃地址刷新消息。
If the TLV Type is 4, the value is a list of FGLs as follows:
如果TLV类型为4，则该值为FGL列表，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV value consists of FGL numbers each in 3 bytes. The Address Flush message applies to those FGLs. For this Type, Length MUST be a multiple of 3; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 4.
TLV值由FGL编号组成，每个编号以3个字节表示。地址刷新消息适用于这些FGL。对于这种类型，长度必须是3的倍数；如果不是，则TLV已损坏，如果接收RBridge实现类型4，则必须丢弃地址刷新消息。
If the TLV Type is 5, the value is a bit map of FGLs as follows:
如果TLV类型为5，则该值为FGLs的位图，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bits...
+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start.FGL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bits...
+-+-+-+-+-+-+-+-
The TLV value consists of three bytes with the 24-bit starting FGL value N. This is followed by bytes with one bit per FGL. The high order bit of the first byte is for FGL N. The next-to-the-highest order bit is for FGL N+1. The low order bit of the first byte is for FGL N+7. The high order bit of the second byte, if there is a second byte, is for FGL N+8, and so on. If that bit is a one, the Address Flush message applies to that FGL. If that bit is a zero, then addresses that have been learned in that FGL are not flushed. Note that Length MUST be at least 3. If Length is 0, 1, or 2 for a Type 5 TLV, the TLV is corrupt and the Address Flush message MUST be discarded if Type 5 is implemented. FGLs do not wrap around. If there are enough bytes so that some bits correspond to an FGL higher than 0xFFFFFF, those bits are ignored, but the message is still processed for bits corresponding to valid FGLs.
TLV值由三个字节组成，其中24位起始FGL值为N。后面是每个FGL一位的字节。第一个字节的高阶位用于FGL N。最高阶位的下一个位用于FGL N+1。第一个字节的低位用于FGL N+7。如果有第二个字节，则第二个字节的高位用于FGL N+8，依此类推。如果该位为1，则地址刷新消息将应用于该FGL。如果该位为零，则不会刷新在该FGL中读入的地址。请注意，长度必须至少为3。如果类型5 TLV的长度为0、1或2，则TLV已损坏，如果实现类型5，则必须丢弃地址刷新消息。FGL不环绕。如果有足够的字节，因此某些位对应于高于0xFFFFFF的FGL，则这些位将被忽略，但仍会针对对应于有效FGL的位处理消息。
If the TLV Type is 6, the value is null as follows:
如果TLV类型为6，则值为空，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This type is used when an RBridge wants to withdraw all addresses for all the Data Labels (all VLANs and FGLs). Length MUST be zero. If Length is any other value, the TLV is corrupt and the Address Flush message MUST be discarded.
当RBridge希望提取所有数据标签（所有VLAN和FGL）的所有地址时，使用此类型。长度必须为零。如果长度为任何其他值，则TLV已损坏，必须丢弃地址刷新消息。
If the TLV Type is 7, the value is a list of MAC addresses as follows:
如果TLV类型为7，则该值为MAC地址列表，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV value consists of a list of 48-bit MAC addresses. Length MUST be a multiple of 6. If it is not, the TLV is corrupt, and the Address Flush message MUST be discarded if the receiving RBridge implements Type 7.
TLV值由48位MAC地址列表组成。长度必须是6的倍数。如果不是，则TLV已损坏，如果接收RBridge实现类型7，则必须丢弃地址刷新消息。
If the TLV Type is 8, the value is a list of blocks of MAC addresses as follows:
如果TLV类型为8，则该值为MAC地址块列表，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 1 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end 2 lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.start ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... upper half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC.end ... lower half |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV value consists of sets of Start.MAC and End.MAC numbers. The Address Flush information applies to the 48-bit MAC Addresses in that range, inclusive. A single MAC address is indicated by setting both Start.MAC and End.MAC to the same value. If End.MAC is less than Start.MAC, considering them as unsigned integers, that block is ignored but the Address Flush message is still processed for any other blocks present. For this Type, Length MUST be a multiple of 12; if it is not, the TLV is corrupt and the Address Flush message MUST be discarded if the receiving RBridge implements Type 7.
TLV值由一组Start.MAC和End.MAC编号组成。地址刷新信息适用于该范围内的48位MAC地址（包括在内）。通过将Start.MAC和End.MAC设置为相同的值来指示单个MAC地址。如果End.MAC小于Start.MAC，将其视为无符号整数，则忽略该块，但仍会对存在的任何其他块处理地址刷新消息。对于这种类型，长度必须是12的倍数；如果不是，则TLV已损坏，如果接收RBridge实现类型7，则必须丢弃地址刷新消息。
IANA has assigned 0x009 as the Address Flush RBridge Channel Protocol number from the range of RBridge Channel protocols allocated by Standards Action [RFC7178] [RFC8126].
IANA已从标准行动[RFC7178][RFC8126]分配的RBridge通道协议范围中分配0x009作为地址刷新RBridge通道协议号。
The added entry to the "RBridge Channel Protocols" registry at <https://www.iana.org/assignments/trill-parameters/> is as follows:
在“RBridge通道协议”注册表中添加的条目<https://www.iana.org/assignments/trill-parameters/>详情如下:
Protocol Description Reference
-------- -------------- ------------------
0x009 Address Flush [RFC8383]
Protocol Description Reference
-------- -------------- ------------------
0x009 Address Flush [RFC8383]
IANA has created the "TRILL Address Flush TLV Types" registry at <https://www.iana.org/assignments/trill-parameters/> as a subregistry of the "RBridge Channel Protocols" registry. Registry headers are as below. The initial entries are as in the table in Section 2.2.
IANA已在以下位置创建了“TRILL地址刷新TLV类型”注册表：<https://www.iana.org/assignments/trill-parameters/>作为“RBridge Channel Protocols”注册中心的子区。注册表头如下所示。初始条目如第2.2节中的表格所示。
Registry: TRILL Address Flush TLV Types Registration Procedures: IETF Review Reference: [RFC8383]
注册表：TRILL地址刷新TLV类型注册程序：IETF审查参考：[RFC8383]
The Address Flush RBridge Channel Protocol itself provides no security assurances or features. However, Address Flush protocol messages can be secured by use of the RBridge Channel Header Extension [RFC7978]. It is RECOMMENDED that all RBridges that implement the Address Flush message be configured to ignore such messages unless they have been secured with an RBridge Channel Header Extension that meets local security policy.
地址刷新RBridge通道协议本身不提供安全保证或功能。然而，地址刷新协议消息可以通过使用RBridge通道头扩展[RFC7978]来保护。建议将所有实现地址刷新消息的RBridge配置为忽略此类消息，除非它们已使用满足本地安全策略的RBridge通道头扩展进行了安全保护。
If RBridges receiving Address Flush messages do not require them to be at least authenticated, they are relatively easy to forge. In that case, such forged Address Flush messages can reduce network efficiency, by purging useful learned information that will have to be relearned. This provides a denial-of-service attack, but cannot cause incorrect operation in the sense that it cannot cause a frame to be improperly delivered.
如果接收地址刷新消息的RBridge不要求它们至少经过身份验证，则它们相对容易伪造。在这种情况下，这种伪造地址刷新消息可以通过清除需要重新学习的有用信息来降低网络效率。这提供了拒绝服务攻击，但不会导致不正确的操作，因为它不会导致不正确地传递帧。
See [RFC7178] for general RBridge Channel Security Considerations.
请参阅[RFC7178]了解一般RBridge通道安全注意事项。
See [RFC6325] for general TRILL Security Considerations.
参见[RFC6325]了解一般TRILL安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325]Perlman，R.，Eastlake 3rd，D.，Dutt，D.，Gai，S.，和A.Ghanwani，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<https://www.rfc-editor.org/info/rfc6325>.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <https://www.rfc-editor.org/info/rfc7172>.
[RFC7172]Eastlake 3rd，D.，Zhang，M.，Agarwal，P.，Perlman，R.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，RFC 7172，DOI 10.17487/RFC7172，2014年5月<https://www.rfc-editor.org/info/rfc7172>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc7178>.
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.
[RFC7780]Eastlake 3rd，D.，Zhang，M.，Perlman，R.，Banerjee，A.，Ghanwani，A.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年2月<https://www.rfc-editor.org/info/rfc7780>.
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <https://www.rfc-editor.org/info/rfc7978>.
[RFC7978]Eastlake 3rd，D.，Umair，M.，和Y.Li，“大量链路的透明互连（TRILL）：RBridge信道头扩展”，RFC 7978，DOI 10.17487/RFC7978，2016年9月<https://www.rfc-editor.org/info/rfc7978>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<https://www.rfc-editor.org/info/rfc4762>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgements
致谢
The following are thanked for their contributions:
感谢以下各方的贡献：
Ramkumar Parameswaran, Henning Rogge
拉姆库马尔·帕拉米斯瓦兰，亨宁·罗格
Authors' Addresses
作者地址
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
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-56624629
Email: liyizhou@huawei.com
Phone: +86-25-56624629
Email: liyizhou@huawei.com
Mohammed Umair Cisco Cessna Business Park, Kadubeesanahalli Village, Hobli, Sarjapur, Varthur Main Road, Marathahalli, Bengaluru, Karnataka 560087 India
Mohammed Umair Cisco Cessna商业园，印度卡纳塔克邦班加卢马拉塔哈利Varthur大道Sarjapur Hobli Kadubeesanahalli村，邮编560087
Email: mohammed.umair2@gmail.com
Email: mohammed.umair2@gmail.com