[要約] RFC 8383は、TRILLネットワークでのアドレスフラッシュメッセージの仕様を定義しています。このRFCの目的は、ネットワーク内の不要なアドレス情報を削除し、ネットワークの効率性とセキュリティを向上させることです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]).
デフォルトでは、エッジ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には、そのような学習をタイムアウトし、一部のネットワーク接続と構成の変更に基づいて適切にそれをクリアするメカニズムがあります。ただし、より迅速な収束を達成するために、リモートRBridgeで特定のエンドステーションの到達可能性情報をTRILLスイッチが明示的にフラッシュ（パージ）できると便利な状況があります。 [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の1つのスパニングツリープロトコル（STP）ツリールートのように構成することを推奨しています。このドキュメントのアドレスフラッシュメッセージは、エッジRBridgeの1つがトポロジ変更（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スイッチは、ローカルで学習した必要なアドレスを簡単にフラッシュできます。このドキュメントは、TRILLデータパケットのカプセル化解除から学習した特定のVLANまたはFGL（[RFC7172]）のフラッシュアドレス情報を要求するRBridge Channel Support protocol [RFC7178]メッセージを指定します。
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.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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
エッジTRILLスイッチ：端末サービスを提供する1つ以上のリンクに接続されたTRILLスイッチ
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：キャンパス内のすべてのTRILLスイッチが関心を示すVLAN。これにより、RBridgeチャネルプロトコルメッセージ[RFC7178]を含む、そのVLANをInner.VLANとして送信される複数の宛先のTRILLデータパケットが、すべてのTRILLスイッチに配信されます。キャンパス。通常、管理VLANではエンドステーションサービスは提供されません。
MAC: Media Access Control
MAC：メディアアクセスコントロール
RBridge: An alternative name for a TRILL switch
RBridge：TRILLスイッチの別名
STP: Spanning Tree Protocol
STP：スパニングツリープロトコル
TC: Topology Change message
TC：トポロジ変更メッセージ
TCN: Topology Change Notification message
TCN：トポロジ変更通知メッセージ
TRILL switch: A device implementing the TRILL protocol [RFC6325] [RFC7780]
TRILLスイッチ：TRILLプロトコルを実装するデバイス[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チャネルヘッダーのプロトコルフィールドは、RBridgeチャネルパケットのタイプを示し、チャネルプロトコル固有のペイロードの解釈方法を示します[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) |
+-----------------------------------+
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.
デフォルトでは、アドレスフラッシュ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.
- 1つの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.
- アドレスフラッシュメッセージペイロードで指定されたVLANまたはFGLの1つとして構成された少なくとも1つのアクセスポートを持つRBridgeに、アドレスフラッシュメッセージを選択的に送信できます。
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].
図2は、VLANのみに基づくアドレスフラッシュメッセージの場合について、図1のRBridgeチャネルヘッダーとチャネルプロトコル固有のペイロードを展開しています。この形式のアドレスフラッシュメッセージは、ニックネームとVLANのブロックに基づいてMACアドレスをフラッシュするために最適化されています。 0x8946は、RBridge Channelプロトコル[RFC7178]のためにIEEEによって割り当てられたEthertypeです。
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ニックネーム：符号なし整数としてリストされているニックネームの数。これがゼロの場合、TRILLヘッダー[RFC6325]の入力ニックネームは、メッセージが適用される唯一のニックネームであると見なされます。ゼロ以外の場合は、メッセージが適用されるKニックの直後にリストされているニックネームの数が表示されます。このゼロ以外の場合、フラッシュは、リストされていない限り、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-VLB：符号なし整数として存在するVLANブロックの数。このバイトがゼロの場合、メッセージはセクション2.2で指定されているより一般的な形式です。ゼロ以外の場合は、存在するVLANのブロック数を示します。したがって、VLANブロックアドレスフラッシュの場合、K-VLBは少なくとも1つになります。
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ブロックは重複する場合があります。その場合、アドレスフラッシュ操作は、メッセージ内の1つ以上のブロックでカバーされる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.
拡張可能なケースは、「K-VLBs」として図2に示されているバイトのゼロで示され、その後に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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 3: Address Flush Message - Extensible Case
図3：アドレスフラッシュメッセージ-拡張可能なケース
Channel Protocol, K-nicks, Nickname: These fields are as specified in Section 2.1.
Channel Protocol、K-nicks、ニックネーム：これらのフィールドはセクション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.
TLV：図2で「K-VLB」とラベル付けされたバイトであるTLVフィールドの直前のバイトがゼロの場合、図3に示すように、メッセージの残りの部分は、図4に示すようにエンコードされたTLVで構成されます。
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]
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が解析されるときに、不明なタイプのTLVが受信RBridgeによって無視されます。同じアドレスフラッシュメッセージに同じタイプの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は、タイプ3、4、および5、FGLタイプを実装する必要があります。 （単にFGL安全[RFC7172]であるが、FGL TRILLデータパケットを出力できないRBridgeは、データプレーンからFGLスコープのMACアドレスを学習しないため、FGLタイプを無視する必要があります。）
- 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.
- 特定のMACアドレスをフラッシュできるように、アドレスフラッシュメッセージを実装するRBridgeはタイプ7および8を実装する必要があります（SHOULD）。そうでない場合、示されたデータラベルのすべてのMACアドレスをフラッシュすることになります。フラッシュすることを意図していないMACアドレスを再学習する必要があるため、非効率になる可能性があります。
The parsing of the TLVs by a receiving RBridge results in three pieces of information:
受信RBridgeによるTLVの解析により、3つの情報が得られます。
1. a flag indicating whether one or more Type 6 TLVs (All Data Labels) were encountered;
1. 1つ以上のタイプ6 TLV（すべてのデータラベル）が検出されたかどうかを示すフラグ。
2. a set of Data Labels accumulated from VLAN and/or FGL specifying TLVs in the message; and,
2. メッセージ内のTLVを指定するVLANまたはFGL、あるいはその両方から蓄積されたデータラベルのセット。そして、
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タイプが実装されている場合、メッセージ内のMACアドレス指定TLVから累積された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セットに含まれます。ブロックのオーバーラップなどにより、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 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.
TLVの解析によって上記の情報が蓄積された後、ニックネームのセット、データラベルのセット、およびMACアドレスのセットの3つのセットが導出されます。レシーバーでのアドレスフラッシュ操作は、これらの派生セットのクロス積に適用されます。つまり、{データラベル、MACアドレス、ニックネーム}のトリプルは、データラベルがデータラベルの派生セットの要素と一致し、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-ニックスフィールドがゼロの場合、メッセージのTRILLヘッダーの入力ニックネームは、唯一のニックネームセットメンバーです。それ以外の場合、ニックネームセットメンバーは、アドレスフラッシュメッセージ。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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が右揃えされた2バイトで始まります（上位4ビットはセクション2.1 RESVで指定されているとおりです）。この後に、VLAN IDごとに1ビットのバイトが続きます。最初のバイトの上位ビットはVLAN N用です。次に上位のビットはVLAN N + 1用です。最初のバイトの下位ビットはVLAN N + 7用です。 2番目のバイトの上位ビットは、2番目のバイトがある場合、VLAN N + 8に対応し、以下同様です。そのビットが1の場合、アドレスフラッシュメッセージはそのVLANに適用されます。そのビットがゼロの場合、そのVLANで学習されたアドレスはフラッシュされません。 Lengthは少なくとも2でなければならないことに注意してください。Lengthが0または1の場合、TLVは破損しており、Address Flushメッセージは破棄する必要があります。 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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値は、それぞれ3バイトのFGL番号で構成されます。 Address Flushメッセージは、それらのFGLに適用されます。このタイプの場合、長さは3の倍数でなければなりません。そうでない場合、TLVは破損しており、受信RBridgeがタイプ4を実装している場合は、アドレスフラッシュメッセージを破棄する必要があります。
If the TLV Type is 5, the value is a bit map of FGLs as follows:
TLVタイプが5の場合、値は次のようなFGLのビットマップです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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を持つ3バイトで構成されます。この後に、FGLごとに1ビットのバイトが続きます。最初のバイトの高位ビットは、FGL N用です。次に上位のビットは、FGL N + 1用です。最初のバイトの下位ビットは、FGL N + 7用です。 2番目のバイトの上位ビットは、2番目のバイトがある場合、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の場合、値は次のようにnullです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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）のすべてのアドレスを取り消す場合に使用されます。長さはゼロでなければなりません。 Lengthが他の値の場合、TLVは破損しており、Address Flushメッセージを破棄する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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よりも小さい場合、それらを符号なし整数と見なして、そのブロックは無視されますが、Address Flushメッセージは、存在する他のブロックに対して引き続き処理されます。このタイプの場合、長さは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チャネルプロトコルの範囲から、アドレスフラッシュRBridgeチャネルプロトコル番号として0x009を割り当てました。
The added entry to the "RBridge Channel Protocols" registry at <https://www.iana.org/assignments/trill-parameters/> is as follows:
<https://www.iana.org/assignments/trill-parameters/>の「RBridge Channel Protocols」レジストリに追加されたエントリは次のとおりです。
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は、「https://www.iana.org/assignments/trill-parameters/>に「RBILL Channel Protocols」レジストリのサブレジストリとして「TRILL Address Flush TLV Types」レジストリを作成しました。レジストリヘッダーは次のとおりです。最初のエントリは、セクション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.
Address Flush RBridge Channel Protocol自体は、セキュリティの保証や機能を提供しません。ただし、アドレスフラッシュプロトコルメッセージは、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.
RBridgeチャネルのセキュリティに関する一般的な考慮事項については、[RFC7178]を参照してください。
See [RFC6325] for general TRILL Security Considerations.
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
[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、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<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.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、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.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、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.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年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.、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>。
[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]ラッセール、M。、エド。およびV. Kompella編、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（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]コットン、M。、レイバ、B。、およびT.ナルテン、「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
Ramkumar Parmeshwaran、Henring Rogge
Authors' Addresses
著者のアドレス
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
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 Chase's Business Park、Kadubisanahalli Village、Hobali、Sarjapur、Vartur Main Road、Marathahalli、バンガロール、カルナータカ州೫೬೦೦೮೭インド
Email: mohammed.umair2@gmail.com