[要約] RFC 9183は、多層透過的なリンクの大量相互接続(TRILL)におけるエリアボーダーRBridgeのための単一ニックネームを定義します。この文書の目的は、TRILLネットワーク内でのルーティングの簡素化と効率化を図ることです。主に、大規模なTRILLネットワークの管理を容易にするために利用されます。
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 9183 Independent
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Futurewei
R. Perlman
EMC
M. Cullen
Painless Security
H. Zhai
JIT
February 2022
Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL)
地域のシングルニックネーム（TRILL）の多値透明な相互接続の距離rbridge
Abstract
概要
A major issue in multilevel TRILL is how to manage RBridge nicknames. In this document, area border RBridges use a single nickname in both Level 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames.
Multilevel Triillの主な問題は、RBridgeニックネームを管理する方法です。このドキュメントでは、エリア境界Rbridgesはレベル1とレベル2の両方で単一のニックネームを使用します。レベル2のRbridgesは固有のニックネームを取得する必要がありますが、異なるレベル1の領域のRbridgesは同じニックネームを持つことがあります。
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/rfc9183.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9183で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Acronyms and Terminology
3. Nickname Handling on Border RBridges
3.1. Actions on Unicast Packets
3.2. Actions on Multi-destination Packets
4. Per-Flow Load Balancing
4.1. L2-to-L1 Ingress Nickname Replacement
4.2. L1-to-L2 Egress Nickname Replacement
5. Protocol Extensions for Discovery
5.1. Discovery of Border RBridges in L1
5.2. Discovery of Border RBridge Sets in L2
6. One Border RBridge Connects Multiple Areas
7. E-L1FS/E-L2FS Backwards Compatibility
8. Manageability Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Appendix A. Level Transition Clarification
Authors' Addresses
TRILL (Transparent Interconnection of Lots of Links) [RFC6325] [RFC7780] multilevel techniques are designed to improve TRILL scalability issues.
TRILL（LOTSのロットの透明相互接続）[RFC6325] [RFC7780]マルチレベルのテクニックは、トリルのスケーラビリティの問題を改善するように設計されています。
"Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)" [RFC8243] is an educational document to explain multilevel TRILL and list possible concerns. It does not specify a protocol. As described in [RFC8243], there have been two proposed approaches. One approach, which is referred to as the "unique nickname" approach, gives unique nicknames to all the TRILL switches in the multilevel campus either by having the Level 1/Level 2 border TRILL switches advertise which nicknames are not available for assignment in the area or by partitioning the 16-bit nickname into an "area" field and a "nickname inside the area" field. [RFC8397] is the Standards Track document specifying a "unique nickname" flavor of TRILL multilevel. The other approach, which is referred to in [RFC8243] as the "aggregated nickname" approach, involves assigning nicknames to the areas, and allowing nicknames to be reused inside different areas, by having the border TRILL switches rewrite the nickname fields when entering or leaving an area. [RFC8243] makes the case that, while unique nickname multilevel solutions are simpler, aggregated nickname solutions scale better.
「LOTSの多くのリンク（TRILL）のマルチレベルの透明な相互接続の代替案は、MultileVel Trillを説明するための教育文書であり、可能な懸念をリストします。プロトコルを指定しません。 [RFC8243]に記載されているように、2つの提案されたアプローチがありました。 「独自のニックネーム」アプローチと呼ばれる1つのアプローチは、レベル1 /レベル2のボーダートライススイッチがエリア内の割り当てのために利用できないことを宣伝することによって、マルチレベルキャンパス内のすべてのトリルスイッチに固有のニックネームを与える。または、16ビットニックネームを「エリア」フィールドに分割することで、「エリア内のニックネーム」フィールドに。 [RFC8397]は、TRIL MULTILEVELの「固有のニックネーム」フレーバーを指定する標準トラック文書です。 「集約ニックネーム」アプローチとして[RFC8243]で参照されているもう1つのアプローチは、エリアにニックネームを割り当て、そして境界トライスイッチが入るときにニックネームフィールドを書き換えることによって、異なる領域内でニックネームの内側のニックネームを再利用することを可能にする。地域を残す。 [RFC8243]ユニークなニックネームマルチレベルソリューションがより単純で、集約されたニックネーム解のスケールがより良くなる場合があります。
The approach specified in this Standards Track document is somewhat similar to the "aggregated nickname" approach in [RFC8243] but with a very important difference. In this document, the nickname of an area border RBridge is used in both Level 1 (L1) and Level 2 (L2). No additional nicknames are assigned to represent L1 areas as such. Instead, multiple border RBridges are allowed and each L1 area is denoted by the set of all nicknames of those border RBridges of the area. For this approach, nicknames in the L2 area MUST be unique but nicknames inside an L1 area can be reused in other L1 areas that also use this approach. The use of the approach specified in this document in one L1 area does not prohibit the use of other approaches in other L1 areas in the same TRILL campus, for example the use of the unique nickname approach specified in [RFC8397]. The TRILL packet format is unchanged by this document, but data plane processing is changed at Border RBridges and efficient high volume data flow at Border RBridges might require forwarding hardware change.
この標準トラック文書で指定されたアプローチは、[RFC8243]の「集約ニックネーム」アプローチとは多少似ていますが、非常に重要な違いがあります。この文書では、エリア境界rbridgeのニックネームは、レベル1（L1）とレベル2（L2）の両方で使用されます。そのようなL1領域を表すために追加のニックネームは割り当てられていません。代わりに、複数の境界rbridgesが許可され、各L1領域は、領域のそれらの境界rbriggesのすべてのニックネームの集合によって示されます。このアプローチでは、L2エリア内のニックネームは固有である必要がありますが、L1エリア内のニックネームは、このアプローチも使用する他のL1エリアで再利用できます。この文書で指定されたアプローチを1つのL1エリアで使用すると、同じトリルキャンパス内の他のL1領域の他のアプローチの使用、たとえば[RFC8397]で指定された固有のニックネームアプローチの使用は禁止されていません。 TRILLパケットフォーマットはこの文書によって変更されていませんが、境界Rbridgesでデータプレーン処理が変更され、境界RBridgesでの効率的な大量のデータフローがハードウェアの変更を転送する必要があります。
Area Border RBridge: A border RBridge between a Level 1 area and Level 2.
エリアボーダーRブリッジ：レベル1の領域とレベル2の間の境界rbridge。
Data Label: VLAN or Fine-Grained Label (FGL).
データラベル：VLANまたは微細粒ラベル（FGL）。
DBRB: Designated Border RBridge.
DBRB：境界rbridgeを指定しました。
IS-IS: Intermediate System to Intermediate System [IS-IS].
IS-IS：中間システムへの中間システム[IS-IS]。
Level: Similar to IS-IS, TRILL has Level 1 for intra-area and Level 2 for inter-area. Routing information is exchanged between Level 1 RBridges within the same Level 1 area, and Level 2 RBridges can only form relationships and exchange information with other Level 2 RBridges.
レベル：IS-ISと同様に、TRILLは面積内にレベル1と、面積間のレベル2になります。ルーティング情報は、同じレベル1の領域内のレベル1のRBridgesとの間で交換され、レベル2のRBridgesは関係を形成し、他のレベル2のRBRidgesとの関係を見つけることしかできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [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" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Familiarity with [RFC6325] is assumed in this document.
この文書では、[RFC6325]に精通しています。
This section provides an illustrative example and description of the border learning border RBridge nicknames.
このセクションでは、境界学習ボーダーRbridgeニックネームの例示的な例と説明を提供します。
Area {2,20} Level 2 Area {3,30}
+-------------------+ +-----------------+ +--------------+
| | | | | |
| S--RB27---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB44---D |
| 27 | | 39 | | 44 |
| ----RB20--- ----RB30--- |
+-------------------+ +-----------------+ +--------------+
Figure 1: An Example Topology for TRILL Multilevel
図1：Trill Multilevelのトポロジの例
In Figure 1, RB2, RB20, RB3, and RB30 are area border TRILL switches (RBridges). Their nicknames are 2, 20, 3, and 30, respectively, and are used as TRILL switch identifiers in their areas [RFC6325]. Area border RBridges use the set of border nicknames to denote the L1 area that they are attached to. For example, RB2 and RB20 use nicknames {2,20} to denote the L1 area on the left.
図1では、RB2、RB20、RB3、およびRB30は、エリア境界トライススイッチ（RBRIDGES）です。それらのニックネームはそれぞれ2,20,3、および30であり、そしてそれらの分野でのトリルスイッチ識別子として使用されます[RFC6325]。エリア境界Rbridges境界線ニックネームのセットを使用して、接続されているL1領域を表します。たとえば、RB2とRB20はニックネーム{2,20}を使用して左側のL1領域を表します。
A source S is attached to RB27 and a destination D is attached to RB44. RB27 has a nickname (say, 27), and RB44 has a nickname (say, 44). (In fact, they could even have the same nickname, since the TRILL switch nickname will not be visible outside these Level 1 areas.)
ソースSがRB27に接続され、宛先DがRB44に接続されている。RB27はニックネーム（例えば、27）を有し、RB44はニックネーム（例えば44）を有する。（実際には、Trillスイッチのニックネームがこれらのレベル1の領域の外側に見えないので、それらは同じニックネームを持つことさえできます。）
Let's say that S transmits a frame to destination D and let's say that D's location has been learned by the relevant TRILL switches already. These relevant switches have learned the following:
Sを宛先Dにフレームを送信し、すでに関連するトリルスイッチによってD'Sの場所が学ばれているとしましょう。これらの関連するスイッチは次のことを学びました：
1) RB27 has learned that D is connected to nickname 3.
1) RB27は、Dがニックネーム3に接続されていることを学びました。
2) RB3 has learned that D is attached to nickname 44.
2) RB3は、Dがニックネーム44に取り付けられていることを学びました。
The following sequence of events will occur:
次の一連のイベントが発生します。
1. S transmits an Ethernet frame with source MAC = S and destination MAC = D.
1. ■ソースMAC = Sおよび宛先MAC = Dを使用してイーサネットフレームを送信します。
2. RB27 encapsulates with a TRILL header with ingress RBridge = 27 and egress RBridge = 3 producing a TRILL Data packet.
2. RB27は、入口RBRIDGE = 27でトライヘッダをカプセル化し、出力RBRIDGE = 3の出力RBRIDGE = 3をカプセル化します。
3. RB2 and RB20 have announced in the Level 1 IS-IS area designated {2,20} that they are attached to the nicknames of all the border RBridges in the Level 2 area including RB3 and RB30. Therefore, IS-IS routes the packet to RB2 (or RB20, if RB20 is on the least-cost route from RB27 to RB3).
3. RB2とRB20はレベル1で発表されています。これは、RB3とRB30を含むレベル2領域のすべての境界RBRIDGESのニックネームに添付されている{2,20}と指定されています。したがって、IS-ISは、パケットをRB2（RB20がRB27からRB3への最小コスト経路上にある場合）に、パケットをRB2（またはRB20）にルーティングします。
4. RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 2, and the egress RBridge field will be 3. (The egress nickname MAY be replaced with any area nickname selected from {3,30} such as 30. See Section 4 for the detail of the selection method. Here, suppose the egress nickname remains 3.) Also, RB2 learns that S is attached to nickname 27 in area {2,20} to accommodate return traffic. RB2 SHOULD synchronize with RB20 using the End Station Address Distribution Information (ESADI) protocol [RFC7357] that MAC = S is attached to nickname 27.
4. RB2は、レベル1からレベル2へのパケットを遷移させるときに、Ingress Trillスイッチのニックネームをそれ自身のニックネームに置き換え、27を2に置き換えます.2 2では、Trillヘッダー内の入口RBRIDGERフィールドは2、および出力Rbridgeフィールドは3になります（出力ニックネームは、30などの{3,30}から選択された任意の領域のニックネームに置き換えられます。RB2は、戻りトラフィックに対応するために、地域{2,20}のニックネーム27に接続されていることを学びます。RB2は、MAC = Sがニックネーム27に接続されているエンドステーションアドレス配布情報（RFC7357]を使用してRB20と同期している必要があります。
5. The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, its L2 nickname as 3.
5. パケットはレベル2を介して転送され、これは広告されているRB3、レベル2で、そのL2 NickNameは3。
6. RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with RB44's nickname (44) based on looking up D. (The ingress nickname MAY be replaced with any area nickname selected from {2,20}. See Section 4 for the detail of the selection method. Here, suppose the ingress nickname remains 2.) So, within the destination area, the ingress nickname will be 2 and the egress nickname will be 44.
6. RB3は、領域{3,30}に転送するとき、DRILLヘッダの出力ニックネームをRB44のニックネーム（44）に基づいてTrillヘッダに置き換えます（Ingress NickNameは{2,20}から選択されたエリアのニックネームに置き換えることができます。。選択方法の詳細についてはセクション4を参照してください。ここでは、入口ニックネームが2のままであるとします。そこで、宛先エリア内で、入力ニックネームは2となり、出力ニックネームは44になります。
7. RB44, when decapsulating, learns that S is attached to nickname 2, which is one of the area nicknames of the ingress.
7. RB44は、カプセル化すると、Sがニックネーム2に接続されていることを学びます。これは、入力のエリアのニックネームの1つです。
Distribution trees for flooding of multi-destination packets are calculated separately within each L1 area and in L2. When a multi-destination packet arrives at the border, it needs to be transitioned either from L1 to L2, or from L2 to L1. All border RBridges are eligible for Level transition. However, for each multi-destination packet, only one of them acts as the Designated Border RBridge (DBRB) to do the transition while other non-DBRBs MUST drop the received copies. By default, the border RBridge with the smallest nickname, considered as an unsigned integer, is elected DBRB. All border RBridges of an area MUST agree on the mechanism used to determine the DBRB locally. The use of an alternative is possible, but out of the scope of this document; one such mechanism is used in Section 4 for load balancing.
マルチ宛先パケットのフラッディングのための分布ツリーは、各L1領域内およびL2内で別々に計算されます。マルチ宛先パケットが境界に到着すると、L1からL2、またはL2からL1のいずれかのどちらかに移行する必要があります。すべての境界rbridgesは、レベル遷移の対象となります。ただし、各マルチデスティネーションパケットごとに、他の非DBRBが受信コピーを削除しなければならない間に、それらのうちの1つだけが遷移を行うために指定された境界RBRIDGE（DBRB）として機能します。デフォルトでは、符号なし整数と見なされる、最小のニックネームを持つ境界rbridgeがDBRBに選出されます。地域の全境界rbriggesは、DBRBをローカルに決定するために使用されるメカニズムについて一致しなければなりません。代替案の使用は可能ですが、この文書の範囲外です。そのようなメカニズムの1つは、ロードバランシングのためにセクション4で使用されています。
As per [RFC6325], multi-destination packets can be classified into three types: unicast packets with unknown destination MAC addresses (unknown-unicast packets), multicast packets, and broadcast packets. Now suppose that D's location has not been learned by RB27 or the frame received by RB27 is recognized as broadcast or multicast. What will happen within a Level 1 area (as it would in TRILL today) is that RB27 will forward the packet as multi-destination, setting its M bit to 1 and choosing an L1 tree, which would flood the packet on that distribution tree (subject to potential pruning).
[RFC6325]によると、マルチ宛先パケットは、宛先MACアドレスが不明なUnicast Packets（Unknown-Unicast Packets）、マルチキャストパケット、およびブロードキャストパケットに分類できます。ここで、Dの位置がRB27によって学習されていないか、RB27によって受信されたフレームがブロードキャストまたはマルチキャストとして認識されるとします。レベル1の領域内で発生するのは、（今日のトイロのトイロのように）RB27がマルチ宛先としてパケットを転送し、そのマイビットを1に設定し、その配信ツリーにパケットをフラッディングするL1ツリーを選択することです。潜在的な剪定を受ける）。
When the copies of the multi-destination packet arrive at area border RBridges, non-DBRBs MUST drop the packet while the DBRB (say, RB2) needs to do the Level transition for the multi-destination packet. For an unknown-unicast packet, if the DBRB has learned the destination MAC address, it SHOULD convert the packet to unicast and set its M bit to 0. Otherwise, the multi-destination packet will continue to be flooded as a multicast packet on the distribution tree. The DBRB chooses the new distribution tree by replacing the egress nickname with the new tree root RBridge nickname from the area the packet is entering. The following sequence of events will occur:
マルチデスティネーションパケットのコピーが領域境界Rbridgesに到着すると、DBRB（SAI）がマルチ宛先パケットのレベル遷移を行う必要がある間、非DBRBはパケットをドロップする必要があります。Unknown-Unicastパケットの場合、DBRBが宛先MACアドレスを学習した場合は、パケットをユニキャストに変換してMビットを0に設定する必要があります。そうしないと、マルチ宛先パケットはマルチキャストパケットとしてフラッディングされます。流通ツリーDBRBは、パケットが入っている領域から新しいツリーRBridgeニックネームとの出力ニックネームを新しいツリーrbridgeニックネームに置き換えることで、新しい配布ツリーを選択します。次の一連のイベントが発生します。
1. RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with its own nickname, replacing 27 with 2. RB2 also MUST replace the egress RBridge nickname with an L2 tree root RBridge nickname (say, 39). In order to accommodate return traffic, RB2 records that S is attached to nickname 27 and SHOULD use the ESADI protocol [RFC7357] to synchronize this attachment information with other border RBridges (say, RB20) in the area.
1. RB2は、レベル1からレベル2へのパケットを遷移させるときに、Ingress Trillスイッチのニックネームを自らのニックネームに置き換え、27を2に置き換えます.22は、RBRIDG NIGNNAMEをL2ツリールートRBRIDG NIGHNAME（39）に置き換える必要があります。戻りトラフィックに対応するために、RB2はNICNNAME 27に接続されており、この添付ファイル情報をエリア内の他の境界RBRIDGES（RB20）と同期するようにESADIプロトコル[RFC7357]を使用する必要があります。
2. RB20 will receive the packet flooded on the L2 tree by RB2. It is important that RB20 does not transition this packet back to L1 as it does for a multicast packet normally received from another remote L1 area. RB20 should examine the ingress nickname of this packet. If this nickname is found to be a border RBridge nickname of the area {2,20}, RB2 must not forward the packet into this area.
2. RB20は、RB2によってL2ツリーにあふれたパケットを受け取ります。RB20は、他のリモートL1領域から通常受信されたマルチキャストパケットの場合、RB20がL1にこのパケットをL1に遷移させないことが重要です。RB20はこのパケットの入口ニックネームを調べる必要があります。このニックネームが境界{2,20}の境界rbridgeニックネームであることが判明した場合、RB2はパケットをこの領域に転送してはいけません。
3. The multi-destination packet is flooded on the Level 2 tree to reach all border routers for all L1 areas including both RB3 and RB30. Suppose RB3 is the selected DBRB. The non-DBRB RB30 will drop the packet.
3. マルチ宛先パケットは、RB3とRB30の両方を含むすべてのL1領域のすべての境界ルータに到達するために、レベル2ツリーにあふれています。RB3が選択されたDBRBであるとする。非DBRB RB30はパケットを削除します。
4. RB3, when forwarding into area {3,30}, replaces the egress nickname in the TRILL header with the root RBridge nickname of a distribution tree of L1 area {3,30} -- say, 30. (Here, the ingress nickname MAY be replaced with a different area nickname selected from {2,20}, the set of border RBridges to the ingress area, as specified in Section 4.) Now suppose that RB27 has learned the location of D (attached to nickname 3), but RB3 does not know where D is because this information has fallen out of cache or RB3 has restarted or some other reason. In that case, RB3 must turn the packet into a multi-destination packet and then floods it on a distribution tree in the L1 area {3,30}.
4. RB3は、領域{3,30}に転送するとき、Trillヘッダの出口ニックネームをL1領域{3,30} - SAY、30の配電ツリーのルートRBridgeニックネームに置き換えます。（ここでは、入力ニックネームMayセクション4で規定されているように、{2,20}から選択された異なる領域のニックネームに置き換えられた境界線Rbrigesのセットは、RB27がD（ニックネーム3に接続されている）の場所を学習したとします。RB3は、この情報がキャッシュから落ちた、またはRB3が再起動したのか、またはその他の理由があるため、Dがどこにあるのかわかりません。その場合、RB3はパケットをマルチ宛先パケットに回してから、L1領域{3,30}の配信ツリーにフラッドを格納しなければなりません。
5. RB30 will receive the packet flooded on the L1 tree by RB3. It is important that RB30 does not transition this packet back to L2. RB30 should also examine the ingress nickname of this packet. If this nickname is found to be an L2 Border RBridge Nickname, RB30 must not transition the packet back to L2.
5. RB30は、RB3によってL1ツリーにあふれたパケットを受け取ります。RB30がこのパケットをL2に遷移させないことが重要です。RB30はこのパケットの入口ニックネームも調べる必要があります。このニックネームがL2境界Rbridgeニックネームであることが判明した場合、RB30はパケットをL2に遷移させてはなりません。
6. The multicast listener RB44, when decapsulating the received packet, learns that S is attached to nickname 2, which is one of the area nicknames of the ingress.
6. 受信したパケットをカプセル化するときのマルチキャストリスナRB44は、Sがニックネーム2に接続されていることを学習し、これは入力の領域のニックネームの1つである。
See also Appendix A.
付録Aも参照
Area border RBridges perform ingress/egress nickname replacement when they transition TRILL Data packets between Level 1 and Level 2. The egress nickname will again be replaced when the packet transitions from Level 2 to Level 1. This nickname replacement enables the per-flow load balance, which is specified in the following subsections. The mechanism specified in Section 4.1 or that in Section 4.2 or both is necessary in general to load-balance traffic across L2 paths.
エリア境界RBridgesは、レベル1とレベル2の間でトライトデータパケットを移行すると、入力/出力ニックネームの置き換えが実行されます。出力ニックネームは、パケットがレベル2からレベル1に遷移するときに再び置き換えられます。このニックネームの置き換えはフロー負荷残高を有効にします。以下のサブセクションでは指定されています。セクション4.1で指定されたメカニズムまたはセクション4.2またはその両方で、L2パス全体でトラフィックをロードバランスすることが必要です。
When a TRILL Data packet from other L1 areas arrives at an area border RBridge, this RBridge MAY select one area nickname of the ingress area to replace the ingress nickname of the packet so that the returning TRILL Data packet can be forwarded to this selected nickname to help load-balance return unicast traffic over multiple paths. The selection is simply based on a pseudorandom algorithm as discussed in Section 5.3 of [RFC7357]. With the random ingress nickname replacement, the border RBridge actually achieves a per-flow load balance for returning traffic.
他のL1領域からのトリルデータパケットがエリア境界rbridgeに到着すると、このRBRIDGEは入力領域の1つのエリアニックネームを選択して、戻りトリルデータパケットがこの選択されたニックネームに転送できるように、パケットのイングレースニックネームを置き換えることができます。ロードバランスを取得するヘルプ複数のパスを介してユニキャストトラフィックを返します。選択は、[RFC7357]のセクション5.3で説明されているように、単に疑似乱数アルゴリズムに基づいています。ランダムな入力ニックネームの置き換えで、境界rbridgeは実際にトラフィックを返すためのフロー荷重バランスを実現します。
All area border RBridges for an L1 area MUST agree on the same pseudorandom algorithm. The source MAC address, ingress area nicknames, egress area nicknames, and the Data Label of the received TRILL Data packet are candidate factors of the input of this pseudorandom algorithm. Note that the value of the destination MAC address SHOULD be excluded from the input of this pseudorandom algorithm; otherwise, the egress RBridge could see one source MAC address flip-flopping among multiple ingress RBridges.
L1領域のすべてのエリア境界rbridgesは、同じ疑似ランダムアルゴリズムに同意する必要があります。送信元MACアドレス、入力領域のニックネーム、出力領域ニックネーム、および受信されたトイレデータパケットのデータラベルは、この擬似ランダムアルゴリズムの入力の候補要因である。宛先MACアドレスの値は、この擬似乱数アルゴリズムの入力から除外されるべきであることに注意してください。それ以外の場合、出口Rbridgeは、複数の入りrbridgesの間で1つのソースMACアドレスフリップフロッピングを見ることができます。
When a unicast TRILL Data packet originated from an L1 area arrives at an area border RBridge of that L1 area, that RBridge MAY select one area nickname of the egress area to replace the egress nickname of the packet. By default, it SHOULD choose the egress area border RBridge with the least cost route to reach or, if there are multiple equal cost egress area border RBridges, use the pseudorandom algorithm as defined in Section 5.3 of [RFC7357] to select one. The use of that algorithm MAY be extended to selection among some stable set of egress area border RBridges that include non-least-cost alternatives if it is desired to obtain more load spreading at the cost of sometimes using a non-least-cost Level 2 route to forward the TRILL Data packet to the egress area.
L1領域から生じるユニキャストトリルデータパケットがそのL1領域の領域境界Rbridgeに到着すると、そのRBRIDGEは出力領域の1つの領域ニックネームを選択してパケットの出力ニックネームを置き換えることができます。デフォルトでは、それは到達するために最も少ないコストルートを持つ出力エリア境界rbridgeを選択するか、または複数の等価の出力エリア境界rbridgesがある場合は、[RFC7357]のセクション5.3で定義されている疑似ランダムアルゴリズムを使用します。そのアルゴリズムの使用は、非少なくともコストレベル2を使用することがあるコストでより多くの負荷拡散を得ることが望まれる場合に、非少なくともコストの選択肢を含むいくつかの安定な出力領域境界rbridgesの間で選択することができる。トライルデータパケットを出力領域に転送するためのルート。
The following topology change scenarios will trigger the discovery processes as defined in Sections 5.1 and 5.2:
次のトポロジ変更シナリオは、セクション5.1と5.2で定義されているディスカバリプロセスをトリガーします。
* A new node comes up or recovers from a previous failure.
* 新しいノードが前回の失敗から起動または回復します。
* A node goes down.
* ノードが停止します。
* A link or node fails and causes partition of an L1/L2 area.
* リンクまたはノードが失敗し、L1 / L2領域のパーティションを引き起こします。
* A link or node whose failure has caused partitioning of an L1/L2 area is repaired.
* L1 / L2領域の分割を引き起こしたリンクまたはノードが修復されます。
The following Level 1 Border RBridge APPsub-TLV will be included in E-L1FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. Through listening for this APPsub-TLV, an area border RBridge discovers all other area border RBridges in this area.
次のレベル1の境界RBRIDGEAPSUB-TLVは、TRIL GENINFO-TLVのAppSub-TLVとしてE-L1FS FS-LSPフラグメントゼロ[RFC7780]に含まれます。このAppsub-TLVを聴くことで、エリアボーダーRbridgeはこの領域の他のすべてのエリア境界rbridgesを発見します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RBRIDGE | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Level 1 Border RBridge (TRILL APPsub-TLV type 256)
タイプ：レベル1境界RBridge（TRILL APPSUB-TLVタイプ256）
Length: 2
長さ：2
Sender Nickname: The nickname the originating IS will use as the L1 Border RBridge Nickname. This field is useful because the originating IS might own multiple nicknames.
送信者ニックネーム：ニックネームの発信元は、L1 Barder Rbridgeニックネームとして使用されます。このフィールドは、発信元が複数のニックネームを所有する可能性があるため便利です。
The following APPsub-TLV will be included in an E-L2FS FS-LSP fragment zero [RFC7780] as an APPsub-TLV of the TRILL GENINFO-TLV. Through listening to this APPsub-TLV in L2, an area border RBridge discovers all groups of L1 border RBridges and each such group identifies an area.
次のAppSub-TLVは、TRIL GENINFO-TLVのAppSub-TLVとしてE-L2FS FS-LSPフラグメントゼロ[RFC7780]に含まれます。L2でこのAppSub-TLVを聴くことで、エリアボーダーRbridgeはL1境界rbridgesのすべてのグループを検出し、そのような各グループはエリアを識別します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = L1-BORDER-RB-GROUP | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1 Border RBridge Nickname k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Level 1 Border RBridge Group (TRILL APPsub-TLV type 257)
タイプ：レベル1ボーダーRブリッジグループ（TRILL APPSUB-TLV TYPE 257）
Length: 2 * k. If length is not a multiple of 2, the APPsub-TLV is corrupt and MUST be ignored.
長さ：2 * k。lengthが2の倍数ではない場合、appsub-tlvは破損しており、無視する必要があります。
L1 Border RBridge Nickname: The nickname that an area border RBridge uses as the L1 Border RBridge Nickname. The L1-BORDER-RB-GROUP TLV generated by an area border RBridge MUST include all L1 Border RBridge Nicknames of the area. It's RECOMMENDED that these k nicknames are ordered in ascending order according to the 2-octet nickname considered as an unsigned integer.
L1 Border Rbridgeニックネーム：エリア境界rbridgeがL1 Barder Rbridgeニックネームとして使用するニックネーム。領域境界RBRIDGEによって生成されたL1-Border-RBグループTLVは、領域のすべてのL1境界Rbridgeニックネームを含める必要があります。これらのKニックネームは、符号なし整数と見なされる2オクテットのニックネームに従って昇順で順序付けられることをお勧めします。
When an L1 area is partitioned [RFC8243], border RBridges will re-discover each other in both L1 and L2 through exchanging LSPs. In L2, the set of border RBridge nicknames for this splitting area will change. Border RBridges that detect such a change MUST flush the reachability information associated to any RBridge nickname from this changing set.
L1領域が分割されている場合[RFC8243]、LSPを交換することによってL1とL2の両方で境界rbridgesが再発見されます。L2では、この分割領域の境界rbridgeニックネームのセットが変わります。このような変更を検出する境界rbridgesは、この変更セットから任意のRBridgeニックネームに関連する到達可能性情報をフラッシュしなければなりません。
It's possible that one border RBridge (say, RB1) connects multiple L1 areas. RB1 SHOULD use a single area nickname for itself for all these areas to minimize nickname consumption and the number of nicknames being advertised in L2; however, such a border RBridge might have to hold multiple nicknames -- for example, it might be the root of multiple L1 or multiple L2 distribution trees.
1つの境界rbridge（RB1）が複数のL1領域を接続する可能性があります。RB1は、ニックネームの消費量とL2でアドバタイズされているニックネームの数を最小限に抑えるために、すべてのこれらの領域に対して単一のエリアのニックネームを使用する必要があります。しかしながら、このような境界rbridgeは複数のニックネームを保持しなければならないかもしれない - 例えば、それは複数のL1または複数のL2分布ツリーの根本であり得る。
Nicknames used within one of these L1 areas can be reused within other areas. It's important that packets destined to those duplicated nicknames are sent to the right area. Since these areas are connected to form a layer 2 network, duplicated {MAC, Data Label} across these areas SHOULD NOT occur (see Section 4.2.6 of [RFC6325] for tie breaking rules). Now suppose a TRILL Data packet arrives at the area border nickname of RB1. For a unicast packet, RB1 can look up the {MAC, Data Label} entry in its MAC table to identify the right destination area (i.e., the outgoing interface) and the egress RBridge's nickname. For a multicast packet for each attached L1 area: either RB1 is not the DBRB and RB1 will not transition the packet, or RB1 is the DBRB. If RB1 is the DBRB, RB1 follows the following rules:
これらのL1エリアのうちの1つで使用されているニックネームは、他の領域内で再利用できます。これらの重複ニックネーム宛てのパケットが正しい領域に送信されることが重要です。これらの領域はレイヤ2ネットワークを形成するように接続されているので、これらの領域全体で重複{Mac、Data Label}が発生してはいけません（Tie Breakingルールの[RFC6325]のセクション4.2.6を参照）。今すぐTrillデータパケットがRB1の領域境界ニックネームに到着するとします。ユニキャストパケットの場合、RB1はそのMACテーブル内の{MAC、データラベル}エントリを検索して、正しい目的地領域（すなわち、発信インターフェース）と出力RBridgeのニックネームを識別できます。添付された各L1領域のマルチキャストパケットの場合：RB1はDBRBではなく、RB1はパケットを遷移しない、またはRB1はDBRBです。RB1がDBRBの場合、RB1は次の規則に従います。
* If this packet originated from an area out of the connected areas, RB1 replicates this packet and floods it on the proper Level 1 trees of all the areas in which it acts as the DBRB.
* このパケットが接続されている領域からのエリアから発生した場合、RB1はこのパケットを複製し、それがDBRBとして機能するすべての領域の適切なレベル1の木にそれをフラッディングします。
* If the packet originated from one of the connected areas, RB1 replicates the packet it receives from the Level 1 tree and floods it on other proper Level 1 trees of all the areas in which it acts as the DBRB except the originating area (i.e., the area connected to the incoming interface). RB1 might also receive the replication of the packet from the Level 2 tree. This replication MUST be dropped by RB1. It recognizes such packets by their ingress nickname being the nickname of one of the border RBridges of an L1 area for which the receiving border RBridge is DBRB.
* パケットが接続されている領域の1つから発生した場合、RB1はレベル1のツリーから受け取るパケットを複製し、それが発信領域を除いてDBRBとして機能するすべての領域の他の適切なレベル1の木にそれをフラッディングします（つまり、着信インタフェースに接続されているエリア）。RB1はまた、レベル2ツリーからパケットの複製を受信する可能性があります。このレプリケーションはRB1によって削除されなければなりません。受信側のrbridgeがDBRBのL1エリアの境界rbriggesの1つのニックネームのニックネームであるそのようなパケットを認識する。
All Level 2 RBridges MUST support E-L2FS [RFC7356] [RFC7780]. The Extended TLVs defined in Section 5 are to be used in Extended Level 1/2 Flooding Scope (E-L1FS/E-L2FS) Protocol Data Units (PDUs). Area border RBridges MUST support both E-L1FS and E-L2FS. RBridges that do not support both E-L1FS or E-L2FS cannot serve as area border RBridges but they can appear in an L1 area acting as non-area-border RBridges.
すべてのレベル2 rbridgesは、E-L2FS [RFC7356] [RFC7780]をサポートしている必要があります。セクション5で定義されている拡張TLVは、拡張レベル1/2フラッディングスコープ（E-L1FS / E-L2FS）プロトコルデータユニット（PDU）で使用されます。エリア境界Rbridgesは、E-L1FSとE-L2FSの両方をサポートしている必要があります。E-L1FSまたはE-L2Fの両方をサポートしていないRBRIDGESは、エリア境界RBRIDGESとして機能することはできませんが、非エリアボーダーのRBRIDGESとして機能するL1領域に表示できます。
If an L1 Border RBridge Nickname is configured at an RBridge and that RBridge has both L1 and L2 adjacencies, the multilevel feature as specified in this document is turned on for that RBridge and normally uses an L2 nickname in both L1 and L2 although, as provided below, such an RBridge may have to fall back to multilevel unique nickname behavior [RFC8397], in which case it uses this L1 nickname. In contrast, unique nickname multilevel as specified in [RFC8397] is enabled by the presence of L1 and L2 adjacencies without an L1 Border RBridge Nickname being configured. RBridges supporting only unique nickname multilevel do not support the configuration of an L2 Border RBridge Nickname. RBridges supporting only the single-level TRILL base protocol specified in [RFC6325] do not support L2 adjacencies.
L1境界RBRIDG NIGNNAMEがRBRIDERで構成され、RBRIDGEがL1とL2の両方の隣接関係がある場合、このドキュメントで指定されているマルチレベル機能はそのRBRIDGにオンになり、通常はL1とL2の両方でL2ニックネームを使用しますが、以下では、このようなRBRIDGEは、マルチレベル固有のニックネーム動作[RFC8397]に戻る必要があります。この場合、このL1ニックネームを使用します。対照的に、[RFC8397]で指定されている固有のニックネームマルチレベルは、L1境界Rbridge NickNameが設定されていないL1およびL2隣接関係によって有効になります。一意のニックネームのみのマルチレベルのみをサポートするRbridgesは、L2 Border Rbridge NickNameの設定をサポートしません。[RFC6325]で指定されたシングルレベルトリル基本プロトコルのみをサポートするRbridgesは、L2隣接関係をサポートしません。
RBridges that support and are configured to use single nickname multilevel as specified in this document MUST support unique nickname multilevel [RFC8397]. If there are multiple border RBridges between an L1 area and L2, and one or more of them only support or are only configured for unique nickname multilevel [RFC8397], any of these border RBridges that are configured to use single nickname multilevel MUST fall back to behaving as a unique nickname border RBridge for that L1 area. Because overlapping sets of RBridges may be the border RBridges for different L1 areas, an RBridge supporting single nickname MUST be able to simultaneously support single nickname for some of its L1 areas and unique nickname for others. For example, RB1 and RB2 might be border RBridges for L1 area A1 using single nickname while RB2 and RB3 are border RBridges for area A2. If RB3 only supports unique nicknames, then RB2 must fall back to unique nickname for area A2 but continue to support single nickname for area A1. Operators SHOULD be notified when this fallback occurs. The presence of border RBridges using unique nickname multilevel can be detected because they advertise in L1 the blocks of nicknames available within that L1 area.
このドキュメントで指定されている単一のニックネームマルチレベルを使用するようにサポートされているRbridgesは、一意のニックネームマルチレベル[RFC8397]をサポートしている必要があります。 L1領域とL2の間に複数の境界RBRIDGESがある場合は、1つ以上のサポートだけで、または一意のニックネームMultileVel [RFC8397]の場合にのみ設定されている場合、単一のニックネームマルチレベルを使用するように構成されているこれらの境界rbriggesのいずれかが戻ってください。そのL1エリアの独自のニックネーム境界rbridgeとして振る舞う。 RBridgesの組の集合は、異なるL1領域の国境RBRIDGESである可能性があるため、単一のニックネームをサポートするRBridgeは、そのL1エリアの一部のニックネームと他のものの独自のニックネームのためのシングルニックネームを同時にサポートできなければなりません。たとえば、RB1とRB2は、RB2とRB3がエリアA2の境界RBRIDGESです。 RB3が固有のニックネームのみをサポートしている場合、RB2はエリアA2の固有のニックネームに戻る必要がありますが、エリアA1のシングルニックネームをサポートし続ける必要があります。このフォールバックが発生したときに演算子を通知する必要があります。独自のニックネームマルチレベルを使用した境界rbridgesの存在は、L1でそのL1領域内で利用可能なニックネームのブロックを広告するため、検出できます。
In both the unique nickname approach specified in [RFC8397] and the single nickname aggregated approach specified in this document, an RBridge that has L1 and L2 adjacencies uses the same nickname in L1 and L2. If an RBridge is configured with an L1 Border RBridge Nickname for any a Level 1 area, it uses this nickname across the Level 2 area. This L1 Border RBridge Nickname cannot be used in any other Level 1 area except other Level 1 areas for which the same RBridge is a border RBridge with this L1 Border RBridge Nickname configured.
[RFC8397]で指定されている一意のニックネームアプローチとこのドキュメントで指定されているシングルニックネーム集約アプローチの両方で、L1とL2隣接関係を持つRBridgeはL1とL2の同じニックネームを使用します。RbridgeがL1 Border Rbridge NickNameで設定されている場合は、レベル1のエリアのL1 Border Rbridge NickNameがこのニックネームを使用します。このL1 Border Rbridgeニックネームは、このL1 Border Rbridge NickNameが設定された他のレベル1の領域を除く他のレベル1領域では使用できません。
In addition to the manageability considerations specified above, the manageability specifications in [RFC6325] still apply.
上記の管理性の考慮事項に加えて、[RFC6325]の管理容易性仕様はまだ適用されます。
Border RBridges replace ingress and/or egress nickname when a TRILL Data packet traverses a TRILL L2 area. A TRILL Operations, Administration, and Maintenance (OAM) message will be forwarded through the multilevel single nickname TRILL campus using a MAC address belonging to the destination RBridge [RFC7455].
境界Rbridges TrillデータパケットがTRILL L2領域を横切るときに、入力および/または出力ニックネームを交換します。Triell Operations、管理、メンテナンス（OAM）メッセージは、Destination Rbridge [RFC7455]に属するMACアドレスを使用して、マルチレベルシングルニックネームトリルキャンパスを介して転送されます。
For general TRILL Security Considerations, see [RFC6325].
一般トリルセキュリティに関する考慮事項については、[RFC6325]を参照してください。
The newly defined TRILL APPsub-TLVs in Section 5 are transported in IS-IS PDUs whose authenticity can be enforced using regular IS-IS security mechanism [IS-IS] [RFC5310]. Malicious devices may also fake the APPsub-TLVs to attract TRILL Data packets, interfere with multilevel TRILL operation, induce excessive state in TRILL switches (or in any bridges that may be part of the TRILL campus), etc. For this reason, RBridges SHOULD be configured to use the IS-IS Authentication TLV (10) in their IS-IS PDUs so that IS-IS security [RFC5310] can be used to authenticate those PDUs and discard them if they are forged.
セクション5の新しく定義されたTRILL APPSUB-TLVSはIS-IS PDUで転送されます。これは、通常のIS-ISセキュリティメカニズム[IS-IS] [RFC5310]を使用して信頼性を強制できます。悪意のある装置はまた、Trillデータパケットを引き付けるためにAppSub-TLVを偽造することができ、マルチレベルトリル操作を妨げ、トリルスイッチで過度の状態を誘発する（またはトリルキャンパスの一部である可能性がある橋）などを誘発することがあります。IS-IS認証TLV（10）を使用するように設定されているため、IS-IS PDUSでは、IS-ISセキュリティ[RFC5310]を使用してそれらのPDUを認証し、鍛造されている場合はそれらを破棄することができます。
Using a variation of aggregated nicknames, and the resulting possible duplication of nicknames between areas, increases the possibility of a TRILL Data packet being delivered to the wrong egress RBridge if areas are unexpectedly merged as compared with a scheme where all nicknames in the TRILL campus are, except as a transient condition, unique such as the scheme in [RFC8397]. However, in many cases, the data would be discarded at that egress RBridge because it would not match a known end station Data Label / MAC address.
集約されたニックネームの変動、およびその結果として生じる領域間のニックネームの重複を使用して、Trill Campusのすべてのニックネームがすべてのニックネームがある場合と比較して、エリアが予期せずにマージされている場合、トイレデータパケットの可能性を誤った出力Rbridgeに配信する可能性を高めます。（RFC8397の方式など、一意の条件として除いてください。ただし、多くの場合、データは既知のエンドステーションデータラベル/ MACアドレスと一致しないため、データはその出力RBRIDGEで破棄されます。
IANA has allocated two new types under the TRILL GENINFO TLV [RFC7357] from the range allocated by Standards Action [RFC8126] for the TRILL APPsub-TLVs defined in Section 5. The following entries have been added to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on the TRILL Parameters IANA web page.
IANAは、セクション5で定義されているTRILL APPSUB-TLVのTRILL APPSUB-TLVの標準アクションで割り当てられた範囲からTRILL GENINFO TLV [RFC7357]の下に2つの新しいタイプを割り当てました。IS-IS TLV 251アプリケーション識別子1 "TRILLパラメータIANA Webページ上のレジストリ。
+======+====================+===========+
| Type | Name | Reference |
+======+====================+===========+
| 256 | L1-BORDER-RBRIDGE | RFC 9183 |
+------+--------------------+-----------+
| 257 | L1-BORDER-RB-GROUP | RFC 9183 |
+------+--------------------+-----------+
Table 1
表1
[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.、Eastleake 3rd、D.、Dutt、D.、Gai、S、およびA. Ghanwani、「ルーティングブリッジ（Rbridges）：基本プロトコル仕様」、RFC 6325、DOI 10.17487 / RFC6325、7月2011年、<https：//www.rfc-editor.org/info/rfc6325>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S.、およびY. Yang、 "Is Is洪水スコープリンクステートPDU（LSP）、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<https：// www。rfc-editor.org/info/rfc7356>。
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F、F.、Perlman、R.、Eastleake 3rd、D.、およびO.Stokes、「ロットのLinks（Trill）の透明な相互接続：エンドステーションアドレス配布情報（ESADI）プロトコル」、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<https：//www.rfc-editor.org/info/rfc7357>。
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <https://www.rfc-editor.org/info/rfc7455>.
[RFC7455] Senevirathne、T.、Finn、N.、Salam、S.、Kumar、D.、Eastlake 3rd、D.、Aldrin、S.、およびY.Li、「ロットの透明な相互接続（トリル）：Fault Management "、RFC 7455、DOI 10.17487 / RFC7455、2015年3月、<https：//www.rfc-editor.org/info/rfc7455>。
[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]イーストレイク3RD、D.、Zhang、M.、Perlman、R.、Banerjee、A。、Ghanwani、A.、およびS.Gupta、「たくさんのリンク（トリル）の透明な相互接続：明確化、修正、およびアップデート "、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<https：//www.rfc-editor.org/info/rfc7780>。
[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.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8397] Zhang, M., Eastlake 3rd, D., Perlman, R., Zhai, H., and D. Liu, "Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames", RFC 8397, DOI 10.17487/RFC8397, May 2018, <https://www.rfc-editor.org/info/rfc8397>.
[RFC8397] Zhang、M.、Eastlake 3rd、D.、Perlman、R.、Zhai、H.、およびD. Liu、「ユニークなニックネームを使用したロットの透明な相互接続」、RFC 8397、DOI 10.17487/ RFC8397、2018年5月、<https://www.rfc-editor.org/info/rfc8397>。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO 8473, ISO/IEC 10589:2002, Second Edition, November 2002.
[IS]標準化のための国際標準化組織「システム間の電気通信と情報交換」コネクションレスモードネットワークサービスを提供するためのプロトコルと組み合わせて使用するためのイントラドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO 8473、ISO / IEC 10589：2002年、第2版、2002年11月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R.、およびM. Fanto、 "Is-Is Generic Cryptographic認証"、RFC 5310、DOI 10.17487 / RFC5310、2009年2月、<https：//www.rfc-editor.org/info/rfc5310>。
[RFC8243] Perlman, R., Eastlake 3rd, D., Zhang, M., Ghanwani, A., and H. Zhai, "Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)", RFC 8243, DOI 10.17487/RFC8243, September 2017, <https://www.rfc-editor.org/info/rfc8243>.
[RFC8243] Perlman、R.、Eastleake 3rd、D.、Zhang、M.、Ghanwani、A.、およびH. Zhai、 "Multilevelの透明な相互接続のための代替案（TRILL）"、RFC 8243、DOI 10.17487 /RFC8243、2017年9月、<https://www.rfc-editor.org/info/rfc8243>。
It's possible that an L1 RBridge is only reachable from a non-DBRB border RBridge. If this non-DBRB RBridge refrains from Level transition, the question is, how can a multicast packet reach this L1 RBridge? The answer is, it will be reached after the DBRB performs the Level transition and floods the packet using an L1 distribution tree.
L1 Rbridgeが非DBRB境界rbridgeからのみ到達可能である可能性があります。この非DBRB RBridgeがレベル遷移を控えると、質問は、マルチキャストパケットがこのL1 Rbridgeに達することができるのでしょうか。答えは、DBRBがLEレベルの遷移を実行した後に到達され、L1配信ツリーを使用してパケットをフラッディングします。
Take the following figure as an example. RB77 is reachable from the border RBridge RB30 while RB3 is the DBRB. RB3 transitions the multicast packet into L1 and floods the packet on the distribution tree rooted from RB3. This packet is finally flooded to RB77 via RB30.
例として次の図を取ります。RB3はDBRBである間、RB77は境界RBRIDG RB30から到達可能です。RB3はマルチキャストパケットをL1に遷移させ、RB3から根ざした配信ツリーにパケットをフラッディングします。このパケットは最終的にRB30を介してRB77にあふれています。
Area{3,30}
+--------------+ (root) RB3 o
| | \
-RB3 | | o RB30
| | | /
-RB30-RB77 | RB77 o
+--------------+
Example Topology L1 Tree
トポロジの例L1ツリー
In the above example, the multicast packet is forwarded along a non-optimal path. A possible improvement is to have RB3 configured not to belong to this area. In this way, RB30 will surely act as the DBRB to do the Level transition.
上記の例では、マルチキャストパケットは、最適ではないパスに沿って転送される。考えられる改善は、この領域に属していないように構成されたRB3を持つことです。このようにして、RB30はレベル遷移をするためにDBRBとして確実に動作する。
Authors' Addresses
著者の住所
Mingui Zhang Independent Beijing China
Mingui Zhang独立北京中国
Email: zhangmingui@qq.com
Donald E. Eastlake, 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America
Donald E.イーストレイク、第3回フューチャーワイテクノロジーズ2386パノラマサークルアポッカ、FL 32703アメリカ
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America
Radia Perlman EMC 2010 256th Avenue Ne、＃200 Bellevue、WA 98007アメリカ合衆国
Email: radia@alum.mit.edu
Margaret Cullen Painless Security 356 Abbott Street North Andover, MA 01845 United States of America
Margaret Cullenの痛みのないセキュリティ356 Abbott Street North Andover、MA 01845アメリカ合衆国
Phone: +1-781-405-7464
Email: margaret@painless-security.com
URI: https://www.painless-security.com
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing Jiangsu, 211169 China
Hongjun Zhai Jinling Technology of Machication 99 Hongjing Avenue、Jiangning District南京Jiangsu、211169
Email: honjun.zhai@tom.com