[要約] RFC 6327は、RBridgesの隣接性に関する要件とプロトコルを定義しています。その目的は、RBridges間の効率的な通信を可能にし、スケーラビリティと柔軟性を提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 6327 Huawei
Updates: 6325 R. Perlman
Category: Standards Track Intel Labs
ISSN: 2070-1721 A. Ghanwani
Brocade
D. Dutt
Cisco Systems
V. Manral
Hewlett Packard Co.
July 2011
Routing Bridges (RBridges): Adjacency
ルーティングブリッジ（Rbridges）：隣接
Abstract
概要
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).
IETFトリル（多くのリンクの透明な相互接続）プロトコルは、構成なしで最適なペアワイズデータ転送、一時的なループの期間中でも安全な転送、ユニキャストとマルチキャストトラフィックの両方のマルチパスのサポートを提供します。Trillは、IS-IS（中間システムから中間システム）リンク状態ルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを達成します。Trillを実装するデバイスは、ルーティングブリッジ（Rbridges）と呼ばれます。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU (Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.
Trillは、複数のエンドステーションとRbridgesが添付される可能性のあるマルチアクセスLAN（ローカルエリアネットワーク）リンクをサポートしています。このドキュメントでは、このようなリンク、特に隣接、指定されたRbridge選択、MTU（最大透過ユニット）およびPSEUDONODE手順、状態マシンを使用して使用されるTrill Lan Helloプロトコルの4つの側面について説明します。Trillのポイントツーポイントとして構成されたリンクで使用されるIS-ISポイントツーポイントのHellosに変更はありません。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc6327.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6327で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Content and Precedence .....................................4
1.2. Terminology and Acronyms ...................................5
2. The TRILL Hello Environment and Purposes ........................5
2.1. Incrementally Replacing 802.1Q-2005 Bridges ................5
2.2. Handling Native Frames .....................................6
2.3. Zero or Minimal Configuration ..............................7
2.4. MTU Robustness .............................................7
2.5. Purposes of the TRILL Hello Protocol .......................8
3. Adjacency State Machinery .......................................9
3.1. TRILL LAN Hellos, MTU Test, and VLANs ......................9
3.2. Adjacency Table Entries and States ........................10
3.3. Adjacency and Hello Events ................................11
3.4. Adjacency State Diagram and Table .........................13
3.5. Multiple Parallel Links ...................................14
3.6. Insufficient Space in Adjacency Table .....................15
4. RBridge LAN Ports and DRB State ................................15
4.1. Port Table Entries and DRB Election State .................16
4.2. DRB Election Events .......................................16
4.2.1. DRB Election Details ...............................17
4.2.2. Change in DRB ......................................18
4.2.3. Change in Designated VLAN ..........................18
4.3. State Table and Diagram ...................................18
5. MTU Matching ...................................................20
6. Pseudonodes ....................................................21
7. TRILL Hello Reception and Transmission .........................21
7.1. Transmitting TRILL Hellos .................................22
7.2. Receiving TRILL Hellos ....................................23
8. Multiple Ports on the Same Link ................................24
9. Security Considerations ........................................24
10. References ....................................................24
10.1. Normative References .....................................24
10.2. Informative References ...................................25
11. Acknowledgements ..............................................25
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using [IS-IS] (Intermediate System to Intermediate System) link state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs (Virtual Local Area Networks) and optimization of the distribution of multi-destination frames based on VLANs and IP-derived multicast groups. Devices that implement TRILL are called RBridges (Routing Bridges).
IETFトリル（多くのリンクの透明な相互接続）プロトコル[RFC6325]は、構成なしで最適なペアワイズデータフレーム転送、一時的なループの期間中でも安全な転送、ユニキャストとマルチキャストトラフィックの両方のマルチパスのサポートを提供します。Trillは、[IS-IS]（中間システムから中間システム）リンク状態ルーティングを使用して、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを達成します。この設計は、VLAN（仮想ローカルエリアネットワーク）と、VLANおよびIP層のマルチキャストグループに基づく多降りフレームの分布の最適化をサポートします。Trillを実装するデバイスは、Rbridges（ルーティングブリッジ）と呼ばれます。
The purpose of this document is to improve the quality of the description of four aspects of the TRILL LAN (Local Area Network) Hello protocol that RBridges use on broadcast (LAN) links. It includes reference implementation details. Alternative implementations that interoperate on the wire are permitted. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL.
このドキュメントの目的は、Rbridgesがブロードキャスト（LAN）リンクで使用するTrill LAN（ローカルエリアネットワーク）Helloプロトコルの4つの側面の説明の品質を改善することです。参照実装の詳細が含まれています。ワイヤー上で相互運用する代替の実装が許可されています。Trillのポイントツーポイントとして構成されたリンクで使用されるIS-ISポイントツーポイントのHellosに変更はありません。
The scope of this document is limited to the following aspects of the TRILL LAN Hello protocol:
このドキュメントの範囲は、Trill Lan Hello Protocolの次の側面に限定されています。
- Adjacency formation
- 隣接する形成
- DRB (Designated RBridge aka DIS (Designated Intermediate System)) election
- DRB（指定Rbridge別名DIS（指定された中級システム））選挙
- Rules for 2-way and MTU (Maximum Transmission Unit) matching for advertisements
- 2ウェイおよびMTU（最大送信ユニット）のルール広告のマッチング
- Creation and use of pseudonodes
- 偽節の作成と使用
For other aspects of the TRILL base protocol, see [RFC6325].
Trillベースプロトコルの他の側面については、[RFC6325]を参照してください。
Section 2 below explains the rationale for the differences between the TRILL LAN Hello protocol and the Layer 3 IS-IS LAN Hello protocol [IS-IS] [RFC1195] in light of the environment for which the TRILL protocol is designed. It also describes the purposes of the TRILL LAN Hello protocol.
以下のセクション2では、Trill Lan Helloプロトコルとレイヤー3 IS-IS LAN Hello Protocol [IS-IS] [RFC1195]の違いについて、Trillプロトコルが設計されている環境に照らして説明します。また、Trill Lan Hello Protocolの目的についても説明しています。
Section 3 describes the adjacency state machine and its states and relevant events.
セクション3では、隣接する状態マシンとその州と関連するイベントについて説明します。
Section 4 describes the Designated RBridge (DRB) election state machine for RBridge ports and its states and relevant events.
セクション4では、Rbridgeポートとその州および関連するイベント用の指定されたRbridge（DRB）選挙状態マシンについて説明します。
Section 5 describes MTU testing and matching on a TRILL link.
セクション5では、TrillリンクでのMTUテストとマッチングについて説明します。
Section 6 discusses pseudonode creation and use.
セクション6では、擬似ノードの作成と使用について説明します。
Section 7 provides more details on the reception and transmission of TRILL LAN Hellos.
セクション7では、Trill Lan Hellosの受信と送信の詳細について説明します。
Section 8 discusses multiple ports from one RBridge on the same link.
セクション8では、同じリンク上の1つのRbridgeからの複数のポートについて説明します。
In case of conflict between this document and [RFC6325], this document prevails.
このドキュメントと[RFC6325]の間で競合した場合、このドキュメントが勝ちます。
This document uses the acronyms defined in [RFC6325] supplemented by the following additional acronym:
このドキュメントでは、次の追加の頭字語で補足された[RFC6325]で定義された頭字語を使用します。
SNPA - Subnetwork Point of Attachment
SNPA-添付ファイルのサブネットワークポイント
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 broadcast (LAN) subnetwork-dependent functions encountered at Layer 3, which are specified in [IS-IS] Section 8.4, the TRILL protocol uses modified subnetwork-dependent functions for a LAN subnetwork. The environmental differences are described in Sections 2.1 through 2.4, followed by a summation, in Section 2.5, of the purposes of the TRILL LAN Hello protocol.
[IS-IS]は、サブネットワークに依存しない関数とサブネットワーク依存関数を備えています。現在、IS-ISのレイヤー3の使用は、2種類のサブネットワークをサポートしています。（1）ルーター間のポイントツーポイントリンクサブネットワークと（2）一般放送（LAN）サブネットワーク。レイヤー3ルーターの環境とTrill Rbridgesの環境との違いのため、[IS-IS]セクション8.4で指定されているレイヤー3で発生する放送（LAN）サブネットワーク依存関数の代わりに、Trillプロトコルが使用します。LANサブネットワーク用の修正サブネットワーク依存関数。環境の違いは、セクション2.1〜2.4で説明されており、その後、Trill Lan Hello Protocolの目的のセクション2.5に合計が続きます。
RBridges can incrementally replace IEEE [802.1Q-2005] bridges. Thus, RBridges need to provide similar services, including delivery of frames only to links in the frame's VLAN and priority queuing of frames, to the extent that multiple queues are implemented at any particular RBridge port.
Rbridgesは、IEEE [802.1Q-2005]ブリッジを徐々に置き換えることができます。したがって、Rbridgesは、特定のRbridgeポートで複数のキューが実装される範囲で、フレームのVLAN内のリンクのみにフレームのリンクのみを配信し、フレームの優先順位を提供するなど、同様のサービスを提供する必要があります。
RBridge ports are IEEE [802.1Q-2005] ports in terms of their frame VLAN and priority configuration and processing as described in Section 2.6 of [RFC6325]. When a frame is received through an RBridge port, like a frame received through any [802.1Q-2005] port, it has an associated VLAN ID and frame priority. When a frame is presented to an [802.1Q-2005] port for queuing and transmission, it must be accompanied by a VLAN ID and frame priority. However, whether the frame, if actually transmitted, will be VLAN tagged is determined by whether or not the port is configured to "strip VLAN tags". Furthermore, in the general case, a broadcast (LAN) link between RBridges can be a VLAN-capable bridged LAN that may be configured to partition VLANs.
Rbridgeポートは、[RFC6325]のセクション2.6で説明されているように、フレームVLANと優先度の構成と処理の観点からIEEE [802.1Q-2005]ポートです。[802.1Q-2005]ポートを通じて受信したフレームのように、フレームがRbridgeポートを介して受信されると、関連するVLAN IDとフレームの優先度があります。キューイングと送信用の[802.1Q-2005]ポートにフレームが表示される場合、VLAN IDとフレームの優先度を添付する必要があります。ただし、フレームが実際に送信された場合、VLANタグ付けされるかどうかは、ポートが「VLANタグをストリップ」するように構成されているかどうかによって決定されます。さらに、一般的なケースでは、Rbridges間の放送（LAN）リンクは、VLANを分割するように構成される可能性のあるVLAN利用可能なブリッジ付きLANになります。
Because devices that restrict VLAN connectivity, such as bridged LANs or provider bridging equipment, can be part of the link between RBridges, TRILL Data and TRILL IS-IS frames between RBridges use the link's Designated VLAN. The Designated VLAN is dictated for a link by the elected Designated RBridge (equivalent to the Designated Intermediate System at Layer 3). Because TRILL Data frames flow between RBridges on a link only in the link's Designated VLAN, adjacency for routing calculations is based only on connectivity characteristics in that VLAN.
ブリッジ付きLANやプロバイダーブリッジング機器などのVLAN接続を制限するデバイスは、Rbridges、Trillデータ、Rbridges間のTrill ISフレーム間のリンクの一部になり、リンクの指定VLANを使用できます。指定されたVLANは、選出された指定されたRbridge（レイヤー3の指定された中間システムに相当）によるリンクに対して決定されます。TRILLデータフレームは、リンクの指定VLANでのみリンク上のRBRIDGES間の流れであるため、ルーティング計算の隣接は、そのVLANの接続特性のみに基づいています。
Ordinary Layer 3 data 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 their outer Layer 2 addressing and, at least if the packets are unicast, they are addressed to their first hop router. In contrast, RBridges running TRILL must accept, transport, and deliver untamed "native" frames (as defined in Section 1.4 of [RFC6325]). Native frames lack a TRILL hop count field. Native frames also have Layer 2 addresses that indicate their source and are used as the basis for their forwarding. 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 (Media Access Control) address mode, while Layer 3 router ports typically receive in a regularly selective MAC address mode.
通常のレイヤー3データパケットは、エンドステーションから発信される場合、すでに「飼いならされています」。ホップカウントとレイヤー3ソースと宛先アドレスフィールドが含まれます。さらに、通常のデータパケットの場合、外側のレイヤー2アドレス指定を保持するための要件はありません。少なくともパケットがユニキャストである場合、最初のホップルーターに対処されます。対照的に、Trillを実行しているRbridgesは、[RFC6325]のセクション1.4で定義されているように、非類似の「ネイティブ」フレームを受け入れ、輸送し、配信する必要があります。ネイティブフレームには、トリルホップカウントフィールドがありません。ネイティブフレームには、ソースを示すレイヤー2アドレスもあり、転送の基礎として使用されます。これらのレイヤー2アドレスは、ネイティブフレームのレイヤー2宛先への配信のために保存する必要があります。その結果、1つの違いは、ネイティブフレームサービスを提供するRbridgeポートが無差別MAC（メディアアクセス制御）アドレスモードで受信する必要があるのに対し、レイヤー3ルーターポートは通常、定期的に選択的なMACアドレスモードで受信することです。
TRILL handles this by having, on the link where an end station originated 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 frame. This augmented frame is then routed to one RBridge on the link having the destination end station for the frame (or one RBridge on each such
トリルは、エンドステーションがネイティブフレームを起源とするリンクに、ホップカウントを含むトリルヘッダーを追加することにより、局所的に生まれたネイティブフレームを「イングレス」し、トリルデータフレームに変換することにより、これを処理します。この拡張フレームは、フレームの宛先エンドステーション（またはそれぞれに1つのrbridgeを持つリンク上の1つのRbridgeにルーティングされます。
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.)
マルチ表示フレームの場合はリンク）。このような最終的なRbridgesは「出口」関数を実行し、トリルヘッダーを削除し、元のフレームを宛先に配信します。（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. Such a loop could 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 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 on each link that is in charge of ingressing and egressing native frames from and to that link. This is the Designated RBridge that is elected using TRILL LAN Hellos as further described in Sections 2.5 and 4 below.
必須のこのようなループに対する主要なTrill防御メカニズムは、実質的に可能な限り、各リンクにネイティブフレームの侵入と脱出を担当する各リンクに、そのリンクへの出力を担当する単一のRbridgeのみがあることを保証することです。これは、以下のセクション2.5および4でさらに説明されているように、Trill Lan Hellosを使用して選出される指定されたRbridgeです。
Because bridged LANs between RBridges can be configured in complex ways (e.g., so that some VLANs pass frames unidirectionally) and loop safety is important, there are additional TRILL defenses against loops that are beyond the scope of this document. Specifically, these defend against the occurrence of looping traffic that is in native format for part of the loop. These additional defenses have no effect on adjacency states or the receipt or forwarding of TRILL Data frames; they only affect native frame ingress and egress.
Rbridge間の橋渡しLANは、複雑な方法で構成できるため（たとえば、一部のVLANがフレスを単方向に通過させる）、ループの安全性が重要であるため、このドキュメントの範囲を超えたループに対する追加のトリル防御があります。具体的には、これらはループの一部についてネイティブ形式のループトラフィックの発生に対して防御します。これらの追加の防御は、隣接する状態やTrillデータフレームの領収書または転送に影響を与えません。それらは、ネイティブのフレームの侵入と出口にのみ影響します。
RBridges are expected to provide service with zero configuration, except for services such as non-default VLAN or priority that require configuration when offered by [802.1Q-2005] bridges. 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.
Rbridgesは、[802.1Q-2005]ブリッジによって提供された場合に構成を必要とする非デフォルトVLANなどのサービスを除き、ゼロ構成でサービスを提供することが期待されています。これは、サービスを提供するために、各ポートなどに接続されたサブネットワークに関して通常、ルーターを構成する必要があるレイヤー3ルーティングとは異なります。
TRILL IS-IS needs to be robust against links with reasonably restricted MTUs, including links that accommodate only classic Ethernet frames, despite the addition of reasonable headers such as VLAN tags. This is particularly true for TRILL LAN Hellos so as to assure that a unique DRB is elected.
Trill IS-ISは、VLANタグなどの合理的なヘッダーが追加されているにもかかわらず、クラシックイーサネットフレームのみに対応するリンクを含む、合理的に制限されたMTUを使用したリンクに対して堅牢である必要があります。これは、独自のDRBが選出されることを保証するために、Trill Lan Hellosに特に当てはまります。
TRILL will also be used inside data centers where it is not uncommon for all or most of the links and switches to support frames substantially larger than the classic Ethernet maximum. For example,
また、Trillはデータセンター内で使用され、すべてまたはほとんどのリンクとスイッチがクラシックイーサネットの最大値よりも大幅に大きいフレームをサポートするために珍しくありません。例えば、
they may have an MTU adequate to comfortably handle Fiber Channel over Ethernet frames, for which T11 recommends a 2,500-byte MTU [FCoE]. It would be beneficial for an RBridge campus with such a large MTU to be able to safely make use of it.
T11は2,500バイトのMTU [FCOE]を推奨するイーサネットフレームでファイバーチャネルを快適に処理するのに適したMTUを持っている可能性があります。このような大きなMTUを備えたRbridgeキャンパスが安全に利用できるようにすることは有益です。
These needs are met by limiting the size of TRILL LAN Hellos and by the use of MTU testing as described below.
これらのニーズは、Trill Lan Hellosのサイズを制限し、以下で説明するようにMTUテストの使用によって満たされます。
There are three purposes for the TRILL-Hello protocol as listed below along with a reference to the section of this document in which each is discussed:
以下にリストされているTrill-Helloプロトコルには、それぞれが議論されているこのドキュメントのセクションへの言及とともに、次の3つの目的があります。
a) To determine which RBridge neighbors have acceptable connectivity to be reported as part of the topology (Section 3)
a) どのRbridgeの隣人がトポロジの一部として報告する許容可能な接続性を持っているかを判断するため（セクション3）
b) To elect a unique Designated RBridge on the link (Section 4)
b) リンクで一意の指定されたRbridgeを選択する（セクション4）
c) To determine the MTU with which it is possible to communicate with each RBridge neighbor (Section 5)
c) 各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 even discovered if it is impossible to communicate with it using maximum-sized 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 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, it does not disrupt Layer 3 IS-IS.
レイヤー3 IS-I-I-I-ISでは、これら3つの関数がすべて結合されています。Hellosは、最大サイズのパケットを使用して通信できない場合、ルーター隣接が発見されないように、最大長（[RFC3719]、セクション6を参照）にパディングされる可能性があります。また、隣接R2のHellosがR1によって受信されたとしても、R2への接続性が2ウェイではない場合（つまり、R2がR2のHelloでR1をリストしていない）、R1はR2を指定されたルーター候補とは見なしません。このロジックのため、複数の指定されたルーターのレイヤー3でLANで選出される可能性があり、それぞれがLANを擬似ノードとして表しています。まるでLANが2つ以上の個別のLANであるかのようにトポロジーに見えます。これは驚くべきことですが、レイヤー3 IS-ISを混乱させません。
In contrast, this behavior is not acceptable for TRILL, since in TRILL it is important that all RBridges on the link know about each other, and choose a single RBridge to be the DRB and to control the native frame ingress and egress on that link. Otherwise, multiple RBridges might encapsulate/decapsulate the same native frame, forming loops that are not protected by the hop count in the TRILL header as discussed above.
対照的に、Trillではこの動作は受け入れられません。なぜなら、Trillでは、リンク上のすべてのRbridgesが互いに知っていることが重要であり、単一のRbridgeを選択してDRBになり、そのリンクのネイティブフレームの侵入と出口を制御することが重要です。それ以外の場合、複数のRbridgesが同じネイティブフレームをカプセル化/脱カプセル化し、上記のようにTrillヘッダーのホップカウントによって保護されていないループを形成する可能性があります。
So, the TRILL-Hello protocol is best understood by focusing on each of these functions separately.
したがって、Trill-Helloプロトコルは、これらの各機能に個別に焦点を合わせることで最もよく理解されています。
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). TRILL-Hello frames, 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 Hello uses a different Neighbor TLV [RFC6326] that lists neighbors seen for a range of MAC (SNPA) addresses.
Trill Lan Hellosのもう1つの問題は、情報のサブセットが任意の単一のメッセージに表示され、IS-ISリンク状態PDU（LSP）および完全なシーケンス番号PDU（CSNP）の精神で処理可能であることを確認することです。Trill-Helloフレームは、パッドではなくても、非常に大きくなる可能性があります。これが当てはまる可能性のある例は、ある種のバックボーン技術が、トリルに見えるものを巨大なイーサネットと見なすものをめぐる何百ものトリルサイトを相互に接続する場合です。そこでは、そのクラウドに接続されたrbridgesがそのバックボーンが数百の単一のリンクであると認識します。隣人の。したがって、Trill Helloは、さまざまなMAC（SNPA）アドレスに見られる隣人をリストする別のネイバーTLV [RFC6326]を使用します。
Each RBridge port has associated with it a port state, as discussed in Section 4, and a table of zero or more adjacencies as discussed in this section. The states such adjacencies can have, the events that cause state changes, the actions associated with those state changes, and a state table and diagram are given below.
各RBRIDGEポートは、セクション4で説明されているように、このセクションで説明したゼロ以上の隣接の表に関連付けられています。そのような隣接が持つことができる州、状態の変化を引き起こすイベント、それらの状態の変更に関連するアクション、および州の表と図を以下に示します。
The determination of LSP-reported adjacencies on links that are not configured as point-to-point is made using TRILL LAN Hellos (see also Section 7) and an optional MTU test. Appropriate TRILL LAN Hello exchange and the satisfaction of the MTU test, if the MTU test is enabled (see Section 5), is required for there to be an adjacency that will be reported in an LSP of the RBridge in question.
ポイントツーポイントとして構成されていないリンク上のLSPが報告した隣接の決定は、Trill Lan Hellos（セクション7も参照）とオプションのMTUテストを使用して行われます。適切なTrill Lan Hello ExchangeとMTUテストの満足度は、MTUテストが有効になっている場合（セクション5を参照）、問題のRBRIDGEのLSPで報告される隣接性があるために必要です。
Because bridges acting as glue on the LAN might be configured in such a way that some VLANs are partitioned, it is necessary for RBridges to transmit Hellos with multiple VLAN tags. The conceptually simplest solution may have been to have all 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, and only an RBridge that believes itself to be the DRB on a port "sprays" its TRILL Hellos on all of its enabled VLANs at a port (with the ability to configure to send on only a subset of those). The details are given in [RFC6325], Section 4.4.3.
LANの接着剤として作用するブリッジは、一部のVLANが分割されるように構成される可能性があるため、Rbridgesが複数のVLANタグでHellosを送信する必要があります。概念的に最も単純なソリューションは、すべてのRBRIDGEが各ポートで各法律VLAN IDを有効にして最大4,094倍のHellosを送信することでしたが、これには明らかに有害なパフォーマンスの意味があります。したがって、Trillプロトコルは、RB1がDRBではないことを知っている場合、HELLOSを限られたVLANのセットのみに送信し、ポートのDRBであると信じているRbridgeのみを、Trill Hellosのすべてに「スプレー」することを指定しています。ポートでの有効化されたVLANのうち（それらのサブセットのみを送信するように設定する機能を備えています）。詳細については、[RFC6325]、セクション4.4.3に記載されています。
If the MAC (SNPA) address of more than one RBridge port on a 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.
リンク上の複数のRbridgeポートのMAC（SNPA）アドレスが同じである場合、そのようなポートの1つを除くすべてが一時停止状態に配置され（セクション4を参照）、リンクに参加しないでください。停止したまま。
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, and Port ID, regardless of the VLAN in which the Hello is sent. Of course, the priority and desired Designated VLAN can change on occasion, but then the new value must similarly be used in all TRILL Hellos on the port, regardless of VLAN.
特定のポートでRbridgeが発行したすべてのTrill Lan Hellosには、Helloが送信されるVLANに関係なく、同じソースMACアドレス、優先度、目的の指定VLAN、およびポートIDが必要です。もちろん、優先順位と目的の指定されたVLANは時々変更できますが、VLANに関係なく、ポート上のすべてのTrill Hellosで同様に新しい値を使用する必要があります。
Each adjacency is in one of the following four states:
各隣接は次の4つの州のいずれかにあります。
Down: This is a virtual state for convenience in creating state diagrams and tables. It indicates that the adjacency is non-existent, and there is no entry in the adjacency table for it.
ダウン：これは、状態図とテーブルを作成するのに便利な仮想状態です。これは、隣接が存在しないことを示しており、隣接テーブルにはエントリがないことを示しています。
Detect: An adjacent neighbor has been detected either (1) not on the Designated VLAN or (2) on the Designated VLAN, but neither 2-way connectivity nor the MTU of such connectivity has been confirmed.
検出：隣接する隣人が（1）指定されたVLANではなく、（2）指定されたVLAN上では検出されましたが、2方向の接続性もそのような接続のMTUも確認されていません。
2-Way: 2-way connectivity to the neighbor has been found on the Designated VLAN but MTU testing is enabled and has not yet confirmed that the connectivity meets the campus minimum MTU requirement.
2ウェイ：近隣への2ウェイ接続が指定されたVLANで見つかりましたが、MTUテストは有効になっており、接続性がキャンパスの最小MTU要件を満たしていることをまだ確認していません。
Report: There is 2-way connectivity to the neighbor on the Designated VLAN and either MTU testing has confirmed that the connectivity meets the campus minimum MTU requirement or MTU testing is not enabled. This connectivity will be reported in an LSP (with appropriate provision for the link pseudonode, if any, as described in Section 6).
レポート：指定されたVLANで近隣への2方向接続があり、いずれかのMTUテストにより、接続性がキャンパスの最小MTU要件を満たしているか、MTUテストが有効になっていないことが確認されています。この接続性は、LSPで報告されます（セクション6で説明されているように、リンクPSEUDONODEの適切な規定がある場合、ある場合は）。
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つの非ダウン状態（検出、2ウェイ、またはレポート）のいずれかの隣接する場合、隣接するテーブルエントリがあります。そのエントリは隣接の状態を与え、以下にリストされている情報も含めます。
o The address of the neighbor (that is, its SNPA address, usually a 48-bit MAC address), and the Port ID and the System ID in the received Hellos. Together, these three quantities uniquely identify the adjacency.
o ネイバーのアドレス（つまり、SNPAアドレス、通常は48ビットMACアドレス）と、受信したHellosのポートIDとシステムID。一緒に、これらの3つの量は隣接を一意に識別します。
o Exactly two Hello holding timers, each consisting of a 16-bit unsigned integer number of seconds: a Designated VLAN holding timer and a non-Designated VLAN holding timer.
o それぞれが16ビットの署名されていない整数秒数で構成される正確な2つのHello Holdingタイマー：指定されたVLAN保持タイマーと非指定VLAN保持タイマー。
o The 7-bit unsigned priority of the neighbor to be the DRB.
o 隣人の7ビットの署名の優先度がDRBになること。
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になりたいと考えているVLAN。
The following events can change the state of an adjacency:
次のイベントは、隣接の状態を変更できます。
A0. Receive a TRILL Hello whose source MAC address (SNPA) is equal to that of the port on which it is received. This is a special event that is handled as described immediately after this list of events. It does not appear in the state transition table or diagram.
A0。ソースMACアドレス（SNPA）が受信されたポートのそれに等しいTrill Helloを受け取ります。これは、このイベントのリストの直後に説明されているように処理される特別なイベントです。状態遷移表や図には表示されません。
A1. Receive a TRILL Hello (other than an A0 event) on the Designated VLAN with a TRILL Neighbor TLV that explicitly lists the receiver's (SNPA) address.
A1。受信者（SNPA）アドレスを明示的にリストするTrill Neighbor TLVを使用して、指定されたVLANでTrill Hello（A0イベントを除く）を受け取ります。
A2. Receive a TRILL Hello (other than an A0 event) that either (1) is not on the Designated VLAN (any TRILL Neighbor TLV in such a Hello is ignored) or (2) is on the Designated VLAN but does not contain a TRILL Neighbor TLV covering an address range that includes the receiver's (SNPA) address.
A2。（1）が指定されたVLAN（このようなHelloのTrill隣人TLVは無視されていない）または（2）が指定されたVLAN上にないが、Trill Neighborを含んでいない、Trill Hello（A0以外のA0イベントを除く）を受け取ります。受信者（SNPA）アドレスを含むアドレス範囲をカバーするTLV。
A3. Receive a TRILL Hello (other than an A0 event) on the Designated VLAN with one or more TRILL Neighbor TLVs covering an address range that includes the receiver's (SNPA) address -- and none of which lists the receiver.
A3。指定されたVLANでTrill Hello（A0イベントを除く）を受け取ります。1つまたは複数のTrill Neighbor TLVが、受信機（SNPA）アドレスを含むアドレス範囲をカバーし、レシーバーをリストしていません。
A4. The expiration of one or both Hello holding timers results in them both being expired.
A4。片方または両方のハロー保持タイマーの有効期限は、両方とも期限切れになります。
A5. The Designated VLAN Hello holding timer expires, but the non-Designated VLAN Hello holding timer still has time left until it expires.
A5。指定されたVLAN Hello Holding Timerは期限切れになりますが、指定されていないVLAN Hello Holding Timerは、期限切れになるまで残っています。
A6. MTU test successful.
A6。MTUテストが成功しました。
A7. MTU test was successful but now fails.
A7。MTUテストは成功しましたが、現在失敗しています。
A8. The RBridge port goes operationally down.
A8。Rbridgeポートは操作的にダウンします。
For the special A0 event, the Hello is examined to determine if it is higher priority to be the DRB than the port on which it is received 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 that 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が受信ポートよりも優先度が低い場合、それ以上のアクションはありません。受信ポートよりも優先度が高い場合、そのポートの隣接は破棄され（ダウン状態に移行）、セクション4.2で説明されているようにポートが中断されます。
The receipt of a TRILL LAN Hello with a source MAC (SNPA) address different from that of the receiving port (that is, the occurrence of events A1, A2, or A3), causes the following actions (except where the Hello would create a new adjacency table entry, the table is full, or the Hello is too low priority to displace an existing entry as described in Section 3.6). The Designated VLAN used in these actions is the Designated VLAN dictated by the DRB determined without taking the received TRILL LAN Hello into account (see Section 4).
ソースMAC（SNPA）を備えたTrill Lan Helloの受信（SNPA）は、受信ポート（つまり、イベントA1、A2、またはA3の発生）とは異なるアドレスを備えています。新しい隣接テーブルエントリ、テーブルはいっぱいです。または、セクション3.6で説明されているように、既存のエントリを移動するには優先度が低すぎます。これらのアクションで使用されている指定VLANは、受信したTrill Lanを考慮せずに決定されたDRBによって指定された指定VLANです（セクション4を参照）。
o If the receipt of the Hellos creates a new adjacency table entry, the neighbor RBridge MAC (SNPA) address, Port ID, and System ID are set from the Hello.
o Hellosの受領が新しい隣接テーブルエントリを作成すると、Neighbor Rbridge Mac（SNPA）アドレス、ポートID、およびシステムIDがHelloから設定されます。
o The appropriate Hello holding timer for the adjacency, depending on whether or not the Hello was received on the Designated VLAN, is set to the Holding Time field of the Hello. If the receipt of the Hello is creating a new adjacency table entry, the other timer is set to expired.
o 隣接する適切なハロー保持タイマーは、指定されたVLANでHelloが受信されたかどうかに応じて、Helloの保持時間フィールドに設定されます。Helloの受領が新しい隣接テーブルエントリを作成している場合、他のタイマーは期限切れに設定されています。
o The priority of the neighbor RBridge to be the DRB is set to the priority field of the Hello.
o DRBである隣のRbridgeの優先順位は、Helloの優先フィールドに設定されています。
o 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 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選挙の結果を変更する場合、セクション4.2で説明されているように、上記のアクションの後、適切なRbridgeポートイベント（D2またはD3）が発生します。
o 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が変更された場合、セクション4.2.3で指定されているリンクの指定VLANの変化があります。。
An event A4 resulting in both Hello Holding timers for an adjacency being expired and the adjacency going Down may also result in an event D3 as described in Section 4.2.
イベントA4は、隣接能力のタイマーを有効にするためのHello Holding Timersと、セクション4.2で説明されているようにイベントD3になる可能性があります。
Concerning events A6 and A7, if MTU testing is not enabled, A6 is considered to occur immediately upon the adjacency entering the 2-Way state, and A7 cannot occur.
イベントA6とA7に関しては、MTUテストが有効になっていない場合、A6は2ウェイ状態に入る隣接時にすぐに発生すると見なされ、A7は発生できません。
See further TRILL LAN Hello receipt details in Section 7.
セクション7のトリルlanハロー領収書の詳細を参照してください。
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 |
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 above.
n/aは、左側のイベントが列の上部にある状態に適用されないことを示しています。これらのイベントは、単一の隣接のみに影響します。特別な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 |
+---------+
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 could be established.)
Trillに見える近隣のRbridge間には、複数の平行隣接があります。（リンク集約[802.1AX]などのテクノロジーによって結合された複数の低レベルリンク[802.1AX]は、単一のTrill隣接のみを確立できる単一のリンクとしてTrillに見えます。）
Any such links that have pseudonodes (see Section 6) are distinguished in the topology; such adjacencies, if they are in the Report state, appear in LSPs as per Section 6. However, there can be
偽節を持つそのようなリンク（セクション6を参照）は、トポロジーで区別されます。このような隣接は、レポート状態にある場合、セクション6に従ってLSPに表示されます。ただし、
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) and Appendix C of [RFC6325].
擬似ノードが作成されていないポイントツーポイントの隣接またはLAN隣接であるため、擬似ノードのない複数の並列隣接。レポート状態のこのような並行して、非義理の隣接は、LSPに単一の隣接として表示されます。このような隣接のコストは、並列パスを考慮して下向きに調整できます。このような並列接続全体のマルチパスは、単キャストトリルデータトラフィックのためにフローごとに自由に行うことができますが、セクション4.5.2（ポイント3）および[RFC6325]の付録Cで説明されているように、マルチ誘引トラフィックには制限されています。
If the receipt of a TRILL LAN 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. In that case, the DRB election priority (see Section 4.2.1) of the new entry that would be created is compared with that 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.
Trill Lan Helloの受領が新しい隣接テーブルエントリを作成する場合（つまり、隣接がダウン状態から移行する）、新しいエントリのためのスペースがない場合があります。その場合、作成される新しいエントリのDRB選挙の優先順位（セクション4.2.1を参照）は、既存のエントリのその優先順位と比較されます。新しいエントリが既存の最優先事項よりも優先度が高い場合、ダウン状態に移行されている最優先の優先度の既存のエントリを置き換えます。
The information at an RBridge associated with each of its LAN ports includes the following:
それぞれのLANポートに関連付けられたRbridgeの情報には、以下が含まれます。
o Enablement bit, which defaults to enabled.
o イネーブルメントビット。デフォルトで有効になります。
o SNPA address (usually 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 Hellos sent on the port.
o Trill Hellosで使用されるDRBであることの優先順位は、ポートで送信されました。
o The DRB status 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 this port, used in TRILL Hellos sent on the port.
o 目的の指定VLAN。VLANこのRbridgeは、ポートで送信されたTrill Hellosで使用されているこのポートのリンクの指定されたVLANになりたいと考えています。
o A table of zero or more adjacencies (see Section 3).
o ゼロ以上の隣接の表（セクション3を参照）。
The TRILL equivalent of the DIS (Designated Intermediate System) on a link is the DRB or Designated RBridge. The DRB election state machinery is described below.
リンク上のDIS（指定された中間システム）に相当するTRILLは、DRBまたは指定されたRBRIDGEです。DRB選挙状態の機械については、以下に説明します。
Each RBridge port 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 adjacency table entries for the port, and no TRILL Hellos or other IS-IS PDUs or TRILL Data frames are accepted or transmitted.
ダウン：ポートは動作しています。リンクレイヤーで管理上無効またはダウンしている可能性があります。この状態では、ポートの隣接テーブルエントリはなく、Trill Hellosまたはその他の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 Hellosが受け入れられていることを除いて、ダウン状態と同じです。
DRB: The port is the DRB and can receive and transmit TRILL Data frames.
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 frames.
DRBではありません：ポートはリンク上の別のポートに延期しています。これはDRBであると考えられていますが、Trillデータフレームを受信および送信できます。
The following events can change the DRB state of a port:
次のイベントでは、ポートのDRB状態を変更できます。
D1. Expiration of the suspension timer while the port is in the Suspended state or the enablement of the port.
D1。ポートが一時停止状態またはポートの有効化中にサスペンションタイマーの有効期限。
D2. 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。ポートの隣接テーブルが変更され、リンク上の1つ以上の他のRbridgeポートのエントリがあり、ローカルポートよりもDRBよりも優先度が高いと思われます。
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。ポートがダウンまたは吊り下げられておらず、ポートの隣接テーブルが変更されているため、リンク上の他のRbridgeポートのエントリは、ローカルポートよりもDRBよりも優先度が高いと思われるエントリがありません。
D4. Receipt of a TRILL Hello with 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 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 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と、ダウン状態以外の隣接状態の港に隣接するすべてのRbridgesです。勝者は、RbridgeのHellosが受け取った7ビット優先度フィールドから決定され、Mac（SNPA）アドレスがタイブレーカー、ポートIDとしてのDRBフィールドになることを優先するように、DRBになる最優先事項のRbridgeです。セカンダリタイブレーカーとして、および第三のタイブレーカーとしてのシステムIDとして。これらのフィールドは、より大きな優先度と見なされている、より大きな大きさが署名されていない整数と比較されます。
Resort 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, that 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, 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）アドレスを持っていて、それらのいくつかがまだ吊り下げられていない場合にのみ必要です。たとえば、リンク上のDRBになるよりも優先度が低いRB1は、互いに同じMACアドレスを持つリンク上の2つの他のポートからHellosを受け取ることができ、DRBであるよりも優先度が高い。同じMACアドレスを持つこれら2つのポートの1つは停止され、Hellosの送信をやめ、RB1が受け取ったHelloは最終的にタイムアウトします。しかし、それまでの間、RB1はタイブレーカーを使用して、どのポートがDRBであるかを判断することができ、したがってどのポートがリンクに指定されたVLANを設定するような目的のために信じるポートが挨拶することができます。
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 the 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 Designated RBridge and not being the Designated RBridge at a port, this will generally change the VLANs on which Hellos are sent by that RBridge on that port as specified in Section 4.4.3 of [RFC6325].
Rbridgeが指定されたRbridgeであり、ポートで指定されたRbridgeではないこととの間にいずれかの方向に変化する場合、これにより、[RFC6325]のセクション4.4.3で指定されているように、そのポートのRbridgeによってHellosが送信されるVLANが変更されます。。
Unnecessary changes in the Designated VLAN on a link should be avoided because a change in the Designated VLAN can cause a transient interruption 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, in case the winner of the DRB election changes, for any reason, the Designated VLAN will remain the same.
指定されたVLANの変更により、リンク上のTRILLデータ転送に一時的な中断を引き起こす可能性があるため、リンク上の指定VLANの不必要な変更を避ける必要があります。実用的な場合、リンク上のすべてのRbridgeポートは、同じ目的の指定VLANで構成する必要があります。これにより、DRB選挙の勝者が変更された場合、何らかの理由で指定されたVLANが同じままになります。
If an RBridge detects a change in Designated VLAN on a 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 Holding Timerは、有効期限までの最大時間と、指定されたVLAN Hello Holdingタイマーの有効期限まで現在の時間に設定されています。
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 Holding Timerが期限切れに設定され（必要に応じて）設定され、隣接するイベント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].
リンクの指定されたVLANが変更された場合、これにより、一般に、[RFC6325]のセクション4.4.3で指定されているように、そのリンクのRbridgeポートによってHellosが送信されるVLANが変更されます。
The table below shows the transitions between the DRB states defined above based on the events defined above:
以下の表は、上記のイベントに基づいて上記のDRB状態間の遷移を示しています。
| Event | Down | Suspend | 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 | Suspend | Suspend | Suspend |
| D5 | Down | Down | Down | Down |
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 |
+----+
The purpose of MTU testing is to ensure that the links used in the campus topology can pass TRILL IS-IS and Data frames at the RBridge campus MTU.
MTUテストの目的は、キャンパストポロジで使用されるリンクがRbridge Campus MTUでTrill ISとデータフレームを渡すことができるようにすることです。
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.
RbridgeのRB1は、リンク状態データベースで宣伝されているが1,470バイト以下である、キャンパス内の他のRbridgeの最小値とキャンパス内の他のRbridgeの発信元のlsspbuffersizeを計算することにより、目的のキャンパスリンクMTUを決定します。レイヤー3 [IS-IS]の由来の由来は512〜1,492バイトの範囲に制限されていますが、トリルでは範囲1,470〜65,535バイトを含む範囲に制限されています。
Although MTU testing is optional, it is mandatory for an RBridge to respond to an MTU-probe PDU with an MTU-ack PDU [RFC6325] [RFC6326]. 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 multicasting MTU-probes when a response from all other RBridges on the link is desired, such as when initializing or re-confirming MTU, unicasting MTU-probes when a response from a single RBridge is desired, such as one that has just been detected on the link, and unicasting all MTU-ack frames.
MTUテストはオプションですが、RbridgeがMTU-ack PDU [RFC6325] [RFC6326]を使用してMTUプローブPDUに応答することは必須です。MTU-ProbeおよびMTU-ACKのマルチキャストまたはユニキャストの使用は、実装の選択肢です。ただし、MTUを初期化または再確認するときなど、リンク上の他のすべてのRbridgeからの応答が必要な場合、MTUポーチをマルチリキャストすることにより、リンクの負担は一般に最小化されます。リンクで検出されたばかりのものや、すべての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 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 MTU failure is noticed by the RBridge at either end of the adjacency, it will not be so used.
RB1は、[RFC6325]のセクション4.3.2で説明されているように、MTUサイズをRB2にテストできます。この目的のために、MTUテストは指定されたVLANでのみ行われます。Campus MTUでMTUテストに失敗した隣接は報告状態に入りません。または、隣接がその状態にある場合、その状態を離れます。したがって、MTUテストに失敗した隣接性は、テストを実行するRbridgeによって報告されません。最小コストのルート計算に含めるには、隣接の両端がMTUの障害が認識されている限り、隣接を両端で報告する必要があるため、隣接するrbridgeがそのように使用されません。
If it tests MTU, RB1 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.
MTUをテストすると、RB1はMTUテストが成功する最大サイズまたはキャンパスMTUで失敗したことを示すフラグを報告します。このレポートは、RB1のTrill Neighbor TLVの隣人に常に表示されます。RB1は、RB1のLSPの拡張された到達可能性TLVの隣接性でこれを報告することもできます。RB1は、目的のキャンパスMTUおよび目的のキャンパスMTUよりも大きいMTUサイズをテストすることを選択できます。
Most types of TRILL IS-IS frames, 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フレームは、キャンパスMTUを利用できます。例外は、ループの安全性のために小さく保つ必要があるTrill Hellosと、実行中のテストのためにサイズを適切に調整する必要があるMTU PDUSです。
The Designated RBridge (DRB), determined as described above, controls whether a pseudonode will be used on a link.
上記のように決定された指定された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 HellosにバイパスPseudonodeビットを設定すると、リンク上のRbridges（DRBを含む）が、レポート状態にあるLAN上のすべての隣接を直接報告します。DRBがTrill HellosにバイパスPseudonodeビットを設定しない場合、（1）DRBはLSPで擬似ノードへの隣接性を報告します。レポート状態の隣接性を確認するリンク上の他のrbridges、および（3）リンク上の他のすべてのRbridgesは、DRBへの隣接が報告状態にあると見なし、報告しない場合、擬似ノードへの隣接を報告しますリンク上のその他の隣接。バイパスの擬似ノードビットの設定は、LSPがリンクにどのように浸水するかに影響を与えません。LSPが生成されるものにのみ影響します。
It is anticipated that many links between RBridges will actually be point-to-point, 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 DRB, then if RB1 creates a pseudonode that is used, there are 3 LSPs: for, say, RB1.25 (the pseudonode), 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. Whereas 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.
Rbridges間の多くのリンクは実際にはポイントツーポイントになると予想されています。その場合、擬似ノードを使用することは単に複雑さを増すだけです。たとえば、RB1とRB2がリンク上の唯一のRbridgesであり、RB1がDRBである場合、RB1が使用される擬似ノードを作成する場合、3つのLSPがあります。RB1.25はRB1およびRB2への接続性を報告し、RB1とRB2はそれぞれRB1.25に接続されていると言われています。一方、DRB Rb1がHellosにバイパスPseudonodeビットを設定する場合、RB1とRB2の2つのLSPのみが互いに接続を報告します。
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つの同時隣接を見ていない場合、Hellosにバイパス擬似ノードビットを設定する必要があります。
This section provides further details on the receipt and transmission of TRILL LAN Hellos.
このセクションでは、Trill Lan Hellosの領収書と送信に関する詳細を説明します。
TRILL LAN Hellos, like all TRILL IS-IS frames, are primarily distinguished from Layer 3 IS-IS frames by being sent to the All-IS-IS-RBridges multicast address (01-80-C2-00-00-41). TRILL IS-IS frames also have the L2-IS-IS Ethertype (0x22F4) and are Ethertype encoded.
Trill Lan Hellosは、すべてのTrill IS-ISフレームと同様に、主にレイヤー3 ISフレームと区別されます。Trill IS-ISフレームには、L2-IS-IS EtherType（0x22F4）もあり、EtherTypeエンコードされています。
Although future extensions to TRILL may include use of Level 2 IS-IS, [RFC6325] specifies TRILL using a single Level 1 Area with Area Address zero (see Section 4.2 of [RFC6326]).
Trillへの将来の拡張にはレベル2 IS-ISの使用が含まれる場合がありますが、[RFC6325]は、面積アドレスゼロの単一レベル1エリアを使用してTrillを指定します（[RFC6326]のセクション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 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 receive TRILL LAN Hellos on every port that is not disabled or configured as point-to-point.
IS-ISレイヤー3ルーターは、異なるルーティングドメインの一部である他のレイヤー3ルーターに頻繁に接続されています。その場合、外部ドメインフラグ（[is-is]を参照）は通常、そのような接続が行われるポートに設定されます。このフラグを「真」に設定すると、IS-IS PDUはポートから送信されます。Rbridgesは、すべての隣人Rbridgesが単一のキャンパスに融合する別の環境で動作します。ループの安全性については、Rbridgesは外部ドメインフラグを実装したり、固定値「False」で実装したりしません。彼らは、無効化されていない、またはポイントツーポイントとして構成されていないすべてのポートにTrill Lan Hellosを送信および受け取ります。
TRILL LAN Hellos are sent with the same timing as Layer 3 IS-IS LAN Hellos [IS-IS]; however, no Hellos are sent if a port is in the Suspended or Down states.
Trill Lan Hellosは、レイヤー3 IS-IS LAN HELLOS [IS-IS]と同じタイミングで送信されます。ただし、ポートが停止状態またはダウン状態にある場合、Hellosは送信されません。
TRILL-Hello PDUs SHOULD NOT be padded and MUST NOT be sent exceeding 1,470 octets; however, a received TRILL Hello longer than 1,470 octets is processed normally.
Trill-hello PDUSをパッドに入れないでください。1,470オクテットを超えて送信してはなりません。ただし、1,470を超えるオクテットが正常に処理されているのに、受信したトリルハローが処理されます。
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に等しい。
Each TRILL Hello MUST contain an Area Addresses TLV listing only the single Area zero, and an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC6326]. If a Protocols Supported TLV is present, it MUST list the TRILL NLPID (0xC0).
各TRILL Helloには、単一のエリアゼロのみをリストするTLVアドレスと、VLAN-FLAGS SUB-TLV [RFC6326]を含むMTポート機能TLVを含むエリアを含める必要があります。サポートされているTLVが存在する場合、Trill NLPID（0xc0）をリストする必要があります。
The TRILL Neighbor TLV sent in a Hello 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 Hellos on the Designated VLAN.
Helloで送信されたTrill Neighbor TLVは、Helloが送信されるVLANについて、送信Rbridgeで感知されるように、隣人情報を表示する必要があります。このドキュメントに準拠している実装は、指定されたVLANに対してのみVLANごとにそのような情報を維持するため、そのような実装は、指定されたVLANのTrill HellosのTrill Neighbor 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 TLV's covering sub-ranges of MAC addresses should be sent so that the entire range is covered reasonably promptly. Delays in sending TRILL
十分なスペースがある場合は、[RFC6325]のセクション4.4.2.1で説明されているように、Trill隣のTLVまたはTLVがある場合、MACアドレスの全範囲をカバーし、すべての隣接を非ゼロの指定VLAN Hello Holdingでリストすることをお勧めします。時間、またはそのような隣接する隣人の空のリストは、指定されたVLANに送られたTrill Hellosにあります。これが不可能な場合は、Trill Neighbor TLVのサブレンジのMacアドレスをカバーして、全範囲が合理的に迅速にカバーされるように送信する必要があります。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 Bidirectional Forwarding Detection (BFD) [RFC5880], use of which with TRILL will be specified in a separate document.
近隣のTLVは、レポート状態への隣接の進歩といくつかのリンク障害の発見を遅らせます。リンクまたはノードの障害の迅速な（たとえば、サブ秒）検出は、双方向転送検出（BFD）[RFC5880]などのその目的のために設計されたプロトコルで最もよく対処されます。。
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, never appears in any list.
Rbridge RB2がRB1がRB2を聞くことができるかどうかを明確に判断できるようにするために、RB1の隣接リストは、最終的に可能なあらゆる範囲のID、つまり、RB1のポリシーに依存し、必ずしも保有時間などの特定の期間内ではない期間内にカバーする必要があります。。言い換えれば、X1がRB1の隣接リストの1つで報告されている最小のIDであり、「最小」フラグが設定されていない場合、そのフラグメントで報告された最大のIDが別の近隣リストにも表示されなければなりません。または、ギャップがない限り、リストが重複する場合があります。そのため、XiとXJの間にある範囲がいずれかのリストに表示されない場合があります。
A TRILL Hello MAY also contain any TLV permitted in a Layer 3 IS-IS Hello. TLVs that are unsupported/unknown are ignored.
Trill Helloには、レイヤー3 IS-IS Helloで許可されているTLVも含まれている場合があります。サポートされていない/不明のTLVは無視されます。
Assuming a frame has the All-IS-IS-RBridges multicast address and L2-IS-IS Ethertype, it will be examined to see if it appears to be an IS-IS PDU. If so, and it appears to be a LAN Hello PDU, the following tests are performed.
フレームにはAll-IS-IS-RBRIDGESマルチキャストアドレスとL2-IS-IS EtherTypeがあると仮定すると、IS-IS PDUのように見えるかどうかを確認するために調べられます。もしそうなら、それはLAN Hello PDUのように見えます、次のテストが実行されます。
o If the Circuit Type field is not 1, the PDU is discarded.
o 回路型フィールドが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が含まれていない場合、または単一エリアアドレスゼロではないエリアアドレス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が含まれている場合、破棄されます。TLVがサポートされているプロトコルが存在しない場合、受け入れられます。
o If the Hello does not contain an MT Port Capabilities TLV containing a VLAN-FLAGS sub-TLV [RFC6326], it is discarded.
o HelloにVLAN-Flags Sub-TLV [RFC6326]を含むMTポート機能TLVが含まれていない場合、廃棄されます。
o If the maximumAreaAddresses field of the PDU is not 1, it is discarded.
o PDUの最大値フィールドが1でない場合、破棄されます。
o If IS-IS authentication is in use on the link and the PDU either has no Authentication TLV or validation of that Authentication TLV fails, it is discarded.
o IS-IS認証がリンクで使用されており、PDUに認証TLVがないか、その認証TLVの検証が失敗した場合、破棄されます。
If none of the rules in the list above has been satisfied, and the frame 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.
上記のリストのルールが満たされておらず、フレームが断片化可能である場合、リンクで受け取った適切に形成されたトリルのHelloであると想定されています。セクション3.3にリストされている基準に基づいて、イベントA0、A1、A2、またはA3として扱われます。
It is possible for an RBridge RB1 to have multiple ports on the same 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 LAN Hello messages with the same LAN ID on multiple ports.
Rbridge RB1が、吊り下げられた状態にないのと同じリンクに複数のポートを持つことができます。RB1が同じリンクにあるポートのどれを認識することが重要です。RB1は、複数のポートで同じLAN IDを持つTrill Lan 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 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 and it is safe to do so as described in Section 4.4.4 of [RFC6325].
DRB選挙は港湾ベースであり（セクション4を参照）、選出されたポートのHellosのみが、指定されたVLANを指示するなどの特定の機能を実行できます。ただし、選挙では、リンクのDRBとしてそのポートを使用してRbridgeを指定しています。Rbridgeは、[RFC6325]のセクション4.4.4で説明されているように、複数の場合、リンク上のポートにいくつかのタスクを分割することを選択することができます。
This memo provides improved documentation of some aspects of the TRILL base protocol standard, particularly four aspects of the TRILL LAN Hello protocol. It does not change the security considerations of the TRILL base protocol. See Section 6 of [RFC6325].
このメモは、Trill Base Protocol標準のいくつかの側面、特にTrill Lan Hello Protocolの4つの側面のいくつかの側面の改善されたドキュメントを提供します。Trill Baseプロトコルのセキュリティ上の考慮事項は変更されません。[RFC6325]のセクション6を参照してください。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing 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、第2版、「Connectionless-Mode Network Service（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-I-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月。
[RFC6325] Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、D。Eastlake、D。Dutt、S。Gai、およびA. Ghanwani、「Rbridges：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.
[RFC6326] Eastlake、D.、Banerjee、A.、Dutt、D.、Perlman、R。、およびA. Ghanwani、「IS-ISのTrill使用」、RFC 6326、2011年7月。
[802.1AX] "IEEE Standard for Local and metropolitan area networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
[802.1AX]「ローカルおよびメトロポリタンエリアネットワーク /リンク集約のIEEE標準」、802.1AX-2008、2008年1月1日。
[802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.1Q-2005]「ローカルおよびメトロポリタンエリアネットワーク /仮想ブリッジ付きローカルエリアネットワークのIEEE標準」、802.1Q-2005、2006年5月19日。
[FCoE] From www.t11.org discussion of "FCoE Max Size" generated from T11/09-251v1, 04/27/2009, "FCoE frame or FCoE PDU".
[FCOE] www.t11.orgから、T11/09-251V1、04/27/2009、「FCOEフレームまたはFCOE PDU」から生成された「FCOEマックスサイズ」の議論。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", February 2004.
[RFC3719] Parker、J.、ed。、「中間システムから中間システム（IS-IS）を使用した相互運用可能なネットワークの推奨」、2004年2月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「双方向転送検出（BFD）」、RFC 5880、2010年6月。
The authors of [RFC6325], those listed in the Acknowledgements section of [RFC6325], and the contributions of Jari Arkko, Ayan Banerjee, Les Ginsberg, Sujay Gupta, David Harrington, Pete McCann, Erik Nordmark, and Mike Shand, to this document, are hereby acknowledged.
[RFC6325]の著者、[RFC6325]の謝辞セクションにリストされている著者、およびJari Arkko、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
ドナルドE.イーストレイク、3番目の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-1549 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、CA 95054-1549 USA
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
Anoop Ghanwani Brocade 130 Holger Way San Jose、CA 95134 USA
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave, Cupertino, CA 95014 USA
Vishwas Manral Hewlett Packard Co. 19111 Pruneridge Ave、Cupertino、CA 95014 USA
Phone: +1-408-447-1497
EMail: vishwas.manral@hp.com