[要約] RFC 8249は、TRILL（Transparent Interconnection of Lots of Links）におけるMTU（Maximum Transmission Unit）の交渉に関する仕様です。このRFCの目的は、異なるMTUを持つネットワーク間での効果的な通信を可能にするための手法を提供することです。
Internet Engineering Task Force (IETF) M. Zhang
Request for Comments: 8249 X. Zhang
Updates: 6325, 7177, 7780 D. Eastlake 3rd
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
Dell EMC
S. Chatterjee
Cisco
September 2017
Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation
多くのリンクの透過的な相互接続（TRILL）：MTUネゴシエーション
Abstract
概要
The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325, 7177, and 7780.
基本IETF TRILL（多数のリンクの透過的相互接続）プロトコルには、RFC 6325および7177で指定されているTRILLキャンパス全体のMTU機能があり、リンク状態の変更がキャンパス全体に確実にフラッディングされ、その利点を活用できます。ジャンボパケットをサポートするキャンパス全体の機能。このドキュメントでは、適切なリンクローカルパケットに対して、TRILLキャンパスMTUを超えるリンクローカルMTUを利用するために、そのMTU機能の推奨アップデートを指定しています。さらに、ローカルMTUテストの効率的なアルゴリズムを指定します。このドキュメントは、RFC 6325、7177、および7780を更新します。
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/rfc8249.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8249で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Conventions Used in This Document ..........................3
2. Link-Wide TRILL MTU Size ........................................4
2.1. Operations .................................................5
3. Testing Link MTU Size ...........................................6
4. Refreshing Sz ...................................................8
5. Relationship between Port MTU, Lz, and Sz .......................9
6. LSP Synchronization ............................................10
7. Recommendations for Traffic Link Testing of MTU Size ...........10
8. Backward Compatibility .........................................11
9. Security Considerations ........................................11
10. Additions to Configuration ....................................12
10.1. Per-RBridge Configuration ................................12
10.2. Per-RBridge Port Configuration ...........................12
11. IANA Considerations ...........................................12
12. References ....................................................12
12.1. Normative References .....................................12
12.2. Informative References ...................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................14
[RFC6325] describes the way RBridges agree on the campus-wide minimum acceptable inter-RBridge MTU (Maximum Transmission Unit) size (called "Sz") to ensure that link-state flooding operates properly and all RBridges converge to the same link state. For the proper operation of TRILL (Transparent Interconnection of Lots of Links) IS-IS, all RBridges format their Link State Protocol Data Units (LSPs) to fit in Sz.
[RFC6325]は、リンク状態のフラッディングが正しく動作し、すべてのRBridgeが同じリンク状態に収束することを保証するために、RBridgeがキャンパス全体の許容可能な最小RBridge MTU（最大伝送ユニット）サイズ（「Sz」と呼ばれる）に同意する方法を説明します。 TRILL（多数のリンクの透過的相互接続）IS-ISが適切に動作するために、すべてのRBridgeはリンク状態プロトコルデータユニット（LSP）をSzに適合するようにフォーマットします。
[RFC7177] diagrams the state transitions of an adjacency. If MTU testing is enabled, "Link MTU size is successfully tested" is part of an event (event A6) causing the transition from the "2-Way" state [RFC7177] to the "Report" state for an adjacency. This means that the link MTU testing of size x succeeds, and x is greater than or equal to Sz [RFC6325]. If this link cannot support an MTU of Sz, it will not be reported as part of the campus topology.
[RFC7177]は、隣接関係の状態遷移を図で示しています。 MTUテストが有効になっている場合、「リンクMTUサイズは正常にテストされました」は、隣接の「双方向」状態[RFC7177]から「レポート」状態への遷移を引き起こすイベント（イベントA6）の一部です。これは、サイズxのリンクMTUテストが成功し、xがSz以上である[RFC6325]ことを意味します。このリンクがSzのMTUをサポートできない場合、キャンパストポロジの一部として報告されません。
In this document, a new RECOMMENDED link-wide minimum inter-RBridge MTU size, "Lz", is specified. As further discussed in Section 2, by calculating and using Lz as specified herein, link-scoped Protocol Data Units (PDUs) can be formatted greater than Sz, up to the link-wide minimum acceptable inter-RBridge MTU size, potentially improving the efficiency of link utilization and speeding link-state convergence.
このドキュメントでは、新しい推奨されるリンク全体の最小RBridge MTUサイズ「Lz」が指定されています。セクション2でさらに説明されているように、ここで指定されたLzを計算および使用することにより、リンクスコープのプロトコルデータユニット（PDU）は、リンク全体の最小許容RBridge MTUサイズまで、Szよりも大きくフォーマットできるため、効率が向上する可能性がありますリンク使用率とリンク状態の収束のスピードアップ。
An optional TRILL MTU size-testing algorithm is specified in Section 3 as an efficient method to update the old MTU testing method described in Section 4.3.2 of [RFC6325] and in [RFC7177]. The new MTU size-testing method specified in this document is backward compatible with the old one. Multicasting the MTU-probes is recommended when there are multiple RBridges on a link responding to the probing with an MTU-ack [RFC7177]. The testing method and rules of this document are devised in a way that minimizes the number of MTU-probes for testing, therefore reducing the number of multicast packets for MTU testing.
オプションのTRILL MTUサイズテストアルゴリズムは、[RFC6325]のセクション4.3.2および[RFC7177]で説明されている古いMTUテスト方法を更新する効率的な方法として、セクション3で指定されています。このドキュメントで指定されている新しいMTUサイズテスト方法は、古い方法と下位互換性があります。 MTU-ack [RFC7177]によるプローブに応答するリンクに複数のRBridgeがある場合は、MTUプローブのマルチキャストが推奨されます。このドキュメントのテスト方法とルールは、テスト用のMTUプローブの数を最小限に抑え、MTUテスト用のマルチキャストパケットの数を減らす方法で考案されています。
This document updates RFCs 6325, 7177, and 7780. The update to [RFC6325] and [RFC7177] is specified in Section 3. The update to [RFC7780] is specified in Section 4.
このドキュメントは、RFC 6325、7177、および7780を更新します。[RFC6325]および[RFC7177]への更新は、セクション3で指定されています。[RFC7780]への更新は、セクション4で指定されています。
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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document specifies a new value "Lz" for the minimum acceptable inter-RBridge link MTU size on a local link. Link-wide Lz is the minimum Lz supported and agreed upon amongst all RBridges on a specific link. If the link is usable, Lz will be greater than or equal to Sz.
このドキュメントでは、ローカルリンクで許容される最小のRBridgeリンクMTUサイズに新しい値「Lz」を指定しています。リンク全体のLzは、特定のリンク上のすべてのRBridge間でサポートおよび合意された最小Lzです。リンクが使用可能な場合、LzはSz以上になります。
Some TRILL IS-IS PDUs are exchanged only between neighbors instead of throughout the whole campus. They are confined by the link-wide Lz instead of Sz. Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) are examples of such PDUs. These PDUs are exchanged only on the local link. (While TRILL IS-IS Hellos are also link local, they are always limited to 1470 bytes for robustness.)
一部のTRILL IS-IS PDUは、キャンパス全体ではなく、ネイバー間でのみ交換されます。それらは、Szではなくリンク全体のLzによって制限されます。完全なシーケンス番号PDU（CSNP）と部分的なシーケンス番号PDU（PSNP）は、そのようなPDUの例です。これらのPDUは、ローカルリンクでのみ交換されます。 （TRILL IS-IS Helloもリンクローカルですが、堅牢性のために常に1470バイトに制限されています。）
[RFC7356] defines the PDUs that support flooding scopes in addition to area-wide scopes and domain-wide scopes. As specified in [RFC8139], RBridges support the Extended L1 Circuit Scope (E-L1CS) Flooding Scope LSP (FS-LSP) [RFC7780]. The originatingSNPBufferSize for a port is the minimum of the following two quantities but not less than 1470 bytes: (1) the MTU of the port and (2) the maximum LSP size that the TRILL IS-IS implementation can handle. They use that flooding to exchange their maximum supported value of "Lz". The smallest value of the Lz advertised by the RBridges on a link, but not less than Sz, is the link-wide Lz. An RBridge on a local link will be able to tell which other RBridges on that link support E-L1CS FS-LSPs because, as required by [RFC7780], all RBridges include the Scope Flooding Support TLV [RFC7356] in their TRILL Hellos.
[RFC7356]は、エリア全体のスコープとドメイン全体のスコープに加えて、フラッディングスコープをサポートするPDUを定義します。 [RFC8139]で指定されているように、RBridgeは拡張L1サーキットスコープ（E-L1CS）フラッディングスコープLSP（FS-LSP）[RFC7780]をサポートしています。ポートのoriginatingSNPBufferSizeは、次の2つの量の最小値ですが、1470バイト以上です。（1）ポートのMTUおよび（2）TRILL IS-IS実装が処理できる最大LSPサイズ。彼らはそのフラッディングを使用して、「Lz」のサポートされている最大値を交換します。リンク上のRBridgeによって通知されるLzの最小値ですが、Sz以上であるのは、リンク全体のLzです。ローカルリンク上のRBridgeは、そのリンク上の他のどのRBridgeがE-L1CS FS-LSPをサポートしているかを知ることができます。
The maximum size for a level-1 link-local PDU (such as a PSNP or CSNP) that may be generated by a system is controlled by the value of the management parameter originatingL1SNPBufferSize. This value determines Lz. The TRILL APPsub-TLV shown in Figure 1 SHOULD be included in a TRILL GENINFO TLV [RFC7357] in an E-L1CS FS-LSP fragment zero. If it is missing from an E-L1CS FS-LSP fragment zero or there is no E-L1CS FS-LSP fragment zero, it is assumed that its originating IS is implicitly advertising its originatingSNPBufferSize value as Sz octets.
システムによって生成される可能性があるレベル1リンクローカルPDU（PSNPやCSNPなど）の最大サイズは、originatingL1SNPBufferSize管理パラメーターの値によって制御されます。この値はLzを決定します。図1に示すTRILL APPsub-TLVは、E-L1CS FS-LSPフラグメントゼロのTRILL GENINFO TLV [RFC7357]に含める必要があります。 E-L1CS FS-LSPフラグメントゼロから欠落している場合、またはE-L1CS FS-LSPフラグメントゼロがない場合は、その発信元のISがそのoriginatingSNPBufferSize値をSzオクテットとして暗黙的にアドバタイズしていると見なされます。
E-L1CS FS-LSPs are link local and can also be sent up to a size of Lz but, for robustness, E-L1CS FS-LSP fragment zero MUST NOT exceed 1470 bytes.
E-L1CS FS-LSPはリンクローカルであり、Lzのサイズまで送信できますが、堅牢性のために、E-L1CS FS-LSPフラグメントゼロは1470バイトを超えてはなりません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 21 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originatingSNPBufferSize | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The originatingSNPBufferSize APPsub-TLV
図1：originatingSNPBufferSize APPsub-TLV
Type: Set to the originatingSNPBufferSize APPsub-TLV (TRILL APPsub-TLV type 21). Two bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
タイプ：originatingSNPBufferSize APPsub-TLV（TRILL APPsub-TLVタイプ21）に設定します。このAPPsub-TLVは拡張TLV [RFC7356]に表示されるため、2バイト。
Length: Set to 2.
長さ：2に設定します。
originatingSNPBufferSize: The local value of originatingL1SNPBufferSize as an unsigned integer, limited to the range from 1470 to 65,535 bytes. (A value less than 1470 will be ignored.)
originatingSNPBufferSize：符号なし整数としてのoriginatingL1SNPBufferSizeのローカル値。1470〜65,535バイトの範囲に制限されています。 （1470未満の値は無視されます。）
Lz MAY be reported using an originatingSNPBufferSize APPsub-TLV that occurs in fragment zero of the RBridge's E-L1CS FS-LSP. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment is ignored. If more than one originatingSNPBufferSize APPsub-TLV occurs in fragment zero, the one advertising the smallest value for originatingSNPBufferSize, but not less than 1470 bytes, is used.
Lzは、RBridgeのE-L1CS FS-LSPのフラグメント0で発生するoriginatingSNPBufferSize APPsub-TLVを使用して報告される場合があります。他のフラグメントで発生するoriginatingSNPBufferSize APPsub-TLVは無視されます。フラグメント0で複数のoriginatingSNPBufferSize APPsub-TLVが発生した場合、originatingSNPBufferSizeの最小値をアドバタイズしているが、1470バイト以上のものが使用されます。
Even if all RBridges on a specific link have reached consensus on the value of link-wide Lz based on advertised originatingSNPBufferSize, it does not mean that these RBridges can safely exchange PDUs between each other. Figure 2 shows such a corner case. RB1, RB2, and RB3 are three RBridges on the same link and their Lz is 1800, so the link-wide Lz of this link is 1800. There is an intermediate bridge (say B1) between RB2 and RB3 whose port MTU size is 1700. If RB2 sends PDUs formatted in chunks of size 1800, those PDUs will be discarded by B1.
特定のリンク上のすべてのRBridgeが、アドバタイズされたoriginatingSNPBufferSizeに基づいてリンク全体のLzの値についてコンセンサスに達したとしても、これらのRBridgeが互いに安全にPDUを交換できることを意味しません。図2は、そのようなコーナーケースを示しています。 RB1、RB2、およびRB3は同じリンク上の3つのRBridgeであり、それらのLzは1800であるため、このリンクのリンク全体のLzは1800です。RB2とRB3の間には、ポートMTUサイズが1700の中間ブリッジ（B1など）があります。 RB2がサイズ1800のチャンクでフォーマットされたPDUを送信する場合、それらのPDUはB1によって破棄されます。
Lz:1800 Lz:1800
+---+ | +---+
|RB1|(2000)---|---(2000)|RB2|
+---+ | +---+
|
Lz:1800 |
+---+ +--+
|RB3|(2000)---(1700)|B1|
+---+ +--+
|
Figure 2: Link-Wide Lz = 1800 vs. Tested Link MTU Size = 1700
Therefore, the link MTU size SHOULD be tested. After the link MTU size of an adjacency is successfully tested, those link-local PDUs, such as CSNPs, PSNPs, and E-L1CS FS-LSPs, will be formatted no greater than the tested link MTU size and will be safely transmitted on this link.
したがって、リンクMTUサイズをテストする必要があります。隣接のリンクMTUサイズが正常にテストされると、CSNP、PSNP、E-L1CS FS-LSPなどのリンクローカルPDUは、テストされたリンクMTUサイズ以下にフォーマットされ、これで安全に送信されますリンク。
As for Sz, RBridges continue to propagate their originatingL1LSPBufferSize across the campus through the advertisement of LSPs as defined in Section 4.3.2 of [RFC6325]. The smallest value of Sz advertised by any RBridge, but not less than 1470, will be deemed as Sz. Each RBridge formats their "campus-wide" PDUs -- for example, LSPs -- no greater than what they determine as Sz.
Szと同様に、RBridgesは引き続き、[RFC6325]のセクション4.3.2で定義されているLSPのアドバタイズを通じて、元のL1LSPBufferSizeをキャンパス全体に伝播します。 RBridgeによってアドバタイズされたSzの最小値（1470以上）は、Szと見なされます。各RBridgeは、「キャンパス全体」のPDU（LSPなど）をフォーマットします。これは、Szとして決定したもの以下です。
[RFC7177] defines event A6 as indicating that the MTU test was successful if MTU testing is enabled. As described in Section 4.3.2 of [RFC6325], this is a combination of the following event and condition:
[RFC7177]は、イベントA6を、MTUテストが有効になっている場合にMTUテストが成功したことを示すと定義しています。 [RFC6325]のセクション4.3.2で説明されているように、これは次のイベントと状態の組み合わせです。
o Event: The link MTU size has been tested.
o イベント：リンクMTUサイズがテストされました。
o Condition: The link can support Sz.
o 条件：リンクはSzをサポートできます。
This condition can be efficiently tested by the following "binary search algorithm" and rules. This updates [RFC6325] and [RFC7177].
この条件は、次の「バイナリ検索アルゴリズム」とルールによって効率的にテストできます。これにより、[RFC6325]と[RFC7177]が更新されます。
x, lowerBound, and upperBound are local integer variables. The MTU-probe and MTU-ack PDUs are specified in Section 3 of [RFC7176]. It is RECOMMENDED that one Round-Trip Time (RTT) between the two adjacent RBridges be used as the minimum interval between two successive probes. Note that RTT estimation is out of scope for this document. If operators cannot estimate the RTT, the default value of 5 milliseconds should be assumed.
x、lowerBound、upperBoundはローカル整数変数です。 MTUプローブPDUとMTU-ack PDUは、[RFC7176]のセクション3で指定されています。 2つの隣接するRBridge間の1つのラウンドトリップ時間（RTT）を、2つの連続するプローブ間の最小間隔として使用することをお勧めします。 RTTの見積もりは、このドキュメントの範囲外であることに注意してください。オペレーターがRTTを推定できない場合は、デフォルト値の5ミリ秒を想定する必要があります。
Step 0: RB1 sends an MTU-probe padded to the size of link-wide Lz.
ステップ0：RB1は、リンク全体のLzのサイズにパディングされたMTUプローブを送信します。
1) If RB1 successfully receives the MTU-ack from RB2 to the probe of the value of link-wide Lz within k tries (where k is a configurable parameter whose default is 3), the link MTU size is set to the size of link-wide Lz. Stop.
1）RB1がk回以内にリンク全体のLzの値のプローブへのRB2からのMTU-ackを正常に受信した場合（kはデフォルトは3の設定可能なパラメーターです）、リンクMTUサイズはリンクのサイズに設定されます全体のLz。やめる。
2) RB1 tries to send an MTU-probe padded to 1470 bytes.
2）RB1は、1470バイトにパディングされたMTUプローブを送信しようとします。
a) If RB1 fails to receive an MTU-ack from RB2 after k tries (an MTU-ack should be considered to have failed two RTTs after the probe is sent out), RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. Stop.
a) k回試行した後、RB1がRB2からMTU-ackを受信できなかった場合（MTU-ackは、プローブの送信後に2つのRTTが失敗したと見なす必要があります）、RB1のHelloでRB2の「失敗した最小MTUテスト」フラグを設定します。やめる。
b) The link MTU size is set to 1470; lowerBound is set to 1470; upperBound is set to the link-wide Lz; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer.
b) リンクMTUサイズは1470に設定されています。 lowerBoundは1470に設定されています。 upperBoundはリンク全体のLzに設定されます。 xは[（lowerBound + upperBound）/ 2]に設定され、最も近い整数に切り捨てられます。
Step 1: RB1 tries to send an MTU-probe padded to the size x.
ステップ1：RB1は、サイズxにパディングされたMTUプローブを送信しようとします。
1) If RB1 fails to receive an MTU-ack from RB2 after k tries:
1）kの試行後にRB1がRB2からのMTU-ackの受信に失敗した場合：
upperBound is set to x - 1; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer.
upperBoundはx-1に設定されます。 xは[（lowerBound + upperBound）/ 2]に設定され、最も近い整数に切り捨てられます。
2) If RB1 receives an MTU-ack to a probe of size x from RB2:
2）RB1がサイズxのプローブへのMTU-ackをRB2から受信した場合：
The link MTU size is set to x; lowerBound is set to x; x is set to [(lowerBound + upperBound) / 2], rounded down to the nearest integer. If lowerBound equals upperBound - 1, then x is set to upperBound.
リンクMTUサイズはxに設定されています。 lowerBoundはxに設定されます。 xは[（lowerBound + upperBound）/ 2]に設定され、最も近い整数に切り捨てられます。 lowerBoundがupperBound-1と等しい場合、xはupperBoundに設定されます。
3) If lowerBound >= upperBound or Step 1 has been repeated n times (where n is a configurable parameter whose default value is 5), stop.
3）lowerBound> = upperBoundまたはステップ1がn回繰り返された場合（nは構成可能なパラメーターで、デフォルト値は5です）、停止します。
4) Repeat Step 1.
4）ステップ1を繰り返します。
After the testing, the two connected RBridges agree on the value of the link MTU size. MTU testing is only done in the Designated VLAN [RFC7177]. Since the execution of the above algorithm can be resource consuming, it is RECOMMENDED that the Designated RBridge (DRB) [RFC7177] take the responsibility to do the testing. Multicast MTU-probes are used instead of unicast when multiple RBridges are desired to respond with an MTU-ack on the link. The binary search algorithm given here is a way to minimize the probing attempts; it reduces the number of multicast packets for MTU-probing.
テスト後、接続された2つのRBridgeは、リンクMTUサイズの値について合意します。 MTUテストは指定VLAN [RFC7177]でのみ行われます。上記のアルゴリズムの実行はリソースを消費する可能性があるため、指定RBridge（DRB）[RFC7177]がテストを行う責任を負うことをお勧めします。リンク上のMTU-ackで応答するために複数のRBridgeが必要な場合は、ユニキャストの代わりにマルチキャストMTUプローブが使用されます。ここで与えられた二分探索アルゴリズムは、調査の試みを最小限に抑える方法です。 MTUプローブ用のマルチキャストパケットの数を減らします。
The following rules are designed to determine whether the aforementioned "Condition" holds.
以下のルールは、前述の「条件」が満たされるかどうかを決定するために設計されています。
RBridges have figured out the upper bound and lower bound of the link MTU size from the execution of the above algorithm. If Sz is smaller than the lower bound or greater than the upper bound, RBridges can directly judge whether the link supports Sz without MTU-probing.
RBridgesは、上記のアルゴリズムの実行からリンクMTUサイズの上限と下限を計算しました。 Szが下限よりも小さいか、上限よりも大きい場合、RBridgeはリンクがMTUプローブなしでSzをサポートしているかどうかを直接判断できます。
(a) If lowerBound >= Sz, this link can support Sz.
（a）lowerBound> = Szの場合、このリンクはSzをサポートできます。
(b) Else if upperBound <= Sz, this link cannot support Sz.
（b）そうでない場合、upperBound <= Szの場合、このリンクはSzをサポートできません。
Otherwise, RBridges SHOULD test whether the link can support Sz as in item (c) below. If they do not, the only safe assumption will be that the link cannot support Sz. This assumption, without testing, might rule out the use of a link that can, in fact, handle packets up to Sz. In the worst case, this might result in unnecessary network partition.
それ以外の場合、RBridgesは、リンクが以下の項目（c）のようにSzをサポートできるかどうかをテストする必要があります（SHOULD）。サポートしていない場合、安全な仮定は、リンクがSzをサポートできないことです。この仮定は、テストなしでは、実際にはSzまでのパケットを処理できるリンクの使用を除外する可能性があります。最悪の場合、これにより不要なネットワーク分割が発生する可能性があります。
(c) lowerBound < Sz < upperBound. RBridges probe the link with MTU-probe messages padded to Sz. If an MTU-ack is received within k tries, this link can support Sz. Otherwise, this link cannot support Sz. Through this test, the lower bound and upper bound of the link MTU size can be updated accordingly.
（c）lowerBound <Sz <upperBound。 RBridgeは、STUにパディングされたMTUプローブメッセージでリンクをプローブします。 k回以内にMTU-ackを受信した場合、このリンクはSzをサポートできます。そうでない場合、このリンクはSzをサポートできません。このテストを通じて、リンクMTUサイズの下限と上限を適宜更新できます。
RBridges may join or leave the campus; this may change Sz.
RBridgesはキャンパスに参加したり、キャンパスを去ったりします。これはSzを変えるかもしれません。
1) Joining
1）加入
a) When a new RBridge joins the campus and its originatingL1LSPBufferSize is smaller than the current Sz, reporting its originatingL1LSPBufferSize in its LSPs will cause other RBridges to decrease their Sz. Then, any LSP greater than the reduced Sz MUST be split, and/or the LSP contents in the campus MUST be otherwise redistributed so that no LSP is greater than the new Sz.
a) 新しいRBridgeがキャンパスに参加し、そのoriginatingL1LSPBufferSizeが現在のSzよりも小さい場合、LSPでoriginatingL1LSPBufferSizeを報告すると、他のRBridgeのSzが減少します。次に、削減されたSzより大きいすべてのLSPを分割する必要があります。また、キャンパス内のLSPコンテンツを別の方法で再配布して、LSPが新しいSzを超えないようにする必要があります。
b) If the joining RBridge's originatingL1LSPBufferSize is greater than or equal to the current Sz, reporting its originatingL1LSPBufferSize will not change Sz.
b) 参加しているRBridgeのoriginatingL1LSPBufferSizeが現在のSz以上の場合、そのoriginatingL1LSPBufferSizeを報告してもSzは変更されません。
2) Leaving
2）立ち去る
a) From the specification of the Joining process, we know that if an RBridge's originatingL1LSPBufferSize is smaller than Sz, this RBridge will not join this campus.
a) 参加プロセスの仕様から、RBridgeのoriginatingL1LSPBufferSizeがSzより小さい場合、このRBridgeはこのキャンパスに参加しないことがわかります。
b) When an RBridge leaves the campus and its originatingL1LSPBufferSize equals Sz, its LSPs are purged from the remainder of the campus after reaching MaxAge [IS-IS]. Sz MAY be recalculated and MAY increase. In other words, while in most cases RB1 ignores link-state information for IS-IS unreachable RBridge RB2 [RFC7780], originatingL1LSPBufferSize is meaningful. Its value, even from IS-IS unreachable RBridges, is used in determining Sz. This updates [RFC7780].
b) RBridgeがキャンパスを離れ、そのoriginatingL1LSPBufferSizeがSzに等しい場合、そのLSPはMaxAge [IS-IS]に到達した後、キャンパスの残りの部分からパージされます。 Szは再計算される場合があり、増加する場合があります。つまり、ほとんどの場合、RB1はIS-IS到達不能RBridge RB2 [RFC7780]のリンク状態情報を無視しますが、originatingL1LSPBufferSizeは意味があります。 IS-IS到達不能RBridgeからの値でさえ、Szの決定に使用されます。これは[RFC7780]を更新します。
c) When an RBridge leaves the campus and its originatingL1LSPBufferSize is greater than Sz, Sz will not be updated, since Sz is determined by another RBridge with a smaller originatingL1LSPBufferSize.
c) RBridgeがキャンパスを離れ、そのoriginatingL1LSPBufferSizeがSzより大きい場合、SzはoriginatingL1LSPBufferSizeが小さい別のRBridgeによって決定されるため、Szは更新されません。
Frequent LSP "resizing" is harmful to the stability of the TRILL campus, so, to avoid this, upward resizing SHOULD be dampened. When an upward resizing event is noticed by an RBridge, it is RECOMMENDED that a timer be set at that RBridge via a configurable parameter -- LSPresizeTime -- whose default value is 300 seconds. Before this timer expires, all subsequent upward resizing will be dampened (ignored). Of course, in a well-configured campus with all RBridges configured to have the same originatingL1LSPBufferSize, no resizing will be necessary. It does not matter if different RBridges have different dampening timers or if some RBridges resize upward more quickly than others.
頻繁なLSPの「サイズ変更」はTRILLキャンパスの安定性に有害であるため、これを回避するには、上方へのサイズ変更を抑制する必要があります。上向きのサイズ変更イベントがRBridgeによって通知された場合、構成可能なパラメーター（LSPresizeTime）を介してそのRBridgeにタイマーを設定することをお勧めします。LSPresizeTimeのデフォルト値は300秒です。このタイマーが期限切れになる前に、以降のすべてのサイズ変更が抑制されます（無視されます）。もちろん、すべてのRBridgeが同じoriginatingL1LSPBufferSizeを持つように構成された適切に構成されたキャンパスでは、サイズ変更は必要ありません。 RBridgeごとにダンプニングタイマーが異なる場合や、一部のRBridgeのサイズが他のRBridgeよりも上方向に速く変化するかどうかは関係ありません。
If the refreshed Sz is smaller than the lower bound or greater than the upper bound of the tested link MTU size, the issue of resource consumption from testing the link MTU size can be avoided according to rule (a) or (b) as specified in Section 3. Otherwise, RBridges test the link MTU size according to rule (c).
更新されたSzがテストされたリンクMTUサイズの下限よりも小さいか、または上限よりも大きい場合、リンクMTUサイズのテストによるリソース消費の問題は、で指定されているルール（a）または（b）に従って回避できます。セクション3.それ以外の場合、RBridgeはルール（c）に従ってリンクMTUサイズをテストします。
When the port MTU of an RBridge is smaller than the local originatingL1SNPBufferSize of an RBridge (an inconsistent configuration), that port SHOULD be disabled, since, in any case, an adjacency cannot be formed through such a port. On the other hand, when an RBridge receives an LSP or E-L1CS FS-LSP with size greater than the link-wide Lz or Sz but not greater than its port MTU size, this LSP is processed normally. If the size of an LSP is greater than the MTU size of a port over which it is to be propagated, this LSP MUST NOT be sent over the port and an LSPTooLargeToPropagate alarm shall be generated [IS-IS].
RBridgeのポートMTUがRBridgeのローカルoriginatingL1SNPBufferSizeよりも小さい場合（構成の不整合）、そのようなポートを通じて隣接を形成できないため、そのポートを無効にする必要があります（SHOULD）。一方、RBridgeが、リンク全体のLzまたはSzより大きく、ポートMTUサイズ以下のLSPまたはE-L1CS FS-LSPを受信すると、このLSPは正常に処理されます。 LSPのサイズがそれが伝搬されるポートのMTUサイズより大きい場合、このLSPはポートを介して送信してはならず、LSPTooLargeToPropagateアラームが生成されます[IS-IS]。
An RBridge participates in LSP synchronization on a link as soon as it has at least one adjacency on that link that has advanced to at least the 2-Way state [RFC7177]. On a LAN link, CSNPs and PSNPs are used for synchronization. On a point-to-point link, only PSNPs are used.
RBridgeは、少なくとも双方向の状態[RFC7177]に進んだリンク上に少なくとも1つの隣接関係があるとすぐに、リンク上のLSP同期に参加します。 LANリンクでは、CSNPとPSNPが同期に使用されます。ポイントツーポイントリンクでは、PSNPのみが使用されます。
The CSNPs and PSNPs can be formatted in chunks of size (at most) link-wide Lz but are processed normally if received having a larger size. Since the link MTU size may not have been tested in the 2-Way state, link-wide Lz may be greater than the supported link MTU size. In that case, a CSNP or PSNP may be discarded. After the link MTU size is successfully tested, RBridges will begin to format these PDUs with a size no greater than that MTU; therefore, these PDUs will eventually get through.
CSNPとPSNPは（最大で）リンク全体のLzサイズのチャンクでフォーマットできますが、受信したサイズが大きい場合は、通常どおり処理されます。リンクMTUサイズは双方向状態でテストされていない可能性があるため、リンク全体のLzはサポートされているリンクMTUサイズよりも大きい場合があります。その場合、CSNPまたはPSNPは破棄されることがあります。リンクMTUサイズが正常にテストされた後、RBridgeはこれらのPDUをそのMTU以下のサイズでフォーマットし始めます。したがって、これらのPDUは最終的に通過します。
Note that the link MTU size is frequently greater than Sz. Link-local PDUs are limited in size by the link MTU size rather than Sz, which, when Lz is greater than Sz, promises a reduction in the number of PDUs and a faster LSP synchronization process.
リンクMTUサイズはSzよりも頻繁に大きいことに注意してください。リンクローカルPDUのサイズは、SzではなくリンクMTUサイズによって制限されます。これは、LzがSzより大きい場合、PDUの数の削減とより高速なLSP同期プロセスを約束します。
Sz and link-wide Lz are used to limit the size of most TRILL IS-IS PDUs. They are different from the MTU size restricting the size of TRILL Data packets. The size of a TRILL Data packet is restricted by the physical MTU of the ports and links the packet traverses. It is possible that a TRILL Data packet successfully gets through the campus but its size is greater than Sz or link-wide Lz values.
Szおよびリンク全体のLzは、ほとんどのTRILL IS-IS PDUのサイズを制限するために使用されます。これらは、TRILLデータパケットのサイズを制限するMTUサイズとは異なります。 TRILLデータパケットのサイズは、ポートの物理MTUによって制限され、パケットトラバースをリンクします。 TRILLデータパケットがキャンパスを正常に通過する可能性がありますが、そのサイズはSzまたはリンク全体のLz値より大きいです。
The algorithm defined for testing the link MTU size can also be used in TRILL traffic MTU size testing; in that case, the link-wide Lz used in that algorithm is replaced by the port MTU of the RBridge sending MTU-probes. The successfully tested size x MAY be advertised as an attribute of this link, using the MTU sub-TLV defined in [RFC7176].
リンクMTUサイズのテスト用に定義されたアルゴリズムは、TRILLトラフィックMTUサイズのテストでも使用できます。その場合、そのアルゴリズムで使用されるリンク全体のLzは、MTUプローブを送信するRBridgeのポートMTUに置き換えられます。 [RFC7176]で定義されているMTUサブTLVを使用して、テストに成功したサイズxがこのリンクの属性として通知される場合があります。
Unlike RBridges, end stations do not participate in the exchange of TRILL IS-IS PDUs; therefore, they cannot grasp the traffic link MTU size from a TRILL campus automatically. An operator may collect these values using network management tools such as TRILL ping or TraceRoute. Then, the path MTU can be set as the smallest tested link MTU on this path, and end stations should not generate frames that -- when encapsulated as TRILL Data packets -- exceed this path MTU.
RBridgeとは異なり、端末はTRILL IS-IS PDUの交換には参加しません。したがって、TRILLキャンパスからトラフィックリンクのMTUサイズを自動的に把握することはできません。オペレーターは、TRILL pingやTraceRouteなどのネットワーク管理ツールを使用してこれらの値を収集できます。次に、パスMTUをこのパスでテストされた最小のリンクMTUとして設定できます。エンドステーションは、TRILLデータパケットとしてカプセル化されたときに、このパスMTUを超えるフレームを生成しません。
There can be a mixture of Lz-ignorant and Lz-aware RBridges on a link. This configuration will behave properly, although it may not be as efficient as it would be if all RBridges on the link are Lz aware.
リンクには、Lzを認識しないRBridgeとLzを認識するRBridgeが混在する場合があります。この構成は適切に動作しますが、リンク上のすべてのRBridgeがLz対応である場合ほど効率的ではありません。
For an Lz-ignorant RBridge, TRILL IS-IS PDUs are always formatted no greater than Sz. Lz-aware RBridges as receivers can handle these PDUs, since they cannot be greater than the link-wide Lz.
Lzを無視したRBridgeの場合、TRILL IS-IS PDUは常にSz以下でフォーマットされます。レシーバーとしてのLz認識RBridgeは、これらのPDUを処理できます。これは、それらがリンク全体のLzより大きくなることができないためです。
For an Lz-aware RBridge, in the case that link-wide Lz is greater than Sz, larger link-local TRILL IS-IS PDUs can be sent out to increase efficiency. Lz-ignorant RBridges as receivers will have no problem handling them, since the originatingL1LSPBufferSize value of these RBridges had been tested and the link-wide Lz is not greater than that value.
Lz対応RBridgeの場合、リンク全体のLzがSzより大きい場合、より大きなリンクローカルTRILL IS-IS PDUを送信して効率を上げることができます。これらのRBridgesのoriginatingL1LSPBufferSize値はテスト済みであり、リンク全体のLzはその値を超えていないため、受信者としてのLzを無視したRBridgesはそれらを処理する問題がありません。
An Lz-ignorant RBridge might not support the link MTU size-testing algorithm defined in Section 3 but could be using some algorithm just to test for the Sz MTU on the link. In any case, if an RBridge per [RFC6325] receives an MTU-probe, it MUST respond with an MTU-ack padded to the same size as the MTU-probe.
Lzを無視したRBridgeは、セクション3で定義されているリンクMTUサイズテストアルゴリズムをサポートしていない可能性がありますが、リンク上のSz MTUをテストするだけのアルゴリズムを使用している可能性があります。いずれの場合でも、[RFC6325]ごとのRBridgeがMTUプローブを受信した場合、MTUプローブと同じサイズにパディングされたMTU-ackで応答する必要があります。
This document raises no significant new security issues for TRILL. In TRILL, RBridges are generally considered to be trusted devices. Protection against forged TRILL IS-IS PDUs, including forged Hellos containing originatingSNPBufferSize APPsub-TLVs, can be obtained through IS-IS PDU cryptographic authentication [RFC5310]. The worst that an RBridge can do by reporting an erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make unavailable the optimization of being able to use link MTUs that exceed the campus-wide MTU for link-local TRILL IS-IS PDUs.
このドキュメントは、TRILLに重大な新しいセキュリティ問題を引き起こしません。 TRILLでは、RBridgeは一般に信頼できるデバイスと見なされます。 origin-SNPBufferSize APPsub-TLVを含む偽造されたHelloを含む偽造されたTRILL IS-IS PDUに対する保護は、IS-IS PDU暗号化認証[RFC5310]を通じて取得できます。誤ったoriginatingSNPBufferSizeを報告することでRBridgeが実行できる最悪の事態は、LzをSzに減らし、リンクローカルTRILL IS-IS PDUに対してキャンパス全体のMTUを超えるリンクMTUを使用できるようにする最適化を利用できなくすることです。
For general and adjacency-related TRILL security considerations, see [RFC6325] and [RFC7177].
一般的な隣接関係のTRILLセキュリティの考慮事項については、[RFC6325]および[RFC7177]を参照してください。
Implementation of the features specified in this document adds two RBridge configuration parameters, as follows:
このドキュメントで指定されている機能を実装すると、次のように2つのRBridge構成パラメーターが追加されます。
Each RBridge implementing the RECOMMENDED LSP resizing damping strategy specified in Section 4 has an LSPresizeTime parameter that is an integer in the range of 0-65,535 and that defaults to 300. It is the number of seconds for which an RBridge determines that Sz has increased before it will create any LSP or E-L1FS FS-LSP fragments.
セクション4で指定されたRECOMMENDED LSPリサイズダンピングストラテジーを実装する各RBridgeには、LSPresizeTimeパラメータがあり、0〜65,535の範囲の整数で、デフォルトは300です。これは、RBridgeがSzが以前に増加したと判断する秒数です。 LSPまたはE-L1FS FS-LSPフラグメントを作成します。
Each RBridge port on which the calculation and use of Lz are implemented has an originatingL1SNPBufferSize parameter that is an integer in the range of 1470-65,535. This parameter defaults to the minimum of the size that the port can accommodate and the link-local IS-IS PDU size that the TRILL implementation can accommodate.
Lzの計算と使用が実装されている各RBridgeポートには、1470〜65,535の範囲の整数であるoriginatingL1SNPBufferSizeパラメーターがあります。このパラメーターのデフォルトは、ポートが対応できる最小サイズ、およびTRILL実装が対応できるリンクローカルIS-IS PDUサイズです。
IANA has assigned a new APPsub-TLV type for the TRILL originatingSNPBufferSize APPsub-TLV defined in Section 2 of this document. This new type has been assigned from the range less than 256 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry. The entry is as follows:
IANAは、このドキュメントのセクション2で定義されているTRILL originatingSNPBufferSize APPsub-TLVに新しいAPPsub-TLVタイプを割り当てました。この新しいタイプは、「IS-IS TLV 251 Application Identifier 1の下のTRILL APPsub-TLVタイプ」レジストリで256未満の範囲から割り当てられています。エントリは次のとおりです。
Type Name Reference
---- ------------------------ ---------
21 originatingSNPBufferSize RFC 8249
[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>。
[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 Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[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>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<https://www.rfc-editor.org/info/rfc7176>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<https://www.rfc-editor.org/info/rfc7177>。
[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 Flooding Scope Link State PDU（LSPs）」、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.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<https://www.rfc-editor.org/info/rfc7357>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <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>。
[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>。
[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/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and F. Hu、 "Transparent Interconnection of Lots of Links（TRILL）：Appointed Forwarders"、RFC 8139、DOI 10.17487 / RFC8139、2017年6月、<https://www.rfc-editor.org/info/rfc8139>。
Acknowledgements
謝辞
The authors would like to thank Vishwas Manral for his comments and suggestions.
著者は、彼のコメントと提案をしてくれたVishwas Manralに感謝します。
Authors' Addresses
著者のアドレス
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China
min鬼Zhang hu Aはテクノロジーno。156 be i青RDですH Hドワーフポイント地区北京100095中国
Phone: +86-13810702575
Email: zhangmingui@huawei.com
Xudong Zhang Huawei Technologies No. 156 Beiqing Rd. Haidian District Beijing 100095 China
X u动Zhang hu Aはテクノロジーno。156 be i青RDです。Hは北京100095中国で不足しています。
Email: zhangxudong@huawei.com Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
メール：zhangxudong@huawei.com Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Radia Perlman Dell EMC 505 1st Ave South Seattle, WA 98104 United States of America
Radia Perlman Dell EMC 505 1st Ave South Seattle、WA 98104アメリカ合衆国
Email: radia@alum.mit.edu
Somnath Chatterjee Cisco Systems SEZ Unit, Cessna Business Park Outer Ring Road Bangalore 560087 India
Somnath Chatterjee Cisco Systems SEZ Unit、Cessna Business Park Outer Ring Road Bangalore India
Email: somnath.chatterjee01@gmail.com