[要約] RFC 7177は、TRILL（Transparent Interconnection of Lots of Links）の隣接性に関する仕様であり、TRILLネットワーク内のノード間の隣接関係を定義しています。このRFCの目的は、TRILLネットワークの効率的な運用とスケーラビリティを実現するために、隣接関係の確立と維持の方法を提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7177 Huawei
Obsoletes: 6327 R. Perlman
Updates: 6325 Intel Labs
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
H. Yang
Cisco
V. Manral
Ionos Corp.
May 2014
Transparent Interconnection of Lots of Links (TRILL): Adjacency
多くのリンクの透過的な相互接続（TRILL）：隣接関係
Abstract
概要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network (LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System (IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325.
IETFの多数のリンクの透過的相互接続（TRILL）プロトコルは、ポイントツーポイントリンクや、複数のTRILLスイッチと端末を接続できるマルチアクセスローカルエリアネットワーク（LAN）リンクなど、TRILLスイッチ間の任意のリンク技術をサポートします。 TRILLは、中間システムから中間システム（IS-IS）へのルーティングを使用します。このドキュメントでは、RBridges（ルーティングブリッジ）とも呼ばれる、TRILLスイッチ間のIS-IS隣接関係の確立、報告、終了について説明しています。また、TRILLの他の4つのリンクローカルな側面、指定RBridge（DRB）の選択、MTU（最大伝送ユニット）テスト、疑似ノードの作成、および隣接に関連するBFD（双方向転送検出）セッションのブートストラップにも関係します。必要に応じて状態図が含まれます。このドキュメントはRFC 6327を廃止し、RFC 6325を更新します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7177.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7177で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Content and Precedence .....................................5
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................6
2.1. RBridge Interconnection by Ethernet ........................6
2.2. Handling Native Frames .....................................7
2.3. Zero or Minimal Configuration ..............................8
2.4. MTU Robustness .............................................8
2.5. Purposes of the TRILL Hello Protocol .......................9
3. Adjacency State Machinery ......................................10
3.1. TRILL Hellos, Ports, and VLANs ............................10
3.2. Adjacency Table Entries and States ........................11
3.3. Adjacency and Hello Events ................................12
3.4. Adjacency State Diagram and Table .........................15
3.5. Multiple Parallel Links ...................................17
3.6. Insufficient Space in Adjacency Table .....................17
4. LAN Ports and DRB State ........................................17
4.1. Port Table Entries and DRB Election State .................18
4.2. DRB Election Events .......................................19
4.2.1. DRB Election Details ...............................20
4.2.2. Change in DRB ......................................20
4.2.3. Change in Designated VLAN ..........................21
4.3. Port State Table and Diagram ..............................21
5. MTU Matching ...................................................22
6. BFD-Enabled TLV and BFD Session Bootstrapping ..................24
7. Pseudonodes ....................................................25
8. More TRILL Hello Details .......................................26
8.1. Contents of TRILL Hellos ..................................27
8.2. Transmitting TRILL Hellos .................................27
8.2.1. TRILL Neighbor TLVs ................................28
8.3. Receiving TRILL Hellos ....................................29
9. Multiple Ports on the Same Broadcast Link ......................29
10. IANA Considerations ...........................................30
11. Security Considerations .......................................30
Appendix A. Changes from RFC 6327 .................................31
Appendix B. Changes to RFC 6325 ...................................31
Normative References...............................................32
Informative References.............................................33
Acknowledgements...................................................34
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during transient loops, and support for transmission of both unicast and multicast traffic taking advantage of multiple paths in multi-hop networks with arbitrary topology. End stations are connected to TRILL switches with Ethernet, but TRILL switches can be interconnected with arbitrary link technology. TRILL accomplishes this by using [IS-IS] (Intermediate System to Intermediate System) link-state routing [RFC1195] [RFC7176] and a header in TRILL Data packets that includes a hop count. The design supports data labeling by Virtual Local Area Networks (VLANs) and fine-grained labels [RFC7172] as well as optimization of the distribution of multi-destination frames based on data label and multicast groups. Devices that implement TRILL are called TRILL switches or RBridges (Routing Bridges).
多くのリンクのIETF透過的相互接続（TRILL）プロトコル[RFC6325]は、構成なしの最適なペアワイズデータフレーム転送、一時的なループ中でも安全な転送を提供し、マルチで複数のパスを利用してユニキャストとマルチキャストの両方のトラフィックの送信をサポートします任意のトポロジーを持つホップネットワーク。端末はイーサネットでTRILLスイッチに接続されますが、TRILLスイッチは任意のリンク技術で相互接続できます。 TRILLは、[IS-IS]（中間システムから中間システム）リンクステートルーティング[RFC1195] [RFC7176]およびホップカウントを含むTRILLデータパケットのヘッダーを使用してこれを実現します。この設計は、仮想ローカルエリアネットワーク（VLAN）によるデータラベリングときめの細かいラベル[RFC7172]をサポートし、データラベルとマルチキャストグループに基づく複数宛先フレームの配布の最適化もサポートします。 TRILLを実装するデバイスは、TRILLスイッチまたはRBridge（ルーティングブリッジ）と呼ばれます。
This document provides detailed specifications for five of the link-local aspects of the TRILL protocol used on broadcast links (also called LAN or multi-access links) and for the three of these aspects that are also used on point-to-point (P2P) links. It includes state diagrams and implementation details where appropriate. Alternative implementations that interoperate on the wire are permitted.
このドキュメントでは、ブロードキャストリンク（LANまたはマルチアクセスリンクとも呼ばれます）で使用されるTRILLプロトコルのリンクローカルな側面の5つと、ポイントツーポイント（P2P）でも使用されるこれらの側面の3つについて詳細な仕様を示します。 ）リンク。必要に応じて、状態図と実装の詳細が含まれます。ネットワーク上で相互運用する代替実装が許可されています。
The scope of this document is limited to the following aspects of the TRILL protocol; their applicability, along with the most relevant section of this document, are as shown here:
このドキュメントの範囲は、TRILLプロトコルの次の側面に限定されています。このドキュメントの最も関連性の高いセクションとともに、それらの適用性は次のとおりです。
LAN P2P Section Link-Local Aspect
--- --- ------- ----------------------------------------------
X X 3 Adjacency formation and dissolution X 4 DRB (Designated RBridge) election X X 5 MTU (Maximum Transmission Unit) matching X X 6 1-hop BFD (Bidirectional Forwarding Detection) for adjacency X 7 Creation and use of pseudonodes [IS-IS]
X X 3隣接の形成と解消X 4 DRB（指定RBridge）の選択X X 5 MTU（最大伝送ユニット）マッチングX X 6隣接の1ホップBFD（双方向転送検出）X 7疑似ノードの作成と使用[IS-IS]
Table 1: LAN/P2P Applicability
表1：LAN / P2Pの適用性
There is no DRB (also known as DIS (Designated Intermediate System)) election and no pseudonode creation on links configured as point-to-point.
DRB（DIS（Designated Intermediate System）とも呼ばれます）の選択や、ポイントツーポイントとして構成されたリンクでの疑似ノードの作成はありません。
For other aspects of the TRILL base protocol, see [RFC6325], [RFC6439], [RFC7180], and [ESADI].
TRILLベースプロトコルの他の側面については、[RFC6325]、[RFC6439]、[RFC7180]、および[ESADI]を参照してください。
This document obsoletes [RFC6327]. See Appendix A for a summary of changes from [RFC6327]. This document updates [RFC6325] as described in Appendix B.
このドキュメントは廃止されました[RFC6327]。 [RFC6327]からの変更点の概要については、付録Aを参照してください。このドキュメントは、付録Bで説明されているように[RFC6325]を更新します。
In cases of conflict between this document and [RFC6325], this document prevails.
このドキュメントと[RFC6325]の間に矛盾がある場合、このドキュメントが優先されます。
Section 2 below explains the rationale for the differences between the TRILL Hello protocol and the Layer 3 IS-IS Hello protocol in light of the environment for which the TRILL protocol is designed. It also describes the purposes of the TRILL Hello protocol.
以下のセクション2では、TRILLプロトコルが設計されている環境に照らして、TRILL Helloプロトコルとレイヤー3 IS-IS Helloプロトコルの違いの根拠について説明します。また、TRILL Helloプロトコルの目的についても説明します。
Section 3 describes the adjacency state machine, its states, and its relevant events.
セクション3では、隣接状態マシン、その状態、および関連するイベントについて説明します。
Section 4 describes the Designated RBridge (DRB) election state machine for RBridge LAN ports, its states, and its relevant events.
セクション4では、RBridge LANポートの指定RBridge（DRB）選択状態マシン、その状態、および関連イベントについて説明します。
Section 5 describes MTU testing and matching on a TRILL link.
セクション5では、MILLテストとTRILLリンクでのマッチングについて説明します。
Section 6 discusses one-hop BFD session bootstrapping in connection with adjacency.
セクション6では、隣接に関連した1ホップBFDセッションのブートストラップについて説明します。
Section 7 discusses pseudonode creation and use on LAN links.
セクション7では、LANリンクでの疑似ノードの作成と使用について説明します。
Section 8 provides more details on the reception and transmission of TRILL Hellos.
セクション8では、TRILL Helloの受信と送信について詳しく説明します。
Section 9 discusses the case of multiple ports from one RBridge on the same link.
セクション9では、同じリンク上の1つのRBridgeからの複数のポートの場合について説明します。
This document uses the acronyms defined in [RFC6325], supplemented by the following additional acronyms:
このドキュメントでは、[RFC6325]で定義されている頭字語を使用し、次の追加の頭字語を補足しています。
BFD - Bidirectional Forwarding Detection [RFC7175].
BFD-双方向転送検出[RFC7175]。
SNPA - Subnetwork Point of Attachment [IS-IS].
SNPA-アタッチメントのサブネットワークポイント[IS-IS]。
TRILL switch - an alternative name for an RBridge.
TRILLスイッチ-RBridgeの別名。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
[IS-IS] has subnetwork-independent functions and subnetwork-dependent functions. Currently, Layer 3 use of IS-IS supports two types of subnetworks: (1) point-to-point link subnetworks between routers and (2) general broadcast (LAN) subnetworks. Because of the differences between the environment of Layer 3 routers and the environment of TRILL RBridges, instead of the subnetwork-dependent functions used at Layer 3, which are specified in Sections 8.2 and 8.4 of [IS-IS], the TRILL protocol uses modified subnetwork-dependent functions for point-to-point subnetworks and broadcast (LAN) subnetworks. The differences between the TRILL and Layer 3 environments are described in Sections 2.1 through 2.4 followed by a summation, in Section 2.5, of the purposes of the TRILL Hello protocol.
[IS-IS]には、サブネットワークに依存しない機能とサブネットワークに依存する機能があります。現在、IS-ISのレイヤー3の使用は、2つのタイプのサブネットワークをサポートしています。（1）ルーター間のポイントツーポイントリンクサブネットワークと、（2）一般的なブロードキャスト（LAN）サブネットワークです。 [IS-IS]のセクション8.2と8.4で指定されている、レイヤー3で使用されるサブネットワーク依存の機能ではなく、レイヤー3ルーターの環境とTRILL RBridgesの環境の違いにより、TRILLプロトコルは変更されたポイントツーポイントサブネットワークおよびブロードキャスト（LAN）サブネットワーク用のサブネットワーク依存機能。 TRILL環境とレイヤー3環境の違いについては、セクション2.1から2.4で説明し、続いてセクション2.5でTRILL Helloプロトコルの目的を要約しています。
TRILL supports the interconnection of RBridges by multi-access LAN links such as Ethernet. Because this includes general bridged LANs [802.1Q], the links between RBridges may contain devices or services that can restrict VLAN connectivity, such as [802.1Q] bridges or carrier Ethernet services. In addition, RBridge Ethernet ports, like [802.1Q] ports, can be configured to restrict input/output on a VLAN basis.
TRILLは、イーサネットなどのマルチアクセスLANリンクによるRBridgeの相互接続をサポートしています。これには一般的なブリッジLAN [802.1Q]が含まれるため、RBridge間のリンクには、[802.1Q]ブリッジやキャリアイーサネットサービスなど、VLAN接続を制限できるデバイスまたはサービスが含まれる場合があります。さらに、[802.1Q]ポートなどのRBridgeイーサネットポートは、VLANベースで入出力を制限するように構成できます。
For this reason, TRILL Data and TRILL IS-IS packets are sent on Ethernet links in a Designated VLAN that is assumed to provide connectivity between all RBridges on the link. The Designated VLAN is dictated for a LAN link by the elected Designated RBridge on that link (DRB, equivalent to the Designated Intermediate System at Layer 3). On an RBridge Ethernet port configured as point-to-point, TRILL Data and IS-IS packets are sent in that port's Desired Designated VLAN, regardless of the state of any other ports on the link. Connectivity on an Ethernet link configured as point-to-point generally depends on both ends being configured with the same Desired Designated VLAN. Because TRILL Data packets flow between RBridges on an Ethernet link only in the link's Designated VLAN, adjacency for routing calculations is based only on connectivity characteristics in that VLAN.
このため、TRILLデータとTRILL IS-ISパケットは、リンク上のすべてのRBridge間の接続を提供すると想定されている指定VLANのイーサネットリンクで送信されます。指定VLANは、そのリンク上で選択された指定RBridge（DRB、レイヤー3の指定中間システムに相当）によってLANリンクに指示されます。ポイントツーポイントとして構成されたRBridgeイーサネットポートでは、リンク上の他のポートの状態に関係なく、TRILLデータとIS-ISパケットがそのポートの希望指定VLANで送信されます。ポイントツーポイントとして構成されたイーサネットリンクの接続は、通常、両端が同じ希望の指定VLANで構成されているかどうかに依存します。 TRILLデータパケットはイーサネットリンク上のRBridge間をリンクの指定VLANでのみ流れるため、ルーティング計算の隣接関係はそのVLANの接続特性のみに基づいています。
(Non-Ethernet links, such as PPP [RFC6361] generally do not have any Outer.VLAN labeling, so the Designated VLAN for such links has no effect.)
（PPP [RFC6361]などの非イーサネットリンクには通常、Outer.VLANラベルが付いていないため、このようなリンクの指定VLANは効果がありません。）
This section discusses the handling of "native" frames as defined in Section 1.4 of [RFC6325]. As such, this section is not applicable to point-to-point links between TRILL switches or any link where all the TRILL switch ports on the link have been configured as "trunk ports" by setting the end-station service disable bit for the port (see Section 4.9.1 of [RFC6325]).
このセクションでは、[RFC6325]のセクション1.4で定義されている「ネイティブ」フレームの処理について説明します。そのため、このセクションは、TRILLスイッチ間のポイントツーポイントリンクや、リンクのすべてのTRILLスイッチポートがポートのエンドステーションサービス無効化ビットを設定して「トランクポート」として構成されているリンクには適用されません。 （[RFC6325]のセクション4.9.1をご覧ください）。
Layer 3 data packets, such as IP packets, are already "tamed" when they are originated by an end station: they include a hop count and Layer 3 source and destination address fields. Furthermore, for ordinary data packets, there is no requirement to preserve any outer Layer 2 addressing, and, if the packets are unicast, they are explicitly addressed to their first-hop router.
IPパケットなどのレイヤ3データパケットは、エンドステーションから発信された時点ですでに「調律」されています。ホップカウントとレイヤ3送信元および宛先アドレスフィールドが含まれています。さらに、通常のデータパケットの場合、外側のレイヤ2アドレッシングを保持する必要はありません。パケットがユニキャストの場合、それらは最初のホップルーターに明示的にアドレス指定されます。
In contrast, TRILL switches must accept, transport, and deliver "untamed" native frames: native frames that lack a hop count field usable by TRILL and have Layer 2 MAC (Media Access Control) addresses that indicate their source and destination. These Layer 2 addresses must be preserved for delivery to the native frame's Layer 2 destination. One resulting difference is that RBridge ports providing native frame service must receive in promiscuous MAC address mode, while Layer 3 router ports typically receive in a selective MAC address mode.
対照的に、TRILLスイッチは、「アンタム」のネイティブフレームを受け入れ、転送し、配信する必要があります。ネイティブフレームには、TRILLで使用できるホップカウントフィールドがなく、送信元と宛先を示すレイヤー2 MAC（Media Access Control）アドレスがあります。これらのレイヤー2アドレスは、ネイティブフレームのレイヤー2宛先に配信するために保持する必要があります。結果として生じる1つの違いは、ネイティブフレームサービスを提供するRBridgeポートは無差別MACアドレスモードで受信する必要があるのに対し、レイヤー3ルーターポートは通常、選択的MACアドレスモードで受信することです。
TRILL handles these requirements by having, on the link where an end station originates a native frame, one RBridge "ingress" such a locally originated native frame by adding a TRILL Header that includes a hop count, thus converting it to a TRILL Data packet. This augmented packet is then routed to one RBridge on the link having the destination end station for the frame (or one RBridge on each such link if it is a multi-destination frame). Such final RBridges perform an "egress" function, removing the TRILL Header and delivering the original frame to its destination(s). (For the purposes of TRILL, a Layer 3 router is an end station.)
TRILLは、エンドステーションがネイティブフレームを発信するリンクで、ホップカウントを含むTRILLヘッダーを追加してTRILLデータパケットに変換することにより、そのようなローカルで発信されたネイティブフレームを1つのRBridgeに「入力」させることで、これらの要件を処理します。この拡張されたパケットは、フレームの宛先エンドステーションを持つリンク上の1つのRBridgeにルーティングされます（マルチ宛先フレームの場合は、そのような各リンク上の1つのRBridge）。このような最後のRBridgeは「出口」機能を実行し、TRILLヘッダーを削除して、元のフレームを宛先に配信します。 （TRILLの目的では、レイヤー3ルーターはエンドステーションです。）
Care must be taken to avoid a loop that would involve egressing a native frame and then re-ingressing it because, while it is in native form, it would not be protected by a hop count and could loop forever. Such a loop could, for multi-destination frames, even involve multiplication of the number of frames each time around and would likely saturate all links involved within milliseconds. For TRILL, safety against such loops for a link is more important than transient loss of data connectivity on that link.
ネイティブ形式の場合、ホップカウントによって保護されず、永久にループする可能性があるため、ネイティブフレームを出力してから再入力するループを回避するように注意する必要があります。このようなループは、複数の宛先フレームの場合、毎回フレーム数の乗算を伴うことさえあり、ミリ秒以内に関与するすべてのリンクを飽和させる可能性があります。 TRILLの場合、リンクのそのようなループに対する安全性は、そのリンクでのデータ接続の一時的な損失よりも重要です。
The primary TRILL defense mechanism against such loops, which is mandatory, is to assure that, as far as practically possible, there is only a single RBridge that is in charge of ingressing and egressing native frames from and to a link where TRILL is offering end-station service. This is the Designated RBridge and Appointed Forwarder mechanism initially specified in the TRILL base protocol [RFC6325], discussed in Section 2.5 below, and further specified in both Section 4 below and [RFC6439].
このようなループに対する必須のTRILL防御メカニズムは、必須ですが、実際には可能な限り、TRILLがエンドを提供しているリンクとの間のネイティブフレームの出入りを担当するRBridgeが1つだけであることを保証することです。 -駅サービス。これは、TRILLベースプロトコル[RFC6325]で最初に指定された、指定のRBridgeおよびAppointed Forwarderメカニズムであり、以下のセクション2.5で説明し、さらにセクション4と[RFC6439]の両方で指定します。
TRILL provides connectivity and least-cost paths with zero configuration. For additional services, it strives to require only minimal configuration; however, services that require configuration when offered by [802.1Q] bridges, such as non-default VLANs or priority, will require configuration. This differs from Layer 3 routing where routers typically need to be configured as to the subnetworks connected to each port, etc., to provide service.
TRILLは、ゼロ構成の接続と最小コストのパスを提供します。追加サービスについては、最小限の構成のみを要求するように努めています。ただし、デフォルト以外のVLANや優先度など、[802.1Q]ブリッジによって提供されるときに構成が必要なサービスは、構成が必要になります。これは、サービスを提供するために各ポートに接続されているサブネットワークなどに関してルーターを構成する必要があるレイヤー3ルーティングとは異なります。
TRILL IS-IS needs to be robust against links with reasonably restricted MTUs, including links that accommodate only the classic Ethernet frame size, despite the addition of reasonable headers such as VLAN tags. Such robustness is particularly required for TRILL Hellos to assure correct adjacency and the election of a unique DRB on LAN links.
VLANタグなどの適切なヘッダーが追加されているにもかかわらず、TRILL IS-ISは、クラシックイーサネットフレームサイズのみに対応するリンクを含む、MTUが合理的に制限されたリンクに対して堅牢である必要があります。このような堅牢性は、TRILL Helloが適切な隣接関係とLANリンク上の一意のDRBの選択を保証するために特に必要です。
TRILL will also be used inside data centers where it is common for all or most of the links and switches to support frames substantially larger than the classic Ethernet maximum size. For example, they may have an MTU adequate to comfortably handle Fiber Channel over Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE], or even 9K byte jumbo frames. It would be beneficial for a TRILL campus with such a large MTU to be able to safely make use of it.
TRILLは、すべてのまたはほとんどのリンクとスイッチが従来のイーサネットの最大サイズより大幅に大きいフレームをサポートすることが一般的であるデータセンター内でも使用されます。たとえば、Fibre Channel over Ethernetフレームを快適に処理するのに十分なMTUがあり、T11は2,500バイトのMTU [FCoE]、または9Kバイトのジャンボフレームを推奨しています。このような大きなMTUを持つTRILLキャンパスが安全にそれを利用できることは有益です。
These needs are met by a mandatory maximum on the size of TRILL Hellos and by the optional use of MTU testing as described below.
これらのニーズは、TRILL Helloのサイズの必須の最大値と、以下で説明するMTUテストのオプションの使用によって満たされます。
There are three purposes for the TRILL Hello protocol. They are listed below, along with a reference to the section of this document in which each is discussed:
TRILL Helloプロトコルには3つの目的があります。以下に、それぞれについて説明するこのドキュメントのセクションへの参照とともに、それらを示します。
1. To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
1. トポロジの一部として報告される接続が許容できるRBridgeネイバーを特定するには（セクション3）
2. To elect a unique Designated RBridge on broadcast (LAN) links (Section 4)
2. ブロードキャスト（LAN）リンクで一意の指定RBridgeを選択するには（セクション4）
3. To determine the MTU with which it is possible to safely communicate with each RBridge neighbor (Section 5)
3. 各RBridgeネイバーと安全に通信できるMTUを決定するには（セクション5）
In Layer 3 IS-IS, all three of these functions are combined. Hellos may be padded to the maximum length (see [RFC3719], Section 6) so that a router neighbor is not discovered if it is impossible to communicate with it using maximum-sized Layer 3 IS-IS packets. Also, even if Hellos from a neighbor R2 are received by R1, if connectivity to R2 is not 2-way (i.e., R2 does not list R1 in R2's Hello), then R1 does not consider R2 as a Designated Intermediate System (Designated Router) candidate. Because of this logic, it is possible at Layer 3 for multiple Designated Routers to be elected on a LAN, with each representing the LAN as a pseudonode. It appears to the topology as if the LAN is now two or more separate LANs. Although this is surprising, this does not cause problems for Layer 3.
レイヤ3 IS-ISでは、これら3つの機能がすべて組み合わされています。最大サイズのレイヤー3 IS-ISパケットを使用して通信できない場合、ルーターのネイバーが検出されないように、helloは最大長までパディングされる場合があります（[RFC3719]、セクション6を参照）。また、ネイバーR2からのHelloがR1によって受信された場合でも、R2への接続が双方向でない場合（つまり、R2はR2のHelloにR1をリストしない）、R1はR2を指定中間システム（指定ルーター）と見なしません。 ）候補者。このロジックのため、レイヤ3では、LANを擬似ノードとして表す複数の指定ルーターをLANで選択することができます。トポロジからは、LANが2つ以上の別個のLANであるかのように見えます。これは驚くべきことですが、レイヤー3で問題が発生することはありません。
In contrast, this behavior is not acceptable for TRILL, since in TRILL it is important that all RBridges on a link know about each other, and on broadcast (LAN) links that they choose a single RBridge to be the DRB to control the native frame ingress and egress. Otherwise, multiple RBridges might ingress/egress the same native frame, forming loops that are not protected by the hop count in the TRILL Header as discussed above.
対照的に、TRILLではリンク上のすべてのRBridgeが相互に認識していること、およびブロードキャスト（LAN）リンク上でネイティブフレームを制御するDRBとして単一のRBridgeを選択することが重要であるため、この動作はTRILLでは受け入れられません。入口と出口。そうしないと、複数のRBridgeが同じネイティブフレームに出入りして、上記で説明したTRILLヘッダーのホップカウントによって保護されないループを形成する可能性があります。
The TRILL Hello protocol is best understood by focusing separately on each of these three functions listed above, which we do in Sections 3, 4, and 5.
TRILL Helloプロトコルは、セクション3、4、および5で行う上記の3つの機能のそれぞれに個別に焦点を当てることによって最もよく理解されます。
One other issue with TRILL LAN Hellos is to ensure that subsets of the information can appear in any single message, and be processable, in the spirit of IS-IS Link State PDUs (LSPs) and Complete Sequence Number PDUs (CSNPs). LAN TRILL Hello packets, even though they are not padded, can become very large. An example where this might be the case is when some sort of backbone technology interconnects hundreds of TRILL sites over what would appear to TRILL to be a giant Ethernet, where the RBridges connected to that cloud will perceive that backbone to be a single link with hundreds of neighbors. Thus, the TRILL LAN Hello uses a different Neighbor TLV [RFC7176] that lists neighbors seen for a range of MAC (SNPA) addresses.
TRILL LAN Helloのもう1つの問題は、IS-ISリンクステートPDU（LSP）および完全シーケンス番号PDU（CSNP）の精神で、情報のサブセットが単一のメッセージに表示され、処理可能であることを確認することです。 LAN TRILL Helloパケットは、パディングされていなくても、非常に大きくなる可能性があります。これが当てはまる例は、ある種のバックボーンテクノロジーが、TRILLから巨大なイーサネットであると思われるものを介して何百ものTRILLサイトを相互接続する場合です。そのクラウドに接続されたRBridgeは、そのバックボーンが数百の単一のリンクであると認識します。隣人の。したがって、TRILL LAN Helloは、MAC（SNPA）アドレスの範囲で見られるネイバーをリストする別のネイバーTLV [RFC7176]を使用します。
Each RBridge port has associated with it a port state, as discussed in Section 4, and a table of zero or more adjacencies (if the port is configured as point-to-point, zero, or one) as discussed in this section. The states such adjacencies can have, the events that cause adjacency state changes, the actions associated with those state changes, a state table, and a state diagram are given below.
セクション4で説明するように、各RBridgeポートにはポート状態が関連付けられており、このセクションで説明するように、ゼロ以上の隣接関係（ポートがポイントツーポイント、ゼロ、または1として構成されている場合）のテーブルが関連付けられています。このような隣接関係が持つ可能性のある状態、隣接状態の変化を引き起こすイベント、それらの状態変化に関連するアクション、状態テーブル、および状態図を以下に示します。
The determination of adjacencies on links is made using TRILL Hellos (see Section 8), an optional MTU test (see Section 5), and, optionally, BFD (see Section 6) and/or other connectivity tests. If the MAC (SNPA) addresses of more than one RBridge port on a broadcast link are the same, all but one of such ports are put in the Suspended state (see Section 4) and do not participate in the link, except to monitor whether they should stay suspended. If the two ports on a point-to-point link have MAC (SNPA) addresses, it does not affect TRILL operation if they are the same. (PPP ports, for example, do not have MAC addresses [RFC6361].)
リンク上の隣接関係の決定は、TRILL Hellos（セクション8を参照）、オプションのMTUテスト（セクション5を参照）、およびオプションでBFD（セクション6を参照）および/またはその他の接続テストを使用して行われます。ブロードキャストリンクの複数のRBridgeポートのMAC（SNPA）アドレスが同じである場合、そのようなポートの1つを除いてすべてが一時停止状態になり（セクション4を参照）、リンクに参加しません。彼らは一時停止しなければなりません。ポイントツーポイントリンクの2つのポートにMAC（SNPA）アドレスがある場合、それらが同じであればTRILL操作に影響しません。 （たとえば、PPPポートにはMACアドレスがありません[RFC6361]。）
The following items MUST be the same for all TRILL Hellos issued by an RBridge on a particular Ethernet port, regardless of the VLAN in which the Hello is sent:
次の項目は、Helloが送信されるVLANに関係なく、特定のイーサネットポートのRBridgeによって発行されるすべてのTRILL Helloで同じである必要があります。
- Source MAC address,
- 送信元MACアドレス、
- Priority to be the DRB,
- DRBであることの優先順位、
- Desired Designated VLAN,
- 必要な指定VLAN、
- Port ID, and,
- ポートID、および
- if included, BFD-Enabled TLV [RFC6213] and PORT-TRILL-VER sub-TLV [RFC7176].
- 含まれている場合、BFD対応TLV [RFC6213]およびPORT-TRILL-VERサブTLV [RFC7176]。
Of course, the priority, Desired Designated VLAN, and possibly the inclusion or value of the PORT-TRILL-VER sub-TLV, and/or BFD-Enabled TLV can change on occasion, but then the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN.
もちろん、優先度、Desired Designated VLAN、および場合によってはPORT-TRILL-VERサブTLVの包含または値、BFD対応TLVが時々変更される可能性がありますが、新しい値も同様に変更する必要がありますVLANに関係なく、LANポート上のすべてのTRILL Helloで使用されます。
On broadcast links:
ブロードキャストリンク：
Because bridges acting as glue on an Ethernet broadcast link might be configured in such a way that some VLANs are partitioned, it is necessary for RBridges to transmit Hellos on Ethernet links with multiple VLAN tags. The conceptually simplest solution may have been to have RBridges transmit up to 4,094 times as many Hellos, one with each legal VLAN ID enabled at each port, but this would obviously have deleterious performance implications. So, the TRILL protocol specifies that if RB1 knows it is not the DRB, it transmits its Hellos on only a limited set of VLANs. Only an RBridge that believes itself to be the DRB on a broadcast Ethernet link "sprays" its TRILL Hellos on all of its enabled VLANs at the port. And in both cases, an RBridge can be configured to send Hellos on only a subset of those VLANs. The details are given in [RFC6325], Section 4.4.3.
イーサネットブロードキャストリンクで接着剤として機能するブリッジは、一部のVLANが分割されるように構成されている場合があるため、RBridgeが複数のVLANタグを持つイーサネットリンクでHelloを送信する必要があります。概念的に最も簡単なソリューションは、RBridgeが最大4,094倍のHelloを送信し、各ポートで有効な各VLAN IDを有効にすることでしたが、これは明らかにパフォーマンスに悪影響を及ぼします。そのため、TRILLプロトコルは、RB1ではないことがRB1に認識されている場合、限られたVLANセットでのみHelloを送信することを指定しています。ブロードキャストイーサネットリンク上のDRBであると信じるRBridgeのみが、ポートで有効になっているすべてのVLANにTRILL Helloを「スプレー」します。また、どちらの場合も、これらのVLANのサブセットのみでHelloを送信するようにRBridgeを構成できます。詳細は[RFC6325]のセクション4.4.3に記載されています。
On point-to-point links:
ポイントツーポイントリンク：
If the link technology is VLAN sensitive, such as Ethernet, an RBridge sends TRILL Hellos only in the Desired Designated VLAN for which it is configured.
リンク技術がイーサネットなどのVLANセンシティブである場合、RBridgeは、それが構成されている必要な指定VLANでのみTRILL Helloを送信します。
Every adjacency is in one of four states, whether it is one of the adjacencies on a broadcast link or the one possible adjacency on a point-to-point link. An RBridge participates in LSP synchronization at a port as long as it has one or more adjacencies out of that port that are in the 2-Way or Report state.
すべての隣接関係は、ブロードキャストリンク上の隣接関係の1つであっても、ポイントツーポイントリンク上の可能な隣接関係の1つであっても、4つの状態のいずれかにあります。 RBridgeは、ポートから2ウェイまたはレポート状態にある1つ以上の隣接関係がある限り、ポートでのLSP同期に参加します。
Down: This is a virtual state for convenience in creating state diagrams and tables. It indicates that the adjacency is nonexistent, and there is no entry in the adjacency table for it.
Down：これは、状態図とテーブルを作成するのに便利な仮想状態です。これは、隣接関係が存在せず、隣接関係テーブルにエントリがないことを示しています。
Detect: A neighbor RBridge has been detected through receipt of a TRILL Hello, but either 2-way connectivity has not been confirmed or the detection was on an Ethernet link in a VLAN other than the Designated VLAN.
検出：TRILL Helloの受信を通じて隣接RBridgeが検出されましたが、双方向接続が確認されていないか、指定VLAN以外のVLANのイーサネットリンクで検出されていました。
2-Way: 2-way connectivity to the neighbor has been found and, if the link is Ethernet, it was found on the Designated VLAN, but some enabled test, such as the link MTU meeting the minimum campus requirement or BFD confirming link connectivity, has not yet succeeded.
双方向：ネイバーへの双方向接続が見つかり、リンクがイーサネットの場合は指定VLANで見つかりましたが、最小キャンパス要件を満たすリンクMTUまたはリンク接続を確認するBFDなど、いくつかの有効なテスト、まだ成功していません。
Report: There is 2-way connectivity to the neighbor (on the Designated VLAN if an Ethernet link); all enabled tests have succeeded, including, if enabled, MTU and/or BFD testing. This state will cause adjacency to be reported in an LSP (with appropriate provision for a pseudonode, if any, as described in Section 7).
レポート：ネイバーへの双方向接続があります（イーサネットリンクの場合、指定VLAN上）。有効な場合、MTUおよび/またはBFDテストを含むすべての有効なテストが成功しました。この状態が発生すると、LSPで隣接関係が報告されます（セクション7で説明されているように、疑似ノードがある場合は、適切なプロビジョニングが行われます）。
For an adjacency in any of the three non-Down states (Detect, 2-Way, or Report), there will be an adjacency table entry. That entry will give the state of the adjacency and will also include the information listed below.
3つの非ダウン状態（検出、双方向、またはレポート）のいずれかの隣接関係の場合、隣接関係テーブルエントリがあります。このエントリは隣接関係の状態を示し、以下の情報も含まれます。
o The address, if any, of the neighbor, the Port ID, and the System ID in the received Hellos. Together, these three quantities uniquely identify the adjacency on a broadcast link.
o 受信したHello内のネイバーのアドレス（存在する場合）、ポートID、およびシステムID。これらの3つの量を合わせて、ブロードキャストリンクの隣接関係を一意に識別します。
o One or more Hello holding timers. For a point-to-point adjacency, there is a single Hello holding timer. For a broadcast LAN adjacency, there are exactly two Hello holding timers: a Designated VLAN holding timer and a non-Designated VLAN holding timer. Each timer consists of a 16-bit unsigned integer number of seconds.
o 1つ以上のHello保持タイマー。ポイントツーポイント隣接の場合、単一のHello保持タイマーがあります。ブロードキャストLAN隣接の場合、Hello保持タイマーが2つあります。指定VLAN保持タイマーと非指定VLAN保持タイマーです。各タイマーは、16ビットの符号なし整数の秒数で構成されています。
o If the adjacency is on a broadcast link, the 7-bit unsigned priority of the neighbor to be the DRB.
o 隣接関係がブロードキャストリンク上にある場合、ネイバーの7ビットの符号なし優先順位がDRBになります。
o The 5 bytes of data from the PORT-TRILL-VER received in the most recent TRILL Hello from the neighbor RBridge.
o ネイバーRBridgeからの最新のTRILL Helloで受信したPORT-TRILL-VERからの5バイトのデータ。
o The VLAN that the neighbor RBridge wants to be the Designated VLAN on the link, called the Desired Designated VLAN.
o ネイバーRBridgeがリンク上の指定VLANになりたいVLAN。これは、Desired Designated VLANと呼ばれます。
o For an adjacency table at an RBridge that supports BFD, a flag indicating whether the last received TRILL Hello from the neighbor RBridge contained a BFD-Enabled TLV (see Section 6).
o BFDをサポートするRBridgeの隣接テーブルの場合、ネイバーRBridgeから最後に受信したTRILL HelloがBFD対応TLVを含んでいたかどうかを示すフラグ（セクション6を参照）。
The following events can change the state of an adjacency:
次のイベントは、隣接の状態を変更する可能性があります。
A0. Receive a TRILL Hello for a broadcast LAN adjacency whose source MAC address (SNPA) is equal to that of the port on which it is received. This is a special event that cannot occur on a port configured as point-to-point and is handled as described immediately after this list of events. It does not appear in the state transition table or diagram.
A0。送信元MACアドレス（SNPA）が受信ポートのアドレスと同じであるブロードキャストLAN隣接のTRILL Helloを受信します。これは、ポイントツーポイントとして構成されたポートでは発生しない特別なイベントであり、このイベントのリストの直後に説明されているように処理されます。状態遷移表や図には表示されません。
A1. Receive a TRILL Hello (other than an A0 event) such that:
A1。次のようなTRILL Hello（A0イベント以外）を受信します。
- If received on an Ethernet port, it was received in the Designated VLAN.
- イーサネットポートで受信した場合、指定VLANで受信されました。
- If received for a broadcast LAN adjacency, it contains a TRILL Neighbor TLV that explicitly lists the receiving port's (SNPA) address.
- ブロードキャストLAN隣接で受信された場合、受信ポートの（SNPA）アドレスを明示的にリストするTRILLネイバーTLVが含まれます。
- If received for a point-to-point adjacency, it contains a Three-Way Handshake TLV with the receiver's System ID and Extended Circuit ID.
- ポイントツーポイント隣接で受信された場合、受信側のシステムIDと拡張回線IDを含むスリーウェイハンドシェイクTLVが含まれています。
A2. Event A2 is not possible for a port configured as point-to-point. Receive a TRILL Hello (other than an A0 event) such that either
A2。イベント間A2は、ポイントツーポイントとして構成されたポートでは不可能です。 TRILL Hello（A0イベント以外）を受け取る
- The port is Ethernet and the Hello was not on the Designated VLAN (any TRILL Neighbor TLV in such a Hello is ignored), or
- ポートがイーサネットであり、Helloが指定VLAN上になかった（そのようなHelloのTRILLネイバーTLVは無視されます）、または
- The Hello does not contain a TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address.
- Helloには、受信者の（SNPA）アドレスを含むアドレス範囲をカバーするTRILL Neighbor TLVは含まれていません。
A3. Receive a TRILL Hello (other than an A0 event) such that:
A3。次のようなTRILL Hello（A0イベント以外）を受信します。
- If received on an Ethernet port, it was received in the Designated VLAN.
- イーサネットポートで受信した場合、指定VLANで受信されました。
- If received for a broadcast LAN adjacency, it contains one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address and none of which list the receiver.
- ブロードキャストLAN隣接で受信された場合、これには、レシーバー（SNPA）アドレスを含み、レシーバーをリストしないアドレス範囲をカバーする1つ以上のTRILLネイバーTLVが含まれます。
- If received for a point-to-point adjacency, it contains a Three-Way Handshake TLV with either the System ID or Extended Circuit ID or both not equal to that of the receiver.
- ポイントツーポイント隣接で受信された場合は、システムIDまたは拡張回線IDのいずれか、あるいはその両方がレシーバーと異なるスリーウェイハンドシェイクTLVが含まれています。
A4. Either
A4。 Ευθερ
(1) the Hello holding timer expires on a point-to-point adjacency, or
（1）ポイントツーポイント隣接でHello保持タイマーが期限切れになる、または
(2) on a broadcast LAN adjacency,
（2）ブロードキャストLAN隣接では、
(2a) both Hello timers expire simultaneously or
（2a）両方のHelloタイマーが同時に期限切れになる、または
(2b) one Hello timer expires when the other Hello timer is already in the expired state.
（2b）1つのHelloタイマーは、もう1つのHelloタイマーがすでに期限切れ状態になっているときに期限切れになります。
A5. For a broadcast LAN adjacency, the Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left until it expires. This event cannot occur for a point-to-point adjacency.
A5。ブロードキャストLAN隣接の場合、指定VLAN Hello保持タイマーは期限切れになりますが、非指定VLAN Hello保持タイマーは、期限が切れるまで残ります。このイベントは、ポイントツーポイント隣接では発生しません。
A6. MTU if enabled, BFD if enabled, and all other enabled connectivity tests successful.
A6。 MTUが有効な場合、BFDが有効な場合、他のすべての有効な接続テストが成功します。
A7. MTU if enabled, BFD if enabled, and all other enabled connectivity tests were successful but one or more now fail.
A7。 MTUが有効な場合、BFDが有効な場合、および他のすべての有効な接続テストは成功しましたが、1つ以上が失敗しました。
A8. The RBridge port goes operationally down.
A8。 RBridgeポートが操作上ダウンしています。
For the special A0 event, the Hello is examined to determine if it has a higher priority than the port on which it is received such that the sending port should be the DRB as described in Section 4.2.1. If the Hello is of lower priority than the receiving port, it is discarded with no further action. If it is of higher priority than the receiving port, then any adjacencies for the receiving port are discarded (transitioned to the Down state), and the port is suspended as described in Section 4.2.
特別なA0イベントの場合、Helloは、セクション4.2.1で説明するように、送信ポートがDRBになるように、Helloが受信されたポートよりも優先度が高いかどうかを判断するために検査されます。 Helloの優先順位が受信ポートよりも低い場合、それは廃棄され、それ以上のアクションは行われません。受信ポートよりも優先度が高い場合、受信ポートの隣接関係はすべて破棄され（ダウン状態に移行）、セクション4.2で説明されているようにポートが一時停止されます。
The receipt of a TRILL Hello that is not an event A0 causes the following actions (except where the Hello would have created a new adjacency table entry but both the adjacency table is full and the Hello is too low priority to displace an existing entry as described in Section 3.6). The Designated VLAN referred to is the Designated VLAN dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4) for a broadcast LAN and the local Desired Designated VLAN for a port configured as point-to-point.
イベントA0ではないTRILL Helloを受信すると、次のアクションが発生します（Helloが新しい隣接テーブルエントリを作成したが、隣接テーブルがいっぱいで、Helloの優先度が低すぎて、説明されているように既存のエントリを置き換えられない場合を除くセクション3.6）。参照される指定VLANは、ブロードキャストLANの場合は受信したTRILL LAN Hello（セクション4を参照）を考慮せずに決定されたDRBによって指示される指定VLANであり、ポイントツーポイントとして構成されたポートの場合はローカルのDesired Designated VLANです。
o If the receipt of a Hello creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address (if any), Port ID, and System ID are set from the Hello.
o Helloを受信すると、新しい隣接テーブルエントリが作成され、ネイバーRBridge MAC（SNPA）アドレス（存在する場合）、ポートID、およびシステムIDがHelloから設定されます。
o For a point-to-point adjacency, the Hello holding timer is set from the Holding Time field of the Hello. For a broadcast link adjacency, the appropriate Hello holding timer for that adjacency, depending on whether or not the Hello was received in the Designated VLAN, is set to the Holding Time field of the Hello and if the receipt of the LAN Hello is creating a new adjacency table entry, the other timer is set to expired.
o ポイントツーポイント隣接の場合、Hello保持タイマーは、Helloの[Holding Time]フィールドから設定されます。ブロードキャストリンク隣接の場合、HelloがDesignated VLANで受信されたかどうかに応じて、その隣接の適切なHello保持タイマーがHelloの[Holding Time]フィールドに設定され、LAN Helloの受信により、新しい隣接テーブルエントリ、他のタイマーは期限切れに設定されます。
o For a broadcast link adjacency, the priority of the neighbor RBridge to be the DRB is set to the priority field of the LAN Hello.
o ブロードキャストリンク隣接の場合、DRBになるネイバーRBridgeの優先度は、LAN Helloの優先度フィールドに設定されます。
o For a broadcast link adjacency, the VLAN that the neighbor RBridge wants to be the Designated VLAN on the link is set from the Hello.
o ブロードキャストリンク隣接の場合、ネイバーRBridgeがリンク上の指定VLANになりたいVLANは、Helloから設定されます。
o The 5 bytes of PORT-TRILL-VER data are set from that sub-TLV in the Hello or set to zero if that sub-TLV does not occur in the Hello.
o 5バイトのPORT-TRILL-VERデータは、HelloでそのサブTLVから設定されるか、HelloでそのサブTLVが発生しない場合はゼロに設定されます。
o For a broadcast link, if the creation of a new adjacency table entry or the priority update above changes the results of the DRB election on the link, the appropriate RBridge port event (D2 or D3) occurs, after the above actions, as described in Section 4.2.
o ブロードキャストリンクの場合、上記の新しい隣接テーブルエントリの作成または上記の優先度の更新によりリンクのDRB選択の結果が変更されると、上記のアクションの後に、適切なRBridgeポートイベント（D2またはD3）が発生します。セクション4.2
o For a broadcast link adjacency, if there is no change in the DRB, but the neighbor Hello is from the DRB and has a changed Designated VLAN from the previous Hello received from the DRB, the result is a change in Designated VLAN for the link as specified in Section 4.2.3.
o ブロードキャストリンク隣接の場合、DRBに変更はないが、ネイバーHelloがDRBからのものであり、DRBから受信した前のHelloから変更された指定VLANがある場合、結果として、リンクの指定VLANが変更されます。セクション4.2.3で指定。
An event A4 resulting in the adjacency transitioning to the Down state may also result in an event D3 as described in Section 4.2.
隣接関係がダウン状態に遷移する結果となるイベントA4は、セクション4.2で説明されているように、イベントD3にもなる場合があります。
Concerning events A6 and A7, if none of MTU, BFD, or other testing is enabled, A6 is considered to occur immediately upon the adjacency entering the 2-Way state, and A7 cannot occur.
イベントA6とA7に関して、MTU、BFD、またはその他のテストがいずれも有効になっていない場合、A6は隣接が2-Way状態になった直後に発生すると見なされ、A7は発生しません。
See further TRILL Hello receipt details in Section 8.
セクション8のTRILL Helloレシートの詳細を参照してください。
The table below shows the transitions between the states defined above, based on the events defined above:
以下の表は、上記で定義されたイベントに基づいた、上記で定義された状態間の遷移を示しています。
| Event | Down | Detect | 2-Way | Report |
+-------+--------+--------+--------+--------+
| A1 | 2-Way | 2-Way | 2-Way | Report |
| A2 | Detect | Detect | 2-Way | Report |
| A3 | Detect | Detect | Detect | Detect |
| A4 | N/A | Down | Down | Down |
| A5 | N/A | Detect | Detect | Detect |
| A6 | N/A | N/A | Report | Report |
| A7 | N/A | N/A | 2-Way | 2-Way |
| A8 | Down | Down | Down | Down |
Table 2: Adjacency State Table
表2：隣接状態テーブル
"N/A" indicates that the event to the left is not applicable in the state at the top of the column. These events affect only a single adjacency. The special A0 event transitions all adjacencies to Down, as explained immediately after the list of adjacency events in Section 3.3.
「N / A」は、左側のイベントが列の上部の状態に該当しないことを示します。これらのイベントは単一の隣接にのみ影響します。セクション3.3の隣接イベントのリストの直後に説明されているように、特別なA0イベントはすべての隣接をダウンに移行します。
The diagram below presents the same information as that in the state table:
以下の図は、状態テーブルと同じ情報を示しています。
+---------------+
| Down |<--------+
+---------------+ |
| | ^ | |
A2,A3| |A8| |A1 |
| +--+ | |
| +-----------|---+
V | |
+----------------+ A4,A8 | |
+----->| Detect |------->| |
| +----------------+ | |
| | | ^ | |
| A1| |A2,A3,A5 | | |
| | +---------+ | |
| | | |
| | +------------|---+
| | | |
| V V |
|A3,A5 +----------------+ A4,A8 |
|<-----| 2-Way |------->|
| +----------------+ |
| | ^ | ^ |
| A6| | |A1,A2,A7| |
| | | +--------+ |
| | | |
| | |A7 |
| V | |
|A3,A5 +-------------+ A4,A8 |
|<-----| Report |---------->|
+-------------+
| ^
|A1,A2,A6 |
+---------+
Figure 1: Adjacency State Diagram
図1：隣接状態図
There can be multiple parallel adjacencies between neighbor RBridges that are visible to TRILL. (Multiple low-level links that have been bonded together by technologies such as link aggregation [802.1AX] appear to TRILL as a single link over which only a single TRILL adjacency can be established.)
TRILLから見える隣接するRBridge間に複数の並列隣接関係が存在する可能性があります。 （リンク集約[802.1AX]などのテクノロジーによって結合された複数の低レベルリンクは、単一のTRILL隣接のみを確立できる単一のリンクとしてTRILLに表示されます。）
Any such links that have pseudonodes (see Section 7) are distinguished in the topology; such adjacencies, if they are in the Report state, appear in LSPs as per Section 7. However, there can be multiple parallel adjacencies without pseudonodes because they are point-to-point adjacencies or LAN adjacencies for which a pseudonode is not being created. Such parallel, non-pseudonode adjacencies in the Report state appear in LSPs as a single adjacency. The cost of such an adjacency MAY be adjusted downwards to account for the parallel paths. Multipathing across such parallel connections can be freely done for unicast TRILL Data traffic on a per-flow basis but is restricted for multi-destination traffic, as described in Section 4.5.2 (point 3) of [RFC6325] and Appendix C of [RFC6325].
疑似ノード（セクション7を参照）を持つそのようなリンクは、トポロジーで区別されます。このような隣接関係は、レポート状態の場合、セクション7のようにLSPに表示されます。ただし、疑似ノードが作成されていないポイントツーポイント隣接またはLAN隣接であるため、疑似ノードのない複数の並列隣接が存在する可能性があります。 Report状態にあるこのような並列の非疑似ノード隣接は、LSPでは単一の隣接として表示されます。このような隣接のコストは、並列パスを考慮して下方に調整される場合があります。 [RFC6325]のセクション4.5.2（ポイント3）および[RFC6325]の付録Cで説明されているように、このような並列接続を介したマルチパスは、フローごとにユニキャストTRILLデータトラフィックに対して自由に実行できますが、マルチ宛先トラフィックに対して制限されます。 ]。
If the receipt of a TRILL Hello would create a new adjacency table entry (that is, would transition an adjacency out of the Down state), there may be no space for the new entry. For ports that are configured as point-to-point and can thus only have zero or one adjacency not in the Down state, it is RECOMMENDED that space be reserved for one adjacency so that this condition cannot occur.
TRILL Helloを受信すると、新しい隣接テーブルエントリが作成される（つまり、隣接がダウン状態から移行する）場合、新しいエントリ用のスペースがない可能性があります。ポイントツーポイントとして構成されているため、隣接状態がゼロまたは1つしかなく、ダウン状態になっていないポートでは、この状態が発生しないように、1つの隣接用にスペースを予約することをお勧めします。
When there is adjacency table space exhaustion, the DRB election priority (see Section 4.2.1) of the new entry that would be created is compared with the DRB election priority for the existing entries. If the new entry is higher priority than the lowest priority existing entry, it replaces the lowest priority existing entry, which is transitioned to the Down state.
隣接するテーブルスペースが枯渇すると、作成される新しいエントリのDRB選択優先度（セクション4.2.1を参照）が、既存のエントリのDRB選択優先度と比較されます。新しいエントリの優先度が、最も低い優先度の既存のエントリよりも高い場合は、最も低い優先度の既存のエントリが置き換えられ、Down状態に移行します。
This section specifies the DRB election process in TRILL at a broadcast (LAN) link port. Since there is no such election when a port is configured as point-to-point, this section does not apply in that case.
このセクションでは、ブロードキャスト（LAN）リンクポートでのTRILLのDRB選定プロセスを指定します。ポートがポイントツーポイントとして設定されている場合、そのような選択は行われないため、このセクションはその場合には適用されません。
The information at an RBridge associated with each of its broadcast LAN ports includes the following:
各ブロードキャストLANポートに関連付けられているRBridgeの情報には、以下が含まれます。
o Enablement bit, which defaults to enabled.
o デフォルトで有効になっている有効化ビット。
o The 5 bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos sent on the port.
o ポートで送信されるTRILL Helloで使用される5バイトのPORT-TRILL-VERサブTLVデータ。
o SNPA address (commonly a 48-bit MAC address) of the port.
o ポートのSNPAアドレス（通常は48ビットMACアドレス）。
o Port ID, used in TRILL Hellos sent on the port.
o ポートで送信されるTRILL Hellosで使用されるポートID。
o The Holding Time, used in TRILL Hellos sent on the port.
o ポートで送信されるTRILL Hellosで使用される保持時間。
o The priority to be the DRB, used in TRILL LAN Hellos sent on the port.
o DRBとなる優先度。ポートで送信されるTRILL LAN Helloで使用されます。
o BFD support. If the port supports BFD, a BFD Enabled flag that controls whether or not a BFD-Enabled TLV is included in TRILL Hellos sent on the port.
o BFDサポート。ポートがBFDをサポートしている場合、BFD対応TLVがポートで送信されるTRILL Helloに含まれるかどうかを制御するBFD有効フラグ。
o The DRB state of the port, determined as specified below.
o 以下で指定されているように決定された、ポートのDRB状態。
o A 16-bit unsigned Suspension Timer, measured in seconds.
o 秒単位で測定される、16ビットの符号なしサスペンションタイマー。
o The Desired Designated VLAN. The VLAN this RBridge wants to be the Designated VLAN for the link out of this port, used in TRILL Hellos sent on the port if the link is Ethernet.
o 必要な指定VLAN。このRBridgeがこのポートからのリンクの指定VLANになりたいVLAN。リンクがイーサネットの場合にポートで送信されるTRILL Helloで使用されます。
o A table of zero or more adjacencies (see Section 3).
o ゼロ以上の隣接関係の表（セクション3を参照）。
The TRILL equivalent of the DIS (Designated Intermediate System) on a broadcast link is the DRB or Designated RBridge. The DRB election state machinery is described below.
ブロードキャストリンクのDIS（指定中間システム）に相当するTRILLは、DRBまたは指定RBridgeです。 DRB選択状態の機構については、以下で説明します。
Each RBridge port that is not configured as point-to-point is in one of the following four DRB states:
ポイントツーポイントとして構成されていない各RBridgeポートは、次の4つのDRB状態のいずれかになります。
Down: The port is operationally down. It might be administratively disabled or down at the link layer. In this state, there will be no adjacencies for the port, and no TRILL Hellos or other TRILL IS-IS PDUs or TRILL Data packets are accepted or transmitted.
Down：ポートは操作上ダウンしています。リンク層で管理上無効になっているか、ダウンしている可能性があります。この状態では、ポートの隣接関係はなく、TRILL Helloや他のTRILL IS-IS PDUやTRILLデータパケットは受け入れられず、送信もされません。
Suspended: Operation of the port is suspended because there is a higher priority port on the link with the same MAC (SNPA) address. This is the same as the Down state, with the exception that TRILL Hellos are accepted for the sole purpose of determining whether to change the value of the Suspension Timer for the port as described below.
一時停止：同じMAC（SNPA）アドレスを持つリンク上に優先度の高いポートがあるため、ポートの操作が一時停止されています。これはダウン状態と同じですが、以下で説明するように、ポートのサスペンドタイマーの値を変更するかどうかを決定するためだけにTRILL Helloが受け入れられる点が異なります。
DRB: The port is the DRB and can receive and transmit TRILL Data packets.
DRB：ポートはDRBであり、TRILLデータパケットを送受信できます。
Not DRB: The port is deferring to another port on the link, which it believes is the DRB, but can still receive and transmit TRILL Data packets.
DRBではない：ポートはリンク上の別のポートに延期されます。これはDRBであると信じていますが、それでもTRILLデータパケットを送受信できます。
The following events can change the DRB state of a port. Note that this is only applicable to broadcast links. There is no DRB state or election at a port configured to be point-to-point.
次のイベントは、ポートのDRB状態を変更する可能性があります。これは、ブロードキャストリンクにのみ適用されることに注意してください。ポイントツーポイントとして構成されたポートには、DRB状態または選択はありません。
D1. The port becomes enabled or the Suspension Timer expires while the port is in the Suspended state.
D1。ポートが一時停止状態のときに、ポートが有効になるか、一時停止タイマーが期限切れになります。
D2. The adjacency table for the port changes, and there are now entries for one or more other RBridge ports on the link that appear to be higher priority to be the DRB than the local port.
D2。ポートの隣接テーブルが変更され、ローカルポートよりもDRBの方が優先度が高いと思われるリンク上の1つ以上の他のRBridgeポートのエントリがあります。
D3. The port is not Down or Suspended, and the adjacency table for the port changes, so there are now no entries for other RBridge ports on the link that appear to be higher priority to be the DRB than the local port.
D3。ポートがダウンまたはサスペンドされておらず、ポートの隣接テーブルが変更されているため、ローカルポートよりもDRBの方が優先度が高いと思われるリンク上の他のRBridgeポートのエントリはありません。
D4. A TRILL LAN Hello is received that has the same MAC address (SNPA) as the receiving port and higher priority to be the DRB as described for event A0.
D4。イベントA0で説明したように、受信ポートと同じMACアドレス（SNPA）を持ち、DRBになる優先度が高いTRILL LAN Helloが受信されます。
D5. The port becomes operationally down.
D5。ポートは操作上ダウンします。
Event D1 is considered to occur on RBridge boot if the port is administratively and link-layer enabled.
ポートが管理上、リンク層が有効になっている場合、イベントD1はRBridgeブート時に発生すると見なされます。
Event D4 causes the port to enter the Suspended state and all adjacencies for the port to be discarded (transitioned to the Down state). If the port was in some state other than Suspended, the Suspension Timer is set to the Holding Time in the Hello that causes event D4. If it was in the Suspended state, the Suspension Timer is set to the maximum of its current value and the Holding Time in the Hello that causes event D4.
イベントD4により、ポートは一時停止状態になり、ポートのすべての隣接関係が破棄されます（ダウン状態に移行）。ポートが一時停止以外の状態にあった場合、一時停止タイマーは、イベントD4の原因となるHelloの保留時間に設定されます。それが一時停止状態であった場合、一時停止タイマーは、現在の値とイベントD4を引き起こすHelloの保持時間の最大値に設定されます。
Events D2 and D3 constitute losing and winning the DRB election at the port, respectively.
イベントD2とD3は、それぞれポートでのDRB選挙の敗北と勝利を構成します。
The candidates for election are the local RBridge and all RBridges with which there is an adjacency on the port in an adjacency state other than the Down state. The winner is the RBridge with highest priority to be the DRB, as determined from the 7-bit priority field in that RBridge's Hellos received and the local port's priority to be the DRB field, with MAC (SNPA) address as a tiebreaker, Port ID as a secondary tiebreaker, and System ID as a tertiary tiebreaker. These fields are compared as unsigned integers, with the larger magnitude being considered higher priority.
選出の候補は、ローカルRBridgeと、ダウン状態以外の隣接状態のポートに隣接関係があるすべてのRBridgeです。勝者は、受信したRBridgeのHelloの7ビットの優先順位フィールドと、ローカルブレーカーの優先順位がDRBフィールドであり、MAC（SNPA）アドレスがタイブレーカーであるポートIDとして決定された、DRBとなる優先順位が最も高いRBridgeです。 2次タイブレーカーとして、システムIDを3次タイブレーカーとして。これらのフィールドは、符号なし整数として比較され、大きさが大きいほど優先順位が高いと見なされます。
Resorting to the secondary and tertiary tiebreakers should only be necessary in rare circumstances when multiple ports have the same priority and MAC (SNPA) address and some of them are not yet suspended. For example, RB1, which has low priority to be the DRB on the link, could receive Hellos from two other ports on the link that have the same MAC address as each other and are higher priority to be the DRB. One of these two ports with the same MAC address will be suspended and cease sending Hellos, and the Hello from it received by RB1 will eventually time out. But, in the meantime, RB1 can use the tiebreakers to determine which port is the DRB and thus which port's Hello to believe for such purposes as setting the Designated VLAN on the link.
複数のポートが同じ優先順位とMAC（SNPA）アドレスを持ち、それらのいくつかがまだ一時停止されていないまれな状況でのみ、2次および3次タイブレーカーに頼る必要があります。たとえば、リンク上のDRBになるための優先度が低いRB1は、リンクと同じMACアドレスを持ち、DRBになるための優先度が高いリンク上の他の2つのポートからHelloを受信できます。同じMACアドレスを持つこれらの2つのポートの1つは一時停止され、Helloの送信を停止し、RB1が受信したHelloは最終的にタイムアウトします。ただし、その間、RB1はタイブレーカーを使用して、どのポートがDRBであるか、つまり、リンクに指定VLANを設定するなどの目的でどのポートがHelloであるかを判断することができます。
Events D2 and D3 result from a change in the apparent DRB on the link. Unnecessary DRB changes should be avoided, especially on links offering native frame service, as a DRB change will generally cause a transient interruption to native frame service.
イベントD2およびD3は、リンク上の見かけのDRBの変更から発生します。特にネイティブフレームサービスを提供するリンクでは、DRBの変更により一般的にネイティブフレームサービスが一時的に中断されるため、不要なDRB変更は避けてください。
If a change in the DRB on the link changes the Designated VLAN on an Ethernet link, the actions specified in Section 4.2.3 are taken.
リンク上のDRBの変更がイーサネットリンク上の指定VLANを変更する場合、セクション4.2.3で指定されたアクションが実行されます。
If an RBridge changes in either direction between being the DRB and not being the DRB at a port, this will generally change the VLANs on which that RBridge sends Hellos through that port, as specified in Section 4.4.3 of [RFC6325].
[RFC6325]のセクション4.4.3で指定されているように、RBridgeがポートでDRBとDRBの間のどちらかの方向に変化すると、通常、RBridgeがそのポートを介してHelloを送信するVLANが変更されます。
Unnecessary changes in the Designated VLAN on an Ethernet link should be avoided because a change in the Designated VLAN can cause a transient interruption to adjacency and thus to TRILL Data forwarding on the link. When practical, all RBridge ports on a link should be configured with the same Desired Designated VLAN so that if the winner of the DRB election changes for any reason, the Designated VLAN will remain the same.
イーサネット上での指定VLANの不要な変更は避けてください。指定VLANを変更すると、隣接関係が一時的に中断され、リンク上でデータ転送がTRILLされる可能性があるためです。実用的な場合、リンク上のすべてのRBridgeポートは、同じ望ましい指定VLANで構成する必要があります。これにより、DRB選出の勝者が何らかの理由で変更された場合でも、指定VLANは同じままになります。
If an RBridge detects a change in Designated VLAN on an Ethernet link, then, for all adjacency table entries for a port to that link, the RBridge takes the following steps, in the order given.
RBridgeがイーサネットリンク上の指定VLANの変更を検出した場合、そのリンクへのポートのすべての隣接テーブルエントリについて、RBridgeは次の手順を順番に実行します。
o The non-Designated VLAN Hello holding timer is set to the maximum of its time to expiration and the current time to expiration of the Designated VLAN Hello holding timer.
o 非指定VLAN Hello保持タイマーは、有効期限までの最大時間と、指定VLAN Hello保持タイマーの有効期限までの現在の時間の最大値に設定されています。
o The Designated VLAN Hello holding timer is then set to expired (if necessary), and an event A5 occurs for the adjacency (see Section 3.3).
o 次に、指定VLAN Hello保持タイマーが期限切れ（必要な場合）に設定され、隣接に対してイベントA5が発生します（セクション3.3を参照）。
If the Designated VLAN for a link changes, this will generally change the VLANs on which Hellos are sent by an RBridge port on that link as specified in Section 4.4.3 of [RFC6325].
[RFC6325]のセクション4.4.3で指定されているように、リンクの指定VLANが変更されると、通常、そのリンクのRBridgeポートによってHelloが送信されるVLANが変更されます。
The table below shows the transitions between the DRB states defined above, based on the events defined above:
以下の表は、上記で定義されたイベントに基づく、上記で定義されたDRB状態間の遷移を示しています。
| Event | Down | Suspended | DRB | Not DRB |
+-------+--------+-----------+-----------+-----------+
| D1 | DRB | DRB | N/A | N/A |
| D2 | N/A | N/A | Not DRB | Not DRB |
| D3 | N/A | N/A | DRB | DRB |
| D4 | N/A | Suspended | Suspended | Suspended |
| D5 | Down | Down | Down | Down |
Table 3: Port State Table
表3：ポート状態テーブル
"N/A" indicates that the event to the left is not applicable in the state at the top of the column.
「N / A」は、左側のイベントが列の上部の状態に該当しないことを示します。
The diagram below presents the same information as in the state table:
以下の図は、状態テーブルと同じ情報を示しています。
+-------------+
| Down |<--------------+
+-+---+-------+ ^ |
| | ^ | |
D1| |D5 | | |
| +---+ |D5 |
| | |
| +--------+----+ |
| | Suspended |<---|---+
| +-+-----+-----+ | |
| D1| ^ | ^ | |
| | | |D4 | | |
| | | +---+ | |
| | | | |
| | |D4 | |
V V | | |
+---------------+-+ D5 | |
| DRB |---------->| |
+--------+--+-----+ | |
^ | | ^ | |
| D2| |D3| | |
| | +--+ | |
| | D4 | |
|D3 | +-----------------|---+
| V | |
+----+-------+-+ D5 |
| Not DRB |-------------->|
+----+---------+
| ^
|D2 |
+----+
Figure 2: Port State Diagram
図2：ポートの状態図
The purpose of MTU testing is to ensure that the links used in the campus topology can pass TRILL IS-IS packets, particularly LSP PDUs, at the TRILL campus MTU. The LSP PDUs generated at a TRILL switch could, as part of the flooding process, be sent over any adjacency in the campus. To assure correct operation of IS-IS, an LSP PDU must be able to reach every RBridge in the IS-IS reachable campus; this might be impossible if the PDU exceeded the MTU of an adjacency that was part of the campus topology.
MTUテストの目的は、キャンパストポロジで使用されるリンクがTRILLキャンパスMTUでTRILL IS-ISパケット、特にLSP PDUを通過できることを確認することです。 TRILLスイッチで生成されたLSP PDUは、フラッディングプロセスの一部として、キャンパス内の隣接を介して送信できます。 IS-ISが正しく動作するためには、LSP PDUがIS-IS到達可能キャンパス内のすべてのRBridgeに到達できる必要があります。 PDUがキャンパストポロジの一部である隣接のMTUを超えた場合、これは不可能になる可能性があります。
An RBridge, RB1, determines the desired campus link MTU by calculating the minimum of its originatingL1LSPBufferSize and the originatingL1LSPBufferSize of other RBridges in the campus, as advertised in the link-state database, but not less than 1,470 bytes. Although originatingL1LSPBufferSize in Layer 3 [IS-IS] is limited to the range 512 to 1,492 bytes inclusive, in TRILL it is limited to the range 1,470 to 65,535 bytes inclusive. (See Section 5 of [RFC7180].)
リンクステートデータベースでアドバタイズされているが1,470バイト以上である、キャンパス内の他のRBridgeのoriginatingL1LSPBufferSizeとoriginatingL1LSPBufferSizeの最小値を計算することにより、RBridge RB1は目的のキャンパスリンクMTUを決定します。レイヤ3 [IS-IS]のoriginatingL1LSPBufferSizeは512〜1,492バイトの範囲に制限されていますが、TRILLでは1,470〜65,535バイトの範囲に制限されています。 （[RFC7180]のセクション5をご覧ください）。
Although MTU testing is optional, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC7176]. The use of multicast or unicast for MTU-probe and MTU-ack is an implementation choice. However, the burden on the link is generally minimized by the following: (1) multicasting MTU-probes when a response from all other RBridges on the link is desired, such as when initializing or reconfirming MTU, (2) unicasting MTU-probes when a response from a single RBridge is desired, such as one that has just been detected on the link, and (3) unicasting all MTU-ack packets.
MTUテストはオプションですが、RBridgeがMTU-ack PDU [RFC6325] [RFC7176]でMTUプローブPDUに応答することは必須です。 MTUプローブとMTU-ackにマルチキャストまたはユニキャストを使用することは、実装の選択です。ただし、リンクへの負担は一般に次のようにして最小限に抑えられます。（1）MTUを初期化または再確認するときなど、リンク上の他のすべてのRBridgeからの応答が必要なときにMTUプローブをマルチキャストする、（2）次のときにMTUプローブをユニキャストするリンク上で検出されたばかりの単一のRBridgeからの応答が必要であり、（3）すべてのMTU-ackパケットをユニキャストしている。
RB1 can test the MTU size to RB2 as described in Section 4.3.2 of [RFC6325]. For this purpose, MTU testing is only done in the Designated VLAN. An adjacency that fails the MTU test at the campus MTU will not enter the Report state, or, if the adjacency is in that state, it leaves that state. Thus, an adjacency failing the MTU test at the campus minimum MTU will not be reported by the RBridge performing the test. Since inclusion in least-cost route computation requires the adjacency to be reported by both ends, as long as the RBridge at either end of the adjacency notices the MTU failure, it will not be so used.
[RFC6325]のセクション4.3.2で説明されているように、RB1はMTUサイズをRB2にテストできます。この目的のために、MTUテストは指定VLANでのみ行われます。キャンパスMTUでMTUテストに失敗した隣接は、レポートステートに入らないか、隣接がそのステートである場合、そのステートを離れます。したがって、キャンパスの最小MTUでMTUテストに失敗した隣接は、テストを実行するRBridgeによって報告されません。最小コストのルート計算に含めるには、隣接の両端にあるRBridgeがMTU障害に気づく限り、隣接が両端から報告される必要があるため、そのようには使用されません。
If RB1 tests MTU size, it reports the largest size for which the MTU test succeeds or a flag indicating that it fails at the campus MTU. This report always appears with the neighbor in RB1's TRILL Neighbor TLV. RB1 MAY also report this with the adjacency in an Extended Reachability TLV in RB1's LSP. RB1 MAY choose to test MTU sizes greater than the desired campus MTU as well as the desired campus MTU.
RB1がMTUサイズをテストする場合は、MTUテストが成功した最大サイズ、またはキャンパスMTUで失敗したことを示すフラグを報告します。このレポートは常に、RB1のTRILLネイバーTLVのネイバーとともに表示されます。 RB1はまた、RB1のLSPの拡張到達可能性TLVの隣接でこれを報告する場合があります。 RB1は、希望のキャンパスMTUと希望のキャンパスMTUより大きいMTUサイズをテストすることを選択できます。
Most types of TRILL IS-IS packets, such as LSPs, can make use of the campus MTU. The exceptions are TRILL Hellos, which must be kept small for loop safety, and the MTU PDUs, whose size must be adjusted appropriately for the tests being performed.
LSPなどのほとんどのタイプのTRILL IS-ISパケットは、キャンパスMTUを利用できます。例外は、ループの安全のために小さく保つ必要があるTRILL Helloと、実行するテストに合わせてサイズを適切に調整する必要があるMTU PDUです。
When the adjacency between RBridges reaches the 2-Way state, TRILL Hellos will already have been exchanged. If an RBridge supports BFD [RFC7175], it will have learned whether the other RBridge has BFD enabled by whether or not a BFD-Enabled TLV [RFC6213] was included in its Hellos. In addition, TRILL Hellos include a nickname of the sending RBridge [RFC7176] so that information will be available to the receiving RBridge.
RBridge間の隣接が2-Way状態に達すると、TRILL Helloはすでに交換されています。 RBridgeがBFD [RFC7175]をサポートしている場合、BFD対応TLV [RFC6213]がHelloに含まれていたかどうかによって、他のRBridgeでBFDが有効になっているかどうかがわかります。さらに、TRILL Helloには送信RBridge [RFC7176]のニックネームが含まれているため、受信RBridgeで情報を利用できます。
The BFD-Enabled TLVs in TRILL Hellos will look like the following:
TRILL HellosのBFD対応TLVは次のようになります。
+-+-+-+-+-+-+-+-+
| Type=148 | (1 byte)
+-+-+-+-+-+-+-+-+
| Length=3*n | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | MT ID=0 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLPID=0xC0 | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-...
| possible additional (3*(n-1) bytes)
| topology/NLPID pairs
+-+-+-+-+-+-+-...
Figure 3: BFD-Enabled TLV Example/Format
図3：BFD対応TLVの例/形式
Type = 148 for BFD Enabled [RFC6213].
Type = 148 for BFD Enabled [RFC6213]。
Length will be 3 times the number of topology and protocol pairs in the TLV.
長さは、TLVのトポロジとプロトコルのペアの数の3倍になります。
MT ID is a topology ID [RFC5120] that will be zero unless multi-topology is being supported [MT].
MT IDはトポロジーID [RFC5120]であり、マルチトポロジーがサポートされている場合を除いてゼロになります[MT]。
NLPID is a Network Layer Protocol ID [RFC6328] and will be 0xC0 for TRILL, but additional topology and protocol pairs could conceivably be listed.
NLPIDはネットワーク層プロトコルID [RFC6328]であり、TRILLの場合は0xC0ですが、追加のトポロジーとプロトコルのペアがリストされる可能性があります。
An RBridge port initiates a one-hop BFD session with another RBridge if the following conditions are met: (1) it has BFD enabled, (2) it has an adjacency to another RBridge in the 2-Way or Report state, and (3) the Hellos it receives indicate that the other RBridge also has BFD enabled. Either (a) BFD was enabled on both RBridge ports when the adjacency changed to the 2-Way or Report state, (b) the adjacency was already in the 2-Way or Report state and BFD was enabled on one RBridge port when BFD had been enabled on the other, or (c) BFD was simultaneously enabled on both RBridge ports.
次の条件が満たされた場合、RBridgeポートは別のRBridgeとの1ホップBFDセッションを開始します：（1）BFDが有効になっている、（2）2ウェイまたはレポート状態にある別のRBridgeに隣接している、および（3 ）受信したHelloは、他のRBridgeでもBFDが有効になっていることを示しています。 （a）隣接が2-WayまたはReport状態に変化したときに両方のRBridgeポートでBFDが有効にされた、（b）BFDがあったときに隣接がすでに2-WayまたはReport状態にあり、BFDが1つのRBridgeポートで有効にされたまたは、（c）BFDが両方のRBridgeポートで同時に有効にされた。
In such a BFD session, BFD is encapsulated as specified in [RFC7175]. The egress nickname to be used will have been learned from received Hellos. On a point-to-point link, the Any-RBridge nickname [RFC7180] can also be used as egress, since support of that nickname is required by support of RBridge Channel [RFC7178] and support of RBridge Channel is required for support of BFD over TRILL.
このようなBFDセッションでは、[RFC7175]で指定されているようにBFDがカプセル化されます。使用される出力ニックネームは、受信したHelloから学習されます。ポイントツーポイントリンクでは、Any-RBridgeニックネーム[RFC7180]を出力として使用することもできます。RBニックチャネル[RFC7178]のサポートにはニックネームのサポートが必要であり、BFDのサポートにはRBridgeチャネルのサポートが必要だからTRILL以上。
The rare case of transient nickname conflict (due to the network operator configuring a conflict, new connectivity to a previously isolated RBridge, or the like) can cause transient failure of an ongoing BFD session. This can be avoided in the one-hop point-to-point case by using the Any-RBridge egress nickname. In cases where Any-RBridge cannot be used as the egress nickname and a transient nickname conflict is detected for the intended destination of a BFD session, initiation of the session SHOULD be delayed until the conflict is resolved.
一時的なニックネームの競合のまれなケース（競合を構成するネットワークオペレーター、以前に分離されたRBridgeへの新しい接続などによる）は、進行中のBFDセッションの一時的な障害を引き起こす可能性があります。これは、Any-RBridge出力ニックネームを使用することにより、1ホップのポイントツーポイントのケースで回避できます。 Any-RBridgeを出力ニックネームとして使用できず、一時的なニックネームの競合がBFDセッションの目的の宛先で検出された場合、セッションの開始は、競合が解決されるまで遅延する必要があります（SHOULD）。
If a one-hop BFD session is initiated when the adjacency is in the 2-Way state, the adjacency MUST NOT advance to the Report state until BFD and any other enabled connectivity tests (including MTU, if enabled) have succeeded, as specified in Section 3.
隣接が2-Way状態のときに1ホップBFDセッションが開始された場合、BFDと他の有効な接続テスト（有効になっている場合はMTUを含む）が成功するまで、隣接はReport状態に移行してはなりません。セクション3。
If a one-hop BFD session is established when the adjacency is in the Report state, due to enablement at the RBridges, then, to minimize unnecessary topology changes, the adjacency MUST remain in the Report state unless and until the BFD session (or some other enabled connectivity test) fails.
隣接がReport状態のときに1ホップBFDセッションが確立された場合、RBridgeでの有効化により、不要なトポロジ変更を最小限に抑えるために、BFDセッション（または他の有効な接続テスト）が失敗します。
This section only applies to broadcast links, as there is no DRB and there cannot be a pseudonode [IS-IS] for a link configured as point-to-point. The Designated RBridge (DRB), determined as described above, controls whether a pseudonode will be used on a link.
DRBがなく、ポイントツーポイントとして構成されたリンクの疑似ノード[IS-IS]は存在できないため、このセクションはブロードキャストリンクにのみ適用されます。上記のように決定された指定RBridge（DRB）は、リンクで疑似ノードを使用するかどうかを制御します。
If the DRB sets the bypass pseudonode bit in its TRILL LAN Hellos, the RBridges on the link (including the DRB) just directly report all their adjacencies on the LAN that are in the Report state. If the DRB does not set the bypass pseudonode bit in its TRILL Hellos, then (1) the DRB reports in its LSP its adjacency to the pseudonode, (2) the DRB sends LSPs on behalf of the pseudonode in which it reports adjacency to all other RBridges on the link where it sees that adjacency in the Report state, and (3) all other RBridges on the link report their adjacency to the pseudonode if they see their adjacency to the DRB as being in the Report state and do not report any other adjacencies on the link. Setting the bypass pseudonode bit has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated.
DRBがTRILL LAN Helloにバイパス疑似ノードビットを設定する場合、リンク上のRBridge（DRBを含む）は、レポート状態にあるLAN上のすべての隣接関係を直接報告します。 DRBがTRILL Helloにバイパス疑似ノードビットを設定しない場合、（1）DRBはその隣接関係を疑似ノードに報告します、（2）DRBはすべてに隣接関係を報告する疑似ノードに代わってLSPを送信しますReport状態でその隣接関係を確認するリンク上の他のRBridge、および（3）リンク上の他のすべてのRBridgeは、DRBへの隣接関係をReport状態であると見なし、何も報告しない場合、疑似ノードに隣接関係を報告します。リンク上の他の隣接。バイパス疑似ノードビットを設定しても、LSPがリンクでフラッディングされる方法には影響しません。生成されるLSPにのみ影響します。
It is anticipated that many links between RBridges will actually be point-to-point even in cases where the link technology supports operation as a multi-access broadcast link, in which case using a pseudonode merely adds to the complexity. For example, if RB1 and RB2 are the only RBridges on the link, and RB1 is the DRB, then if RB1 creates a pseudonode -- for example, RB1.25 -- that is used, there are then 3 LSPs: RB1.25, RB1, and RB2, where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they are connected to RB1.25. However, if DRB RB1 sets the bypass pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and RB2, each reporting connectivity to each other.
リンクテクノロジがマルチアクセスブロードキャストリンクとしての動作をサポートする場合でも、RBridge間の多くのリンクは実際にはポイントツーポイントであると予想されます。この場合、疑似ノードを使用すると、複雑さが増すだけです。たとえば、RB1とRB2がリンク上の唯一のRBridgeであり、RB1がDRBである場合、RB1が使用される疑似ノード（たとえばRB1.25）を作成すると、3つのLSPが存在します。RB1.25 、RB1、およびRB2。RB1.25はRB1とRB2への接続を報告し、RB1とRB2はそれぞれRB1.25に接続されているとだけ言います。ただし、DRB RB1がHellosにバイパス疑似ノードビットを設定した場合、LSPは2つしか存在しません。RB1とRB2であり、それぞれが相互の接続を報告します。
A DRB SHOULD set the bypass pseudonode bit in its Hellos if it has not seen at least two simultaneous adjacencies in the Report state since it last rebooted or was reset by network management.
DRBは、最後に再起動されたか、ネットワーク管理によってリセットされてから、レポート状態で少なくとも2つの同時隣接を検出していない場合、Helloにバイパス疑似ノードビットを設定する必要があります（SHOULD）。
This section provides further details on the receipt, transmission, and content of TRILL Hellos. Unless otherwise stated, it applies to both LAN and point-to-point Hellos.
このセクションでは、TRILL Helloの受信、送信、および内容について詳しく説明します。特に明記しない限り、これはLANとポイントツーポイントの両方のHelloに適用されます。
TRILL Hellos, like all TRILL IS-IS packets, are primarily distinguished from Layer 3 IS-IS packets on Ethernet by being sent to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS packets on Ethernet also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.
TRILL Helloは、すべてのTRILL IS-ISパケットと同様に、All-IS-IS-RBridgesマルチキャストアドレス（01-80-C2-00-00-41）に送信されることにより、イーサネット上のレイヤー3 IS-ISパケットと主に区別されます。イーサネット上のTRILL IS-ISパケットもL2-IS-IS Ethertype（0x22F4）を持ち、Ethertypeエンコードされています。
Although future extensions to TRILL may include the use of Level 2 IS-IS, [RFC6325] specifies TRILL using a single Level 1 Area using the fixed Area Address zero (see Section 4.2 of [RFC7176]).
TRILLの将来の拡張にはレベル2 IS-ISの使用が含まれる可能性がありますが、[RFC6325]は、固定エリアアドレス0を使用して単一のレベル1エリアを使用するTRILLを指定します（[RFC7176]のセクション4.2を参照）。
IS-IS Layer 3 routers are frequently connected to other Layer 3 routers that are part of a different routing domain. In that case, the externalDomain flag (see [IS-IS]) is normally set for the port through which such a connection is made. The setting of this flag to "true" causes no IS-IS PDUs to be sent out of the port and any IS-IS PDUs received to be discarded, including Hellos. RBridges operate in a different environment where all neighbor RBridges merge into a single campus. For loop safety, RBridges do not implement the externalDomain flag or implement it with the fixed value "false". They send and can receive TRILL Hellos on every port that is not disabled.
IS-ISレイヤー3ルーターは、別のルーティングドメインの一部である他のレイヤー3ルーターに頻繁に接続されます。その場合、externalDomainフラグ（[IS-IS]を参照）は通常、そのような接続が行われるポートに対して設定されます。このフラグを「true」に設定すると、IS-IS PDUがポートから送信されなくなり、Helloを含め、受信したIS-IS PDUが破棄されます。 RBridgesは、隣接するすべてのRBridgesが単一のキャンパスに統合される異なる環境で動作します。ループの安全性のために、RBridgeは、externalDomainフラグを実装しないか、固定値「false」でそれを実装しません。無効になっていないすべてのポートでTRILL Helloを送受信できます。
The table below lists mandatory (M) and optional (O) content TLVs for TRILL Hellos that are particularly relevant to this document, distinguishing between TRILL LAN Hellos and TRILL P2P Hellos. A "-" indicates that an occurrence would be ignored. There are additional TLVs and sub-TLVs that can occur in TRILL Hellos [RFC7176].
次の表は、このドキュメントに特に関連するTRILL Helloの必須（M）およびオプション（O）コンテンツのTLVを示し、TRILL LAN HelloとTRILL P2P Helloを区別しています。 「-」は、発生が無視されることを示します。 TRILL Hellos [RFC7176]で発生する可能性のある追加のTLVとサブTLVがあります。
LAN P2P Number Content Item
--- --- ------ ----------------------------------------------
M M 1 Area Addresses TLV with Area Address zero only M M 1 MT Port Capabilities TLV containing a VLAN-FLAGs sub-TLV O O 0-n Other MT Port Capability TLVs M - 0-n TRILL Neighbor TLV (see Section 8.2.1) - M 1 Three-Way Handshake TLV O O 0-n Protocols Supported TLV -- MUST list the TRILL NLPID (0xC0) [RFC6328] O O 0-1 BFD-Enabled TLV O O 0-1 Authentication TLV - - 0-n Padding TLV -- SHOULD NOT be included
MM 1エリアアドレスTLV、エリアアドレスゼロのみMM 1 MTポート機能TLV、VLAN-FLAGを含むサブTLV OO 0-nその他のMTポート機能TLV M-0-n TRILLネイバーTLV（セクション8.2.1を参照）-M 1サポートされる3ウェイハンドシェイクTLV OO 0-nプロトコルTLV-TRILL NLPID（0xC0）をリストする必要があります（RFC6328）OO 0-1 BFD対応TLV OO 0-1認証TLV--0-nパディングTLV-SHOULD含まれない
Table 4: TRILL Hello Contents
表4：TRILL Helloコンテンツ
A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello. As with all IS-IS PDUs, TLVs that are unsupported/unknown in TRILL Hellos are ignored.
TRILL Helloには、レイヤ3 IS-IS Helloで許可されているすべてのTLVが含まれる場合があります。すべてのIS-IS PDUと同様に、TRILL Helloでサポートされていない/不明なTLVは無視されます。
TRILL Hellos are sent with the same timing as Layer 3 IS-IS Hellos [IS-IS]; however, no Hellos are sent if a port is in the Suspended or Down state or if the port is disabled.
TRILL Helloは、レイヤー3 IS-IS Hello [IS-IS]と同じタイミングで送信されます。ただし、ポートがSuspendedまたはDown状態の場合、またはポートが無効になっている場合、Helloは送信されません。
TRILL Hello PDUs SHOULD NOT be padded and MUST NOT be sent if they exceed 1,470 bytes; however, a received TRILL Hello longer than 1,470 bytes is processed normally.
TRILL Hello PDUはパディングしてはならず、1,470バイトを超える場合は送信してはなりません。ただし、1,470バイトより長い受信TRILL Helloは正常に処理されます。
TRILL Hello PDU headers MUST conform to the following:
TRILL Hello PDUヘッダーは、以下に準拠する必要があります。
o Maximum Area Addresses equal to 1.
o 最大エリアアドレスは1です。
o Circuit Type equal to 1.
o 回路タイプは1です。
See Section 8.1 for mandatory Hello TLV contents and some optional Hello TLV contents.
必須のHello TLVコンテンツとオプションのHello TLVコンテンツについては、セクション8.1を参照してください。
A TRILL Neighbor TLV SHOULD NOT be included in TRILL point-to-point Hellos, as it MUST be ignored in that context and wastes space.
TRILLネイバーTLVはTRILLポイントツーポイントHellosに含めないでください。そのコンテキストでは無視する必要があり、スペースを浪費するためです。
TRILL Neighbor TLVs sent in a LAN Hello on an Ethernet link MUST show the neighbor information, as sensed by the transmitting RBridge, for the VLAN on which the Hello is sent. Since implementations conformant to this document maintain such information on a per-VLAN basis only for the Designated VLAN, such implementations only send the TRILL Neighbor TLV in TRILL LAN Hellos in the Designated VLAN.
イーサネットリンク上のLAN Helloで送信されるTRILLネイバーTLVは、Helloが送信されるVLANについて、送信RBridgeによって検出されたネイバー情報を表示する必要があります。このドキュメントに準拠する実装は、指定VLANについてのみVLANごとにそのような情報を維持するため、そのような実装は、指定VLANのTRILL LAN HelloでTRILLネイバーTLVのみを送信します。
It is RECOMMENDED that, if there is sufficient room, a TRILL Neighbor TLV or TLVs, as described in Section 4.4.2.1 of [RFC6325], covering the entire range of MAC addresses and listing all adjacencies with a non-zero Designated VLAN Hello Holding Time, or an empty list of neighbors if there are no such adjacencies, be in TRILL Hellos sent on the Designated VLAN. If this is not possible, then TRILL Neighbor TLVs covering sub-ranges of MAC addresses should be sent so that the entire range is covered reasonably promptly. Delays in sending TRILL Neighbor TLVs will delay the advancement of adjacencies to the Report state and the discovery of some link failures. Rapid (for example, sub-second) detection of link or node failures is best addressed with a protocol designed for that purpose, such as BFD (see Section 6).
[RFC6325]のセクション4.4.2.1で説明されているように、十分なスペースがある場合は、MACアドレスの範囲全体をカバーし、ゼロ以外の指定VLAN Helloホールディングを持つすべての隣接をリストするTRILLネイバーTLVを推奨します時間、またはそのような隣接関係がない場合は空のネイバーリストが、指定VLANで送信されるTRILL Helloに含まれます。これが不可能な場合は、MACアドレスのサブ範囲をカバーするTRILLネイバーTLVを送信して、範囲全体が適度に迅速にカバーされるようにする必要があります。 TRILLネイバーTLVの送信が遅延すると、隣接関係のレポート状態への移行と一部のリンク障害の検出が遅延します。リンクまたはノードの障害の迅速な（たとえば、1秒未満）検出は、BFD（セクション6を参照）など、その目的のために設計されたプロトコルで対処するのが最適です。
To ensure that any RBridge RB2 can definitively determine whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover every possible range of IDs, that is, within a period that depends on RB1's policy and not necessarily within any specific period such as its Holding Time. In other words, if X1 is the smallest ID reported in one of RB1's neighbor lists, and the "smallest" flag is not set, then X1 MUST appear in a different neighbor list as well, as the largest ID reported in that fragment. Or lists may overlap, as long as there is no gap, such that some range, say, between Xi and Xj, would never appear in any list.
RBridge RB2がRB1がRB2を聞くことができるかどうかを確実に判断できるようにするには、RB1のネイバーリストが最終的にすべての可能なIDの範囲をカバーする必要があります。 。言い換えると、X1がRB1のネイバーリストの1つで報告された最小のIDであり、「最小」フラグが設定されていない場合、X1はそのフラグメントで報告された最大のIDとして別のネイバーリストにも表示される必要があります。または、ギャップがない限り、リストは重複する場合があります。たとえば、XiとXjの間のある範囲がリストに表示されない場合があります。
Assuming that a packet is labeled as TRILL IS-IS -- for example, on Ethernet it has the L2-IS-IS Ethertype and the All-IS-IS-RBridges destination multicast address or is so marked by the appropriate code point on other link types such as PPP [RFC6361] or a pseudowire [RFC7173] -- it will be examined to see if it appears to be an IS-IS PDU. If so, and it appears to be a TRILL Hello PDU, the following tests are performed:
パケットがTRILL IS-ISとしてラベル付けされていると仮定します-たとえば、イーサネットでは、L2-IS-IS EthertypeおよびAll-IS-IS-RBridges宛先マルチキャストアドレスを持っているか、他の適切なコードポイントによってそのようにマークされていますPPP [RFC6361]や疑似配線[RFC7173]などのリンクタイプ-IS-IS PDUのように見えるかどうかを調べるために調べられます。その場合、それがTRILL Hello PDUであると思われる場合、次のテストが実行されます。
o The type of Hello PDU (LAN or P2P) is compared with the port configuration. If a LAN Hello is received on a port configured to be point-to-point or a P2P Hello is received on a port not configured to be point-to-point, it is discarded.
o Hello PDUのタイプ（LANまたはP2P）がポート構成と比較されます。ポイントツーポイントとして構成されたポートでLAN Helloを受信した場合、またはポイントツーポイントとして構成されていないポートでP2P Helloを受信した場合、P2P Helloは破棄されます。
o If the Circuit Type field is not 1, the PDU is discarded.
o Circuit Typeフィールドが1でない場合、PDUは破棄されます。
o If the PDU does not contain an Area Address TLV or it contains an Area Address TLV that is not the single Area Address zero, it is discarded.
o PDUにエリアアドレスTLVが含まれていないか、単一のエリアアドレス0ではないエリアアドレスTLVが含まれている場合、それは破棄されます。
o If the Hello includes a Protocols Supported TLV that does not list the TRILL NLPID (0xC0), it is discarded. It is acceptable if there is no Protocols Supported TLV present.
o HelloにTRILL NLPID（0xC0）をリストしないプロトコルサポートTLVが含まれている場合、それは破棄されます。 Protocols Supported TLVが存在しなくても問題ありません。
o If the Hello does not contain an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC7176], it is discarded.
o HelloにVLAN-FLAGSサブTLV [RFC7176]を含むMTポート機能TLVが含まれていない場合、それは破棄されます。
o If the maximumAreaAddresses field of the PDU is not 1, it is discarded.
o PDUのmaximumAreaAddressesフィールドが1でない場合、それは破棄されます。
o If IS-IS authentication is in use on the link and either the PDU has no Authentication TLV or validation of the PDU's Authentication TLV fails, it is discarded.
o リンクでIS-IS認証が使用されていて、PDUに認証TLVがないか、PDUの認証TLVの検証に失敗した場合、その認証は破棄されます。
If none of the rules in the list above cause the packet to be discarded and the packet is parseable, it is assumed to be a well-formed TRILL Hello received on the link. It is treated as an event A0, A1, A2, or A3, based on the criteria listed in Section 3.3.
上記のリストのどのルールもパケットを破棄せず、パケットが解析可能な場合、リンクで受信された整形式のTRILL Helloであると見なされます。セクション3.3にリストされている基準に基づいて、イベントA0、A1、A2、またはA3として扱われます。
It is possible for an RBridge RB1 to have multiple ports on the same broadcast (LAN) link that are not in the Suspended state. It is important for RB1 to recognize which of its ports are on the same link. RB1 can detect this condition based on receiving TRILL Hello messages with the same LAN ID on multiple ports.
RBridge RB1が、サスペンド状態ではない同じブロードキャスト（LAN）リンク上に複数のポートを持つ可能性があります。 RB1がどのポートが同じリンク上にあるかを認識することが重要です。 RB1は、複数のポートで同じLAN IDを持つTRILL Helloメッセージを受信することに基づいて、この状態を検出できます。
The DRB election is port-based (see Section 4), and only the Hellos from the elected port can perform certain functions such as dictating the Designated VLAN or whether a pseudonode will be used; however, the election also designates the RBridge with that port as the DRB for the link. An RBridge may choose to load split some tasks among its ports on the link if it has more than one. Section 4.4.4 of [RFC6325] describes when it is safe to do so.
DRBの選択はポートベースで行われ（セクション4を参照）、選択されたポートからのHelloのみが、指定VLANの指定や疑似ノードの使用の有無などの特定の機能を実行できます。ただし、この選択では、そのポートを持つRBridgeもリンクのDRBとして指定されます。 RBridgeは、複数のタスクがある場合、リンク上のポート間でいくつかのタスクをロードスプリットすることを選択できます。 [RFC6325]のセクション4.4.4は、安全な場合について説明しています。
This document serves as a reference for 'Fail' (Failed MTU test), value 0, in the "TRILL Neighbor TLV NEIGHBOR RECORD Flags" registry. IANA has updated that reference to point to this RFC.
このドキュメントは、「TRILL Neighbor TLV NEIGHBOR RECORD Flags」レジストリの「Fail」（失敗したMTUテスト）、値0のリファレンスとして機能します。 IANAは、このRFCを指すようにその参照を更新しました。
This memo provides improved documentation of some aspects of the TRILL base protocol standard, particularly five aspects of the TRILL adjacency establishment and Hello protocol as listed in Section 1. It does not change the security considerations of the TRILL base protocol as detailed in Section 6 of [RFC6325].
このメモは、TRILLベースプロトコル標準のいくつかの側面、特にセクション1にリストされているTRILL隣接関係確立とHelloプロトコルの5つの側面の改善されたドキュメントを提供します。それは、セクション6で詳述されているTRILLベースプロトコルのセキュリティに関する考慮事項を変更しません[RFC6325]。
See [RFC7175] for security considerations for BFD, whose use in connection with TRILL adjacency is discussed in this document, particularly Section 6.
BFDのセキュリティに関する考慮事項については、[RFC7175]を参照してください。BFDの使用については、このドキュメント、特にセクション6で説明しています。
This document has the following changes from [RFC6327]. It obsoletes [RFC6327].
このドキュメントには、[RFC6327]からの次の変更点があります。 [RFC6327]は廃止されました。
1. This document extends the TRILL Hello size limit, MTU testing, and state machine to point-to-point links.
1. このドキュメントでは、TRILL Helloのサイズ制限、MTUテスト、およびステートマシンからポイントツーポイントリンクまでを拡張しています。
2. This document incorporates the updates to [RFC6327] from [RFC7180].
2. このドキュメントは、[RFC7180]からの[RFC6327]への更新を組み込んでいます。
3. The bulk of [RFC6327] was written from the point of view that links between TRILL switches would only be Ethernet. In fact, they could be any technology, such as PPP [RFC6361], pseudowire [RFC7173], or IP [TrillIP]. This replacement document generalizes [RFC6327] to cover such link types.
3. [RFC6327]の大部分は、TRILLスイッチ間のリンクはイーサネットのみであるという観点から書かれました。実際、これらはPPP [RFC6361]、疑似配線[RFC7173]、IP [TrillIP]などの任意のテクノロジーである可能性があります。この置換文書は、そのようなリンクタイプをカバーするために[RFC6327]を一般化しています。
4. This document includes a specification of one-hop BFD session establishment in connection with adjacency.
4. このドキュメントには、隣接関係に関連する1ホップBFDセッション確立の仕様が含まれています。
5. Numerous editorial changes were incorporated.
5. 多数の編集上の変更が組み込まれました。
Section 2 of this document replaces Section 4.4.1 of [RFC6325]. Section 8 of this document replaces Section 4.4.2 of [RFC6325], except for Section 4.4.2.1. The changes in [RFC6325] made by this document include
このドキュメントのセクション2は、[RFC6325]のセクション4.4.1を置き換えます。このドキュメントのセクション8は、セクション4.4.2.1を除き、[RFC6325]のセクション4.4.2を置き換えます。このドキュメントによって行われた[RFC6325]の変更には、
- Prohibiting the sending of TRILL Hellos out of a port while it is in the Suspended state, and the specification of the Suspended state. ([RFC6325] specifies that Hellos be sent with the same timing as [IS-IS].)
- Suspended状態のポートからのTRILL Hellosの送信の禁止と、Suspended状態の指定。 （[RFC6325]は、[IS-IS]と同じタイミングでHelloが送信されることを指定します。）
- Permitting the inclusion of the Three-Way-Handshake TLV, BFD-Enabled TLV, and other TLVs in TRILL Hellos when these were omitted in TRILL Hello contents lists in Section 4.4.2 of [RFC6325].
- [RFC6325]のセクション4.4.2のTRILL Helloコンテンツリストでこれらが省略されている場合、3ウェイハンドシェイクTLV、BFD対応TLV、およびその他のTLVをTRILL Helloに含めることを許可します。
- Extending the TRILL Hello protocol to support point-to-point and non-Ethernet links.
- ポイントツーポイントおよび非イーサネットリンクをサポートするためのTRILL Helloプロトコルの拡張。
Normative References
引用文献
[IS-IS] ISO/IEC 10589:2002, Second Edition, "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)", 2002.
[IS-IS] ISO / IEC 10589：2002、Second Edition、 "Information technology-Telecommunications and information exchange between systems-Intermediate System to Intermediate System intra-domain routinging information exchange protocol with used with with the protocol with with with using the protocol toコネクションレスモードのネットワークサービス（ISO 8473）」、2002年。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、2008年2月。
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV", RFC 6213, April 2011.
[RFC6213] Hopps、C。およびL. Ginsberg、「IS-IS BFD-Enabled TLV」、RFC 6213、2011年4月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328] Eastlake 3rd、D。、「ネットワークレイヤープロトコル識別子に関するIANAの考慮事項」、BCP 164、RFC 6328、2011年7月。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「Transparent Interconnection of Lots of Links（TRILL）：Bidirectional Forwarding Detection（BFD）Support」、RFC 7175、2014年5月。
[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, May 2014.
[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、May 2014。
[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, May 2014.
[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、May 2014 。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、2014年5月。
Informative References
参考引用
[802.1AX] "IEEE Standard for Local and metropolitan area networks-- Link Aggregation", 802.1AX-2008, January 2008.
[802.1AX]「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、802.1AX-2008、2008年1月。
[802.1Q] "IEEE Standard for Local and metropolitan area networks-- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", 802.1Q-2011, August 2011.
[802.1Q]「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、802.1Q-2011、2011年8月。
[ESADI] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "TRILL: ESADI (End Station Address Distribution Information) Protocol", Work in Progress, April 2014.
[ESADI] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「TRILL：ESADI（End Station Address Distribution Information）Protocol」、Work in Progress、2014年4月。
[FCoE] Excerpt of discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU", <www.t11.org>.
[FCoE] T11 / 09-251v1、2009年4月27日、「FCoEフレームまたはFCoE PDU」、<www.t11.org>から生成された「FCoE最大サイズ」のディスカッションの抜粋。
[MT] Eastlake, D., Zhang, M., Banerjee, A., and V. Manral, "TRILL: Multi-Topology", Work in Progress, September 2013.
[MT] Eastlake、D.、Zhang、M.、Banerjee、A.、V。Manral、「TRILL：Multi-Topology」、Work in Progress、2013年9月。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
[RFC3719] Parker、J。、編、「Intermediate System to Intermediate System（IS-IS）を使用した相互運用可能なネットワークの推奨事項」、RFC 3719、2004年2月。
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
[RFC6327] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Dutt、D.、and V. Manral、 "Routing Bridges（RBridges）：Adjacency"、RFC 6327、July 2011。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361] Carlson、J。およびD. Eastlake 3度、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、2011年8月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A。、およびF. Hu、「Routing Bridges（RBridges）：Appointed Forwarders」、RFC 6439、2011年11月。
[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, May 2014.
[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、May 2014。
[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, May 2014.
[RFC7173] Yong、L.、Eastlake 3rd、D.、Aldrin、S。、およびJ. Hudson、「トランスペアレントインターコネクションオブリンクス（TRILL）Transport using Pseudowires」、RFC 7173、2014年5月。
[TrillIP] Wasserman, M., Eastlake, D., and D. Zhang, "Transparent Interconnection of Lots of Links (TRILL) over IP", Work in Progress, March 2014.
[TrillIP] Wasserman、M.、Eastlake、D。、およびD. Zhang、「IPを介した多数のリンクの透過的な相互接続（TRILL）」、進行中の作業、2014年3月。
Acknowledgements
謝辞
The suggestions and comments of the following are gratefully acknowledged:
以下の提案とコメントは感謝されます。
Stewart Bryant, Elwyn Davies, Adrian Farrel, Brian Haberman, Jon Hudson, Arnel Lim, and Gayle Noble.
スチュワートブライアント、エルウィンデイビス、エイドリアンファレル、ブライアンハーバーマン、ジョンハドソン、アーネルリム、ゲイルノーブル。
The authors of [RFC6327] included Dinesh Dutt. The acknowledgements section of [RFC6327] includes the following, listed in alphabetic order: Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand.
[RFC6327]の作者はDinesh Duttを含みました。 [RFC6327]の謝辞セクションには、次のものがアルファベット順にリストされています。JariArkko、Ayan Banerjee、Les Ginsberg、Sujay Gupta、David Harrington、Pete McCann、Erik Nordmark、Mike Shand。
Authors' Addresses
著者のアドレス
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、カリフォルニア州95054米国
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054 USA
EMail: anoop@alumni.duke.edu Howard Yang Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
メール：anoop@alumni.duke.eduハワードヤンCisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
EMail: howardy@cisco.com
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 95117彼
EMail: vishwas@ionosnetworks.com