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
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（リンクの多くの透明な相互接続）プロトコルは、任意のトポロジーも一時的ループの期間中に安全な転送、およびユニキャストのマルチパスおよびマルチキャストトラフィックをサポートするマルチホップネットワークで構成せずに最小コストのペアワイズデータ転送を提供。 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）でネイティブトラフィックがATによって処理されることを意図して、「任命フォワーダー」と呼ばれるものをRBridgesのサブセットによって処理されます最も1つの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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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 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 TRILL（リンクの多くの透明な相互接続）プロトコル[RFC6325]の任意のトポロジであっても一時的なループの期間中に安全な転送、およびユニキャストのマルチパスをサポートするマルチホップネットワークで構成せずに最適なペアワイズデータフレーム転送を提供およびマルチキャストトラフィック。 TRILLは、IS-IS（中間システムへの中間システム）を使用することによって、これを達成する[IS-IS] [RFC1195]リンク状態ルーティングホップカウントを含むヘッダを使用してトラフィックをカプセル化します。設計では、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（ローカルエリアネットワーク）リンクをサポートしています。複数RBridgesがリンクに接続されている場合は、ネイティブのトラフィックは、そのリンクの端局から各VLANでネイティブトラフィックは、せいぜい1 RBridgeによって処理されることを意図して、「任命フォワーダー」と呼ばれるものをRBridgesのサブセットによって処理されます。 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.)
任命フォワーダ機構は、エンドステーションのサービスが提供されていない任意のリンクとは無関係です。これは、ポイント・ツー・ポイントのリンクやトランクポートとして設定されているリンク上のすべてのRBridgeポートを持つ任意のリンク-ISとして設定されたリンクを含んでいます。 （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.
任命フォワーダ機構は、リンクMTUマッチング、または擬似形成のために指定RBridge（DRB）の選挙を隣接の形成に影響を及ぼしません。これらのトピックは、[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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「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のリンク上の任命フォワーダは、リンクからネイティブフレームをingressesとVLAN-xのリンクにネイティブフレームをegresses RBridgeあります。デフォルトでは、DRB（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をネイティブフレームを着信するとegressingされているリンク上の2つの任命フォワーダがないことが重要です。これが発生した場合、それはフレームがループの一部にTRILLホップカウントによって保護されていないループを形成することができます。リンク内のポートまたはブリッジは、セクション2.4で議論するようにVLAN-xおよびVLAN-Yとの間のフレームをマッピングするように構成されている場合（このような条件であっても二つの異なるVLANの、VLAN-X及びVLAN-Y、のための2つの内装フォワーダを介して起こり得ます。 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 RBridgeリンクと完全に収容されているこれらのケースの組み合わせで同じMACアドレスを持つ複数のポートの場合のリンク上の複数のポートの場合。しかし、RBridgeはまれな疾患であることとMACアドレスを複製することが期待されているいずれかのリンク上の複数のポートは、TRILLまたはIEEE 802.1規格のいずれかによって推奨されていません。
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.
RBridgeが任命または任命フォワーダとして非任命することが可能な三つのメカニズムが存在する：DRBによるアクションの結果として、セクション2.1で議論するようDRB選挙[RFC6327]の結果として、セクション2.2で議論するように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のための任命フォワーダーとして機能することができますそれがリンク上で複数のポートを持っている場合か、そのポートの少なくとも一つ）が、これらの基準を満たしています。
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は、リンク上で複数のポートを持っているまれなコーナーケースでは、の一つは、以前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は、TRILLこんにちは、それはDRBの選挙に勝ったポートから指定VLAN上で送信して、[RFC6326]一つ以上の任命フォワーダサブのTLVを含めることによって、リンク上の他のRBridgesを任命することができます。 DRBこんにちはTRILL内の任意の予定を送信すると、そのこんにちはにそのリンクのすべての予定を送信する必要があります。含まれていない任意の先約が暗黙のうちに取り消されます。
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はDRBがリンク上で自分以外のRBridgesためのすべての予定を取り消すことを希望する場合、それは自分自身のための任命を送信することにより任命フォワーダーとして機能することを選択したためにVLANを発表する必要はありませんが、送ることをお勧めしますいくつかのVLANのために自分自身のための任命とTRILLこんにちは。
The DRB MUST NOT send any appointments on a link unless its DRB inhibition timer (see Section 3) for that link is expired.
そのリンクのためのDRB禁止タイマーが（セクション3を参照）有効期限が切れている場合を除きDRBは、リンク上の任意の予定を送ってはいけません。
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は、TRILLこんにちはそれは、[RFC6327]で与えられたのいずれかの理由で破棄されていないを受信すると、送信元MACアドレスとこんにちはにおけるポートIDおよびシステムIDをチェックしますそれが勝利DRBポートからであるかどうかを判断します。それはそのポートからではない場合、こんにちはにおけるサブTLVのフォワーダ任命いずれかが無視され、受信RBridgeの任命フォワーダの状態に変化がないされています。サブTLVのフォワーダ任命決してこんにちはTRILLに存在している場合も、受信者の任命フォワーダの状態に変化がありません。
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こんにちは受賞DRBポートからのものであり、こんにちは1つ以上のサブTLVのフォワーダ任命含まれている場合しかし、その後、受信RBridgeは、両方のHelloにそれのためにリストされ、受信ポートで有効になっているVLAN用に任命なり。 （予定はVLAN IDが$ 000または0xFFFが含まれている場合、それらは無視されますが、他のVLAN IDがまだ効果的である。）受信機は、他のVLANのフォワーダに任命された場合は、その取り消され、そのような他のVLANのステータスフォワーダ任命します。ハローにおけるこれらのサブのTLVのいずれも受信RBridgeを任命しない場合、例えば、それは、すべてのステータスフォワーダ任命、もはやハローを受信したポート上の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を任命受賞ポートからこんにちはにサブTLVのフォワーダ就任一つ以上の取り扱いがあります。サブTLVフォワーダ任命で予定が特定RBridgeとVLAN IDの連続する間隔のためのものです。しかし、上述のように、それは実際RBridgeのみRBridgeは、リンク上で持っている1つまたは複数のポート上で有効になっていること範囲のVLAN（複数可）（のためのフォワーダトランクポートとして、または点-ISのように構成された任意のポートを無視することを任命します-to-点ポート）。 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.
VLANは、メッセージを受信したポートまたはポートがトランクまたはポイントツーポイントのポートだったので、有効になっていなかったので、それが無効であったVLANのための有効な予定のメッセージを受け取ったことを覚えておくことはRBridgeのための理由はありません。これは、その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は任命したいVLANが不便に分布されるべきである、例えば、DRB RB1は全て偶数VLANのRB2フォワーダを任命し、すべての奇数VLANのRB3フォワーダを任命したいことわざ場合は、以下の方法を用いることができます。ネットワーク管理者は、通常のVLANは、RBridgeポートで有効になっているかを制御します。したがって、ネットワーク管理者は、関連するポート（またはポート）上のみのVLANを有効にした後、DRBは、すべてのVLANのための標的RBridgeフォワーダを任命するように見える予定を送信有することによって散乱VLANの任意のセットについてRBridgeフォワーダを指名することができます。しかし、適切な動作およびインターRBridgeの通信のために、リンクのために指定VLANがそのリンク上のすべてのRBridgeポートで有効にする必要があり、指定されたVLANのRBridgeフォワーダを任命することが所望されなくてもよいです。指定VLANは、VLAN 0xFFEまたはデフォルトVLAN 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であるネットワーク管理者がすべて偶数のVLANプラスVLAN 101の関連するポート上で有効にされる可能性がありますと仮定RB2、次いで、所望の効果と、それは102から4094を介して100を介して1からすべてのVLANフォワーダと任命RB2する予定を送信するDRBを引き起こします。
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のために、阻害されるRBridgesの一つ以上の原因となります。
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 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.
DRBは、それがリンクの指定VLAN上で送信するすべてのTRILLこんにちはにおけるフォワーダの予定を含めるする必要はありません。ループの安全のために、すべてのRBridge毎TRILLに示すために必要とされるハローそれは（第3の項目4を参照）、そのリンクのためのVLAN-xの内装フォワーダであるかどうか、リンクにVLAN-Xに送ります。また、DRBは、エンドステーションサービスが有効になってリンクだけでなく、指定VLAN、上で提供されるすべてのVLANを持っていることが推奨されます。このように、DRBは、一般的に、彼らはフォワーダを任命していると信じているVLANのリンク上の他のRBridgesによって通知されます。これはDRBを行いたいの予定と一致した場合、そのフォワーダの予定を再送信するために必要とされていません。しかし、堅牢性のために、特に、ブリッジLANリンクでのVLANの設定ミスなどの場合には、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ハローズの限られた長さのメカニズムはフォワーダに任命することができるリンクをRBridgesの数に制限を課します。控えめな見積もりを取得するには、せいぜい1000のバイトは、そのような予定のTRILLこんにちはで提供されていないことを前提としています。 VLANの任意の非交差セットのリンクフォワーダ上の様々なRBridgesを任命することが望まれると仮定する。上述した技術を使用してRBridge当たり2回の予定、または12のバイトを、一般的に必要とするであろう。サブTLVとTLVのオーバーヘッドのために余裕をもって、83 RBridgesのための予定が1000バイトの下に収まるでしょう。 DRBを含め、これは付属の84以上のRBridgesとのリンクを意味します。添付RBridgesの一握り以上とのリンクは稀であると予想されます。
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を無効にすると、VLAN-xはRBridgeが同じリンクに接続されたいくつかの他のポートで有効にされない限り、任意の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.
もはやにポートを引き起こすこと自体では、ない、RBridgeポートがオンになっていることをリンクの任命フォワーダになる場合がトランクまたはポイントツーポイントポートとして設定またはポート上でVLAN-Xを可能にします。しかし、そのような行為は、それがDRBであるか、予約制であれば、それはリンク上DRBでない場合、ポートのRBridgeは、選択によって任命フォワーダになることを許可することができます。
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ハローズは、彼らが送信されるVLANに設定されているフィールドを含みます。彼らは異なるVLANに到着した場合は、VLANマッピングは、リンク内で発生されます。 （RBridges間のリンク内のこのようなVLANマッピングはRBridge [VLANMAP】内部VLANマッピングと混同してはなりません）。 VLANの任命フォワーダが異なる場合VLAN-XおよびVLAN-Yとの間のVLANマッピングはループをもたらすことができます。リンク内のこのようなマッピングは、許可および例えばVLANマッピング、ブロードキャストフレームのサイクルがあったように、2つの以上のリンク上で発生した場合はループを永遠だろう。
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でハローを受信することにより、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.
- 4094の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 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.
阻害に対するネイティブトラフィックの損失は、論理的には、エンドステーションサービスは、これまでのリンクをRBridgeによって提供される各VLANごとにVLAN阻害タイマーを実装することにより、最小化されます。これは行われるべきです。 （VLAN阻害タイマーを動機例えば、付録を参照してください。）ただし、実装上の制限は、このようなタイマーのフルセットが非現実的ならば、複数のVLANのためのVLAN禁止タイマーは、注意して、1つのタイマーにマージすることができます。それは他のためのものとないために任命権者フォワーダーであれば、これは不要な無期限に延長された阻害につながる可能性として具体的には、RBridgeは、2つのVLANのために一緒にVLAN禁止タイマーをマージしてはなりません。 1をRBridgeが任命フォワーダー、他のすべてのVLANの一つであるためにVLAN用：リミットでは、唯一の2つのVLAN禁止タイマーが提供されていても、そうでない場合に必要とされるよりも多くのネイティブフレーム損失はあるものの、安全操業があるでしょう。少なくとも2つのVLAN阻害タイマーを実装する必要があります。 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.
RBridgeはまだことを学ぶ機会を持っていないので、起動や管理リセット1.は、各ポートは、二つ以上のそのようなポートが同じリンク上にある場合でも、タイマーの独自のセットを持っています。すべての阻害タイマーは、以下の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.
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.
RBridge RB1は、送信者がいずれかのハロー内部に示されているように（1）VLAN-xまたは（2）に到着がVLAN-X上で送信された後、RB1が、VLANを設定し、そのフォワーダ任命されていることをアサートTRILLハローを受信4.そのタイマーの既存の値と受信こんにちはにおける保持時間の最大値へのリンク用のx阻害タイマー。 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.
RBridge RB1は、リンクに接続しているポート上のVLAN-Xを可能にし、VLAN-Xが以前にそのリンク上RB1のポートのいずれかで有効になっていなかった、それはそのホールディングにそのリンク用VLAN-xのそのVLAN阻害タイマーをセットする5.そのポートのための時間。これは、ポートがあれば、後でトランクまたはポイントツーポイントのポートではないと設定されている場合があり、いくつかの可能性があるとして、トランクまたはポイントツーポイントポートとして設定されている場合でも行われます。
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秒にそのデフォルトの時間へのリンク用のルート変更禁止タイマーを設定し、ゼロまでの30から任意の値に設定可能です秒。 RBridgeが結合ブリッジLANのポート上でブリッジPDU（BPDUの）受信されていない限り、この状態は発生しません。添付のブリッジLANのセトリング時間に、この禁止時間を設定しても安全です。それすることが知られている場合、例えば、ラピッドスパニングツリープロトコル（RSTP [802.1Q]）取り付けブリッジLANを通じて実行され、7秒に、この禁止時間を設定することが安全でなければならない、または、取り付けられたブリッジを有するように構成されている場合最小橋こんにちはタイマー、4秒にそれを設定しても安全。 RBridgeが受信したBPDUの検査によってそれと任意の直接接続されたブリッジ間の物理リンク上で実行されているものを直接接続するブリッジを越えてブリッジ間のリンクが実行していたならば、それは言うことができなかったスパニングツリーのバージョンを決定することができる一方で、なおルート変更禁止タイマーを必要とするかもしれない古典的なスパニングツリープロトコル（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は、そのポートのいずれか（またはそのポートのセット）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.
RBridgeは、同じリンク上にあるものとして処理されていたそのポートのセットが同じリンク上でもはや、これらのポートは、必ずしも（限界にポートごとに一つのリンク）は、2つの以上のリンク上にないことを決定する8 。これは、これらのポートが接続RBridgeが決定した2つの以上のリンクの各々についてタイマーのコピーをクローニングすることによって処理されます。
An Appointed Forwarder for a link is inhibited for VLAN-x if:
リンクの任命フォワーダは、VLAN-xの場合のために禁止されます。
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 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.
リンクのためのVLAN-X任命フォワーダが阻害され、そのカプセル化されたフレームVLAN-Xであり、通常は、そのリンクにegressedされるTRILLデータフレームを受信した場合、それはいつものようにネイティブフレームをデカプセル化します。しかし、それは、それまで出力しないか、そのリンクのためにそれをキューものの適切な（例えば、フレームは、マルチデスティネーションである）、それは出力これにまたは他のリンクのためにそれをキューことがあります。
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の任命フォワーダが抑制され、通常はそのリンクからingressedられる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のそれが任命されているかどうかをVLAN-Xフォワーダに送信しTRILLハローズに示すために必要とされますそれはこんにちはを送信します。
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ネイティブフレームが着信するとegressingのタスクを共有してロードすることができますそれは一方のポートからのリンクにegressesフレームがループを作成、そのポートの他にingressed可能なことがありません。 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ベースのプロトコルのセキュリティの考慮事項を変更しません。 [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]、およびロンBonica、スチュワートブライアント、リンダダンバー、レスギンズバーグ、エリックNordmarkと、ダンRomascanu、およびマイクシャンドはここあるの謝辞セクションに記載されたものの作者彼らの貢献のために感謝しました。
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.
"ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格 - 仮想ブリッジローカルエリアネットワーク" [802.1Q] IEEE 802.1、IEEE 802.1Q STD-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「コネクションレスモードネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムのドメイン内のRouteing交換プロトコルへの中間システム」2002年、第2版、。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]パールマン、R.、イーストレーク3、D.、ダット、D.、ガイ、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]イーストレイク、D.、バネルジー、A.、ダット、D.、パールマン、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]イーストレーク3、D.、パールマン、R.、Ghanwani、A.、ダット、D.、およびV. Manral、 "ルーティングブリッジ（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]パールマン、R.、ダット、D.、バネルジー、A.、Rijhsinghani、A.、およびD.イーストレイク、 "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がリンク上の唯一のRBridgesあり、そのRB1はDRBすべき優先順位が高い、そして彼らの両方がVLAN 1（デフォルト）指定VLANにしたいと仮定します。しかし、そのRB1は、RB1からRB2が、フレームのどれによって送信されたすべてのフレームは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それはRB1からハローズを参照してくださいので、それが最優先であると考えていないので、それはRB2、およびRB2からhelloを見ているにもかかわらず、高い優先度であるため。
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は、RB2はVLANの3と4の任命フォワーダーとして機能することを選択した全く問題はVLANの2と4ではありませんが、あなたはそれについて何かをしない場合は、あなたが持っている可能性がありながら、VLANの2と3のための任命フォワーダーとして機能することを選択したと言いますVLAN 3. RB1を含むループは、それ自体がフォワーダを任命宣言VLAN 3にハローズのRB2の問題が表示されますので、RB1は、VLAN上で阻害されるVLAN 3にRB1によって発行されたhelloを見ていないので、RB2が奔放になり、処理されます。3. 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は、ブリッジがクラッシュする可能性があります、またはそれはもはや発生する可能性がVLAN 3、またはその他の問題のために任命フォワーダーとして機能しようとしたので、RB2を再構成していない可能性があります。だから、RB1は、VLAN 3阻害タイマーを維持しなければならない、そしてそれは十分に長い時間でVLAN 3のためのフォワーダを任命すると主張し、リンク上の他のRBridgeから何のhelloを見ない場合、RB1は、ポート上のVLANのための奔放になり質問とVLAN 3にエンドステーションのトラフィックを処理することができます。
Authors' Addresses
著者のアドレス
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
ラディア・パールマンインテル・ラボ2200ミッション・カレッジブルバードサンタクララ、CA 95054 USA
Phone: +1-408-765-8080 EMail: Radia@alum.mit.edu
電話：+ 1-408-765-8080 Eメール：Radia@alum.mit.edu
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク第三華為技術155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
電話：+ 1-508-333-2270 Eメール：d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012, China
技術のY IリットルIH UA周辺101ソフトウェア大通り、南京210012、中国
Phone: +86-25-56622310 EMail: liyizhou@huawei.com
電話：+ 86-25-56622310 Eメール：liyizhou@huawei.com
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
アヤンバネルジーシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1-408-333-7149 EMail: ayabaner@cisco.com
電話：+ 1-408-333-7149 Eメール：ayabaner@cisco.com
Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China
ファンGはHU ZT E社889 BIボー道路上海201203中国です
Phone: +86-21-68896273 EMail: hu.fangwei@zte.com.cn
電話：+ 86-21-68896273 Eメール：hu.fangwei@zte.com.cn