[要約] RFC 8139は、TRILL（Transparent Interconnection of Lots of Links）プロトコルのAppointed Forwardersに関するものであり、ネットワーク内の特定のリンクにトラフィックを転送するためのメカニズムを提供します。目的は、ネットワークの効率性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8139 Y. Li
Obsoletes: 6439 Huawei
Updates: 6325, 7177 M. Umair
Category: Standards Track IP Infusion
ISSN: 2070-1721 A. Banerjee
Cisco
F. Hu
ZTE
June 2017
Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders
多数のリンクの透過的な相互接続（TRILL）：指定されたフォワーダー
Abstract
概要
TRILL (Transparent Interconnection of Lots of Links) supports multi-access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates the Appointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439.
TRILL（多数のリンクの透過的相互接続）は、マルチアクセスLAN（ローカルエリアネットワーク）リンクをサポートしており、単一のリンクで複数のエンドステーションとTRILLスイッチを接続できます。複数のTRILLスイッチがリンクに接続されている場合、そのリンクのエンドステーションとの間のネイティブトラフィックは、RFC 6325で最初に指定された「Appointed Forwarders」と呼ばれるTRILLスイッチのサブセットによって処理され、各VLANのネイティブトラフィックを意図しています。最大1つのTRILLスイッチで処理されます。このドキュメントでは、Appointed Forwarderメカニズムを明確にし、更新します。 RFC 6325および7177を更新し、RFC 6439を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8139.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8139で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Appointed Forwarders and Active-Active .....................5
1.2. Terminology and Abbreviations ..............................6
2. Appointed Forwarders and Their Appointment ......................7
2.1. The Appointment Databases and DRB Actions ..................8
2.2. Appointment Effects of DRB Elections ......................10
2.2.1. Processing Forwarder Appointments in Hellos ........11
2.2.2. Frequency of Hello Appointments ....................13
2.2.3. Appointed Forwarders Hello Limit ...................13
2.3. Effects of Local Configuration Actions on Appointments ....14
2.4. Overload and Appointed Forwarders .........................14
2.5. VLAN Mapping within a Link ................................15
3. The Inhibition Mechanism .......................................15
3.1. Inhibited Appointed Forwarder Behavior ....................18
3.2. Root Bridge Change Inhibition Optimizations ...............18
3.2.1. Optimization for Change to Lower Priority ..........19
3.2.2. Optimization for Change to Priority Only ...........19
3.2.3. Optimizing the Detection of Completed Settling .....19
4. Optional TRILL Hello Reduction .................................20
5. Multiple Ports on the Same Link ................................22
6. Port-Shutdown Messages .........................................23
6.1. Planned Shutdown and Hellos ...............................23
6.2. Port-Shutdown Message Structure ...........................23
6.3. Port-Shutdown Message Transmission ........................24
6.4. Port-Shutdown Message Reception ...........................25
6.5. Port-Shutdown Message Security ............................25
6.6. Port-Shutdown Configuration ...............................26
7. FGL-VLAN Mapping Consistency Checking ..........................26
8. Support of E-L1CS ..............................................27
8.1. Backward Compatibility ....................................27
9. Security Considerations ........................................28
10. Code Points and Data Structures ...............................28
10.1. IANA Considerations ......................................28
10.2. AppointmentBitmap APPsub-TLV .............................29
10.3. AppointmentList APPsub-TLV ...............................30
10.4. FGL-VLAN-Bitmap APPsub-TLV ...............................31
10.5. FGL-VLAN-Pairs APPsub-TLV ................................32
11. Management Considerations .....................................33
12. References ....................................................34
12.1. Normative References .....................................34
12.2. Informative References ...................................36
Appendix A. VLAN Inhibition Example ...............................37
Appendix B. Multi-Link VLAN Mapping Loop Example ..................38
Appendix C. Changes to RFCs 6325, 6439, and 7177 ..................39
Acknowledgments ...................................................40
Authors' Addresses ................................................41
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides optimal pairwise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes these by using IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC7176] link-state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs, FGLs (Fine-Grained Labels) [RFC7172], and optimization of the distribution of multi-destination frames based on VLANs and multicast groups. Devices that implement TRILL are called TRILL switches or "RBridges" (Routing Bridges).
IETF TRILL（多数のリンクの透過的相互接続）プロトコル[RFC6325] [RFC7780]は、任意のトポロジーとリンクテクノロジー、一時ループの期間でも安全な転送、およびユニキャストとマルチキャストの両方のトラフィックのマルチパス。 TRILLは、IS-IS（中間システムから中間システム）[IS-IS] [RFC7176]リンクステートルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することで、これらを実現します。この設計は、VLAN、FGL（Fine-Grained Labels）[RFC7172]、およびVLANとマルチキャストグループに基づく複数宛先フレームの配布の最適化をサポートしています。 TRILLを実装するデバイスは、TRILLスイッチまたは「RBridges」（ルーティングブリッジ）と呼ばれます。
Section 2 of [RFC7177] discusses the environment for which the TRILL protocol is designed and the differences between that environment and the typical Layer 3 routing environment.
[RFC7177]のセクション2では、TRILLプロトコルが設計されている環境と、その環境と一般的なレイヤー3ルーティング環境の違いについて説明します。
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and TRILL switches attached. Where multiple TRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those switches called "Appointed Forwarders" as originally specified in [RFC6325], with the intent that native traffic in each VLAN be handled by at most one switch. A TRILL switch can be Appointed Forwarder for many VLANs.
TRILLは、複数のエンドステーションとTRILLスイッチを接続できるマルチアクセスLAN（ローカルエリアネットワーク）リンクをサポートしています。複数のTRILLスイッチがリンクに接続されている場合、そのリンクのエンドステーションとの間のネイティブトラフィックは、[RFC6325]で最初に指定された「Appointed Forwarders」と呼ばれるスイッチのサブセットによって処理され、各VLANのネイティブトラフィックを意図しています。最大1つのスイッチで処理されます。 TRILLスイッチは、多くのVLANのAppointed Forwarderにすることができます。
The purpose of this document is to update and improve the Appointed Forwarder mechanism and free it from the limitations imposed by the requirement in its initial design that all appointments fit within a TRILL Hello Protocol Data Unit (PDU). This is accomplished by requiring support of link-scoped FS-LSPs (Flooding Scope Link State PDUs) (Section 8) and providing the option to send appointment information in those LSPs. In addition, this document provides a number of other optional features to
このドキュメントの目的は、Appointed Forwarderメカニズムを更新および改善し、すべての予定がTRILL Hello Protocol Data Unit（PDU）内に収まるという初期設計の要件によって課せられる制限から解放することです。これは、リンクスコープのFS-LSP（フラッディングスコープリンクステートPDU）のサポートを要求し（セクション8）、それらのLSPで予定情報を送信するオプションを提供することで実現されます。さらに、このドキュメントは、他の多くのオプション機能を提供します
1. detect inconsistent VLAN-ID-to-FGL [RFC7172] mappings among the TRILL switch ports on a link, as discussed in Section 7,
1. セクション7で説明されているように、リンク上のTRILLスイッチポート間で矛盾するVLAN-IDからFGL [RFC7172]へのマッピングを検出する
2. expedite notification of ports going down so that Appointed Forwarders can be adjusted, as discussed in Section 6, and
2. セクション6で説明されているように、ポートがダウンしたことを通知して、Appointed Forwardersを調整できるようにします。
3. reduce or eliminate the need for "inhibition" of ports for loop safety, as discussed in Section 3.2.
3. セクション3.2で説明されているように、ループの安全性のためにポートを「禁止」する必要性を減らすか排除します。
This document replaces and obsoletes [RFC6439], incorporating the former material in [RFC6439] with these additions. The various optimizations are orthogonal and optional. Implementers can choose to provide all, some, or none of them, and TRILL switches will still be interoperable. In accordance with the TRILL design philosophy, these optimizations require zero or minimal configuration, but there are a couple of configurable parameters, as summarized in Section 11.
この文書は[RFC6439]を置き換え、廃止し、[RFC6439]の以前の資料にこれらの追加を組み込んだものです。さまざまな最適化は直交しており、オプションです。実装者はそれらすべてを提供するか、一部を提供するか、まったく提供しないかを選択でき、TRILLスイッチは引き続き相互運用可能です。 TRILLの設計哲学に従って、これらの最適化にはゼロまたは最小限の構成が必要ですが、セクション11に要約されているように、構成可能なパラメーターがいくつかあります。
As described in Appendix C, this document updates [RFC6325] by mandating support of E-L1CS FS-LSPs and provides backward compatibility in the presence of legacy TRILL switches that do not provide this support. It also updates [RFC7177] by providing, as an optional optimization, that receipt of the Port-Shutdown message specified herein be treated as an event in the state machine specified in [RFC7177].
付録Cで説明されているように、このドキュメントはE-L1CS FS-LSPのサポートを義務付けることによって[RFC6325]を更新し、このサポートを提供しないレガシーTRILLスイッチが存在する場合の下位互換性を提供します。また、[RFC7177]で指定された状態マシンで、ここで指定されたPort-Shutdownメッセージの受信がイベントとして扱われるように、オプションの最適化として[RFC7177]を更新します。
This document includes reference implementation details. Alternative implementations that interoperate on the wire are permitted.
このドキュメントには、リファレンス実装の詳細が含まれています。ネットワーク上で相互運用する代替実装が許可されています。
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 TRILL switch 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.)
Appointed Forwarderメカニズムは、エンドステーションサービスが提供されていないリンクとは無関係です。これには、ポイントツーポイントIS-ISリンクとして構成されたリンクと、そのリンク上のすべてのTRILLスイッチポートがトランクポートとして構成されたリンクが含まれます。 （TRILLでは、「トランクポート」としてのポートの構成は、エンドステーションサービスが提供されないことを意味します。すべてのVLANがそのポートで有効になっていることを意味するわけではありません。）
The Appointed Forwarder mechanism has no effect on the formation of adjacencies, the election of the Designated RBridge (DRB) [RFC7177] for a link, MTU matching, or pseudonode formation. Those topics are covered in [RFC7177]. Furthermore, Appointed Forwarder status has no effect on the forwarding of TRILL Data frames; it only affects the handling of native frames to and from end stations.
Appointed Forwarderメカニズムは、隣接の形成、リンクの指定RBridge（DRB）[RFC7177]の選択、MTUマッチング、または疑似ノードの形成には影響を与えません。これらのトピックは[RFC7177]でカバーされています。さらに、Appointed ForwarderステータスはTRILLデータフレームの転送に影響を与えません。エンドステーションとの間のネイティブフレームの処理にのみ影響します。
For other aspects of the TRILL base protocol, see [RFC6325], [RFC7177], and [RFC7780]. In cases of conflict between this document and [RFC6325] or [RFC7177], this document prevails.
TRILLベースプロトコルの他の側面については、[RFC6325]、[RFC7177]、および[RFC7780]を参照してください。このドキュメントと[RFC6325]または[RFC7177]との間に矛盾がある場合、このドキュメントが優先されます。
As discussed in [RFC7379], TRILL active-active provides support for end stations connected to multiple edge TRILL switches where these connections are separate links. Since TRILL Hellos are not forwarded between these links, the Appointed Forwarder mechanism as described herein operates separately on each such link.
[RFC7379]で説明されているように、TRILL active-activeは、これらの接続が個別のリンクである複数のエッジTRILLスイッチに接続された端末をサポートします。 TRILL Helloはこれらのリンク間で転送されないため、ここで説明するAppointed Forwarderメカニズムは、このようなリンクごとに個別に動作します。
This document uses the abbreviations and terms defined in [RFC6325], some of which are repeated below for convenience, and additional abbreviations and terms listed below.
このドキュメントでは、[RFC6325]で定義されている略語と用語を使用しています。その一部は便宜上以下で繰り返されています。また、以下にリストされている追加の略語と用語も使用されています。
Data Label mapping: The mapping from VLAN ID to FGL and from FGL to VLAN ID.
データラベルマッピング：VLAN IDからFGLおよびFGLからVLAN IDへのマッピング。
DRB: Designated RBridge. The RBridge on a link elected as specified in [RFC7177] to handle certain decisions and tasks for that link, including forwarder appointment as specified herein.
DRB：指定されたRBridge。 [RFC7177]で指定されているように選択されたリンクのRBridgeは、そのリンクの特定の決定とタスクを処理します。
E-L1CS: Extended Level 1 Circuit Scope (Section 8).
E-L1CS：拡張レベル1サーキットスコープ（セクション8）。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
FS-LSP: Flooding Scope Link State PDU (Section 8).
FS-LSP：フラッディングスコープのリンク状態PDU（セクション8）。
Link: The means by which adjacent TRILL switches are connected. A TRILL link may be various technologies and, in the common case of Ethernet, can be a "bridged LAN" -- that is to say, some combination of Ethernet links with zero or more bridges, hubs, repeaters, or the like.
リンク：隣接するTRILLスイッチを接続する手段。 TRILLリンクはさまざまなテクノロジーであり、イーサネットの一般的なケースでは、「ブリッジLAN」、つまりイーサネットリンクと0個以上のブリッジ、ハブ、リピーターなどの組み合わせが考えられます。
LSDB: Link State Database.
LSDB：リンク状態データベース。
PDU: Protocol Data Unit.
PDU：プロトコルデータユニット。
RBridge: An alternative name for a TRILL switch.
RBridge：TRILLスイッチの別名。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL：多くのリンクの透過的な相互接続またはリンク層のトンネルルーティング。
TRILL switch: A device implementing the TRILL protocol. An alternative name for an RBridge.
TRILLスイッチ：TRILLプロトコルを実装するデバイス。 RBridgeの別名。
Trunk port: A TRILL switch port configured with the "end-station service disable" bit on, as described in Section 4.9.1 of [RFC6325].
トランクポート：[RFC6325]のセクション4.9.1で説明されているように、「端末サービス無効化」ビットがオンに設定されたTRILLスイッチポート。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The Appointed Forwarder on a link for VLAN-x is the TRILL switch (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 TRILL switches that have ports on the link as Appointed Forwarder for one or more VLANs.
VLAN-xのリンク上のAppointed Forwarderは、リンクからネイティブフレームに入り、VLAN-xのリンクにネイティブフレームを出力するTRILLスイッチ（RBridge）です。デフォルトでは、リンク上のDRB（指定RBridge）は、リンク上のすべてのVLANのネイティブトラフィックを担当します。 DRBは、必要に応じて、任意のVLANの指定フォワーダーとして機能し、リンク上のポートを持つ他のTRILLスイッチを1つ以上のVLANの指定フォワーダーとして指定できます。
By definition, the DRB considers the other ports on the link to be the ports with which a DRB port has adjacency on that link [RFC7177]. If the DRB loses adjacency to a TRILL switch that it has appointed as forwarder and the native traffic that was being handled by that Appointed Forwarder is still to be ingressed and egressed, it SHOULD immediately appoint another forwarder or itself become the forwarder for that traffic.
定義上、DRBはリンク上の他のポートを、DRBポートがそのリンク上で隣接しているポートであると見なします[RFC7177]。 DRBがフォワーダーとして指定したTRILLスイッチへの隣接性を失い、そのAppointed Forwarderによって処理されていたネイティブトラフィックが引き続き入力および出力される場合は、すぐに別のフォワーダーを指定するか、それ自体がそのトラフィックのフォワーダーになる必要があります。
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.5.) While TRILL tries to avoid such situations, for loop safety there is also an "inhibition" mechanism (see Section 3) that can cause a TRILL switch that is an Appointed Forwarder not to ingress or egress native frames. Appointed Forwarder status and port "inhibition" have no effect on the reception, transmission, or forwarding of TRILL Data or TRILL IS-IS frames. Appointed Forwarder status and inhibition only affect the handling of native frames.
同じVLANに対して同時にネイティブフレームの入力と出力を行う2つのAppointed Forwarderがリンク上にないことが重要です。これが発生した場合、ループの一部のフレームがTRILLホップカウントによって保護されないループを形成する可能性があります。 （セクション2.5で説明したように、リンク内のポートまたはブリッジがVLAN-xとVLAN-yの間でフレームをマップするように構成されている場合、このような状態は、2つの異なるVLAN、VLAN-xとVLAN-yの2つのAppointed Forwarderによっても発生する可能性があります。 ）TRILLはそのような状況を回避しようとしますが、ループの安全性のために、指定されたフォワーダーであるTRILLスイッチがネイティブフレームに出入りしないようにする「抑制」メカニズム（セクション3を参照）もあります。 Appointed Forwarderのステータスとポートの「抑制」は、TRILLデータまたはTRILL IS-ISフレームの受信、送信、または転送には影響しません。 Appointed Forwarderのステータスと抑制は、ネイティブフレームの処理にのみ影響します。
As discussed in Section 5, an RBridge may have multiple ports on a link. As discussed in [RFC7177], if there are multiple ports with the same Media Access Control (MAC) address on the same link, all but one will be suspended. The case of multiple ports on a link for the same TRILL switch and the case of multiple ports with the same MAC address on a link, as well as combinations of these cases, are fully accommodated; however, the case of multiple ports on a link for the same TRILL switch is expected to be a rare condition, and the case of duplicate MAC addresses is not recommended by either TRILL or IEEE 802.1 standards.
セクション5で説明したように、RBridgeはリンク上に複数のポートを持つ場合があります。 [RFC7177]で説明されているように、同じリンク上に同じメディアアクセスコントロール（MAC）アドレスを持つ複数のポートがある場合、1つを除くすべてが一時停止されます。同じTRILLスイッチのリンク上の複数のポートの場合、およびリンク上の同じMACアドレスを持つ複数のポートの場合、およびこれらのケースの組み合わせは、完全に対応されています。ただし、同じTRILLスイッチのリンクに複数のポートがある場合はまれな状態であると予想され、重複するMACアドレスの場合はTRILLまたはIEEE 802.1標準のいずれでも推奨されていません。
There are six mechanisms by which an RBridge can be appointed or unappointed as Appointed Forwarder:
RBridgeをAppointed Forwarderとして任命または任命解除できるメカニズムは6つあります。
1. assumption of appointment, when the DRB decides to act as Appointed Forwarder for a VLAN,
1. 予約の想定。DRBがVLANの指定フォワーダーとして機能することを決定した場合、
2. E-L1CS appointment, as a result of appointments sent by the DRB in E-L1CS FS-LSPs,
2. E-L1CS FS-LSPのDRBによって送信されたアポイントメントの結果としてのE-L1CSアポイントメント、
3. Hello appointment, as a result of appointments sent by the DRB in TRILL Hellos,
3. こんにちは予定、DRBによってTRILL Hellosで送信された予定の結果、
4. as a result of the DRB elections [RFC7177] as discussed in Section 2.2,
4. セクション2.2で説明したDRB選挙[RFC7177]の結果として、
5. as a result of a Port-Shutdown message as discussed in Section 6, and
5. セクション6で説明したポートシャットダウンメッセージの結果として、および
6. as a result of a local configuration action as discussed in Section 2.3.
6. セクション2.3で説明したローカル構成アクションの結果として。
Mechanisms 2 and 3 are covered in Section 2.1.
メカニズム2と3については、セクション2.1で説明します。
The DRB MAY appoint other RBridges on the link as Appointed Forwarders through two mechanisms, "A" and "B", as described below.
DRBは、以下で説明するように、「A」と「B」の2つのメカニズムを通じて、リンク上の他のRBridgeをAppointed Forwarderとして指定する場合があります。
Each RBridge maintains two databases of appointment information: (1) its E-L1CS LSDB, which shows appointments that each RBridge on the link would make using mechanism A if that RBridge were the DRB, and (2) its Hello appointment database, which shows the appointments most recently sent by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment database is more transient and is completely reset by each Hello received from the DRB that contains any appointments; this database is also cleared under other circumstances, as described below. An RBridge considers itself to be the Appointed Forwarder for VLAN-x if this is indicated by either its Hello appointment database or its E-L1CS LSDB entries from the DRB.
各RBridgeは、アポイントメント情報の2つのデータベースを維持します。（1）リンク上の各RBridgeがメカニズムAを使用して作成するアポイントメントを示すE-L1CS LSDB（そのRBridgeがDRBである場合）、および（2）表示するHelloアポイントメントデータベースDRBがTRILL Helloで最近送信した予定。 E-L1CS LSDBは半永久的で、E-L1CS FS-LSPまたはIS-ISパージによってのみ変更されます。 Hello予定データベースはより一時的であり、予定を含むDRBから受信した各Helloによって完全にリセットされます。このデータベースは、以下で説明するように、他の状況でもクリアされます。 RBridgeは、HelloアポイントメントデータベースまたはDRBからのE-L1CS LSDBエントリのいずれかによって示されている場合、それ自体をVLAN-xのAppointed Forwarderと見なします。
The two mechanisms by which the DRB can appoint other RBridges on a link as Appointed Forwarders are as follows:
DRBがリンク上の他のRBridgeをAppointed Forwarderとして指定できる2つのメカニズムは次のとおりです。
(A) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176], AppointmentBitmap APPsub-TLVs (Section 10.2), or AppointmentList APPsub-TLVs (Section 10.3) in E-L1CS LSPs it sends on a link. Appointments sent using this method will not be seen by legacy RBridges that do not support E-L1CS (Section 8).
（A）1つ以上のAppointed ForwardersサブTLV [RFC7176]、AppointmentBitmap APPsub-TLV（セクション10.2）、またはAppointmentList APPsub-TLV（セクション10.3）を、リンクで送信するE-L1CS LSPに含める。この方法を使用して送信された予定は、E-L1CSをサポートしないレガシーRBridgeでは表示されません（セクション8）。
(B) The inclusion of one or more Appointed Forwarders sub-TLVs [RFC7176] in a TRILL Hello it sends on the Designated VLAN out of the port that won the DRB election. When the DRB sends any appointments in a TRILL Hello, it must send all appointments it is sending in Hellos for that link in that Hello. Any previous appointment it has sent in a Hello that is not included is implicitly revoked.
（B）1つ以上のAppointed ForwardersサブTLV [RFC7176]をTRILL Helloに含めると、DRB選出に勝ったポートから指定VLANに送信されます。 DRBがTRILL Helloで予定を送信する場合、DRBは、Helloで送信しているすべての予定を、そのHelloのそのリンクに対して送信する必要があります。 Helloで送信された、含まれていない以前の予定は、暗黙的に取り消されます。
To avoid the size limitations of the Hello PDU, it is RECOMMENDED that the E-L1CS FS-LSP method be used to distribute forwarder appointments and that all RBridges on a link use this method to advertise the appointments they would make if they were the DRB. However, if some RBridges on a link do not support E-L1CS FS-LSPs, then Hello appointments must be used for the DRB to appoint such legacy RBridges as Appointed Forwarders.
Hello PDUのサイズ制限を回避するには、E-L1CS FS-LSPメソッドを使用してフォワーダーのアポイントメントを配布し、リンク上のすべてのRBridgeがこのメソッドを使用して、DRBである場合に行うアポイントメントをアドバタイズすることをお勧めします。 。ただし、リンク上の一部のRBridgeがE-L1CS FS-LSPをサポートしない場合、DRBがHelloの予定を使用して、指定されたフォワーダーなどのレガシーRBridgeを指定する必要があります。
Although the DRB does not need to announce the VLANs for which it has chosen to act as Appointed Forwarder by sending appointments for itself, if the DRB wishes to revoke all appointments made in Hellos for RBridges other than itself on the link, it can do so by sending a TRILL Hello with just an appointment for itself for some VLAN.
DRBは、アポイントドフォワーダーとして機能することを選択したVLANを、それ自体のアポイントメントを送信することによりアナウンスする必要はありませんが、DRBがリンク上の自分以外のRBridgeのHellosで行われたすべてのアポイントメントを取り消す場合は、そのようにすることができます。いくつかのVLANについて、自分自身の予定のみを指定してTRILL Helloを送信します。
How the DRB decides what other RBridges on the link, if any, to appoint as forwarder for some VLAN or VLANs is beyond the scope of this document.
リンク上の他のどのRBridgeがある場合、DRBがどのVLANのフォワーダーとして指定するかを決定する方法は、このドキュメントの範囲外です。
Unnecessary changes in Appointed Forwarders SHOULD NOT be made, as they may result in transient lack of end-station service.
Appointed Forwardersでの不要な変更は行わないでください。エンドステーションサービスが一時的に不足する可能性があります。
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, the scenario described in item 4 in Section 3 will cause one or more of the RBridges to be inhibited for that VLAN, thus avoiding persistent loops.
ネットワーク管理者が有効なVLANとAppointed Forwarderを誤って構成し、2つのRBridgeが同じVLANのAppointed Forwarderであると信じ込んだ場合、セクション3の項目4で説明されているシナリオにより、そのVLANで1つ以上のRBridgeが禁止されます。 、したがって、永続的なループを回避します。
When forwarder appointments are being encoded for transmission, different patterns of VLANs are most efficiently encoded in different ways. The following table gives advice regarding the most efficient encoding for a given pattern:
フォワーダーの予定が送信用にエンコードされている場合、VLANのさまざまなパターンがさまざまな方法で最も効率的にエンコードされます。次の表は、特定のパターンの最も効率的なエンコーディングに関するアドバイスを示しています。
sub-TLV and Reference
Pattern of VLAN IDs |enclosing TLV(s) and Reference
------------------- ------------------------------------
Blocks of consecutive VLANs
Appointed Forwarders sub-TLV [RFC7176]
|Router CAPABILITY TLV [RFC7981]
|or MT-Capability TLV [RFC6329]
Scattered VLANs within a small range AppointmentBitmap APPsub-TLV (Section 10.2) |TRILL GENINFO TLV [RFC7357]
狭い範囲内に散在するVLAN AppointmentBitmap APPsub-TLV（セクション10.2）| TRILL GENINFO TLV [RFC7357]
Scattered VLANs over a large range AppointmentList APPsub-TLV (Section 10.3) |TRILL GENINFO TLV [RFC7357]
広範囲にわたる分散VLAN AppointmentList APPsub-TLV（セクション10.3）| TRILL GENINFO TLV [RFC7357]
When a TRILL switch port on a link wins the DRB election, there are four possible cases:
リンク上のTRILLスイッチポートがDRB選出に勝った場合、次の4つのケースが考えられます。
1. A TRILL switch believes that it was the DRB and remains the DRB: there is no change in Appointed Forwarder status. This also applies in the corner case where a TRILL switch 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 TRILL switch on the same link (possibly due to management configuration of port priorities). In this case, there also is no change in which TRILL switch is the DRB.
1. TRILLスイッチは、それがDRBであると見なし、DRBのままです。AppointedForwarderステータスに変更はありません。これは、TRILLスイッチにリンク上に複数のポートがあり、そのうちの1つは以前はDRB選出の勝者であったが、同じリンク上の同じTRILLスイッチの別のポートへのDRB選出を失ったというコーナーの場合にも適用されます（おそらくポートの優先順位の管理構成が原因です）。この場合、TRILLスイッチがDRBであるという変更もありません。
2. A TRILL switch believes that it was not the DRB but has now won the DRB election and 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). It ignores any previous forwarder appointment information it received from other TRILL switches on the link.
2. TRILLスイッチは、それがDRBではなかったと信じていますが、DRB選出に勝利し、リンク上のDRBになっています。デフォルトでは、ポートが次のとおりである限り、選択したそのリンク上のVLANのAppointed Forwarderとして機能できます。トランクポートとして構成されておらず、そのVLANが有効になっている（または、リンク上に複数のポートがある場合は、そのポートの少なくとも1つがこれらの基準を満たしている）。リンク上の他のTRILLスイッチから受信した以前のフォワーダー予定情報はすべて無視されます。
3. A TRILL switch was not the DRB and does not become the DRB, but it observes that the port winning the DRB election has changed: the TRILL switch loses all Hello appointments. In addition, there are two subcases:
3. TRILLスイッチはDRBではなかったため、DRBにはなりませんが、DRB選出を勝ち取ったポートが変更されたことがわかります。TRILLスイッチはすべてのHelloアポイントメントを失います。さらに、2つのサブケースがあります。
a. The new winning port and the old winner are ports of different TRILL switches on the link. In this case, it switches to using the E-L1CS FS-LSP appointments for the winning TRILL switch.
a. 新しい勝者ポートと古い勝者は、リンク上の異なるTRILLスイッチのポートです。この場合、勝利したTRILLスイッチにE-L1CS FS-LSPアポイントメントを使用するように切り替わります。
b. The new winning port and the old winner are ports of the same TRILL switch, which has two (or more) ports on the link: although the Hello appointments are still discarded, since the same TRILL switch is the DRB, the E-L1CS FS-LSP appointments are unchanged.
b. 新しい勝者ポートと古い勝者は、同じTRILLスイッチのポートであり、リンクに2つ（またはそれ以上）のポートがあります。同じTRILLスイッチがDRB、E-L1CS FSであるため、Hello予定はまだ破棄されます。 -LSPの予定は変更されていません。
4. The winning port is unchanged: as in case 1, there is no change in Appointed Forwarder status.
4. 優勝したポートは変更されていません。ケース1と同様に、Appointed Forwarderのステータスに変化はありません。
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 [RFC7177], 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 forwarder appointment sub-TLVs in the Hello are ignored, and there is no change in the receiving RBridge's Appointed Forwarder status due to that Hello. Also, if no forwarder appointment sub-TLVs are present in the TRILL Hello, there is no change in the receiver's Appointed Forwarder status due to that Hello.
リンクで端末サービスを提供できる非DRB RBridgeが、[RFC7177]で指定された理由の1つのために破棄されないTRILL Helloを受信すると、送信元MACアドレスとポートIDおよびシステムIDをチェックします。こんにちは、勝ったDRBポートからのものかどうかを判断します。そのポートからのものではない場合、Hello内のフォワーダー予約サブTLVは無視され、そのHelloによる受信RBridgeのAppointed Forwarderステータスに変化はありません。また、TRILL Helloにフォワーダー予約サブTLVが存在しない場合、そのHelloによって受信者のAppointed Forwarderステータスに変化はありません。
However, if the TRILL Hello is from the winning DRB port and the Hello includes one or more forwarder appointment sub-TLVs, then the receiving RBridge sets its Hello appointment database to be the set of VLANs that have both of the following characteristics:
ただし、TRILL Helloが勝者のDRBポートからのものであり、Helloに1つ以上のフォワーダー予約サブTLVが含まれている場合、受信RBridgeは、Hello予約データベースを次の両方の特性を持つVLANのセットに設定します。
o The VLAN is listed as an appointment for the receiving RBridge in the Hello, and
o VLANは、Helloの受信RBridgeの予定としてリストされています。
o The VLAN is enabled on the port where the Hello was received.
o Helloを受信したポートでVLANが有効になっています。
(If the appointment includes VLAN IDs 0x000 or 0xFFF, they are ignored, but any other VLAN IDs are still effective.) It then becomes Appointed Forwarder for all the VLANs for which it is appointed in either its Hello appointment database or its E-L1CS FS-LSP appointment database from the DRB if the VLAN is enabled and if the port is not configured as a trunk or IS-IS point-to-point port. If the receiver was Appointed Forwarder for any VLANs because they were in the Hello appointment database and they are no longer in the Hello appointment database, its Appointed Forwarder status for such 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 on the port where the Hello was received due to Hello appointment database entries, but it retains Appointed Forwarder status due to E-L1CS FS-LSP appointments.
（アポイントメントにVLAN ID 0x000または0xFFFが含まれている場合、それらは無視されますが、他のVLAN IDは引き続き有効です。）その後、HelloアポイントメントデータベースまたはそのE-L1CSで指定されているすべてのVLANのAppointed Forwarderになります。 VLANが有効で、ポートがトランクまたはIS-ISポイントツーポイントポートとして構成されていない場合、DRBからのFS-LSP予約データベース。 Helloアポイントメントデータベースにあり、Helloアポイントメントデータベースに存在しないためにレシーバーがVLANのAppointed Forwarderであった場合、そのようなVLANのAppointed Forwarderステータスは取り消されます。たとえば、Hello内のこれらのサブTLVのいずれも受信RBridgeを指定していない場合、Helloアポイントメントデータベースエントリのために、Helloが受信されたポート上のすべてのAppointed Forwarderステータスを失いますが、E- L1CS FS-LSPの予定。
The handling of one or more forwarder appointment sub-TLVs in a Hello from the winning port that appoints the receiving RBridge is as follows: an appointment in an Appointed Forwarders sub-TLV is for a specific RBridge and a contiguous interval of VLAN IDs; however, as stated above, it actually appoints that RBridge as forwarder only for the VLAN or VLANs 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).
受信RBridgeを指定する勝利ポートからのHello内の1つ以上のフォワーダー予約サブTLVの処理は、次のとおりです。AppointedForwardersサブTLVでの予約は、特定のRBridgeとVLAN IDの連続した間隔に対するものです。ただし、前述したように、実際には、RBridgeがリンク上にある1つ以上のポートで有効になっているVLANまたはその範囲内のVLANに対してのみ、そのRBridgeをフォワーダーとして指定します（トランクポートまたはIS-ISポイントとして構成されたポートは無視されます） -to-pointポート）。
There is no reason for an RBridge to remember that it received a valid appointment Hello message for a VLAN that was ineffective because the VLAN was not enabled on the port where the Hello 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 is later reconfigured.
Helloが受信されたポートでVLANが有効になっていないか、ポートがトランクまたはポイントツーポイントだったために無効であったVLANの有効な予定Helloメッセージを受信したことをRBridgeが覚えている理由はありません港。そのVLANが後で有効になるか、ポートが後で再構成されるという理由だけで、そのようなVLANのAppointed Forwarderにはなりません。
The limitations due to the size of the Hello PDU make it desirable to use E-L1CS FS-LSPs for appointment. But if Hellos need to be used, due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the remainder of this section provides a method to maximize the use of the limited space in Hellos for forwarder appointment.
Hello PDUのサイズによる制限により、予約にはE-L1CS FS-LSPを使用することが望ましいです。ただし、Helloを使用する必要がある場合は、リンクのTRILLスイッチがE-L1CS FS-LSPをサポートしていないため、このセクションの残りの部分で、Hello内の限られたスペースをフォワーダーの予約に最大限に活用する方法を説明します。
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 that the DRB wishes to appoint be inconveniently distributed (for example, the proverbial case where a DRB (say RB1) wishes to appoint RB2 as forwarder for all even-numbered VLANs and appoint RB3 as forwarder for all odd-numbered VLANs), the following method may be used:
DRBが1つのHello内で、数十のVLAN IDまたは連続したVLAN IDの数十のブロックの予定を送信するのは簡単です。 DRBが指定することを希望するVLANが不便に分散されている場合（たとえば、DRB（RB1など）がRB2をすべての偶数番号のVLANのフォワーダーとして指定し、すべての奇数番号のVLANのフォワーダーとしてRB3を指定することを望む場合） 、次の方法を使用できます。
The network manager normally controls what VLANs are enabled on an RBridge port. Thus, the network manager can appoint an RBridge as 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 as 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 as forwarder for the Designated VLAN. Thus, in the general case, two appointments would be required, although only one appointment would be required if the Designated VLAN value were extremely low or high (such as VLAN 0xFFE) or the default value (VLAN 1).
通常、ネットワークマネージャーは、RBridgeポートで有効にするVLANを制御します。したがって、ネットワークマネージャーは、関連するポート（1つまたは複数）でそれらのVLANのみを有効にしてから、ターゲットRBridgeをすべてのフォワーダーとして指定するように見えるアポイントメントをDRBに送信させることにより、RBridgeをフォワーダーとして指定できます。 VLAN。ただし、適切な操作とRBridge間通信のために、リンクの指定VLANはそのリンクのすべてのRBridgeポートで有効にする必要があり（SHOULD）、RBridgeを指定VLANのフォワーダーとして指定することは望ましくない場合があります。したがって、一般的なケースでは、2つの予約が必要になりますが、指定VLAN値が極端に低いか高い場合（VLAN 0xFFEなど）またはデフォルト値（VLAN 1）の場合、必要な予約は1つだけです。
For example, assume that 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がすべての偶数VLANのRB2をAppointed Forwarderにすることを望み、リンクの指定VLANがVLAN 101であると想定します。ネットワークマネージャーは、すべての偶数VLANとVLAN 101を関連ポートで有効にすることができます。次に、希望する効果で、DRBがRB2にアポイントメントを送信し、1〜100および102〜4,094のすべてのVLANのフォワーダーを指定します。
Appointments made through E-L1CS FS-LSPs use the same IS-IS timing constants as those for LSP flooding. The general IS-IS link-state flooding mechanism is robust and includes acknowledgments so that it automatically recovers from lost PDUs, rebooted TRILL switches, and the like.
E-L1CS FS-LSPを介して行われた予定は、LSPフラッディングの場合と同じIS-ISタイミング定数を使用します。一般的なIS-ISリンク状態フラッディングメカニズムは堅牢で、確認応答が含まれているため、失われたPDUや再起動されたTRILLスイッチなどから自動的に回復します。
For Hello appointments, it is not necessary for the DRB to include the Hello 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, but see also Section 4). It is also RECOMMENDED that the DRB have enabled all VLANs for which end-station service will be offered on the link as well as the Designated VLAN. Thus, the DRB will generally be informed by other RBridges on the link of the VLANs for which they believe that they are the Appointed Forwarder. If this matches the appointments the DRB wishes to make, it is not required to resend 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.
Helloアポイントメントの場合、DRBがリンクの指定VLANで送信するすべてのTRILL HelloにHelloフォワーダーアポイントメントを含める必要はありません。ループの安全性のために、すべてのRBridgeは、リンク上のVLAN-xで送信されるすべてのTRILL Helloで、そのリンクのVLAN-xのAppointed Forwarderであるかどうかを示す必要があります（セクション3の項目4を参照してください。 4）。また、DRBがリンク上で端末サービスを提供するすべてのVLANと指定VLANを有効にすることもお勧めします。したがって、DRBは一般に、指定されたフォワーダーであると信じているVLANのリンク上の他のRBridgeから通知されます。これがDRBが希望する予定と一致する場合、フォワーダーの予定を再送信する必要はありません。ただし、堅牢性のために、特にブリッジLANリンクでのVLANの設定ミスなどの場合、DRBが勝ったポートでの保持時間ごとに、DRBが指定VLANでフォワーダーのアポイントメントを少なくとも1回送信することをお勧めします。
The Hello 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 when E-L1CS FS-LSP appointments cannot be used due to the presence of legacy RBridges. To obtain a conservative estimate of this limit, assume that no more than 1,000 bytes are available in a TRILL Hello for such appointments. Assume also that it is desired to appoint various RBridges on a link as forwarder for arbitrary non-intersecting sets of VLANs. Using the technique discussed at the end of Section 2.2.1 would generally
DRBフォワーダーの予約のHelloメカニズムとTRILL Helloの制限された長さにより、レガシーRBridgeが存在するためにE-L1CS FS-LSP予約を使用できない場合に、指定されたフォワーダーになるリンク上のRBridgeの数に制限が課されます。この制限の控えめな見積もりを取得するために、そのような予定のTRILL Helloで利用できるのは1,000バイト以下であると想定します。また、リンク上のさまざまなRBridgeを、交差しない任意のVLANセットのフォワーダーとして指定することが望ましいと仮定します。セクション2.2.1の最後で説明した手法を使用すると、通常、
require two appointments, or 12 bytes, per RBridge. With allowance for sub-TLV and TLV overhead, appointments for 83 RBridges would fit in under 1,000 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, and in any case such limitations are easily avoided by using E-L1CS FS-LSP appointment.
RBridgeごとに2つの予約、つまり12バイトが必要です。サブTLVとTLVのオーバーヘッドが許容されるため、83 RBridgeの予定は1,000バイト未満に収まります。 DRBを含め、これは84以上のRBridgeが接続されたリンクを意味します。少数のRBridgeが接続されたリンクはまれであると予想され、どのような場合でも、E-L1CS FS-LSPアポイントメントを使用することにより、このような制限を簡単に回避できます。
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に対して持っているAppointed Forwarderステータスがキャンセルされます。ポートをトランクポートまたはポイントツーポイントポートとして構成すると、そのポートで有効になっているVLANに依存するAppointed Forwarderステータスが取り消されます。
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 necessarily cause the RBridge to become an Appointed Forwarder for the link that port is on. However, such actions allow the port's RBridge to become Appointed Forwarder by choice if it is the DRB or, if it is not the DRB on the link, by appointment as indicated by the Hello appointment database or the E-L1CS FS-LSP appointment database.
ポートがトランクポートまたはポイントツーポイントポートとして構成されなくなったり、ポート上でVLAN-xが有効になったりしても、RBridgeがそのポートが存在するリンクのAppointed Forwarderになるとは限りません。ただし、そのようなアクションにより、ポートのRBridgeは、DRBである場合は選択によってAppointed Forwarderになり、リンク上のDRBでない場合は、HelloアポイントメントデータベースまたはE-L1CS FS-LSPアポイントメントデータベースによって示されるアポイントメントによって許可されます。
A TRILL switch in link-state overload [RFC7780] will, in general, do a poorer job of forwarding frames than a TRILL switch not in overload, because the TRILL switch not in overload has full knowledge of the campus topology. For example, as explained in [RFC7780], an overloaded TRILL switch may not be able to distribute multi-destination TRILL Data packets at all.
リンク状態の過負荷[RFC7780]のTRILLスイッチは、一般に、過負荷でないTRILLスイッチよりキャンパスのトポロジーを完全に把握しているため、フレームを転送する機能が過負荷でないTRILLスイッチよりも貧弱です。たとえば、[RFC7780]で説明されているように、過負荷のTRILLスイッチは、複数の宛先のTRILLデータパケットをまったく配信できない場合があります。
Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder, and if an Appointed Forwarder becomes overloaded, the DRB SHOULD reassign VLANs from the overloaded RBridge to another RBridge on the link that is not overloaded, if one is available.
したがって、DRBはオーバーロード状態のRBridgeをAppointed Forwarderとして指定しないでください。AppointedForwarderがオーバーロードになった場合、DRBは、オーバーロードされたRBridgeから、オーバーロードされていないリンク上の別のRBridgeにVLANを再割り当てする必要があります（使用可能な場合）。
A counter-example where it would be best to appoint an RBridge in overload as Appointed Forwarder would be if RB1 was in overload but all end stations in the campus in VLAN-x were on links attached to RB1. In such a case, RB1 would never have to route VLAN-x end-station traffic as TRILL Data packets but would always be forwarding them locally as native frames. In this case, RB1 SHOULD NOT be disadvantaged for selection as the VLAN-x Appointed Forwarder on any such links, even if RB1 is in overload.
Appointed ForwarderとしてRBridgeをオーバーロードに指定するのが最善である反例は、RB1がオーバーロードになっているが、VLAN-xのキャンパス内のすべてのエンドステーションがRB1に接続されたリンク上にある場合です。このような場合、RB1はVLAN-xエンドステーショントラフィックをTRILLデータパケットとしてルーティングする必要はありませんが、常にローカルフレームとしてネイティブフレームとして転送します。この場合、たとえRB1が過負荷状態であっても、そのようなリンク上のVLAN-x Appointed Forwarderとして選択する場合、RB1は不利になってはなりません（SHOULD NOT）。
There is also the case where it is unavoidable to appoint an RBridge in overload as Appointed Forwarder, because all RBridges on the link are in overload.
また、リンク上のすべてのRBridgeが過負荷になっているため、過負荷のRBridgeをAppointed Forwarderとして指定することが避けられない場合もあります。
These cases do not violate the prohibition in the IS-IS standard against routing through an overloaded node. Designation as an Appointed Forwarder has to do with the ingress and egress of native frames and has nothing to do with the IS-IS routing of TRILL Data packets through a TRILL switch.
これらのケースは、過負荷のノードを経由するルーティングに対するIS-IS標準の禁止事項に違反していません。 Appointed Forwarderとしての指定は、ネイティブフレームの入力と出力に関係し、TRILLスイッチを介したTRILLデータパケットのIS-ISルーティングには関係ありません。
Overload does not affect DRB election, but a TRILL switch in overload MAY reduce its own priority to be the DRB.
過負荷はDRBの選択に影響を与えませんが、過負荷のTRILLスイッチは、自身の優先順位をDRBに下げる場合があります。
TRILL Hellos include a field that is set to the VLAN in which they are sent when they are sent on a link technology such as Ethernet that has outer VLAN labeling. (For link technologies such as PPP that do not have outer VLAN labeling, this Hello field is ignored.) If a TRILL Hello arrives on a different VLAN than the VLAN on which it was sent, then VLAN mapping is occurring within the link. 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 multi-destination frame would loop forever. Such a frame would be "immortal". For a specific example, see Appendix B.
TRILL Helloには、外部VLANラベルのあるイーサネットなどのリンクテクノロジーで送信されるときに送信されるVLANに設定されるフィールドが含まれます。 （外部VLANラベルのないPPPなどのリンクテクノロジーの場合、このHelloフィールドは無視されます。）TRILL Helloが送信されたVLANとは異なるVLANに到着した場合、VLANマッピングはリンク内で発生しています。 VLAN-xとVLAN-y間のVLANマッピングは、VLANのAppointed Forwarderが異なる場合にループを引き起こす可能性があります。リンク内でのそのようなマッピングが許可され、2つ以上のリンクで発生して、VLANマッピングのサイクルが発生した場合、複数の宛先のフレームは永久にループします。このようなフレームは「不滅」です。具体的な例については、付録Bを参照してください。
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 TRILL switch (possibly the DRB) is the Appointed Forwarder on the link for both VLAN-x and VLAN-y.
この潜在的な問題を回避するには、リンク上のDRBがVLAN-yで送信されたVLAN-xでHelloを受信することによりVLANマッピングを検出した場合、同じTRILLスイッチ（おそらくDRB）を確実にするためにアポイントメントを作成または取り消す必要があります）は、VLAN-xとVLAN-yの両方のリンク上のAppointed Forwarderです。
A TRILL switch 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:
TRILLスイッチには、エンドステーションサービスを提供できるすべてのリンク（つまり、アポイントドフォワーダーとして機能できるすべてのリンク）について、秒単位の次のタイマーがあります。
- a DRB inhibition timer,
- DRB禁止タイマー
- a root bridge change inhibition timer, and
- ルートブリッジ変更禁止タイマー
- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.
- 有効なVLAN IDごとに1つ、最大4,094のVLAN禁止タイマー。
The DRB and root bridge 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 Appendix A for an example illustrating a potential problem that is solved by 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 for two VLANs if it is the Appointed Forwarder for one but not for the other, as this can lead to unnecessary indefinitely prolonged inhibition. In a given implementation limitation, there will be safe operations, albeit with more loss of native frames than would otherwise be required, even if only two VLAN inhibition timers are provided: one for the VLANs for which the RBridge is the Appointed Forwarder and one for all other VLANs. Thus, 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禁止タイマーによって解決される潜在的な問題を示す例については、付録Aを参照してください。）ただし、実装の制限によりそのようなタイマーの完全なセットが実用的でない場合は、複数のVLANのVLAN禁止タイマーを慎重にマージできます。 1つのタイマーに。特に、RBridgeが2つのVLANのVLAN禁止タイマーをマージしてはなりません。一方がAppointed Forwarderである場合、もう一方はそうではありません。これにより、不必要に無期限に禁止が延長される可能性があるためです。特定の実装制限では、2つのVLAN禁止タイマーのみが提供されている場合でも、ネイティブフレームの損失が他の方法で必要とされるよりも多くても、安全な操作があります。RBridgeがAppointed ForwarderであるVLAN用と、他のすべての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 TRILL switch will not have had a chance yet to learn that they are on the same link. 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 that it is the DRB.
1. 起動時または管理リセット時に、2つ以上のポートが同じリンク上にある場合でも、TRILLスイッチはそれらが同じリンク上にあることをまだ知る機会がなかったため、各ポートには独自のタイマーセットがあります。以下の項目2に従って設定されるDRB禁止タイマーを除き、すべての禁止タイマーは「期限切れ」に設定されます。各ポートは最初にそれがDRBであると信じるので、DRB禁止タイマーの処理は異なります。
2. When a TRILL switch 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. TRILLスイッチは、管理によって最初に起動またはリセットされたときも含めて、それがリンク上のDRBになったと判断すると、DRB選択タイマーを、DRB選定に勝ったそのリンク上のポートの保持時間に設定します。
3. When a TRILL switch decides that it has lost DRB status on a link, it sets the DRB inhibition timer to "expired".
3. TRILLスイッチは、リンクでDRBステータスを失ったと判断すると、DRB禁止タイマーを「期限切れ」に設定します。
Note: In the corner case where one port of a TRILL switch was the DRB election winner but later lost the DRB election to a different port of the same TRILL switch on that link (perhaps due to management configuration of port priorities), neither item 2 nor item 3 above applies, and the DRB timer is not changed.
注：TRILLスイッチの1つのポートがDRB選択の勝者であったが、後でそのリンクの同じTRILLスイッチの別のポートへのDRB選択を失った（おそらくポートプライオリティの管理構成が原因で）コーナーケースでは、どちらの項目2も上記の項目3も適用されず、DRBタイマーは変更されません。
4. When a TRILL switch RB1 receives a TRILL Hello asserting that the sender is the Appointed Forwarder and that Hello either (1) arrives on VLAN-x or (2) was sent on VLAN-x as indicated inside the Hello, RB1 uses as its VLAN-x inhibition timer for the link (1) that timer's existing value or (2) the Holding Time in the received Hello, whichever is longer. A TRILL switch MUST maintain VLAN inhibition timers covering a link to which it connects if it can offer end-station service on that link, even if it is not currently the Appointed Forwarder for any VLAN on that link.
4. TRILLスイッチRB1がTRILL Helloを受信すると、送信者がAppointed Forwarderであり、Helloが（1）VLAN-xに到着するか、（2）Hello内に示されているようにVLAN-xに送信されたと表明し、RB1は次のように使用します。リンクのVLAN-x抑制タイマー（1）そのタイマーの既存の値または（2）受信したHelloの保持時間のいずれか長い方。 TRILLスイッチは、そのリンク上のVLANのAppointed Forwarderでなくても、そのリンクで端末サービスを提供できる場合、接続するリンクをカバーするVLAN抑制タイマーを維持する必要があります。
5. When a TRILL switch 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. Remember, inhibition has no effect on TRILL Data or IS-IS packets; inhibition only affects native frames.
5. TRILLスイッチRB1がリンクに接続するポートでVLAN-xを有効にし、そのリンク上のRB1のポートでVLAN-xが以前に有効にされていなかった場合、そのリンクのVLAN-xのVLAN禁止タイマーをその保持時間に設定します。そのポート。これは、ポートがトランクポートまたはポイントツーポイントポートとして構成されている場合でも、後でトランクポートまたはポイントツーポイントポートにならないように構成されている可能性がある限り、行われます。禁止はTRILLデータまたはIS-ISパケットには影響しません。抑制はネイティブフレームにのみ影響します。
6. When a TRILL switch detects a change in the common spanning tree root bridge on a port, it sets its root bridge 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 0 seconds. This condition will not occur unless the TRILL switch is receiving Bridge PDUs (BPDUs) on the port from an attached bridged LAN; if no BPDUs are being received, the root bridge change inhibition timer will never be set. It is safe to configure this inhibition time to the settling time of an attached bridged LAN. For example, if it is known that the Rapid Spanning Tree Protocol (RSTP) [802.1Q] is running throughout the attached bridged LAN, it is safe to configure this inhibition time to 7 seconds or, if the attached bridges have been configured to have a minimum Bridge Hello Timer, it is safe to configure it to 4 seconds. Further optimizations are specified in Section 3.2.
6. TRILLスイッチは、ポート上の共通スパニングツリールートブリッジの変更を検出すると、リンクのルートブリッジ変更禁止タイマーを、デフォルトで30秒に設定された時間に設定し、30から0までの任意の値に設定できます。秒。この状態は、TRILLスイッチが接続されたブリッジLANからポート上でブリッジPDU（BPDU）を受信していない限り発生しません。 BPDUが受信されていない場合、ルートブリッジ変更禁止タイマーは設定されません。この禁止時間を、接続されたブリッジLANの整定時間に設定しても安全です。たとえば、接続されているブリッジLAN全体でRapid Spanning Tree Protocol（RSTP）[802.1Q]が実行されていることがわかっている場合は、この禁止時間を7秒に設定するか、接続されているブリッジが最小のBridge Helloタイマー。4秒に設定しても安全です。さらなる最適化はセクション3.2で指定されています。
7. When a TRILL switch decides that one of its ports (or a set of its ports) P1 is on the same link as another one of its ports (or set of its ports) P2, the inhibition timers are merged into a single set of inhibition timers by using the longest value of the corresponding timers as the initial value of the merged timers.
7. TRILLスイッチがそのポート（またはそのポートのセット）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 (up to one link per port). This is handled by cloning a copy of the timers for each of the two or more links to which the TRILL switch has decided these ports connect.
8. RBridgeが、同じリンク上にあるものとして処理していた一連のポートが同じリンク上に存在しないと判断した場合、それらのポートは必ず2つ以上のリンク上にあります（ポートごとに最大1つのリンク）。これは、TRILLスイッチがこれらのポートの接続を決定した2つ以上のリンクのそれぞれのタイマーのコピーを複製することによって処理されます。
Inhibition has no effect on the receipt or forwarding of TRILL Data packets or TRILL IS-IS packets. It only affects ingressing and egressing native frames.
抑制は、TRILLデータパケットまたはTRILL IS-ISパケットの受信または転送には影響しません。これは、ネイティブフレームの入力と出力にのみ影響します。
An Appointed Forwarder for a link is inhibited for VLAN-x if:
次の場合、リンクのAppointed ForwarderはVLAN-xに対して禁止されます。
1. its DRB inhibition timer for that link is not expired,
1. そのリンクのDRB禁止タイマーが期限切れになっていない、
2. its root bridge change inhibition timer for that link is not expired, or
2. そのリンクのルートブリッジ変更禁止タイマーが期限切れになっていない、または
3. its VLAN inhibition timer for that link covering 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 packet whose encapsulated frame would normally be egressed to that link in VLAN-x, 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 Appointed Forwarderが抑制され、カプセル化されたフレームが通常VLAN-xのそのリンクに出力される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 Appointed Forwarderが禁止され、通常そのリンクから入力されるVLAN-xでネイティブフレームを受信した場合、アドレス学習を除いて、ネイティブフレームは無視されます。
A TRILL switch with one or more unexpired inhibition timers, possibly including an unexpired inhibition timer covering 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つ以上の期限切れでない抑制タイマーを備えたTRILLスイッチは、ポートのVLAN-xのAppointed ForwarderであるかどうかをVLAN-xで送信することをTRILL Hellosで示すために必要です。 Helloを送信します。
The subsections below specify three optimizations that can reduce the inhibition time of an RBridge port under certain circumstances for changes in the root Bridge ID [802.1Q] being received by that port and thus decrease any transient interruption in end-station service due to inhibition. TRILL switches MAY implement these optimizations. In the first two optimizations, inhibition can be eliminated entirely under some circumstances. These optimizations are a bit heuristic in that with some unlikely multiple changes in a bridged LAN that occur simultaneously, or nearly so, the optimizations make transient looping more likely.
以下のサブセクションでは、ルートブリッジID [802.1Q]の変更がポートで受信される特定の状況下でRBridgeポートの抑制時間を短縮できる3つの最適化を指定し、抑制による端末サービスの一時的な中断を減らします。 TRILLスイッチは、これらの最適化を実装する場合があります。最初の2つの最適化では、状況によっては抑制を完全になくすことができます。これらの最適化は少し経験則的であり、ブリッジLANで同時に発生する可能性の低い複数の変更が同時に発生するか、ほぼ同時に発生するため、最適化により一時的なループが発生する可能性が高くなります。
Assume that the root Bridge ID being received on an RBridge port changes to a new root Bridge ID with lower priority and a different root Bridge MAC address due to a single change in the bridged LAN. There are two possible reasons for this:
RBridgeポートで受信されているルートブリッジIDが、ブリッジされたLANの1回の変更により、優先度が低く、ルートブリッジのMACアドレスが異なる新しいルートブリッジIDに変更されたとします。これには2つの理由が考えられます。
1. The bridged LAN to which the port is connected has partitioned into two or more parts due to link failure or otherwise, and the port is connected to a part that does not contain the original root bridge.
1. ポートが接続されているブリッジLANが、リンク障害などにより2つ以上に分割されており、ポートが元のルートブリッジを含まない部分に接続されている。
2. The original root bridge has been reconfigured to have a lower priority, and a new root has taken over.
2. 元のルートブリッジは優先順位が低くなるように再構成され、新しいルートが引き継いだ。
Both of these scenarios are safe conditions that do not require inhibition.
これらのシナリオはどちらも、抑制を必要としない安全な状態です。
Assume that the root Bridge ID changes due to a single change in the bridged LAN but only the explicit priority portion of it changes. This means that the 48-bit MAC address portion of the root Bridge ID is unchanged and the root bridge has been reconfigured to have a different priority. Thus, the same bridge is root, and a topology change is not indicated. Thus, it is safe to ignore this sort of root Bridge ID change and not invoke the inhibition mechanism.
ルートブリッジIDは、ブリッジングされたLANの1つの変更により変更されたものの、その明示的な優先順位部分のみが変更されたと仮定します。つまり、ルートブリッジIDの48ビットMACアドレス部分は変更されておらず、ルートブリッジは異なる優先度を持つように再構成されています。したがって、同じブリッジがルートであり、トポロジの変更は示されません。したがって、この種のルートブリッジIDの変更を無視して、抑制メカニズムを呼び出さなくても安全です。
A dangerous case is the merger of bridged LANs that had been separate TRILL links in the same campus. In general, these links may have had different Appointed Forwarders on them for the same VLAN. Without inhibition, loops involving those VLANs could occur after the merger.
危険なケースは、同じキャンパスで別々のTRILLリンクであったブリッジLANの合併です。一般に、これらのリンクには、同じVLANの異なるAppointed Forwarderが含まれている可能性があります。禁止しないと、これらのVLANを含むループが合併後に発生する可能性があります。
Only native frames egressed and ingressed by RBridges are a potential problem. TRILL Data packets are either
RBridgesによって出入りするネイティブフレームのみが潜在的な問題です。 TRILLデータパケットは、
1. individually addressed (TRILL Header M bit = 0) and will be ignored if delivered to any incorrect TRILL switch ports or
1. 個別にアドレス指定され（TRILLヘッダーMビット= 0）、不正なTRILLスイッチポートに配信された場合は無視されます。
2. multicast (TRILL Header M bit = 1), in which case the Reverse Path Forwarding Check discards any copies delivered to incorrect TRILL switch ports.
2. マルチキャスト（TRILLヘッダーMビット= 1）。この場合、リバースパス転送チェックは、誤ったTRILLスイッチポートに配信されたコピーを破棄します。
Thus, there is no need for inhibition to affect the sending or receiving of TRILL Data packets, and inhibition does not do so.
したがって、TRILLデータパケットの送信または受信に影響を与えるために禁止する必要はなく、禁止はそうしません。
However, root bridge change inhibition is only needed until TRILL Hellos have been exchanged on the merged bridged LAN. Hellos indicate Appointed Forwarder status and, in general, after an exchange of Hellos the new merged bridged LAN link will, if necessary, be rendered TRILL loop safe by VLAN inhibition so that root bridge change inhibition is no longer needed.
ただし、ルートブリッジの変更を禁止する必要があるのは、マージされたブリッジLANでTRILL Helloが交換されるまでです。 HelloはAppointed Forwarderステータスを示し、一般に、Helloの交換後、新しいマージされたブリッジLANリンクは、必要に応じて、VLAN禁止によってTRILLループセーフになるため、ルートブリッジの変更禁止は不要になります。
TRILL switches are required to advertise in their link state the IDs of the root Bridge IDs they can see. If an RBridge port sees a change in root Bridge ID from Root1 to Root2, it is safe to terminate root bridge change inhibition on that port as soon as Hellos have been received on the port from all RBridges that can see Root1 or Root2, except any such RBridge that is no longer reachable.
TRILLスイッチは、リンク状態で、表示できるルートブリッジIDのIDを通知する必要があります。 RBridgeポートがルートブリッジIDのRoot1からRoot2への変更を検出した場合、Root1またはRoot2を参照できるすべてのRBridgeからHellosがポートで受信されるとすぐに、そのポートでルートブリッジの変更禁止を終了しても安全です。もはや到達できないそのようなRBridge。
In further detail, when a change from Root1 to Root2 is noticed at a port of RB1, RB1 associates with that port a list of all of the reachable RBridges, other than itself, that had reported in their LSPs that they could see either Root1 or Root2. It then removes from this list any RBridge that becomes unreachable from RB1 or from which it has received a Hello on that port. If there is a subsequent change in root Bridge ID being received before this list is empty, say to Root7, then those RBridges reporting in their LSPs that they can see Root7 are added to the list. Root bridge change inhibition can be terminated for the port as soon as either the timeout is reached or this list of RBridges is empty.
さらに詳しくは、Root1からRoot2への変更がRB1のポートで検出されると、RB1はそのポートに、自身以外の、到達可能RBridgeのリストを関連付けます。ルート2。次に、このリストから、RB1から到達できなくなるか、そのポートでHelloを受信したRBridgeを削除します。このリストが空になる前に受信されるルートブリッジIDにその後の変更がある場合、たとえばRoot7に対して、Root7を参照できるとLSPで報告しているRBridgeがリストに追加されます。ルートブリッジの変更禁止は、タイムアウトに達するか、RBridgeのこのリストが空になるとすぐに、ポートに対して終了できます。
If the optimizations described in Sections 3.2.1 and/or 3.2.2 are in effect at an RBridge port and indicate that no inhibition is needed, then the mechanism described in this section is not needed either.
セクション3.2.1または3.2.2で説明されている最適化がRBridgeポートで有効であり、抑制が不要であることを示している場合、このセクションで説明されているメカニズムも不要です。
If a network manager has sufficient confidence that they know the configuration of bridges, ports, and the like, within an Ethernet link, they may be able to reduce the number of TRILL Hellos sent on that link by sending Hellos in fewer VLANs -- for example, if all TRILL switches on the link will see all Hellos without VLAN constraints. However, because adjacencies are established in the Designated VLAN, an RBridge MUST always attempt to send Hellos in the Designated VLAN.
ネットワーク管理者がイーサネットリンク内のブリッジ、ポートなどの構成を知っているという十分な自信がある場合、より少ないVLANでHelloを送信することにより、そのリンクで送信されるTRILL Helloの数を減らすことができる可能性があります-たとえば、リンク上のすべてのTRILLスイッチがVLANの制約なしにすべてのHelloを見る場合です。ただし、指定VLANで隣接関係が確立されているため、RBridgeは常に指定VLANでHelloを送信しようとする必要があります。
Hello reduction makes TRILL less robust in the face of decreased VLAN connectivity within a link, such as partitioned VLANs, VLANs disabled on ports, or disagreement over the Designated VLAN; however, as long as all RBridge ports on the link are configured for the same Desired Designated VLAN [RFC6325], can see each other's frames in that VLAN, and utilize the mechanisms specified below to update VLAN inhibition timers, operations will be safe. (These considerations do not arise on links between RBridges that are configured as point to point, since, in that case, each RBridge sends point-to-point Hellos, other TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to be the Designated VLAN of the link (although it may send them untagged) and no native frame end-station service is provided. Thus, for such links, there is no reason to send Hellos in any VLAN other than the Designated VLAN.)
Hello削減により、パーティション化されたVLAN、ポートで無効にされたVLAN、または指定されたVLANでの不一致など、リンク内のVLAN接続の減少に直面してTRILLの堅牢性が低下します。ただし、リンク上のすべてのRBridgeポートが同じDesired Designated VLAN [RFC6325]に構成されており、そのVLAN内で互いのフレームを確認でき、以下に指定されたメカニズムを利用してVLAN禁止タイマーを更新できる限り、操作は安全です。 （これらの考慮事項は、ポイントツーポイントとして構成されているRBridge間のリンクでは発生しません。その場合、各RBridgeは、ポイントツーポイントのHello、その他のTRILL IS-IS PDU、およびTRILLデータフレームを、それが信じているものだけで送信するためです。リンクの指定VLANになる（タグなしで送信される場合があります）ため、ネイティブフレームエンドステーションサービスは提供されません。したがって、このようなリンクの場合、指定VLAN以外のVLANでHelloを送信する理由はありません。）
The provision for a configurable set of "Announcing VLANs", as described in Section 4.4.3 of [RFC6325], provides a mechanism in the TRILL base protocol for a reduction in TRILL Hellos.
[RFC6325]のセクション4.4.3で説明されているように、「Announcing VLANs」の構成可能なセットの規定は、TRILL Helloを削減するためのTRILLベースプロトコルのメカニズムを提供します。
To maintain loop safety in the face of occasional lost frames, RBridge failures, link failures, new RBridges coming up on a link, and the like, the inhibition mechanism specified in Section 3 is still required. Strictly following Section 3, a VLAN inhibition timer can only be set by the receipt of a Hello sent or received in that VLAN. Thus, to safely send a reduced number of TRILL Hellos on a reduced number of VLANs requires additional mechanisms to set the VLAN inhibition timers at an RBridge. Two such mechanisms, specified below, expand upon the mechanisms provided in Section 3. Support for both of these mechanisms is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge to send TRILL Hellos on fewer VLANs than the set of VLANs recommended in [RFC6325] on a link unless all its adjacencies on that link (excluding those in the Down state [RFC7177]) indicate support of these mechanisms and these mechanisms are in use.
たまに失われるフレーム、RBridgeの障害、リンクの障害、リンクで発生する新しいRBridgeなどに直面してもループの安全性を維持するには、セクション3で指定された抑制メカニズムが依然として必要です。セクション3に厳密に従うと、VLAN禁止タイマーは、そのVLANで送信または受信されたHelloを受信することによってのみ設定できます。したがって、少ない数のVLANで少ない数のTRILL Helloを安全に送信するには、RBridgeでVLAN禁止タイマーを設定する追加のメカニズムが必要です。以下に示す2つのメカニズムは、セクション3で提供されるメカニズムを拡張したものです。これらのメカニズムの両方のサポートは、PORT-TRILL-VERサブTLVの機能ビットで示されます（[RFC7176]のセクション5.4）。リンク上のすべての隣接関係（ダウン状態の[RFC7177]を除く）がこれらのメカニズムのサポートを示さない限り、RBridgeがリンク上の[RFC6325]で推奨されているVLANのセットよりも少ないVLANでTRILL Helloを送信することは安全ではない可能性がありますこれらのメカニズムが使用されています。
1. An RBridge RB2 MAY include in any TRILL Hello an Appointed Forwarders sub-TLV [RFC7176] appointing itself for one or more ranges of VLANs. The Appointee Nickname field(s) in the self-appointment Appointed Forwarders sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hellos sent by RB2. This indicates that the sending RBridge believes that it is Appointed Forwarder for those VLANs. For each of an RBridge's VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV, the RBridge sets that timer to either (1) its current value or (2) the Holding Time of the Hello containing the sub-TLV, whichever is longer. This is backward compatible. That is, such sub-TLVs will have no effect on any legacy receiving RBridge not implementing this mechanism unless RB2, the sending RBridge, is the DRB sending Hellos on the Designated VLAN. If RB2 is the DRB, it MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link.
1. RBridge RB2は、VLANの1つ以上の範囲に対して自分自身を指定する任意のTRILL Hello Appointed Forwarders sub-TLV [RFC7176]に含めることができます（MAY）。自己予定Appointed ForwardersサブTLVのAppointee Nicknameフィールドは、RB2によって送信されたTRILL HelloのSpecial VLANsおよびFlagsサブTLVのSender Nicknameと同じである必要があります。これは、送信RBridgeがそれらのVLANのAppointed Forwarderであると信じていることを示しています。 Appointed ForwardersサブTLVにリストされている1つまたは複数のブロック内のすべてのVLANに対するRBridgeの各VLAN抑制タイマーについて、RBridgeはそのタイマーを（1）現在の値または（2）を含むHelloの保留時間に設定しますサブTLV、どちらか長い方。これには下位互換性があります。つまり、このようなサブTLVは、送信元のRBridgeであるRB2が指定VLANでHelloを送信するDRBでない限り、このメカニズムを実装していないレガシー受信RBridgeには影響を与えません。 RB2がDRBである場合、リンク上の自分以外のRBridgeの場合、Hello allフォワーダーの予定があれば、それを含める必要があります。
2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2 on any VLAN, RB1 updates the VLAN inhibition timers for all the VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is Appointed Forwarder. Each such timer is updated to (1) its current value or (2) the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV, whichever is longer. This sub-TLV will be an unknown sub-TLV to RBridges not implementing it, and such RBridges will ignore it. Even if a TRILL Hello sent by the DRB on the Designated VLAN includes one or more VLANs Appointed sub-TLVs, as long as no Appointed Forwarders sub-TLVs appear, the Hello is not required to indicate all forwarder appointments.
2. RBridgeはVLANs Appointed sub-TLV [RFC7176]を使用してもよい（MAY）。 RB1は、任意のVLAN上のRB2からTRILL HelloでVLAN Appointed Sub-TLVを受信すると、RB2がそのサブTLVにリストするすべてのVLANのVLAN抑制タイマーを、RB2がAppointed ForwarderであるVLANとして更新します。このような各タイマーは、（1）現在の値または（2）VLAN Appointed sub-TLVを含むTRILL Helloの保持時間のいずれか長い方に更新されます。このサブTLVは、RBridgeが実装していない未知のサブTLVであり、そのようなRBridgeはそれを無視します。 DRBが指定VLANで送信するTRILL Helloに1つ以上のVLAN Appointed Sub-TLVが含まれている場合でも、Appointed ForwardersサブTLVが表示されない限り、Helloはすべてのフォワーダーの予定を示す必要はありません。
Two different encodings are provided above to optimize the listing of VLANs. Large blocks of contiguous VLANs are more efficiently encoded with the Appointed Forwarders sub-TLV, and scattered VLANs are more efficiently encoded with the VLANs Appointed sub-TLV. These encodings may be mixed in the same Hello. The use of these sub-TLVs does not affect the requirement that the AF bit in the Special VLANs and Flags sub-TLV MUST be set if the originating RBridge believes that it is Appointed Forwarder for the VLAN in which the Hello is sent.
上記の2つの異なるエンコーディングは、VLANのリストを最適化するために提供されています。隣接するVLANの大きなブロックはAppointed ForwardersサブTLVでより効率的にエンコードされ、分散したVLANはVLAN AppointedサブTLVでより効率的にエンコードされます。これらのエンコーディングは、同じHelloに混在させることができます。これらのサブTLVの使用は、Helloが送信されるVLANのAppointed Forwarderであると元のRBridgeが信じている場合、特別なVLANおよびフラグサブTLVのAFビットを設定する必要があるという要件に影響しません。
If the above mechanisms are used on a link, then each RBridge on the link MUST send Hellos in one or more VLANs with such VLANs Appointed sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s), and the AF bit is appropriately set such that no VLAN inhibition timer will improperly expire unless three or more Hellos are lost. For example, an RBridge could announce all VLANs for which it believes that it is Appointed Forwarder in a Hello sent on the Designated VLAN three times per Holding Time.
上記のメカニズムがリンクで使用される場合、リンク上の各RBridgeは、1つ以上のVLANでHelloを送信する必要があります（そのようなVLANが指定されたサブTLVおよび/または自己指定の指定されたフォワーダーサブTLV）。 AFビットが適切に設定されているため、3つ以上のHelloが失われない限り、VLAN抑制タイマーが不適切に期限切れになることはありません。たとえば、RBridgeは、指定されたVLANで保持時間ごとに3回送信されるHelloでAppointed Forwarderであると考えるすべてのVLANをアナウンスすることができます。
A TRILL switch may have multiple ports on the same link. Some of these ports may be suspended due to MAC address duplication, as described in [RFC7177]. Suspended ports never ingress or egress native frames.
TRILLスイッチには、同じリンク上に複数のポートがある場合があります。これらのポートの一部は、[RFC7177]で説明されているように、MACアドレスの重複が原因で一時停止されている可能性があります。一時停止されたポートは、ネイティブフレームに出入りしません。
If a TRILL switch 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 TRILL switch is eligible to be an Appointed Forwarder for that link. It can become Appointed Forwarder in the ways discussed in Section 2.
TRILLスイッチにリンク上に1つ以上の非一時停止ポートがあり、それらのポートがエンドステーションサービスを提供している場合（つまり、これらのポートがポイントツーポイントまたはトランクポートとして構成されていない場合）、そのTRILLスイッチは適格ですそのリンクの指定フォワーダーになる。セクション2で説明した方法でAppointed Forwarderになることができます。
If a TRILL switch 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 one of its ports, creating a loop. If the TRILL switch 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のAppointed ForwarderであるTRILLスイッチがそのリンク上に複数の非サスペンドポートを持っている場合、選択したポート間でVLAN-xネイティブフレームの入力と出力のタスクを負荷共有する可能性があります。あるポートからリンクに出力されるフレームが別のポートに入力されてループが発生する場合がない限り。 TRILLスイッチが複数のVLANのAppointed Forwarderである場合、簡単なことは、リンク上にあるポート間でそれらのVLANを分割することです。
A TRILL switch may note that one of its ports has failed, or it may be about to shut down that port. If the port is on a link along with ports of other TRILL switches, those TRILL switches will not notice the port shutdown or failure using TRILL base protocol mechanisms until there is a failure to receive a number of Hellos from that port. This can take many seconds. Network topology (adjacencies) and forwarder appointments can react more rapidly to port shutdown or failure through explicit notification. As discussed below, this notification SHOULD be provided through the Port-Shutdown message.
TRILLスイッチは、そのポートの1つに障害が発生したこと、またはそのポートをシャットダウンしようとしていることを通知する場合があります。ポートが他のTRILLスイッチのポートと共にリンク上にある場合、それらのTRILLスイッチは、そのポートから多数のHelloの受信に失敗するまで、TRILLベースのプロトコルメカニズムを使用したポートのシャットダウンまたは失敗に気づきません。これには数秒かかる場合があります。ネットワークトポロジ（隣接関係）とフォワーダーの予定は、明示的な通知により、ポートのシャットダウンまたは障害に対してより迅速に対応できます。以下で説明するように、この通知はPort-Shutdownメッセージを通じて提供する必要があります（SHOULD）。
A TRILL switch that is shutting down one of its ports (say P1) soon SHOULD reduce its Holding Time on that port, so that the shutdown will be more rapidly noticed by adjacent RBridges that might not support the Port-Shutdown message.
ポートの1つ（P1など）をシャットダウンするTRILLスイッチは、すぐにそのポートの保持時間を短縮する必要があるため（SHOULD）、シャットダウンは、Port-Shutdownメッセージをサポートしていない可能性のある隣接するRBridgeによってより迅速に認識されます。
The Port-Shutdown message is an RBridge Channel message [RFC7178] using RBridge Channel Protocol number 0x006. The payload specific to the Channel Protocol consists of a list of Port IDs (see Section 4.4.2 of [RFC6325]) for the port or ports that have failed or are being shut down, as shown in the diagram below. Support for the Port-Shutdown message is advertised by simply advertising support for its RBridge Channel Protocol in the RBridge Channel Protocols sub-TLV [RFC7176].
Port-Shutdownメッセージは、RBridge Channel Protocol番号0x006を使用するRBridge Channelメッセージ[RFC7178]です。下の図に示すように、チャネルプロトコル固有のペイロードは、障害が発生したかシャットダウンされたポートのポートIDのリスト（[RFC6325]のセクション4.4.2を参照）で構成されています。 Port-Shutdownメッセージのサポートは、RBridge Channel ProtocolsサブTLV [RFC7176]でRBridge Channel Protocolのサポートを単にアドバタイズすることによってアドバタイズされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA = All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Special Inner.MacDA (cont.) | Inner.MacSA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner.MacSA (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN Tag Ethertype=0x8100 | Priority=7, DEI=0, VLAN ID=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Chan. Ethertype=0x8946| CHV=0 | Channel Protocol=0x006|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Information specific to the Port-Shutdown Channel Protocol:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port ID K |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For robustness, a TRILL switch sends a configurable number of copies of Port-Shutdown messages separated by a configurable time interval. The default number of copies is two, although this can be configured as one copy or as three copies, and the default interval is 20 milliseconds (see Section 6.6). As with any "adjacency critical" message, the Port-Shutdown message SHOULD be sent with the highest priority, which is priority 7, and SHOULD NOT be marked as "drop eligible".
堅牢性のために、TRILLスイッチは、構成可能な時間間隔で区切られた、ポートシャットダウンメッセージの構成可能な数のコピーを送信します。デフォルトのコピー数は2ですが、これは1つのコピーまたは3つのコピーとして構成でき、デフォルトの間隔は20ミリ秒です（6.6節を参照）。 「隣接クリティカル」メッセージと同様に、Port-Shutdownメッセージは最高の優先度（優先度7）で送信する必要があり（SHOULD）、「ドロップ適格」としてマークしてはいけません（SHOULD NOT）。
If a failure of port P1 on RBridge RB2 is detected by RB2, then the Port-Shutdown message announcing this failure is sequentially unicast through the rest of the TRILL campus to all RBridges (1) with which P1 had an adjacency and (2) that are advertising support for the Port-Shutdown RBridge Channel Protocol.
RBridge RB2上のポートP1の障害がRB2によって検出された場合、この障害を通知するPort-Shutdownメッセージは、残りのTRILLキャンパスを介して、P1が隣接していたすべてのRBridgeに順次ユニキャストされ、（2）は、Port-Shutdown RBridge Channel Protocolのサポートをアドバタイズしています。
If a port shutdown is planned within 1 second, then the TRILL switch ceases to send Hellos out of the port being shut down and either (1) sends the Port-Shutdown message to RBridge ports on the link advertising support of the Port-Shutdown RBridge Channel Protocol or (2) broadcasts the Port-Shutdown message announcing this event through the port as follows:
ポートのシャットダウンが1秒以内に計画されている場合、TRILLスイッチはシャットダウンされているポートからHellosを送信しなくなり、（1）Port-Shutdown RBridgeのサポートをアドバタイズするリンク上のRBridgeポートにPort-Shutdownメッセージを送信します。チャネルプロトコルまたは（2）次のように、ポートを介してこのイベントを通知するポートシャットダウンメッセージをブロードキャストします。
- The Outer.MacDA is the All-RBridges multicast address.
- Outer.MacDAはAll-RBridgesマルチキャストアドレスです。
- If an outer VLAN tag is present, it specifies the Designated VLAN for the link, SHOULD specify priority 7, and SHOULD NOT specify "drop eligible".
- 外部VLANタグが存在する場合、それはリンクの指定VLANを指定し、優先順位7を指定する必要があり（SHOULD）、「ドロップ適格」を指定してはなりません（SHOULD NOT）。
- In the TRILL Header, the egress nickname is All-RBridges, and the M bit in the TRILL Header is set to 0.
- TRILLヘッダーでは、出力ニックネームはAll-RBridgesで、TRILLヘッダーのMビットは0に設定されています。
- In the RBridge Channel Header, the MH and NA bits are zero.
- RBridgeチャネルヘッダーでは、MHおよびNAビットはゼロです。
There is no need for a special message to indicate that a port P1 has come back up or that a shutdown has been "canceled". This is indicated by simply sending Hellos out of port P1.
ポートP1が復旧したこと、またはシャットダウンが「キャンセルされたこと」を示す特別なメッセージは必要ありません。これは、ポートP1からHellosを送信するだけで示されます。
When a TRILL switch RB1 receives a Port-Shutdown message, RB1 checks to see if the ingress nickname specifies some TRILL switch RB2 with which RB1 has one or more adjacencies. If so, it drops those adjacencies that are to RB2 ports whose Port IDs are listed in the Port-Shutdown message. There could be more than one if RB2 had multiple ports on the link that are going down.
TRILLスイッチRB1がPort-Shutdownメッセージを受信すると、RB1は、RB1に1つ以上の隣接があるTRILLスイッチRB2が入力ニックネームで指定されているかどうかを確認します。その場合、Port-ShutdownメッセージにポートIDがリストされているRB2ポートへの隣接をドロップします。ダウンするリンク上にRB2の複数のポートがある場合、複数存在する可能性があります。
If RB1 is the DRB and this eliminates all adjacencies on a link between the DRB and RB2, then, for all VLANs whose ingress/egress was being handled by RB2, the DRB either starts acting as Appointed Forwarder or appoints some new TRILL switch with which it has adjacency as Appointed Forwarder.
RB1がDRBであり、これによりDRBとRB2の間のリンク上のすべての隣接関係が排除される場合、RB2によって入力/出力が処理されていたすべてのVLANについて、DRBはAppointed Forwarderとして機能を開始するか、新しいTRILLスイッチを指定します。 Appointed Forwarderとして隣接しています。
Port-Shutdown messages can be secured through the use of the RBridge Channel Header Extension security feature [RFC7978].
ポートシャットダウンメッセージは、RBridgeチャネルヘッダー拡張セキュリティ機能[RFC7978]を使用して保護できます。
There are two Port-Shutdown configuration parameters, as listed below. Section 6.3 provides details regarding their use.
以下に示すように、2つのポートシャットダウン構成パラメーターがあります。セクション6.3は、それらの使用に関する詳細を提供します。
Parameter Default Range
--------------- ---------------- ---------------------
PShutdownRepeat 2 1-3
PShutdownDelay 20 milliseconds 0-1,000 milliseconds
TRILL switches support 24-bit Fine-Grained Labels as specified in [RFC7172]. Basically, a VLAN ID in native traffic between an edge TRILL switch and an end station is mapped from/to an FGL as an Inner.Label in TRILL Data packets. Since the Appointed Forwarder for a VLAN will be ingressing and egressing such native traffic, the mapping configured at the Appointed Forwarder is the mapping performed.
TRILLスイッチは、[RFC7172]で指定されている24ビットの細粒度ラベルをサポートしています。基本的に、エッジTRILLスイッチとエンドステーションの間のネイティブトラフィックのVLAN IDは、FILLとの間でTRGLデータパケットのInner.Labelとしてマッピングされます。 VLANのAppointed Forwarderはそのようなネイティブトラフィックに出入りするため、Appointed Forwarderで構成されたマッピングが実行されます。
However, the Appointed Forwarder for VLAN-x on a link can change for reasons discussed elsewhere in this document. Thus, all TRILL switches on a link that are configured with an FGL-VLAN mapping SHOULD be configured with the same mapping. Otherwise, traffic might unpredictably jump from one FGL to another when the Appointed Forwarder changes. TRILL switches SHOULD advertise their mapping on the link using the FGL-VLAN-Bitmap and FGL-VLAN-Pairs APPsub-TLVs (Sections 10.4 and 10.5) so that consistency checking can be automated.
ただし、リンク上のVLAN-xのAppointed Forwarderは、このドキュメントの他の場所で説明されている理由により変更される場合があります。したがって、FGL-VLANマッピングで構成されているリンク上のすべてのTRILLスイッチは、同じマッピングで構成する必要があります（SHOULD）。そうしないと、Appointed Forwarderが変更されると、トラフィックが1つのFGLから別のFGLに予期せずジャンプする可能性があります。 TRILLスイッチは、FGL-VLAN-BitmapおよびFGL-VLAN-Pairs APPsub-TLV（セクション10.4および10.5）を使用して、リンク上のマッピングをアドバタイズする必要があります（セクション10.4および10.5）。これにより、整合性チェックを自動化できます。
A TRILL switch SHOULD compare the FGL-VLAN mappings that it sees advertised by other TRILL switches on a link with its own and alert the network operator if they are inconsistent. "Inconsistent" means that (1) one TRILL switch maps FGL-z to VLAN-x while another maps FGL-z to VLAN-y or (2) one TRILL switch maps VLAN-x to FGL-w while another maps VLAN-x to FGL-z, all on the same link.
TRILLスイッチは、リンク上の他のTRILLスイッチによって通知されたFGL-VLANマッピングを独自のFGL-VLANマッピングと比較し、矛盾がある場合はネットワークオペレーターに警告する必要があります。 「不整合」とは、（1）TRILLスイッチがFGL-zをVLAN-xにマッピングし、別のFILL-zをVLAN-yにマッピングする、または（2）1つのTRILLスイッチがVLAN-xをFGL-wにマッピングする、別のTRILLスイッチがVLAN-xをマッピングする、という意味です。 FGL-zに、すべて同じリンクで。
Depending on how the network is being managed, a transient inconsistency may not be a problem. Thus, the network operator SHOULD NOT be alerted unless the inconsistency persists for a period of time that defaults to the TRILL switch's Holding Time and is configurable to between 0 seconds and 2**16 - 1 seconds, where 2**16 - 1 is a special value and indicates that such alerts are disabled.
ネットワークの管理方法によっては、一時的な不整合は問題にならない場合があります。したがって、ネットワークオペレーターは、デフォルトでTRILLスイッチの保持時間になり、0秒から2 ** 16-1秒の間で構成可能である期間（2 ** 16-1の場合）に不整合が持続しない限り、警告されるべきではありません（SHOULD NOT）。特別な値であり、そのようなアラートが無効であることを示します。
All TRILL switches MUST support the E-L1CS flooding scope [RFC7356], Extended Level 1 Flooding Scope (E-L1FS) [RFC7780], and base LSPs [IS-IS]. It will be apparent to any TRILL switch on a link if any other TRILL switch on the link is a legacy implementation not supporting E-L1CS because, as stated in [RFC7780], all TRILL switches MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send. This support of E-L1CS increases the amount of information from each TRILL switch that can be synchronized on the link, compared with the information capacity of Hellos, by several orders of magnitude.
すべてのTRILLスイッチは、E-L1CSフラッディングスコープ[RFC7356]、拡張レベル1フラッディングスコープ（E-L1FS）[RFC7780]、およびベースLSP [IS-IS]をサポートする必要があります。 [RFC7780]で述べられているように、リンク上の他のTRILLスイッチがE-L1CSをサポートしていないレガシー実装である場合、リンク上のすべてのTRILLスイッチは、スコープフラッディングサポートTLV [RFC7356]を含める必要があるため、明らかです。彼らが送るすべてのTRILL Helloに。 E-L1CSのこのサポートにより、Helloの情報容量と比較して、リンク上で同期できる各TRILLスイッチからの情報量が数桁増加します。
For robustness, E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs (Flooding Scope Complete Sequence Number PDUs) [RFC7356], and E-L1CS FS-PSNPs (Flooding Scope Partial Sequence Number PDUs) [RFC7356]) MUST NOT exceed 1,470 bytes in length; however, any such E-L1CS PDU that is received that is longer than 1,470 bytes is processed normally.
堅牢性のために、E-L1CS PDU（FS-LSPフラグメント、E-L1CS FS-CSNPs（フラッディングスコープの完全なシーケンス番号PDU）[RFC7356]、およびE-L1CS FS-PSNPs（フラッディングスコープの部分的なシーケンス番号PDU）[RFC7356]）長さが1,470バイトを超えてはなりません。ただし、受信されたE-L1CS PDUが1,470バイトを超える場合は、通常どおり処理されます。
As with any type of IS-IS LSP, FS-LSPs are identified by the System ID of the originating router (TRILL switch) and the fragment number. In particular, there is no port identifier in the header of an E-L1CS PDU. Thus, a TRILL switch RB1 with more than one non-suspended port on a link (Section 5) transmitting such a PDU MAY transmit it out of any one or more of such ports. RB1 will generally receive such a PDU that other TRILL switches send on all of RB1's ports on the link. In addition, with multiple ports on the link, it will receive any such PDU that it sends on the ports it has on the link other than the transmitting port.
あらゆるタイプのIS-IS LSPと同様に、FS-LSPは、発信元ルーター（TRILLスイッチ）のシステムIDとフラグメント番号によって識別されます。特に、E-L1CS PDUのヘッダーにはポート識別子がありません。したがって、そのようなPDUを送信するリンク上の複数の非一時停止ポート（セクション5）を持つTRILLスイッチRB1は、そのようなポートの1つ以上から送信することができます（セクション5）。 RB1は通常、リンク上のRB1のすべてのポートで他のTRILLスイッチが送信するようなPDUを受信します。さらに、リンク上に複数のポートがある場合、送信ポート以外のリンク上にあるポートで送信するそのようなPDUを受信します。
Future TRILL specifications making use of E-L1CS MUST specify how situations involving a TRILL link will be handled when one or more TRILL switches attached to that link support E-L1CS and one or more do not.
E-L1CSを使用する将来のTRILL仕様では、そのリンクに接続された1つ以上のTRILLスイッチがE-L1CSをサポートし、1つ以上がサポートしない場合に、TRILLリンクを含む状況がどのように処理されるかを指定する必要があります。
This document provides improved documentation of the TRILL Appointed Forwarder mechanism. It does not change the security considerations of the TRILL base protocol as described in Section 6 of [RFC6325].
このドキュメントは、TRILL Appointed Forwarderメカニズムの改善されたドキュメントを提供します。 [RFC6325]のセクション6で説明されているTRILLベースプロトコルのセキュリティに関する考慮事項は変更されません。
The Port-Shutdown messages specified in Section 6 are sent using the RBridge Channel facility [RFC7178]. Such messages SHOULD be secured through the use of the RBridge Channel Header Extension [RFC7978]. If they are not adequately secured, they are a potential denial-of-service vector.
セクション6で指定されたPort-Shutdownメッセージは、RBridge Channel機能[RFC7178]を使用して送信されます。このようなメッセージは、RBridge Channel Header Extension [RFC7978]を使用して保護する必要があります（SHOULD）。それらが適切に保護されていない場合、サービス拒否の可能性があります。
The E-L1CS FS-LSPs added by Section 8 are a type of IS-IS PDU [RFC7356]. As such, they are securable through the addition of Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.
セクション8で追加されたE-L1CS FS-LSPは、IS-IS PDUの一種です[RFC7356]。そのため、Helloまたは他のIS-IS PDUと同じ方法で認証TLV [RFC5310]を追加することで、セキュリティを確保できます。
This section provides IANA considerations for this document and specifies the structures of the AppointmentBitmap, AppointmentList, VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs. These APPsub-TLVs appear within a TRILL GENINFO TLV [RFC7357] in E-L1CS FS-LSPs [RFC7356].
このセクションでは、このドキュメントに関するIANAの考慮事項を示し、AppointmentBitmap、AppointmentList、VLAN-FGLマッピングビットマップ、およびVLAN-FGLマッピングペアAPPsub-TLVの構造を指定します。これらのAPPsub-TLVは、E-L1CS FS-LSP [RFC7356]のTRILL GENINFO TLV [RFC7357]内に表示されます。
IANA has assigned four new APPsub-TLV type codes from the range below 255 and entered them in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry as follows:
IANAは、255未満の範囲から4つの新しいAPPsub-TLVタイプコードを割り当て、次のように「IS-IS TLV 251 Application Identifier 1のTRILL APPsub-TLVタイプ」レジストリに入力しました。
Type Name Reference
---- ----------------- ---------
17 AppointmentBitmap [RFC8139]
18 AppointmentList [RFC8139]
19 FGL-VLAN-Bitmap [RFC8139]
20 FGL-VLAN-Pairs [RFC8139]
IANA has assigned a new RBridge Channel Protocol number in the range assigned by Standards Action [RFC5226] and updated the "RBridge Channel Protocols" registry as follows:
IANAは、標準アクション[RFC5226]によって割り当てられた範囲の新しいRBridgeチャネルプロトコル番号を割り当て、「RBridgeチャネルプロトコル」レジストリを次のように更新しました。
Protocol Description Reference
-------- -------------- ---------
0x006 Port-Shutdown [RFC8139]
IANA has updated the reference for the "Hello reduction support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags" registry to refer to this document.
IANAは、このドキュメントを参照するために、「PORT-TRILL-VER Sub-TLV Capability Flags」レジストリの「Helloリダクションサポート」ビットのリファレンスを更新しました。
The AppointmentBitmap APPsub-TLV provides an efficient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs when those VLAN IDs are relatively compact (that is, they do not span a large numeric range). Such an appointment is only effective when the appointing TRILL switch is the DRB.
AppointmentBitmap APPsub-TLVは、それらのVLAN IDが比較的コンパクトである（つまり、それらが大きな数値範囲に及ばない）場合に、どのTRILLスイッチがどのVLAN IDのフォワーダーとして指定するかを示すTRILLスイッチの効率的な方法を提供します。そのような予定は、予定するTRILLスイッチがDRBである場合にのみ有効です。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV 17.
o タイプ：APPsub-TLVタイプ。AppointmentBitmapsub-TLV 17に設定します。
o Length: 4 + size of bit map in bytes. If Length is less than 4, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：4 +バイト単位のビットマップのサイズ。長さが4未満の場合、APPsub-TLVは破損しているため、無視する必要があります。
o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder.
o Appointee Nickname：フォワーダーとして任命されているTRILLスイッチのニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Starting VLAN ID: The smallest VLAN ID to which the bits in the Bit Map correspond.
o 開始VLAN ID：ビットマップのビットが対応する最小のVLAN ID。
o Bit Map: A bit map of the VLANs for which the TRILL switch with Appointee Nickname is appointed as the forwarder. The size of the bit map is length minus 4. If the size of the bit map is zero, no appointments are made.
o ビットマップ：Appointee Nicknameを持つTRILLスイッチがフォワーダーとして指定されているVLANのビットマップ。ビットマップのサイズは、長さから4を引いたものです。ビットマップのサイズがゼロの場合、予約は行われません。
Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field. Bit 1 is for that VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and VLAN 0xFFF, or any larger ID, are invalid and are ignored.
ビットマップの各ビットは、VLAN IDに対応しています。ビット0は、開始VLAN IDフィールドにIDが表示されるVLAN用です。ビット1は、そのVLAN IDに1を加えたもの（VLAN IDを符号なし整数として扱う）などであり、ビットNは通常、開始VLAN IDにNを加えたものです。VLAN0x000およびVLAN 0xFFF、またはそれより大きいIDは無効であり、無視されます。
If the AppointmentBitmap APPsub-TLV is originated by the DRB on a link, it appoints the TRILL switch whose nickname appears in the Appointee Nickname field for the VLAN IDs corresponding to 1 bits in the Bit Map and revokes any Hello appointment of that TRILL switch for VLANs corresponding to 0 bits in the Bit Map.
AppointmentBitmap APPsub-TLVがリンク上のDRBによって発信された場合、そのニックネームがビットマップの1ビットに対応するVLAN IDのAppointee Nicknameフィールドに表示されるTRILLスイッチを指定し、そのTRILLスイッチのHelloアポイントメントを取り消します。ビットマップの0ビットに対応するVLAN。
The AppointmentList APPsub-TLV provides a convenient method for a TRILL switch to indicate which TRILL switches it appoints as forwarders for which VLAN IDs. Such an appointment is only effective when the appointing TRILL switch is the DRB.
AppointmentList APPsub-TLVは、どのTRILLスイッチがどのVLAN IDのフォワーダーとして指定するかを示すTRILLスイッチの便利な方法を提供します。そのような予定は、予定するTRILLスイッチがDRBである場合にのみ有効です。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to AppointmentList sub-TLV 18.
o タイプ：APPsub-TLVタイプ。AppointmentListsub-TLV 18に設定します。
o Length: 2 + 2 * k. If Length is not an even number, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：2 + 2 * k。 Lengthが偶数でない場合、APPsub-TLVは破損しているため、無視する必要があります。
o Appointee Nickname: The nickname of the TRILL switch being appointed as forwarder.
o Appointee Nickname：フォワーダーとして任命されているTRILLスイッチのニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o VLAN ID: A 12-bit VLAN ID for which the appointee is being appointed as the forwarder.
o VLAN ID：アポイント先がフォワーダーとして任命されている12ビットのVLAN ID。
Type and Length are 2 bytes, because these are extended FS-LSPs.
タイプと長さは、拡張FS-LSPであるため、2バイトです。
This APPsub-TLV, when originated by the DRB, appoints the TRILL switch with Appointee Nickname to be the Appointed Forwarder for the VLAN IDs listed.
このAPPsub-TLVは、DRBによって開始された場合、リストされたVLAN IDの指定フォワーダーとして、Appointee Nicknameを使用してTRILLスイッチを指定します。
The FGL-VLAN-Bitmap APPsub-TLV provides a method for a TRILL switch to indicate mappings of FGLs to VLAN IDs that it is configured to perform when egressing and ingressing native frames.
FGL-VLAN-ビットマップAPPsub-TLVは、TRILLスイッチが、ネイティブフレームを出入りするときに実行するように構成されているVLAN IDへのFGLのマッピングを示す方法を提供します。
The coding is efficient when both of the following apply:
次の両方が当てはまる場合、コーディングは効率的です。
- the VLAN IDs are compact (that is, they do not span a large numeric range), and
- VLAN IDはコンパクトです（つまり、数値範囲が広くありません）。
- the FGLs and VLAN IDs are paired in a monotonically increasing fashion.
- FGLとVLAN IDは単調に増加する方法でペアになっています。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV 19.
o タイプ：APPsub-TLVタイプ。VLAN-FGL-Bitmapsub-TLV 19に設定します。
o Length: 5 + size of bit map in bytes. If Length is less than 5, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：5 +ビットマップのサイズ（バイト単位）。長さが5未満の場合、APPsub-TLVは破損しているため、無視する必要があります。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Starting VLAN ID: Initial VLAN ID for the mapping information as discussed below.
o 開始VLAN ID：以下で説明するように、マッピング情報の初期VLAN ID。
o Starting FGL: Fine-Grained Label [RFC7172].
o FGLの開始：細粒度ラベル[RFC7172]。
o Bit Map: Map of bits for VLAN-ID-to-FGL mappings. The size of the bit map is Length minus 5. If the size of the bit map is zero, no mappings are indicated.
o ビットマップ：VLAN-ID-to-FGLマッピングのビットのマップ。ビットマップのサイズは、Lengthから5を引いたものです。ビットマップのサイズがゼロの場合、マッピングは示されません。
Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. Bit 0 is for the VLAN whose ID appears in the Starting VLAN ID field and the Fine-Grained Label that appears in the FGL field. Bit 1 is for that VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as unsigned integers) and so on, with Bit N generally being Starting VLAN ID plus N and FGL plus N.
ビットマップの各ビットは、VLAN IDとFGLに対応しています。ビット0は、開始VLAN IDフィールドにIDが表示されるVLANと、FGLフィールドに表示される細粒度ラベル用です。ビット1は、そのVLAN IDプラス1とそのFGLプラス1（VLAN IDとFGLを符号なし整数として扱う）などのためのもので、通常、ビットNは開始VLAN IDプラスNとFGLプラスNです。
If a Bit Map bit is a 1, it indicates that the advertising TRILL switch will map between the corresponding VLAN ID and FGL on ingressing native frames and egressing TRILL Data packets if it is Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does not indicate any configured mapping of the VLAN ID to the FGL. However, VLAN ID 0x000 and VLAN ID 0xFFF or any larger ID are invalid, and FGLs larger than 0xFFFFFF are invalid; any Bit Map bits that correspond to an illegal VLAN ID or an illegal FGL are ignored.
ビットマップビットが1の場合、それは、VLANのAppointed Forwarderである場合、アドバタイズTRILLスイッチが入力ネイティブフレームと出力TRILLデータパケットの対応するVLAN IDとFGLの間でマッピングすることを示します。ビットマップビットが0の場合、それはVLAN IDのFGLへの構成済みマッピングを示していません。ただし、VLAN ID 0x000およびVLAN ID 0xFFFまたはそれ以上のIDは無効であり、0xFFFFFFより大きいFGLは無効です。不正なVLAN IDまたは不正なFGLに対応するビットマップビットは無視されます。
The FGL-VLAN-Pairs APPsub-TLV provides a method for a TRILL switch to indicate a list of the mappings of FGLs to VLAN IDs that it is configured to perform when egressing and ingressing native frames.
FGL-VLAN-Pairs APPsub-TLVは、TRILLスイッチが、ネイティブフレームの出力および入力時に実行するように構成されているVLAN IDへのFGLのマッピングのリストを示す方法を提供します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 1 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 2 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD k | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
Where a Mapping RECORD has the following structure:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV 20.
o タイプ：APPsub-TLVタイプ、VLAN-FGL-Pairs sub-TLV 20に設定。
o Length: 5 * k. If Length is not a multiple of 5, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：5 * k。長さが5の倍数でない場合、APPsub-TLVは破損しているため、無視する必要があります。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o VLAN ID: 12-bit VLAN label.
o VLAN ID：12ビットVLANラベル。
o FGL: Fine-Grained Label [RFC7172].
o FGL：きめの細かいラベル[RFC7172]。
Each Mapping RECORD indicates that the originating TRILL switch is configured to map between the FGL and VLAN given on egressing and ingressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF are invalid; any Mapping RECORD that corresponds to an illegal VLAN ID is ignored.
各マッピングRECORDは、発信側TRILLスイッチが、出力および入力ネイティブフレームで指定されたFGLとVLANの間でマッピングするように構成されていることを示しています。ただし、VLAN ID 0x000およびVLAN ID 0xFFFは無効です。不正なVLAN IDに対応するマッピングRECORDは無視されます。
This document primarily adds optional enhancements or optimizations. The only configuration parameters specified in this document are the number and frequency of copies of Port-Shutdown messages sent, as specified in Section 6.6.
このドキュメントでは、主にオプションの拡張機能または最適化を追加しています。このドキュメントで指定されている唯一の構成パラメータは、セクション6.6で指定されているように、送信されたPort-Shutdownメッセージのコピーの数と頻度です。
TRILL switch support of SNMPv3 is provided in the TRILL base protocol document [RFC6325]. MIBs have been specified in [RFC6850] and [RFC7784], but they do not include the configurable parameters specified herein. It is anticipated that YANG modules will be specified for TRILL.
SNMPv3のTRILLスイッチサポートは、TRILLベースプロトコルドキュメント[RFC6325]で提供されています。 MIBは[RFC6850]と[RFC7784]で指定されていますが、ここに指定されている構成可能なパラメータは含まれていません。 YANGモジュールがTRILL用に指定される予定です。
[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, <http://ieeexplore.ieee.org/ servlet/opac?punumber=6991460>.
[802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ブリッジおよびブリッジネットワーク」、IEEE Std 802.1Q-2014、DOI 10.1109 / ieeestd.2014.6991462、<http://ieeexplore.ieee.org/ servlet / opac？punumber = 6991460>。
[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)", November 2002.
[IS-IS] ISO / IEC 10589：2002、第2版、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システムから中間システムへのドメイン内ルーティング交換プロトコル」、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.
[RFC6329] Fedyk、D。、編、Ashwood-Smith、P。、編、Allan、D.、Bragg、A、およびP. Unbehagen、「IEEE 802.1aq最短パスブリッジングをサポートするIS-IS拡張」、 RFC 6329、DOI 10.17487 / RFC6329、2012年4月、<http://www.rfc-editor.org/info/rfc6329>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<http://www.rfc-editor.org/info/rfc7177>。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、DOI 10.17487 / RFC7178、2014年5月、<http://www.rfc-editor.org/info/rfc7178>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-IS Flooding Scope Link State PDU（LSPs）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// www。 rfc-editor.org/info/rfc7356>。
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<http://www.rfc-editor.org/info/rfc7357>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>.
[RFC7978] Eastlake 3rd、D.、Umair、M。、およびY. Li、「Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Header Extension」、RFC 7978、DOI 10.17487 / RFC7978、2016年9月、<http： //www.rfc-editor.org/info/rfc7978>。
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>.
[RFC7981] Ginsberg、L.、Previdi、S。、およびM. Chen、「IS-IS Extensions for Advertising Router Information」、RFC 7981、DOI 10.17487 / RFC7981、2016年10月、<http：//www.rfc-editor .org / info / rfc7981>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A.、and F. Hu、 "Routing Bridges（RBridges）：Appointed Forwarders"、RFC 6439、DOI 10.17487 / RFC6439、November 2011、 <http://www.rfc-editor.org/info/rfc6439>。
[RFC6850] Rijhsinghani, A. and K. Zebrose, "Definitions of Managed Objects for Routing Bridges (RBridges)", RFC 6850, DOI 10.17487/RFC6850, January 2013, <http://www.rfc-editor.org/info/rfc6850>.
[RFC6850] Rijhsinghani、A。およびK. Zebrose、「ルーティングブリッジ（RBridges）の管理対象オブジェクトの定義」、RFC 6850、DOI 10.17487 / RFC6850、2013年1月、<http://www.rfc-editor.org/info / rfc6850>。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントとリンクの多くの透過的相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標」 "、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<http://www.rfc-editor.org/info/rfc7379>。
[RFC7784] Kumar, D., Salam, S., and T. Senevirathne, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB", RFC 7784, DOI 10.17487/RFC7784, February 2016, <http://www.rfc-editor.org/info/rfc7784>.
[RFC7784] Kumar、D.、Salam、S。、およびT. Senevirathne、「多数のリンクの透過的な相互接続（TRILL）操作、管理、および保守（OAM）MIB」、RFC 7784、DOI 10.17487 / RFC7784、2016年2月、<http://www.rfc-editor.org/info/rfc7784>。
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であると見なします。RB2からのHelloを確認しても優先度が高いためRB1、RB1からのHelloを確認できないためRB2が最高の優先度であると見なします。
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 that 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がVLAN 2および3のAppointed Forwarderとして機能することを選択し、RB2がVLAN 3および4のAppointed Forwarderとして機能することを選択したとします。VLAN2および4には問題はありませんが、何もしなければ、 VLAN 3を含むループ。RB1は、VLAN 3でRB2が発行するHelloを確認し、それ自体がAppointed Forwarderを宣言するため、RB3でRB1は禁止されます。RB2は、VLAN 3のRB1によって発行されたHelloを確認できないため、RB2は非禁止になり、 VLAN 3ネイティブトラフィックを処理します。
However, this situation may change. RB2 might crash, the bridge might crash, 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 for 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のAppointed Forwarderとして機能しなくなったり、その他の問題が発生する可能性があります。したがって、RB1はVLAN 3抑制タイマーを維持する必要があり、リンク上の他のRBridgeからのVLAN 3のAppointed Forwarderであると主張するHelloが十分に長い間見られない場合、RB1はポートのそのVLANに対して抑制されなくなりますVLAN 3でエンドステーショントラフィックを処理できます。
Assume that RBridges RB1 and RB2 have ports P1 and P2, respectively, that are both on Link L1 and that RBridges RB3 and RB4 have ports P3 and P4, respectively, that are both on Link L2. Assume further that P1 and P3 are Appointed Forwarders for VLAN-x and P2 and P4 are Appointed Forwarders for VLAN-y. This situation is shown in the figure below.
RBridge RB1とRB2にそれぞれリンクL1にあるポートP1とP2があり、RBridges RB3とRB4にそれぞれリンクL2にあるポートP3とP4があると仮定します。さらに、P1とP3はVLAN-xの指定フォワーダーであり、P2とP4はVLAN-yの指定フォワーダーであると想定します。この状況を次の図に示します。
+ - - - - - - - - - - - - - - - - - - - - - +
| |
| TRILL network |
| |
| +---+ +---+ +---+ +---+ |
+ -|RB1|- -|RB2|- - - - - - -|RB3|- -|RB4|- +
+---+ +---+ +---+ +---+
P1| P2| P3| P4|
| | | |
|x |y |x |y
| +-+ | | +-+ |
L1 ---+---|M|---+--+--- L2 ---+---|M|---+---
+-+ | +-+
+---+
|ES1|
+---+
Further assume that L1 and L2 are each bridged LANs that include a device M, presumably a bridge, that maps VLAN-x into VLAN-y and VLAN-y into VLAN-x.
さらに、L1とL2はそれぞれ、デバイスM（おそらくブリッジ）を含むブリッジLANであり、VLAN-xをVLAN-yに、VLAN-yをVLAN-xにマッピングするとします。
If end station ES1 originated a broadcast or other multi-destination frame in VLAN-y, it would be ingressed by RB2. (The frame would also be mapped to VLAN-x and ingressed by RB1, but we initially ignore that.) RB2 will flood the resulting TRILL Data packet through the campus, and, at least in the broadcast and unknown unicast cases, it will get to RB4, where it will be egressed to L2. Inside L2, this broadcast frame is mapped to VLAN-x and then ingressed by RB3. RB3 then floods the resulting TRILL Data packet through the campus, this time with an Inner.VLAN of VLAN-x, as a result of which it will be egressed by RB1 into L1. Inside L1, it will be mapped back to VLAN-y and then ingressed by RB2, completing the loop. The packet will loop indefinitely, because in native form on L1 and L2 it has no TRILL Hop Count, and an indefinitely large number of copies will be delivered to ES1 and any other end station so situated. The same problem would occur even if P1 and P2 were on the same RBridge and/or P3 and P4 were on the same RBridge. Actually, because the original frame was also mapped to VLAN-x inside L1 and ingressed by RB1, there are two copies looping around in opposite directions.
エンドステーションES1がVLAN-yでブロードキャストまたは他のマルチ宛先フレームを発信した場合、それはRB2によって入力されます。 （フレームもVLAN-xにマップされ、RB1によって入力されますが、最初は無視します。）RB2は、キャンパスを介して結果のTRILLデータパケットをフラッディングし、少なくともブロードキャストおよび不明なユニキャストの場合は、 L2に出力されるRB4に。 L2内では、このブロードキャストフレームはVLAN-xにマッピングされ、RB3から入力されます。次に、RB3は、結果のTRILLデータパケットをキャンパスを通してフラッディングします。今回はVLAN-xのInner.VLANを使用します。その結果、RB1からL1に送信されます。 L1内では、VLAN-yにマッピングされて戻り、RB2から入り、ループを完了します。パケットは無期限にループします。これは、L1およびL2のネイティブ形式ではTRILLホップカウントがなく、ES1およびそのように配置されている他のエンドステーションに無制限に多数のコピーが配信されるためです。 P1とP2が同じRBridgeにある場合や、P3とP4が同じRBridgeにある場合でも、同じ問題が発生します。実際、元のフレームもL1内のVLAN-xにマッピングされ、RB1によって入力されたため、2つのコピーが反対方向にループしています。
The use of Fine-Grained Labels [RFC7172] complicates but does not essentially change the potential problem.
きめの細かいラベル[RFC7172]の使用は複雑化しますが、潜在的な問題を本質的に変更するものではありません。
This example shows why VLAN mapping between Appointed Forwarder ports on a TRILL link is loop unsafe. When such a situation is detected, the DRB on the link changes Appointed Forwarders as necessary to assure that a single RBridge port is Appointed Forwarder for all VLANs involved in mapping. This change makes the situation loop safe.
この例は、TRILLリンク上のAppointed Forwarderポート間のVLANマッピングがループセーフでない理由を示しています。このような状況が検出されると、リンク上のDRBは必要に応じてAppointed Forwarderを変更し、マッピングに関与するすべてのVLANに対して単一のRBridgeポートがAppointed Forwarderになるようにします。この変更により、状況ループが安全になります。
Appendix C. Changes to RFCs 6325, 6439, and 7177
付録C. RFC 6325、6439、および7177の変更
This document updates [RFC6325], obsoletes [RFC6439], and updates [RFC7177].
このドキュメントは[RFC6325]を更新し、[RFC6439]を廃止し、[RFC7177]を更新します。
The change to [RFC6325], the TRILL base protocol, is as follows:
TRILL基本プロトコルである[RFC6325]への変更は次のとおりです。
Addition of mandatory support for E-L1CS FS-LSPs.
E-L1CS FS-LSPの必須サポートの追加。
Changes to [RFC6439], which this document obsoletes, are as follows:
このドキュメントで廃止された[RFC6439]への変更は次のとおりです。
1. Specification of APPsub-TLVs and procedures to be used in E-L1CS FS-LSP forwarder appointments.
1. E-L1CS FS-LSPフォワーダーの予定で使用されるAPPsub-TLVと手順の仕様。
2. Incorporation of updates to [RFC6439] that appeared in Section 10 of RFC 7180, which has been obsoleted by [RFC7780]. They appear primarily in Section 4 of this document.
2. [RFC7780]によって廃止された、RFC 7180のセクション10にある[RFC6439]への更新の組み込み。それらは主にこのドキュメントのセクション4に表示されます。
3. Addition of an optional FGL-VLAN consistency check feature, including specification of APPsub-TLVs.
3. APPsub-TLVの仕様を含む、オプションのFGL-VLAN整合性チェック機能の追加。
4. Deletion of references to the October 2011 version of the document "RBridges: Campus VLAN and Priority Regions" (draft-ietf-trill-rbridge-vlan-mapping), which has been dropped by the TRILL WG.
4. 2011年10月版のドキュメント「RBridges：Campus VLAN and Priority Regions」（draft-ietf-trill-rbridge-vlan-mapping）への参照の削除。これはTRILL WGによって削除されました。
5. Addition of the Port-Shutdown message.
5. Port-Shutdownメッセージの追加。
6. Elimination of the requirement that the DRB not send appointments in Hellos until its DRB inhibition timer has expired. This was an unnecessary safety precaution that is pointless, given that appointments in E-L1CS FS-LSPs are immediately visible.
6. DRB禁止タイマーが期限切れになるまで、HelloでDRBがアポイントメントを送信しないという要件の排除。 E-L1CS FS-LSPの予定がすぐに表示されることを考えると、これは無意味な不要な安全対策でした。
7. Addition of three optional methods (Section 3.2) to optimize (reduce) inhibition time under various circumstances.
7. さまざまな状況下で抑制時間を最適化（削減）するための3つのオプションメソッド（セクション3.2）の追加。
8. Editorial changes.
8. 編集上の変更。
Changes to [RFC7177] are as follows:
[RFC7177]の変更点は次のとおりです。
As provided in Section 6, TRILL switches SHOULD treat the reception of a Port-Shutdown RBridge Channel message from RB1 listing port P1 as if it were an event A3 as specified in [RFC7177], resulting in transition of any adjacency to P1 to the Detect state.
セクション6で提供されているように、TRILLスイッチは、ポートP1をリストするRB1からのポートシャットダウンRBridge Channelメッセージの受信を、[RFC7177]で指定されているイベントA3であるかのように処理する必要があります。これにより、隣接からP1への遷移が検出されます。状態。
Acknowledgments
謝辞
The following are hereby thanked for their contributions to this document:
以下は、このドキュメントへの貢献に感謝します。
Spencer Dawkins, Shawn M. Emery, Stephen Farrell, Joel Halpern, Sue Hares, Christer Holmberg, Gayle Noble, Alvaro Retana, Dan Romascanu, and Mingui Zhang.
スペンサードーキンス、ショーンM.エメリー、スティーブンファレル、ジョエルハルパーン、スーヘアズ、クリスターホルムバーグ、ゲイルノーブル、アルバロレタナ、ダンローマスカヌ、ミンギチャン。
The following are thanked for their contributions to [RFC6439], the predecessor to this document:
以下は、この文書の前身である[RFC6439]への貢献に感謝します。
Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan Romascanu, and Mike Shand.
ロンボニカ、スチュワートブライアント、リンダダンバー、レジンスバーグ、エリックノードマーク、ダンロマスカヌ、マイクシャンド。
We also thank Radia Perlman, who coauthored [RFC6439].
また、[RFC6439]を共著したRadia Perlmanにも感謝します。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Mohammed Umair IP Infusion
Mohammed Umair IP輸液
Email: mohammed.umair2@ipinfusion.com
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国
Phone: +1-408-333-7149
Email: ayabaner@cisco.com
Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China
ファンGは胡ZT E株式会社889 BIボーロード上海201203中国
Phone: +86-21-68896273
Email: hu.fangwei@zte.com.cn