[要約] RFC 6439は、RBridgesにおけるAppointed Forwardersの役割と目的を定義しています。Appointed Forwardersは、RBridges間のトラフィックを効率的に転送するために任命された特定のポートです。このRFCの目的は、Appointed Forwardersの動作と選択方法を明確にすることです。
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 6439 Intel Labs
Updates: 6325 D. Eastlake 3rd
Category: Standards Track Y. Li
ISSN: 2070-1721 Huawei Technologies
A. Banerjee
Cisco Systems
F. Hu
ZTE Corporation
November 2011
Routing Bridges (RBridges): Appointed Forwarders
ルーティングブリッジ（Rbridges）：任命されたフォワーダー
Abstract
概要
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, 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 "RBridges" (Routing Bridges).
IETFトリル（多くのリンクの透明な相互接続）プロトコルは、任意のトポロジーを備えたマルチホップネットワークでの構成なし、一時的なループの期間中でも安全な転送、ユニキャストとマルチキャストトラフィックの両方のマルチパスのサポートをサポートする最小コストペアワイズデータ転送を提供します。Trillは、IS-IS（中間システムから中間システム）リンク状態ルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを達成します。Trillを実装するデバイスは、「Rbridges」（ルーティングブリッジ）と呼ばれます。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325.
Trillは、複数のエンドステーションとRbridgesが添付される可能性のあるマルチアクセスLAN（ローカルエリアネットワーク）リンクをサポートしています。複数のrbridgesがリンクに取り付けられている場合、そのリンクのエンドステーションとの間のネイティブトラフィックは、各VLAN（仮想LAN）のネイティブトラフィックが処理されることを目的として、「指定されたフォワーダー」と呼ばれるRbridgesのサブセットによって処理されます。ほとんどのRbridge。このドキュメントの目的は、指定された転送メカニズムの文書を改善することです。したがって、RFC 6325を更新します。
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/rfc6439.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6439で取得できます。
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 ....................................................2
1.1. Terminology and Acronyms ...................................3
2. Appointed Forwarders and Their Appointment ......................4
2.1. Appointment Effects of DRB Elections .......................5
2.2. Appointment and Removal by the DRB .........................5
2.2.1. Processing Forwarder Appointments ...................6
2.2.2. Frequency of Appointments ...........................7
2.2.3. Appointed Forwarders Limit ..........................8
2.3. Local Configuration Action Appointment Effects .............8
2.4. VLAN Mapping within a Link .................................9
3. The Inhibition Mechanism ........................................9
4. Inhibited Appointed Forwarder Behavior .........................11
5. Multiple Ports on the Same Link ................................12
6. Security Considerations ........................................12
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
Appendix. VLAN Inhibition Example .................................14
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology, 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) [IS-IS] [RFC1195] link state routing and encapsulating traffic using a header that includes a hop count. The design
IETFトリル（多くのリンクの透明な相互接続）プロトコル[RFC6325]は、任意のトポロジー、一時的なループの期間中でも安全な転送、および単菌の両方のマルチパスのサポートを備えたマルチホップネットワークでの構成なしで最適なペアワイズデータフレーム転送を提供しますおよびマルチキャストトラフィック。Trillは、IS-IS（中間システムから中間システム）[IS-IS] [RFC1195]を使用して、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを達成します。デザイン
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).
VLAN（仮想ローカルエリアネットワーク）と、VLANおよびIP層のマルチキャストグループに基づいたマルチデステーションフレームの分布の最適化をサポートします。Trillを実装するデバイスは、「Rbridges」（ルーティングブリッジ）と呼ばれます。
Section 2 of [RFC6327] explains the environment for which the TRILL protocol is designed and the differences between that environment and the typical Layer 3 routing environment.
[RFC6327]のセクション2では、Trillプロトコルが設計されている環境と、その環境と典型的なレイヤー3ルーティング環境の違いについて説明します。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multiple RBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called "Appointed Forwarders", with the intent that native traffic in each VLAN be handled by at most one RBridge. An RBridge can be Appointed Forwarder for many VLANs.
Trillは、複数のエンドステーションとRbridgesが添付される可能性のあるマルチアクセスLAN（ローカルエリアネットワーク）リンクをサポートしています。複数のRBRIDGEがリンクに接続されている場合、そのリンクのエンドステーションとの間のネイティブトラフィックは、各VLANのネイティブトラフィックを最大1つのRbridgeによって処理することを目的として、「指定されたフォワーダー」と呼ばれるRbridgeのサブセットによって処理されます。Rbridgeは、多くのVLANの転送者に任命できます。
The purpose of this document is to improve the documentation of the Appointed Forwarder mechanism; thus, it updates RFC 6325. It includes reference implementation details. Alternative implementations that interoperate on the wire are permitted.
このドキュメントの目的は、指定された転送メカニズムの文書を改善することです。したがって、RFC 6325を更新します。参照実装の詳細が含まれています。ワイヤー上で相互運用する代替の実装が許可されています。
The Appointed Forwarder mechanism is irrelevant to any link on which end station service is not offered. This includes links configured as point-to-point IS-IS links and any link with all RBridge ports on that link configured as trunk ports. (In TRILL, configuration of a port as a "trunk port" just means that no end station service will be provided. It does not imply that all VLANs are enabled on that port.)
任命されたフォワーダーメカニズムは、エンドステーションサービスが提供されていないリンクとは無関係です。これには、ポイントツーポイントIS-ISリンクとして構成されたリンクと、トランクポートとして構成されたリンク上のすべてのRbridgeポートとのリンクが含まれます。（Trillでは、「トランクポート」としてのポートの構成は、エンドステーションサービスが提供されないことを意味します。これは、すべてのVLANがそのポートで有効になっていることを意味しません。）
The Appointed Forwarder mechanism has no effect on the formation of adjacencies, the election of the Designated RBridge (DRB) for a link, MTU matching, or pseudonode formation. Those topics are covered in [RFC6327]. Furthermore, Appointed Forwarder status has no effect on the forwarding of TRILL Data frames. It only affects the handling of native frames.
任命されたフォワーダーメカニズムは、隣接の形成、リンクの指定されたRbridge（DRB）の選挙、MTUマッチング、または擬似ノード形成に影響を与えません。これらのトピックについては、[RFC6327]で説明しています。さらに、任命されたフォワーダーのステータスは、Trillデータフレームの転送に影響を与えません。ネイティブフレームの処理にのみ影響します。
For other aspects of the TRILL base protocol, see [RFC6325] and [RFC6327]. Familiarity with [RFC6325] and [RFC6327] is assumed in this document. In case of conflict between this document and [RFC6325], this document prevails.
Trillベースプロトコルの他の側面については、[RFC6325]および[RFC6327]を参照してください。このドキュメントでは、[RFC6325]および[RFC6327]に精通しています。このドキュメントと[RFC6325]の間で競合した場合、このドキュメントが勝ちます。
This document uses the acronyms defined in [RFC6325].
このドキュメントでは、[RFC6325]で定義されている頭字語を使用しています。
A "trunk port" is a port configured with the "end station service disable" bit on, as described in Section 4.9.1 of [RFC6325].
「トランクポート」は、[RFC6325]のセクション4.9.1で説明されているように、「エンドステーションサービスを無効にする」ビットで構成されたポートです。
In this document, the term "link" means "bridged LAN", that is to say some combination of physical links with zero or more bridges, hubs, repeaters, or the like.
このドキュメントでは、「リンク」という用語は「ブリッジ付きLAN」を意味します。つまり、ゼロ以上のブリッジ、ハブ、リピーターなどとの物理的リンクの組み合わせです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワードは「必須」、「必要」、「必須」、「shall」、「shall "、" bood "、" low "not"、 "becommended"、 "bodement"、 ""、 "、" optional「このドキュメントでは、[RFC2119]に記載されているように解釈されます。
The Appointed Forwarder on a link for VLAN-x is the RBridge that ingresses native frames from the link and egresses native frames to the link in VLAN-x. By default, the DRB (Designated RBridge) on a link is in charge of native traffic for all VLANs on the link. The DRB may, if it wishes, act as Appointed Forwarder for any VLAN and it may appoint other RBridges that have ports on the link as Appointed Forwarder for one or more VLANs.
VLAN-Xのリンクに任命されたフォワーダーは、リンクからネイティブフレームを侵入し、ネイティブフレームをVLAN-Xのリンクに誘惑するRbridgeです。デフォルトでは、リンク上のDRB（Rbridgeに指定されたRbridge）は、リンク上のすべてのVLANのネイティブトラフィックを担当しています。DRBは、希望する場合、任意のVLANの任命されたフォワーダーとして機能し、1つ以上のVLANの任命されたフォワーダーとしてリンクにポートを持つ他のRbridgesを任命する場合があります。
It is important that there not be two Appointed Forwarders on a link that are ingressing and egressing native frames for the same VLAN at the same time. Should this occur, it could form a loop where frames are not protected by a TRILL Hop Count for part of the loop. (Such a condition can even occur through two Appointed Forwarders for two different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the link are configured to map frames between VLAN-x and VLAN-y as discussed in Section 2.4.) While TRILL tries to avoid such situations, for loop safety there is also an "inhibition" mechanism (see Section 3) that can cause an RBridge that is an Appointed Forwarder to not ingress or egress native frames.
同じVLANのネイティブフレームを侵入して脱出しているリンクに、2人の任命された転送業者が同時に登場していないことが重要です。これが発生した場合、ループの一部のトリルホップカウントによってフレームが保護されていないループを形成する可能性があります。（このような条件は、2つの異なるVLAN、VLAN-XとVLAN-Yの2つの任命されたフォワーダーを介して発生する可能性があります。リンク内のポートまたはブリッジが、セクション2.4で説明されているようにVLAN-XとVLAN-Yの間のフレームをマッピングするように構成されている場合さえ発生します。）Trillはそのような状況を避けようとしますが、ループの安全性のために、ネイティブフレームを侵入または出力しないように指定されたフォワーダーであるRbridgeを引き起こす可能性のある「阻害」メカニズム（セクション3を参照）もあります。
As discussed in Section 5, an RBridge may have multiple ports on a link. As discussed in [RFC6327], if there are multiple ports with the same Media Access Control (MAC) address on a link, all but one will be suspended. The case of multiple ports on a link for one RBridge and the case of multiple ports with the same MAC address on a link and combinations of these cases are fully accommodated; however, multiple ports on a link for one RBridge is expected to be a rare condition and duplicate MAC addresses are not recommended by either TRILL or IEEE 802.1 standards.
セクション5で説明したように、Rbridgeにはリンクに複数のポートがある場合があります。[RFC6327]で説明したように、リンクに同じメディアアクセス制御（MAC）アドレスを持つ複数のポートがある場合、1つを除くすべてが停止されます。1つのRbridgeのリンク上の複数のポートのケースと、これらのケースのリンクと組み合わせに同じMACアドレスを持つ複数のポートのケースは完全に収容されています。ただし、1つのRbridgeのリンク上の複数のポートはまれな状態であると予想されており、TrillまたはIEEE 802.1標準のいずれでも複製されたMacアドレスは推奨されません。
Appointed Forwarder status has no effect on the forwarding of TRILL Data frames. It only affects the handling of native frames.
任命されたフォワーダーのステータスは、Trillデータフレームの転送に影響を与えません。ネイティブフレームの処理にのみ影響します。
There are three mechanisms by which an RBridge can be appointed or un-appointed as Appointed Forwarder: as a result of the DRB elections [RFC6327] as discussed in Section 2.1, as a result of action by the DRB as discussed in Section 2.2, as a result of a local configuration action as discussed in Section 2.3.
セクション2.2で説明したDRB選挙の結果として、DRB選挙[RFC6327]の結果として、Rbridgeを指定された転送者として任命または任命できない3つのメカニズムがあります。セクション2.3で説明したローカル構成アクションの結果。
When an RBridge believes that it has become the DRB on a link, by default, it can act as Appointed Forwarder for any VLANs on that link that it chooses as long as its port is not configured as a trunk port and has that VLAN enabled (or at least one of its ports meets these criteria, if it has more than one port on the link).
RbridgeがリンクのDRBになったと信じている場合、デフォルトでは、ポートがトランクポートとして構成されていない限り、そのリンク上の任意のVLANの任命されたフォワーダーとして機能することができます（そのVLANが有効になっている限り）または、リンクに複数のポートがある場合、そのポートの少なくとも1つがこれらの基準を満たしています）。
An RBridge loses all Appointed Forwarder status when:
Rbridgeは、次の場合に指定されたすべての転送ステータスを失います。
1. it decides that it has lost the status of being the DRB for a link; or
1. リンクのDRBであるというステータスを失ったと判断しました。また
2. it observes a change in the RBridge that is the DRB for the link without itself becoming the DRB.
2. それは、それ自体がDRBにならずにリンクのDRBであるRbridgeの変化を観察します。
In the rare corner case where an RBridge has more than one port on a link, one of which was previously the DRB election winner but has just lost the DRB election to a different port of the same RBridge (possibly due to management configuration of port priorities), there is no change in which RBridge is the DRB. Therefore, neither of the above points applies and there is no change in Appointed Forwarder status.
Rbridgeがリンクに複数のポートを持っているまれなコーナーケースでは、そのうちの1つは以前はDRB選挙の勝者でしたが、同じRbridgeの別のポートへのDRB選挙を失ったばかりです（おそらくポート優先順位の管理構成による）、RbridgeがDRBである変更はありません。したがって、上記のポイントのいずれも適用されず、任命されたフォワーダーステータスに変更はありません。
The DRB may appoint other RBridges on the link through inclusion of one or more Appointed Forwarders sub-TLVs [RFC6326] in a TRILL Hello it sends on the Designated VLAN out the port that won the DRB election. When the DRB sends any appointments in a TRILL Hello, it must send all appointments for that link in that Hello. Any previous appointment not included is implicitly revoked.
DRBは、DRB選挙に勝ったポートから指定されたVLANに送信されるTrill Helloで、1つ以上の任命されたフォワーダーサブTLV [RFC6326]を含めることにより、リンクに他のRBRIDGEを任命することができます。DRBがTrill Helloで予約を送信するとき、そのリンクのすべての予定をそのHelloで送信する必要があります。含まれていない以前の任命は、暗黙的に取り消されます。
Although the DRB does not need to announce the VLANs for which it has chosen to act as Appointed Forwarder by sending appoints for itself, if the DRB wishes to revoke all appointments for RBridges other than itself on the link, it is recommended that it send a TRILL Hello with an appointment for itself for some VLAN.
DRBは、任命されたフォワーダーとして行動することを選択したVLANをそれ自体のために送信することを選択する必要はありませんが、DRBがリンク上のRBRIDGES以外のすべての任命を取り消すことを希望する場合、それはそれが送信することをお勧めしますTrill Hello hell with for for for some vlan。
The DRB MUST NOT send any appointments on a link unless its DRB inhibition timer (see Section 3) for that link is expired.
DRBは、そのリンクの有効期限が切れているため、DRB阻害タイマー（セクション3を参照）を除いて、リンクに予約を送信してはなりません。
How the DRB decides what other RBridges on the link, if any, to appoint forwarder for which VLANs is beyond the scope of this document.
DRBが、このドキュメントの範囲を超えてVLANが登録されているフォワーダーを任命するために、リンク上の他のRbridgesを決定する方法。
When a non-DRB RBridge that can offer end station service on a link receives a TRILL Hello that is not discarded for one of the reasons given in [RFC6327], it checks the source MAC address and the Port ID and System ID in the Hello to determine if it is from the winning DRB port. If it is not from that port, any Appointed Forwarder sub-TLVs in the Hello are ignored, and there is no change in the receiving RBridge's Appointed Forwarder status. Also, if no Appointed Forwarder sub-TLVs are present in the TRILL Hello, there is no change in the receiver's Appointed Forwarder status.
リンクでエンドステーションサービスを提供できる非DRB Rbridgeが、[RFC6327]で与えられた理由の1つで破棄されないTrill Helloを受信すると、HelloのソースMACアドレスとポートIDとシステムIDをチェックします。優勝したDRBポートからかどうかを判断します。そのポートからのものではない場合、Helloの任命されたフォワーダーのサブTLVは無視され、Rbridgeの任命された転送状態の受信に変更はありません。また、Trill Helloに任命されたフォワーダーのサブTLVが存在しない場合、受信者の指定されたフォワーダーステータスに変更はありません。
However, if the TRILL Hello is from the winning DRB port and the Hello includes one or more Appointed Forwarder sub-TLVs, then the receiving RBridge becomes appointed for the VLANs that are both listed for it in the Hello and are enabled on the receiving port. (If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored, but any other VLAN IDs are still effective.) If the receiver was Appointed Forwarder for any other VLANs, its Appointed Forwarder status for such other VLANs is revoked. For example, if none of these sub-TLVs in a Hello appoints the receiving RBridge, then it loses all Appointed Forwarder status and is no longer Appointed Forwarder for any VLAN on the port where the Hello was received.
ただし、Trill Helloが優勝したDRBポートからのものであり、Helloが1つ以上の任命されたフォワーダーサブTLVを含む場合、受信RBRIDGEはHelloにリストされ、受信ポートで有効になっているVLANに任命されます。。（予約にVLAN IDが0x000または0xFFFが含まれている場合、それらは無視されますが、他のVLAN IDはまだ効果的です。）受信者が他のVLANの転送者に任命された場合、そのような他のVLANの指定されたフォワーダーステータスが取り消されます。たとえば、HelloのこれらのサブTLVが受信Rbridgeを任命していない場合、任命されたすべてのフォワーダーステータスを失い、Helloが受信されたポートのVLANのフォワーダーに任命されなくなりました。
The handling of one or more Appointed Forwarder sub-TLVs in a Hello from the winning port that appoints the receiving RBridge is as follows. An appointment in an Appointed Forwarder sub-TLV is for a specific RBridge and a contiguous interval of VLAN IDs; however, as stated above, it actually appoints that RBridge forwarder only for the VLAN(s) in that range that are enabled on one or more ports that RBridge has on the link (ignoring any ports configured as trunk ports or as IS-IS point-to-point ports). If the RBridge was Appointed Forwarder for any additional VLANs beyond the VLANs for which it was being appointed, it loses Appointed Forwarder status for such additional VLANs.
受信rbridgeを任命する勝利ポートからのHelloで、1つ以上の任命されたフォワーダーサブTLVの処理は次のとおりです。任命されたフォワーダーSUB-TLVでの予約は、特定のRBRIDGEとVLAN IDの連続的な間隔を対象としています。ただし、上記のように、実際には、Rbridgeがリンク上にある1つ以上のポートで有効になっているその範囲のVLANのみのRbridge Forwarderのみを任命します（トランクポートとして構成されているポートまたはIS ISポイントを無視してください - ポイントポートまで）。Rbridgeが、任命されているVLANを超えた追加のVLANの転送者に任命された場合、そのような追加のVLANに対して任命されたフォワーダーステータスを失います。
There is no reason for an RBridge to remember that it received a valid appointment message for a VLAN that was ineffective because the VLAN was not enabled on the port where the message was received or because the port was a trunk or point-to-point port. It does not become Appointed Forwarder for such a VLAN just because that VLAN is later enabled or the port later reconfigured.
RbridgeがVLANの有効な予約メッセージを受け取ったことを覚えておく理由はありません。これは、メッセージが受信されたポートでVLANが有効になっていないため、またはポートがトランクまたはポイントツーポイントポートであったために有効になっていないためです。。そのVLANが後で有効になったり、ポートが後で再構成されたりするという理由だけで、このようなVLANのフォワーダーに任命されることはありません。
It should be straightforward for the DRB to send, within one Hello, the appointments for several dozen VLAN IDs or several dozen blocks of contiguous VLAN IDs. Should the VLANs the DRB wishes to appoint be inconveniently distributed, for example, the proverbial case where the DRB RB1 wishes to appoint RB2 forwarder for all even-numbered VLANs and appoint RB3 forwarder for all odd-numbered VLANs, the following method may be used. The network manager normally controls what VLANs are enabled on RBridge port. Thus, the network manager can appoint an RBridge forwarder for an arbitrary set of scattered VLANs by enabling only those VLANs on the relevant port (or ports) and then having the DRB send an appointment that appears to appoint the target RBridge forwarder for all VLANs. However, for proper operation and inter-RBridge communication, the Designated VLAN for a link SHOULD be enabled on all RBridge ports on that link, and it may not be desired to appoint the RBridge forwarder for the Designated VLAN. Thus, in the general case, it would require two appointments, although it would still only require one appointment if the Designated VLAN were an extreme low or high value such as VLAN 0xFFE or the default VLAN 1.
DRBが1つのハロー内で、数十個のVLAN IDまたは数十ブロックの連続したVLAN IDの予定を送信するのは簡単です。 DRBが不便に配布することを望んでいる場合、たとえばDRB RB1がすべての均等なVLANにRB2転送を任命し、すべての奇数番号VLANにRB3フォワーダーを任命することを望んでいることを望む場合、次の方法を使用できます。 。ネットワークマネージャーは通常、Rbridgeポートで有効になっているVLANを制御します。したがって、ネットワークマネージャーは、関連するポート（またはポート）でそれらのVLANのみを有効にすることにより、散在するVLANの任意のセットのRbridge Forwerderを任命し、すべてのVLANのターゲットRbridgeフォワーダーを任命するように見える予約をDRBに送信することができます。ただし、適切な操作とRブリッジ間通信のために、そのリンク上のすべてのRbridgeポートでリンクの指定VLANを有効にする必要があり、指定されたVLANのRbridgeフォワーダーを任命することは望ましくない場合があります。したがって、一般的なケースでは、2つの予約が必要ですが、指定されたVLANがVLAN 0xffeまたはデフォルトのVLAN 1などの極端な低いまたは高い値である場合、1つの予約のみが必要になります。
For example, assume the DRB wants RB2 to be Appointed Forwarder for all even-numbered VLANs and the Designated VLAN for the link is VLAN 101. The network manager could cause all even-numbered VLANs plus VLAN 101 to be enabled on the relevant port of RB2 and then, with the desired effect, cause the DRB to send appointments to RB2 appointing it forwarder for all VLANs from 1 through 100 and from 102 through 4,094.
たとえば、DRBがRB2がすべての均等なVLANの転送者に任命されたいと考えていると仮定し、リンクに指定されたVLANはVLAN 101です。RB2およびその後、望ましい効果により、DRBはRB2に予定を送信し、100から100から102〜4,094までのすべてのVLANのフォワーダーを任命します。
Should the network manager have misconfigured the enabled VLANs and Appointed Forwarders, resulting in two RBridges believing they are Appointed Forwarders for the same VLAN, then item 4 in Section 3 will cause one or more of the RBridges to be inhibited for that VLAN.
ネットワークマネージャーが有効なVLANを誤って構成し、任命されたフォワーダーを任命した場合、2つのRbridgesが同じVLANのフォワーダーに任命されていると信じている場合、セクション3のアイテム4はそのVLANに対して1つ以上のRbridgeを阻害します。
It is not necessary for the DRB to include the forwarder appointments in every TRILL Hello that it sends on the Designated VLAN for a link. For loop safety, every RBridge is required to indicate, in every TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed Forwarder for VLAN-x for that link (see item 4 in Section 3). It is also RECOMMENDED that the DRB have all VLANs for which end station service will be offered on the link as well as the Designated VLAN, enabled. Thus, the DRB will generally be informed by other RBridges on the link of the VLANs for which they believe they are Appointed Forwarder. If this matches the appointments the DRB wishes to make, it is not required to re-send its forwarder appointments; however, for robustness, especially in cases such as VLAN misconfigurations in
DRBが、リンクの指定されたVLANに送信するすべてのTrill Helloに転送業者の予定を含める必要はありません。ループの安全性のために、すべてのRbridgeを示す必要があります。すべてのトリルでは、リンクでVLAN-Xで送信されます。これは、そのリンクのVLAN-Xの任命されたフォワーダーであるかどうか（セクション3の項目4を参照）。また、DRBには、リンクでエンドステーションサービスが提供されるすべてのVLANが有効になることをお勧めします。したがって、DRBは一般に、彼らが任命されたフォワーダーであると信じているVLANのリンクに関する他のRbridgesから通知されます。これがDRBが希望する任命と一致する場合、フォワーダーの任命を再送信する必要はありません。ただし、特にVLANの間違い性のような場合の場合、堅牢性のために
a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder appointments on the Designated VLAN at least once per its Holding Time on the port that won the DRB election.
橋渡しされたLANリンクであるため、DRBは、DRB選挙に勝った港の保有時間に従って、指定VLANのフォワーダーの予約を送信することをお勧めします。
The mechanism of DRB forwarder appointment and the limited length of TRILL Hellos impose a limit on the number of RBridges on a link that can be Appointed Forwarders. To obtain a conservative estimate, assume that no more than 1000 bytes are available in a TRILL Hello for such appointments. Assume it is desired to appoint various RBridges on a link forwarder for arbitrary non-intersecting sets of VLANs. Using the technique discussed above would generally require two appointments, or 12 bytes, per RBridge. With allowance for sub-TLV and TLV overhead, appointments for 83 RBridges would fit in under 1000 bytes. Including the DRB, this implies a link with 84 or more RBridges attached. Links with more than a handful of RBridges attached are expected to be rare.
DRBフォワーダーの予約のメカニズムとTrill Hellosの長さが限られているため、フォワーダーを指定できるリンク上のRbridgesの数に制限があります。保守的な推定を取得するために、そのような任命のためにTrill Helloで1000バイト以下が利用可能でないと仮定します。VLANの任意の非交差セットセットのために、リンク転送者にさまざまなRbridgeを任命することが望ましいと仮定します。上記の手法を使用するには、通常、Rbridgeごとに2つの予定、または12バイトが必要です。Sub-TLVおよびTLVのオーバーヘッドの許容量により、83のRbridgesの予定は1000バイト未満に収まります。DRBを含めて、これは84以上のRbridgeが添付されたリンクを意味します。いくつかのRbridgeが添付されているリンクはまれであると予想されます。
Note: If the Designated VLAN were an extreme low or high value, such as VLAN 1, which is the default and may be a common value in practice, only 6 bytes per RBridge would be required. This would permit twice as many different Appointed Forwarder RBridges than indicated by the general analysis above or, alternatively, would take only half as much space to appoint the same number of Appointed Forwarders.
注：指定されたVLANが、デフォルトであり、実際には共通の値であるVLAN 1などの極端な低い値または高い値である場合、Rbridgeあたり6バイトのみが必要です。これにより、上記の一般的な分析で示されるよりも2倍の異なる任命されたフォワーダーRbridgesが許可されます。または、同じ数の任命されたフォワーダーを任命するために半分のスペースしかかかりません。
Unnecessary changes in Appointed Forwarders SHOULD NOT be made as they may result in transient lack of end station service. Large numbers of Appointed Forwarders on a link (in excess of 65) are NOT RECOMMENDED due to the complexity of their establishment and maintenance.
任命されたフォワーダーの不必要な変更は、エンドステーションサービスの一時的な不足をもたらす可能性があるため、行うべきではありません。リンク上の多数の任命されたフォワーダー（65を超える）は、設立とメンテナンスの複雑さのために推奨されません。
Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder status that RBridge has for VLAN-x unless VLAN-x is enabled on some other port that the RBridge has connected to the same link. Configuring a port as a trunk port or point-to-point port revokes any Appointed Forwarder status that depends on enabled VLANs at that port.
RbridgeポートでVLAN-Xを無効にすると、Rbridgeが同じリンクに接続されている他のポートでVLAN-Xが有効になっていない限り、RbridgeがVLAN-Xに対して持っている任命されたフォワーダーステータスをキャンセルします。ポートをトランクポートまたはポイントツーポイントポートとして構成すると、そのポートで有効なVLANに依存する指定されたフォワーダーステータスが取り消されます。
Causing a port to no longer be configured as a trunk or point-to-point port or enabling VLAN-x on a port does not, in itself, cause the RBridge to become an Appointed Forwarder for the link that port is on. However, such actions can allow the port's RBridge to become Appointed Forwarder by choice if it is the DRB or by appointment, if it is not the DRB on the link.
ポートをトランクまたはポイントツーポイントポートとして構成しなくなった場合、またはポートでVLAN-Xを有効にすること自体は、Rbridgeがポートが使用されているリンクの任命された転送者になることはありません。ただし、このようなアクションにより、ポートのRbridgeは、リンク上のDRBではない場合、DRBまたは予約によって選択することにより、選択によりフォワーダーに任命されることができます。
TRILL Hellos include a field that is set to the VLAN in which they are sent. If they arrive on a different VLAN, then VLAN mapping is occurring within the link. (Such VLAN mapping within a link between RBridges should not be confused with VLAN mapping inside an RBridge [VLANMAP]). VLAN mapping between VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for the VLANs are different. If such mapping within a link was allowed and occurred on two or more links so that there was a cycle of VLAN mappings, a broadcast frame, for example, would loop forever.
Trill Hellosには、送信されるVLANに設定されたフィールドが含まれています。別のVLANに到着した場合、VLANマッピングはリンク内で発生します。（Rbridges間のリンク内のこのようなVLANマッピングは、Rbridge [VLANMAP]内のVLANマッピングと混同しないでください）。VLAN-XとVLAN-Yの間のVLANマッピングは、VLANの指定されたフォワーダーが異なる場合、ループにつながる可能性があります。リンク内のそのようなマッピングが許可され、2つ以上のリンクで発生してVLANマッピングのサイクルがあるように発生した場合、たとえばブロードキャストフレームは永遠にループします。
To prevent this potential problem, if the DRB on a link detects VLAN mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it MUST make or revoke appointments so as to assure that the same RBridge (possibly the DRB) is the Appointed Forwarder on the link for both VLAN-x and VLAN-y.
この潜在的な問題を防ぐために、リンクのDRBがVLAN-Yで送信されたVLAN-XでHelloを受信してVLANマッピングを検出する場合、同じRbridge（おそらくDRB）を保証するために予約を作成または取り消す必要があります。VLAN-XとVLAN-Yの両方のリンクに任命されたフォワーダーです。
An RBridge has, for every link on which it can offer end station service (that is every link for which it can act as an Appointed Forwarder), the following timers denominated in seconds:
Rbridgeには、エンドステーションサービスを提供できるすべてのリンク（任命されたフォワーダーとして機能するすべてのリンク）があり、次のタイマーは秒単位で命名されます。
- a DRB inhibition timer,
- DRB阻害タイマー、
- a root change inhibition timer, and
- ルート変更阻害タイマー、および
- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.
- 最大4,094 VLAN阻害タイマー、各法律VLAN IDに1つ。
The DRB and root change inhibition timers MUST be implemented.
DRBおよびルート変更阻害タイマーを実装する必要があります。
The loss of native traffic due to inhibition will be minimized by logically implementing a VLAN inhibition timer per each VLAN for which end station service will ever be offered by the RBridge on the link; this SHOULD be done. (See the Appendix for an example motivating VLAN inhibition timers.) However, if implementation limitations make a full set of such timers impractical, the VLAN inhibition timers for more than one VLAN can, with care, be merged into one timer. In particular, an RBridge MUST NOT merge the VLAN inhibition timers together for two VLANs if it is the Appointer Forwarder for one and not for the other, as this can lead to unnecessary indefinitely prolonged inhibition. In the limit, there will be safe operations, albeit with more native frame loss than would otherwise be required, even if only two VLAN inhibition timers are provided: one for VLANs for which the RBridge is the Appointed Forwarder and one for all other VLANs. At least two VLAN inhibition
抑制によるネイティブトラフィックの喪失は、リンク上のRbridgeによってエンドステーションサービスが提供される各VLANごとにVLAN阻害タイマーを論理的に実装することにより最小化されます。これは行う必要があります。（VLAN阻害タイマーの動機付けの例については、付録を参照してください。）ただし、実装の制限がそのようなタイマーの完全なセットを非現実的にする場合、複数のVLANのVLAN阻害タイマーは、注意して1つのタイマーに統合することができます。特に、Rbridgeは、1つが1つではなくAppointer Forwerderである場合、2つのVLANのVLAN阻害タイマーを一緒にマージしてはなりません。限界では、2つのVLAN阻害タイマーのみが提供されていても、ネイティブフレームの損失が必要なよりも多くのネイティブフレーム損失があるにもかかわらず、安全な操作があります。少なくとも2つのVLAN阻害
timers MUST be implemented. Where a VLAN inhibition timer represents more than one VLAN, an update or test that would have been done to the timer for any of the VLANs is performed on the merged timer.
タイマーを実装する必要があります。VLAN阻害タイマーが複数のVLANを表している場合、VLANのいずれかについてタイマーに対して行われた更新またはテストがマージされたタイマーで実行されます。
These timers are set as follows:
これらのタイマーは次のように設定されています。
1. On booting or management reset, each port will have its own set of timers, even if two or more such ports are on the same link, because the RBridge will not have had a chance to learn that yet. All inhibition timers are set to expired except the DRB inhibition timer that is set in accordance with item 2 below. The DRB inhibition timer is handled differently because each port will initially believe it is the DRB.
1. ブートまたは管理のリセットでは、2つ以上のポートが同じリンク上にある場合でも、各ポートにはタイマーのセットがあります。これは、Rbridgeがまだそれを学ぶ機会がなかったためです。すべての抑制タイマーは、以下の項目2に従って設定されたDRB阻害タイマーを除き、期限切れに設定されています。DRB阻害タイマーは、各ポートが最初にDRBであると信じているため、異なる方法で処理されます。
2. When an RBridge decides that it has become the DRB on a link, including when it is first booted or reset by management, it sets the DRB inhibition timer to the Holding Time of its port on that link that won the DRB election.
2. Rbridgeが、管理によって最初に起動またはリセットされたときなど、リンクのDRBになったことを決定すると、DRB選挙に勝ったリンクのポートの保持時間にDRB阻害タイマーを設定します。
3. When an RBridge decides that it has lost DRB status on a link, it sets the DRB inhibition timer to expired.
3. RbridgeがリンクでDRBステータスを失ったと判断した場合、DRB阻害タイマーを有効期限に設定します。
Note: In the rare corner case where one port of an RBridge was the DRB election winner, but later lost the DRB election to a different port of the same RBridge on that link (perhaps due to management configuration of port priority), neither 2 nor 3 above applies, and the DRB timer is not changed.
注：Rbridgeの1つの港がDRB選挙の勝者であったまれなコーナーケースでは、後にそのリンク上の同じRbridgeの別のポート（おそらくポートの優先順位の構成による）のDRB選挙を失いました。上記の3が適用され、DRBタイマーは変更されません。
4. When an RBridge RB1 receives a TRILL Hello asserting that the sender is the Appointed Forwarder that either (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated inside the Hello, then RB1 sets its VLAN-x inhibition timer for the link to the maximum of that timer's existing value and the Holding Time in the received Hello. An RBridge MUST maintain VLAN inhibition timers for a link to which it connects if it can offer end station service on that link even if it is not currently Appointed Forwarder for any VLAN on that link.
4. Rbridge RB1がTrill Helloを受け取ったとき、送信者が（1）VLAN-Xに到着するか（2）Helloの内部に示されているようにVLAN-Xに送信された任命された転送者であると主張すると、RB1はVLAN-X阻害を設定します。タイマーの既存の値の最大値へのリンクと、受信したHelloの保持時間へのタイマー。Rbridgeは、そのリンクのVLANに現在任命されていない場合でも、そのリンクでエンドステーションサービスを提供できる場合、接続するリンクのVLAN阻害タイマーを維持する必要があります。
5. When an RBridge RB1 enables VLAN-x on a port connecting to a link and VLAN-x was previously not enabled on any of RB1's ports on that link, it sets its VLAN inhibition timer for VLAN-x for that link to its Holding Time for that port. This is done even if the port is configured as a trunk or point-to-point port as long as there is some chance it might later be configured not to be a trunk or point-to-point port.
5. Rbridge RB1がリンクに接続するポートでVLAN-Xを有効にし、VLAN-Xが以前にそのリンク上のRB1のポートのいずれでも有効になっていなかった場合、VLAN-XのVLAN阻害タイマーをそのリンクに設定します。そのポート。これは、ポートがトランクまたはポイントツーポイントポートとして構成されていても、後でトランクまたはポイントツーポイントポートではないように構成される可能性がある限り、実行されます。
6. When an RBridge detects a change in the common spanning tree root bridge on a port, it sets its root change inhibition timer for the link to an amount of time that defaults to 30 seconds and is configurable to any value from 30 down to zero seconds. This condition will not occur unless the RBridge is receiving Bridge PDU (BPDUs) on the port from an attached bridged LAN. It is safe to configure this inhibition time to the settling time of an attached bridged LAN. For example, if it is known that Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running throughout the attached bridged LAN, it should be safe to configure this inhibition time to 7 seconds or, if the attached bridges have been configured to have a minimum Bridge Hello Timer, safe to configure it to 4 seconds. Note that, while an RBridge could determine what version of spanning tree is running on the physical link between it and any directly connected bridge by examination of the BPDUs it receives, it could not tell if inter-bridge links beyond those directly connected bridges were running classic Spanning Tree Protocol (STP), which might require the root change inhibition timer to be set to 30 seconds for safety.
6. Rbridgeがポートの一般的なスパンニングツリールートブリッジの変更を検出すると、リンクのルート変更抑制タイマーをデフォルトでデフォルトで30秒に任意の値に設定できます。この状態は、Rbridgeが取り付けられたブリッジ付きLANからポートにブリッジPDU（BPDU）を受け取っていない限り発生しません。この抑制時間を取り付けられた橋渡しLANの沈降時間に構成することは安全です。たとえば、迅速なスパニングツリープロトコル（RSTP [802.1Q]）が付属されているブリッジ型LAN全体で実行されていることがわかっている場合、この阻害時間を7秒に設定するか、接続されたブリッジが構成されている場合は安全である必要があります。最小のブリッジハロータイマー、4秒に構成するために安全です。 Rbridgeは、受信するBPDUの検査により、Spanningツリーのバージョンが物理的リンクと直接接続されたブリッジで実行されているかどうかを判断できますが、直接接続されたブリッジを超えたブリッジ間リンクが実行されているかどうかはわかりません。古典的なスパニングツリープロトコル（STP）。これは、安全のためにルート変更阻害タイマーを30秒に設定する必要がある場合があります。
7. When an RBridge decides that one of its ports (or a set of its ports) P1 is on the same link as another of its ports (or set of its ports) P2, then the inhibition timers are merged to a single set of inhibition timers by using the maximum value of the corresponding timers.
7. Rbridgeがポートの1つ（またはポートのセット）P1が別のポート（またはポートのセット）P2と同じリンクにあると判断すると、抑制タイマーは阻害タイマーの単一のセットにマージされます。対応するタイマーの最大値を使用します。
8. When an RBridge decides that a set of its ports that it had been treating as being on the same link are no longer on the same link, those ports will necessarily be on two or more links (one link per port in the limit). This is handled by cloning a copy of the timers for each of the two or more links to which the RBridge has decided these ports connect.
8. Rbridgeが、同じリンクにあると扱っていたポートのセットが同じリンクにないと判断した場合、それらのポートは必ず2つ以上のリンク（制限のポートごとに1つのリンク）にあります。これは、Rbridgeがこれらのポートが接続することを決定した2つ以上のリンクのそれぞれについて、タイマーのコピーをクローニングすることによって処理されます。
An Appointed Forwarder for a link is inhibited for VLAN-x if:
リンクの任命されたフォワーダーは、以下の場合、VLAN-Xに対して阻害されます。
1. its DRB inhibition timer for that link is not expired, or
1. そのリンクのDRB阻害タイマーは有効期限が切れていない、または
2. its root change inhibition timer for that link is not expired, or
2. そのリンクのルート変更阻害タイマーは有効期限が切れていない、または
3. its VLAN inhibition timer for that link for VLAN-x is not expired.
3. VLAN-XのリンクのVLAN阻害タイマーは期限切れではありません。
If a VLAN-x Appointed Forwarder for a link is inhibited and receives a TRILL Data frame whose encapsulated frame is in VLAN-x and would normally be egressed to that link, it decapsulates the native frame
リンクのVLAN-Xが任命されたフォワーダーが阻害され、カプセル化されたフレームがVLAN-Xにあり、通常はそのリンクにegされるトリルデータフレームを受信すると、ネイティブフレームが脱カプセル化されます。
as usual. However, it does not output it to or queue it for that link, although, if appropriate (for example, the frame is multi-destination), it may output it to or queue it for other links.
いつものように。ただし、そのリンクに出力したり、キューに出力したりしませんが、必要に応じて（たとえば、フレームはマルチ候補です）、他のリンクに出力またはキューに出力する場合があります。
If a VLAN-x Appointed Forwarder for a link is inhibited and receives a native frame in VLAN-x that would normally be ingressed from that link, the native frame is ignored except for address learning.
リンクのVLAN-Xが任命されたフォワーダーが阻害され、通常そのリンクから侵入されるVLAN-Xのネイティブフレームを受信すると、住所学習を除いてネイティブフレームは無視されます。
An RBridge with one or more unexpired inhibition timers, possibly including an unexpired inhibition timer for VLAN-x, is still required to indicate in TRILL Hellos it sends on VLAN-x whether or not it is Appointed Forwarder for VLAN-x for the port on which it sends the Hello.
VLAN-Xの期限切れの抑制タイマーを含む、おそらく1つ以上の期限切れの抑制タイマーを備えたRbridgeは、VLAN-Xに送信するTrill Hellosで、ポートのVLAN-Xのフォワーダーが任命されているかどうかを示す必要があります。それはこんにちはを送ります。
Inhibition has no effect on the receipt or forwarding of TRILL Data frames.
阻害は、Trillデータフレームの受領または転送に影響を与えません。
An RBridge may have multiple ports on the same link. Some of these ports may be suspended due to MAC address duplication as described in [RFC6327]. Suspended ports never ingress or egress native frames.
Rbridgeには、同じリンクに複数のポートがある場合があります。これらのポートの一部は、[RFC6327]に記載されているように、MACアドレスの重複のために停止される場合があります。吊り下げられたポートは、ネイティブフレームを侵入したり出力したりしません。
If an RBridge has one or more non-suspended ports on a link and those ports offer end station service, that is, those ports are not configured as point-to-point or trunk ports, then that RBridge is eligible to be an Appointed Forwarder for that link. It can become Appointed Forwarder either by its choice, because it is the DRB, or by appointment by the DRB as described in Sections 2.1 and 2.2.
Rbridgeにリンクに1つ以上の吊り下げのないポートがあり、それらのポートがエンドステーションサービスを提供する場合、つまり、それらのポートはポイントツーポイントまたはトランクポートとして構成されていない場合、Rbridgeは任命された転送者になる資格がありますそのリンクのために。それは、それがDRBであるため、またはセクション2.1および2.2で説明されているDRBによる予約により、その選択によりフォワーダーに任命される可能性があります。
If an RBridge that is the Appointed Forwarder for VLAN-x on a link has multiple non-suspended ports on that link, it may load share the task of ingressing and egressing VLAN-x native frames across those ports however it chooses, as long as there is no case in which a frame it egresses onto the link from one port can be ingressed on another of its ports, creating a loop. If the RBridge is the Appointed Forwarder for multiple VLANs, a straightforward thing to do would be to partition those VLANs among the ports it has on the link.
リンク上のVLAN-Xの任命されたフォワーダーであるRbridgeがそのリンク上に複数の懸濁ポートを備えている場合、それらのポートでVLAN-Xネイティブフレームを侵入して脱出するタスクをロードする可能性がありますが、選択します。1つのポートからリンクに出口を登録するフレームを別のポートに侵入して、ループを作成する場合があります。Rbridgeが複数のVLANの任命されたフォワーダーである場合、簡単なことは、リンク上にあるポート間でこれらのVLANを分割することです。
This memo provides improved documentation of the TRILL Appointed Forwarder mechanism. It does not change the security considerations of the TRILL base protocol. See Section 6 of [RFC6325].
このメモは、Trillが任命された転送メカニズムの改善されたドキュメントを提供します。Trill Baseプロトコルのセキュリティ上の考慮事項は変更されません。[RFC6325]のセクション6を参照してください。
The authors of [RFC6325] and [RFC6327], those listed in the Acknowledgements section of [RFC6325] and [RFC6327], and Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand are hereby thanked for their contributions.
[RFC6325]および[RFC6327]の著者は、[RFC6325]および[RFC6327]の謝辞セクションにリストされている著者、およびロンボニカ、スチュワートブライアント、リンダダンバー、レスギンズバーグ、エリックノルドマーク、ダンローマスマーク、マイケシャンド彼らの貢献に感謝しました。
Normative and Informative references for this document are listed below.
このドキュメントの規範的および有益な参照を以下に示します。
[802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, May 2011.
[802.1Q] IEEE 802.1、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク」、IEEE STD 802.1Q -2011、2011年5月。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing 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., 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、「ルーティングブリッジ（Rbridges）：基本プロトコル仕様」、RFC 6325、2011年7月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (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月。
[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.、およびV. Manral、「Routing Bridges（Rbridges）：隣接」、RFC 6327、2011年7月。
[VLANMAP] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and D. Eastlake, "RBridges: Campus VLAN and Priority Regions", Work in Progress, October 2011.
[Vlanmap] Perlman、R.、Dutt、D.、Banerjee、A.、Rijhsinghani、A。、およびD. Eastlake、「Rbridges：キャンパスVLANおよび優先地域」、2011年10月の進行中。
Appendix. VLAN Inhibition Example
付録。VLAN阻害の例
The per-VLAN inhibition timers (or the equivalent) are needed to be loop safe in the case of misconfigured bridges on a link.
リンク上の誤解されたブリッジの場合、VLANごとの抑制タイマー（または同等のもの）が安全であるために必要です。
For a simple example, assume that RB1 and RB2 are the only RBridges on the link, that RB1 is higher priority to be the DRB, and that they both want VLAN 1 (the default) to be the Designated VLAN. However, there is a bridge between them configured so that RB1 can see all the frames sent by RB2 but none of the frames from RB1 can get through to RB2.
簡単な例では、RB1とRB2がリンク上の唯一のRbridgeであり、RB1がDRBであるよりも優先度が高いと仮定し、両方ともVLAN 1（デフォルト）が指定VLANであることを望んでいると仮定します。ただし、RB1がRB2から送信したすべてのフレームを確認できるように構成されたそれらの間にブリッジがありますが、RB1のフレームはRB2に到達できません。
Both will think they are the DRB. RB1 because it is higher priority even though it sees the Hellos from RB2, and RB2 because it doesn't see the Hellos from RB1 and therefore thinks it is highest priority.
どちらも彼らがDRBだと思うでしょう。RB1は、RB2のHellosとRB2がRB1のHellosを見ていないため、最優先事項であると考えているため、優先度が高いためです。
Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There is no problem with VLANs 2 and 4 but if you do not do something about it, you could have a loop involving VLAN 3. RB1 will see the Hellos RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 will be inhibited on VLAN 3. RB2 does not see the Hellos issued by RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3 native traffic.
RB1はVLANS 2および3の任命されたフォワーダーとして行動することを選択し、RB2はVLANS 3および4の任命されたフォワーダーとして行動することを選択します。VLANS2と4には問題ありませんが、それについて何かをしないと、VLAN 3を含むループ。RB1は、VLAN 3のHellos RB2の問題が任命されたフォワーダーを宣言するため、VLAN 3でRB1が阻害されるため、RB2はVLAN 3でRB1が発行したHellosを見ないため、RB2は抑制され、処理されます。VLAN 3ネイティブトラフィック。
However, this situation may change. RB2 might crash, the bridge might crash, or RB2 might be reconfigured so it no longer tried to act as Appointed Forwarder for VLAN 3, or other issues may occur. So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no Hellos from any other RBridge on the link claiming to be Appointed Forwarder for VLAN 3 in a long enough time, then RB1 becomes uninhibited for that VLAN on the port in question and can handle end station traffic in VLAN 3.
ただし、この状況は変わる可能性があります。RB2はクラッシュしたり、ブリッジがクラッシュしたり、RB2が再構成される可能性があるため、VLAN 3の任命された転送者として機能しようとしたり、他の問題が発生したりする可能性があります。したがって、RB1はVLAN 3阻害タイマーを維持する必要があり、Linkの他のRbridgeからHellosが十分に長い間VLAN 3のフォワーダーに任命されたと主張するHellosが表示されない場合、RB1はポートのそのVLANに対して抑制されずになります。質問とVLAN 3のエンドステーショントラフィックを処理できます。
Authors' Addresses
著者のアドレス
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、CA 95054 USA
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012, China
Yizhou Li Huawei Technologies 101 Software Avenue、Nanjing 210012、China
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1-408-333-7149
EMail: ayabaner@cisco.com
Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China
Fangwei Hu Zte Corporation 889 Bibo Road Shanghai 201203 China
Phone: +86-21-68896273
EMail: hu.fangwei@zte.com.cn