[要約] 要約： RFC 7180は、TRILL（Transparent Interconnection of Lots of Links）プロトコルに関する説明、修正、更新を提供しています。目的： RFC 7180の目的は、TRILLプロトコルの実装や運用に関する誤解や問題を解決し、より明確な指針を提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7180 M. Zhang
Updates: 6325, 6327, 6439 Huawei
Category: Standards Track A. Ghanwani
ISSN: 2070-1721 Dell
V. Manral
Ionos Corp.
A. Banerjee
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
多数のリンクの透過的な相互接続（TRILL）：明確化、修正、および更新
Abstract
概要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data 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 this by using Intermediate System to Intermediate System (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
IETFのたくさんのリンクの透過的相互接続（TRILL）プロトコルは、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークでの構成なしに、最小コストのペアワイズデータ転送を提供し、一時的なループの期間でも安全に転送し、両方のマルチパスをサポートします。ユニキャストおよびマルチキャストトラフィック。 TRILLは、Intermediate System to Intermediate System（IS-IS）リンクステートルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを実現します。 2011年7月にTRILLベースプロトコルが公開されて以来、TRILLの活発な開発により、RFC 6325のエラッタと、説明や更新を使用できるいくつかのケースが明らかになりました。
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439.
RFC 6327および6439は、隣接関係およびAppointed Forwarderに関する説明と更新を提供しています。このドキュメントでは、RFC 6325、6327、および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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7180.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7180で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Precedence .................................................4
1.2. Changes That Are Not Backward Compatible ...................4
1.3. Terminology and Acronyms ...................................5
2. Overloaded and/or Unreachable RBridges ..........................5
2.1. Reachability ...............................................6
2.2. Distribution Trees .........................................6
2.3. Overloaded Receipt of TRILL Data Frames ....................7
2.3.1. Known Unicast Receipt ...............................7
2.3.2. Multi-Destination Receipt ...........................7
2.4. Overloaded Origination of TRILL Data Frames ................7
2.4.1. Known Unicast Origination ...........................7
2.4.2. Multi-Destination Origination .......................8
2.4.2.1. An Example Network .........................8
2.4.2.2. Indicating OOMF Support ....................9
2.4.2.3. Using OOMF Service .........................9
3. Distribution Trees .............................................10
3.1. Number of Distribution Trees ..............................10
3.2. Clarification of Distribution Tree Updates ................10
3.3. Multicast Pruning Based on IP Address .....................10
3.4. Numbering of Distribution Trees ...........................11
3.5. Link Cost Directionality ..................................11
4. Nickname Selection .............................................11
5. MTU (Maximum Transmission Unit) ................................13
5.1. MTU-Related Errata in RFC 6325 ............................13
5.1.1. MTU PDU Addressing .................................14
5.1.2. MTU PDU Processing .................................14
5.1.3. MTU Testing ........................................14
5.2. Ethernet MTU Values .......................................15
6. Port Modes .....................................................15
7. The CFI/DEI Bit ................................................16
8. Graceful Restart ...............................................17
9. Updates to RFC 6327 ............................................17
10. Updates on Appointed Forwarders and Inhibition ................18
10.1. Optional TRILL Hello Reduction ...........................18
10.2. Overload and Appointed Forwarders ........................20
11. IANA Considerations ...........................................21
12. Security Considerations .......................................21
13. Acknowledgements ..............................................21
14. References ....................................................22
14.1. Normative References .....................................22
14.2. Informative References ...................................23
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] provides optimal pair-wise 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 this by using Intermediate System to Intermediate System (IS-IS) [IS-IS] [RFC1195] [RFC7176] link-state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs (Virtual Local Area Networks) and optimization of the distribution of multi-destination frames based on VLANs and IP derived multicast groups.
多くのリンクのIETF透過的相互接続（TRILL）プロトコル[RFC6325]は、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークでの構成なしで、最適なペアワイズデータフレーム転送、一時的なループの期間中も安全な転送、およびマルチパスのサポートを提供しますユニキャストとマルチキャストの両方のトラフィックの。 TRILLは、Intermediate System to Intermediate System（IS-IS）[IS-IS] [RFC1195] [RFC7176]リンクステートルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを実現します。この設計は、VLAN（仮想ローカルエリアネットワーク）と、VLANおよびIP派生マルチキャストグループに基づく複数宛先フレームの配信の最適化をサポートしています。
In the years since the TRILL base protocol [RFC6325] was published, active development of TRILL has revealed five errors in the specification [RFC6325] and cases that could use clarifications or updates.
TRILLベースプロトコル[RFC6325]が公開されてから数年、TRILLの活発な開発により、仕様[RFC6325]の5つのエラーと、説明または更新を使用する可能性のあるケースが明らかになりました。
[RFC6327] and [RFC6439] provide clarifications with respect to Adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to [RFC6325], [RFC6327], and [RFC6439].
[RFC6327]と[RFC6439]は、隣接関係とAppointed Forwarderに関する説明を提供します。このドキュメントは、[RFC6325]、[RFC6327]、および[RFC6439]に対するその他の既知の明確化、修正、および更新を提供します。
In case of conflict between this document and any of [RFC6325], [RFC6327], or [RFC6439], this document takes precedence. In addition, Section 1.2 (Normative Content and Precedence) of [RFC6325] is updated to provide a more complete precedence ordering of the sections of [RFC6325] as following, where sections to the left take precedence over sections to their right:
このドキュメントと[RFC6325]、[RFC6327]、または[RFC6439]のいずれかとの間に矛盾がある場合、このドキュメントが優先されます。さらに、[RFC6325]のセクション1.2（規範的な内容と優先順位）が更新され、[RFC6325]のセクションのより完全な優先順位が次のように提供されます。ここで、左側のセクションが右側のセクションよりも優先されます。
4 > 3 > 7 > 5 > 2 > 6 > 1
The change made by Section 3.4 below is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes.
以下のセクション3.4で行われた変更は、[RFC6325]との下位互換性はありませんが、トポロジの変更に起因する配布ツリーの変更を減らすために採用されています。
The several other changes herein that are fixes to errata for [RFC6325] -- [Err3002] [Err3003] [Err3004] [Err3052] [Err3053] [Err3508] -- may not be backward compatible with previous implementations that conformed to errors in the specification.
[RFC6325]のエラッタに対する修正である他のいくつかの変更点-[Err3002] [Err3003] [Err3004] [Err3052] [Err3053] [Err3508]-のエラーに準拠していた以前の実装との下位互換性がない可能性があります仕様。
This document uses the acronyms defined in [RFC6325] and the following acronyms and terms:
このドキュメントでは、[RFC6325]で定義されている頭字語と、次の頭字語および用語を使用しています。
CFI - Canonical Format Indicator [802]
CFI-正規フォーマットインジケーター[802]
DEI - Drop Eligibility Indicator [802.1Q-2011]
DEI-適格性指標の削除[802.1Q-2011]
EISS - Enhanced Internal Sublayer Service
EISS-拡張内部サブレイヤーサービス
OOMF - Overload Originated Multi-destination Frame
OOMF-過負荷の発信元マルチ宛先フレーム
TRILL Switch - An alternative name for an RBridge
TRILLスイッチ-RBridgeの別名
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
RBridges may be in overload as indicated by the [IS-IS] overload flag in their LSPs (Link State PDUs). This means that either (1) they are incapable of holding the entire link-state database and thus do not have a view of the entire topology or (2) they have been configured to have the overload bit set. Although networks should be engineered to avoid actual link-state overload, it might occur under various circumstances. For example, if a large campus included one or more low-end TRILL Switches.
RBridgeは、LSP（リンク状態PDU）の[IS-IS]過負荷フラグによって示されるように過負荷になっている可能性があります。つまり、（1）リンク状態データベース全体を保持することができず、トポロジ全体を表示できないか、（2）過負荷ビットが設定されるように構成されているかのいずれかです。実際のリンク状態の過負荷を回避するようにネットワークを設計する必要がありますが、さまざまな状況で発生する可能性があります。たとえば、大規模なキャンパスに1つ以上のローエンドTRILLスイッチが含まれている場合です。
It is a common operational practice to set the overload bit in an [IS-IS] router (such as an RBridge) when performing maintenance on that router that might affect its ability to correctly forward frames; this will usually leave the router reachable for maintenance traffic, but transit traffic will not be routed through it. (Also, in some cases, TRILL provides for setting the overload bit in the pseudonode of a link to stop TRILL Data traffic on an access link (see Section 4.9.1 of [RFC6325]).)
[IS-IS]ルーター（RBridgeなど）でフレームを正しく転送する機能に影響を与える可能性のあるメンテナンスを実行するときに、そのルーターに過負荷ビットを設定するのが一般的な運用方法です。これにより、通常、ルータはメンテナンストラフィックに到達可能になりますが、トランジットトラフィックはルーティングされません。 （また、場合によっては、TRILLはリンクの疑似ノードで過負荷ビットを設定して、アクセスリンク上のTRILLデータトラフィックを停止することを提供します（[RFC6325]のセクション4.9.1を参照）。）
[IS-IS] and TRILL make a reasonable effort to do what they can even if some RBridges/routers are in overload. They can do reasonably well if a few scattered nodes are in overload. However, actual least-cost paths are no longer assured if any RBridges are in overload.
[IS-IS]とTRILLは、一部のRBridges /ルーターが過負荷になっている場合でも、できることを実行するために合理的な努力をします。散在するいくつかのノードが過負荷になっている場合、それらはかなりうまく機能します。ただし、RBridgeが過負荷の場合、実際の最小コストのパスは保証されなくなります。
For the effect of overload on the appointment of forwarders, see Section 10.2.
フォワーダーの任命に対する過負荷の影響については、セクション10.2を参照してください。
In this Section 2, the term "neighbor" refers only to actual RBridges and ignores pseudonodes.
このセクション2では、「ネイバー」という用語は実際のRBridgeのみを指し、疑似ノードを無視します。
Frames are not least-cost routed through an overloaded TRILL Switch, although they may originate or terminate at an overloaded TRILL Switch. In addition, frames will not be least-cost routed over links with cost 2**24 - 1 [RFC5305]; such links are reserved for traffic-engineered frames, the handling of which is beyond the scope of this document.
フレームは過負荷のTRILLスイッチを介してルーティングされる最小コストではありませんが、過負荷のTRILLスイッチで発生または終了する場合があります。さらに、フレームはコストが2 ** 24-1 [RFC5305]のリンクを介してルーティングされる最小コストにはなりません。このようなリンクはトラフィックエンジニアリングされたフレーム用に予約されており、その処理はこのドキュメントの範囲外です。
As a result, a portion of the campus may be unreachable for least-cost routed TRILL Data because all paths to it would be through a link with cost 2**24 - 1 or through an overloaded RBridge. For example, an RBridge RB1 is not reachable by TRILL Data if all of its neighbors are connected to RB1 by links with cost 2**24 - 1. Such RBridges are called "data unreachable".
その結果、最小コストのルーティングTRILLデータではキャンパスの一部に到達できない可能性があります。これは、キャンパスへのすべてのパスがコスト2 ** 24-1のリンクまたは過負荷のRBridgeを経由するためです。たとえば、RBridge RB1は、そのすべてのネイバーがコスト2 ** 24-1のリンクによってRB1に接続されている場合、TRILL Dataから到達できません。そのようなRBridgeは「データ到達不能」と呼ばれます。
The link-state database at an RBridge RB1 can also contain information on TRILL Switches that are unreachable by IS-IS link-state flooding due to link or RBridge failures. When such failures partition the campus, the TRILL Switches adjacent to the failure and on the same side of the failure as RB1 will update their LSPs to show the lack of connectivity, and RB1 will receive those updates. As a result, RB1 will be aware of the partition. Nodes on the far side of the partition are both IS-IS unreachable and data unreachable. However, LSPs held by RB1 for TRILL Switches on the far side of the failure will not be updated and may stay around until they time out, which could be tens of minutes or longer. (The default in [IS-IS] is twenty minutes.)
RBridge RB1のリンクステートデータベースには、リンクまたはRBridgeの障害が原因でIS-ISリンクステートフラッディングによって到達できないTRILLスイッチに関する情報も含まれる場合があります。このような障害によってキャンパスが分割されると、障害に隣接し、障害の同じ側にあるTRILLスイッチが、RB1がLSPを更新して接続の欠如を示し、RB1がそれらの更新を受信します。その結果、RB1はパーティションを認識します。パーティションの反対側のノードは、IS-ISに到達できず、データに到達できません。ただし、障害の反対側にあるTRILLスイッチのRB1によって保持されているLSPは更新されず、タイムアウトするまで数十分以上かかる場合があります。 （[IS-IS]のデフォルトは20分です。）
An RBridge in overload cannot be trusted to correctly calculate distribution trees or correctly perform the RPFC (Reverse-Path Forwarding Check). Therefore, it cannot be trusted to forward multi-destination TRILL Data frames. It can only appear as a leaf node in a TRILL multi-destination distribution tree. Furthermore, if all the immediate neighbors of an RBridge are overloaded, then it is omitted from all trees in the campus and is unreachable by multi-destination frames.
過負荷のRBridgeは、配布ツリーを正しく計算したり、RPFC（Reverse-Path Forwarding Check）を正しく実行したりするために信頼できません。したがって、マルチ宛先TRILLデータフレームを転送することは信頼できません。これは、TRILL複数宛先配布ツリーのリーフノードとしてのみ表示できます。さらに、RBridgeのすべての隣接ノードが過負荷の場合、キャンパス内のすべてのツリーから除外され、複数の宛先のフレームから到達できなくなります。
When an RBridge determines what nicknames to use as the roots of the distribution trees it calculates, it MUST ignore all nicknames held by TRILL Switches that are in overload or are data unreachable. When calculating RPFCs for multi-destination frames, an RBridge RB1 MAY, to avoid calculating unnecessary RPF check state, ignore any trees that cannot reach to RB1 even if other RBridges list those trees as trees that other TRILL Switches might use. (But see Section 3.)
RBridgeが、計算する分散ツリーのルートとして使用するニックネームを決定するとき、過負荷状態にある、またはデータに到達できないTRILLスイッチが保持するすべてのニックネームを無視する必要があります。複数の宛先フレームのRPFCを計算する場合、RBridge RB1は、不要なRPFチェック状態の計算を回避するために、他のRBridgeが他のTRILLスイッチが使用するツリーとしてそれらのツリーをリストしていても、RB1に到達できないツリーを無視します。 （しかし、セクション3を参照してください。）
The receipt of TRILL Data frames by overloaded RBridge RB2 is discussed in the subsections below. In all cases, the normal Hop Count decrement is performed, and the TRILL Data frame is discarded if the result is less than one or if the egress nickname is illegal.
過負荷のRBridge RB2によるTRILLデータフレームの受信については、以下のサブセクションで説明します。すべての場合において、通常のホップカウントの減分が実行され、結果が1未満の場合、または出力ニックネームが不正な場合、TRILLデータフレームは破棄されます。
RB2 will not usually receive unicast TRILL Data frames unless it is the egress, in which case it decapsulates and delivers the frames normally. If RB2 receives a unicast TRILL Data frame for which it is not the egress, perhaps because a neighbor does not yet know it is in overload, RB2 MUST NOT discard the frame because the egress is an unknown nickname as it might not know about all nicknames due to its overloaded condition. If any neighbor, other than the neighbor from which it received the frame, is not overloaded, it MUST attempt to forward the frame to one of those neighbors. If there is no such neighbor, the frame is discarded.
RB2は、それが出力である場合を除き、通常はユニキャストTRILLデータフレームを受信しません。その場合、フレームはカプセル化を解除され、通常どおり配信されます。 RB2が出力ではないユニキャストTRILLデータフレームを受信した場合、おそらくネイバーが過負荷状態であることをまだ認識していないため、RB2はフレームを破棄してはなりません。出力はすべてのニックネームを知らない可能性があるため不明なニックネームであるためです過負荷状態のため。フレームを受信したネイバー以外のネイバーが過負荷でない場合、それらのネイバーの1つにフレームを転送する必要があります。そのようなネイバーがない場合、フレームは破棄されます。
If RB2 in overload receives a multi-destination TRILL Data frame, RB2 MUST NOT apply an RPFC since, due to overload, it might not do so correctly. RB2 decapsulates and delivers the frame locally where it is Appointed Forwarder for the frame's VLAN, subject to any multicast pruning. But since, as stated above, RB2 can only be the leaf of a distribution tree, it MUST NOT forward a multi-destination TRILL Data frame (except as an egressed native frame where RB2 is Appointed Forwarder).
過負荷のRB2が複数の宛先のTRILLデータフレームを受信する場合、RB2はRPFCを適用してはなりません。これは、過負荷のために正しく行われない可能性があるためです。 RB2はフレームをカプセル化解除し、ローカルでフレームのVLANのAppointed Forwarderに配信します。マルチキャストプルーニングの影響を受けます。ただし、上記のように、RB2は配布ツリーのリーフにしかなり得ないため、マルチ宛先TRILLデータフレームを転送してはなりません（RB2がAppointed Forwarderである出力ネイティブフレームを除く）。
Overloaded origination of unicast frames with known egress and of multi-destination frames are discussed in the subsections below.
既知の出力を備えたユニキャストフレームと複数の宛先フレームの過負荷発生については、以下のサブセクションで説明します。
When an overloaded RBridge RB2 ingresses or creates a known destination unicast TRILL Data frame, it delivers it locally if the destination Media Access Control (MAC) is local. Otherwise, RB2 unicasts it to any neighbor TRILL Switch that is not overloaded. It MAY use what routing information it has to help select the neighbor.
過負荷のRBridge RB2は、既知の宛先ユニキャストTRILLデータフレームを入力または作成するときに、宛先のメディアアクセス制御（MAC）がローカルである場合、それをローカルに配信します。それ以外の場合、RB2は、過負荷になっていない近隣のTRILLスイッチにユニキャストします。ネイバーの選択に役立つルーティング情報を使用する場合があります。
Overloaded RBridge RB2 ingressing or creating a multi-destination TRILL Data frame is more complex than for a known unicast frame.
マルチデスティネーションTRILLデータフレームを入力または作成する過負荷のRBridge RB2は、既知のユニキャストフレームよりも複雑です。
For example, consider the network below in which, for simplicity, end stations and any bridges are not shown. There is one distribution tree of which RB4 is the root; it is represented by double lines. Only RBridge RB2 is overloaded.
たとえば、以下のネットワークを考えます。ここでは、簡単にするために、エンドステーションとブリッジは表示されていません。 RB4をルートとする配布ツリーが1つあります。二重線で表されます。 RBridge RB2のみが過負荷です。
+-----+ +-----+ +-----+ +-----+
| RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
+-----+ +--+--+ +-++--+ +--+--|
| || |
+---+---+ || |
+------+RB2(ov)|======++ |
| +-------+ || |
| || |
+--+--+ +-----+ ++==++=++ +--+--+
| RB8 +=====+ RB6 +==++ RB4 ++=====+ RB9 |
+-----+ +-----+ ++=====++ +-----+
Since RB2 is overloaded, it does not know what the distribution tree or trees are for the network. Thus, there is no way it can provide normal TRILL Data encapsulation for multi-destination native frames. So RB2 tunnels the frame to a neighbor that is not overloaded if it has such a neighbor that has signaled that it is willing to offer this service. RBridges indicate this in their Hellos as described below. This service is called OOMF (Overload Originated Multi-destination Frame) service.
RB2は過負荷になっているため、ネットワークの配信ツリーが何であるかはわかりません。したがって、複数の宛先のネイティブフレームに通常のTRILLデータカプセル化を提供する方法はありません。したがって、RB2は、このサービスを提供する用意があることを通知したネイバーがいる場合、過負荷にならないネイバーにフレームをトンネルします。 RBridgeは、以下に説明するように、Helloでこれを示します。このサービスは、OOMF（過負荷発信マルチ宛先フレーム）サービスと呼ばれます。
- The multi-destination frame MUST NOT be locally distributed in native form at RB2 before tunneling to a neighbor because this would cause the frame to be delivered twice. For example, if RB2 locally distributed a multicast native frame and then tunneled it to RB5, RB2 would get a copy of the frame when RB3 transmitted it as a TRILL Data frame on the multi-access RB2-RB3-RB4 link. Since RB2 would, in general, not be able to tell that this was a frame it had tunneled for distribution, RB2 would decapsulate it and locally distribute it a second time.
- 複数の宛先フレームは、ネイバーにトンネリングする前にRB2でネイティブ形式でローカルに配布してはなりません。これは、フレームが2回配信される原因となるためです。たとえば、RB2がマルチキャストネイティブフレームをローカルに配布し、それをRB5にトンネリングした場合、RB2は、RB3がマルチアクセスRB2-RB3-RB4リンクでTRILLデータフレームとして送信したときに、フレームのコピーを取得します。 RB2は、一般に、これが配布のためにトンネリングされたフレームであることを認識できないため、カプセル化を解除し、2回目にローカルに配布します。
- On the other hand, if there is no neighbor of RB2 offering RB2 the OOMF service, RB2 cannot tunnel the frame to a neighbor. In this case, RB2 MUST locally distribute the frame where it is Appointed Forwarder for the frame's VLAN and optionally subject to multicast pruning.
- 一方、RB2にOOMFサービスを提供するRB2のネイバーがない場合、RB2はフレームをネイバーにトンネリングできません。この場合、RB2は、フレームのVLANのAppointed Forwarderであるフレームをローカルに配布しなければならず、オプションでマルチキャストプルーニングの対象となります。
An RBridge RB3 indicates its willingness to offer the OOMF service to RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit associated with the SNPA (Subnetwork Point of Attachment, also known as MAC address) of RB2 on the link. (See Section 11.) Overloaded RBridge RB2 can only distribute multi-destination TRILL Data frames to the campus if a neighbor of RB2 not in overload offers RB2 the OOMF service. If RB2 does not have OOMF service available to it, RB2 can still receive multi-destination frames from non-overloaded neighbors and, if RB2 should originate or ingress such a frame, it distributes it locally in native form.
RBridge RB3は、リンク上のRB2のSNPA（サブネットワーク接続点、MACアドレスとも呼ばれる）に関連付けられたビットを設定することにより、RB3のTRILL HellosのTRILL Neighbor TLVのRB2にOOMFサービスを提供する意思を示します。 （セクション11を参照。）過負荷のRBridge RB2は、過負荷になっていないRB2のネイバーがRBMFにOOMFサービスを提供している場合のみ、複数の宛先のTRILLデータフレームをキャンパスに配信できます。 RB2がOOMFサービスを利用できない場合でも、RB2は過負荷でないネイバーから複数の宛先フレームを受信でき、RB2がそのようなフレームを発信または入力する必要がある場合は、ネイティブ形式でローカルに配信します。
If RB2 sees this OOMF (Overload Originated Multi-destination Frame) service advertised for it by any of its neighbors on any link to which RB2 connects, it selects one such neighbor by a means beyond the scope of this document. Assuming RB2 selects RB3 to handle multi-destination frames it originates, RB2 MUST advertise in its LSP that it might use any of the distribution trees that RB3 advertises so that the RPFC will work in the rest of the campus. Thus, notwithstanding its overloaded state, RB2 MUST retain this information from RB3 LSPs, which it will receive as it is directly connected to RB3.
RB2は、RB2が接続する任意のリンク上のネイバーのいずれかによってアドバタイズされたこのOOMF（Overload Originated Multi-Destination Frame）サービスを見ると、このドキュメントの範囲を超えた方法でそのようなネイバーを1つ選択します。 RB2がRB3を選択して、それが発信するマルチ宛先フレームを処理すると仮定すると、RB2は、RP3がアドバタイズする配信ツリーのいずれかを使用する可能性があることをLSPでアドバタイズし、RPFCがキャンパスの残りの部分で機能するようにする必要があります。したがって、その過負荷状態にもかかわらず、RB2は、RB3に直接接続されているときに受信するRB3 LSPからのこの情報を保持する必要があります。
RB2 then encapsulates such frames as TRILL Data frames to RB3 as follows: M bit = 0, Hop Count = 2, ingress nickname = a nickname held by RB2, and, since RB2 cannot tell what distribution tree RB3 will use, egress nickname = a special nickname indicating an OOMF frame (see Section 11). RB2 then unicasts this TRILL Data frame to RB3. (Implementation of Item 4 in Section 4 below provides reasonable assurance that, notwithstanding its overloaded state, the ingress nickname used by RB2 will be unique within at least the portion of the campus that is IS-IS reachable from RB2.)
次に、RB2はTRILLデータフレームなどのフレームを次のようにRB3にカプセル化します。Mビット= 0、ホップカウント= 2、入力ニックネーム= RB2が保持するニックネーム、RB2はRB3が使用する配布ツリーを通知できないため、出力ニックネーム= a OOMFフレームを示す特別なニックネーム（セクション11を参照）。次に、RB2はこのTRILLデータフレームをRB3にユニキャストします。 （以下のセクション4の項目4の実装は、その過負荷状態にもかかわらず、RB2によって使用される入力ニックネームが、少なくともRB2からIS-ISが到達可能なキャンパスの部分内で一意であることを合理的に保証します。）
On receipt of such a frame, RB3 does the following:
このようなフレームを受信すると、RB3は次のことを行います。
- changes the Egress Nickname field to designate a distribution tree that RB3 normally uses, - sets the M bit to one, - changes the Hop Count to the value it would normally use if it were the ingress, and - forwards the frame on that tree.
- 出力ニックネームフィールドを変更して、RB3が通常使用する配布ツリーを指定し、Mビットを1に設定し、ホップカウントを入力の場合に通常使用する値に変更し、そのツリーのフレームを転送します。
RB3 MAY rate limit the number of frames for which it is providing this service by discarding some such frames from RB2. The provision of even limited bandwidth for OOMFs by RB3, perhaps via the slow path, may be important to the bootstrapping of services at RB2 or at end stations connected to RB2, such as supporting DHCP and ARP/ND (Address Resolution Protocol / Neighbor Discovery). (Everyone sometimes needs a little OOMF (pronounced "oomph") to get off the ground.)
RB3は、RB2からこのようなフレームを破棄することにより、このサービスを提供するフレームの数をレート制限する場合があります。おそらく低速パスを介した、RB3によるOOMFの限られた帯域幅の提供も、RB2またはRB2に接続されたエンドステーションでのサービスのブートストラップに重要である可能性があります。 ）。 （誰もが地面から降りるために、少しOOMF（発音は "oomph"）を必要とする場合があります。）
Two corrections, a clarification, and two updates related to distribution trees appear in the subsections below. See also Section 2.2.
2つの修正、説明、および配布ツリーに関連する2つの更新が、以下のサブセクションに表示されます。セクション2.2も参照してください。
In [RFC6325], Section 4.5.2, page 56, Point 2, 4th paragraph, the parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052]. It should read "(up to k if j is zero or the minimum of (j, k) if j is non-zero)".
[RFC6325]、セクション4.5.2、56ページ、ポイント2、4番目の段落で、括弧（「最大{j、k}まで）」は正しくありません[Err3052]。 「（jがゼロの場合はkまで、jがゼロ以外の場合は（j、k）の最小値）」と表示されます。
When a link-state database change causes a change in the distribution tree(s), there are several possibilities. If a tree root remains a tree root but the tree changes, then local forwarding and RPFC entries for that tree should be updated as soon as practical. Similarly, if a new nickname becomes a tree root, forwarding and RPFC entries for the new tree should be installed as soon as practical. However, if a nickname ceases to be a tree root and there is sufficient room in local tables, the forwarding and RPFC entries for the former tree MAY be retained so that any multi-destination TRILL Data frames already in flight on that tree have a higher probability of being delivered.
リンク状態データベースの変更によって配布ツリーが変更される場合、いくつかの可能性があります。ツリールートはツリールートのままですが、ツリーが変更された場合は、そのツリーのローカル転送とRPFCエントリをできるだけ早く更新する必要があります。同様に、新しいニックネームがツリールートになる場合は、新しいツリーの転送およびRPFCエントリをできるだけ早くインストールする必要があります。ただし、ニックネームがツリールートでなくなり、ローカルテーブルに十分なスペースがある場合は、元のツリーの転送エントリとRPFCエントリが保持されるため、そのツリーですでに処理中のすべての複数宛先TRILLデータフレームの方が高くなります。配信される確率。
The TRILL base protocol specification [RFC6325] provides for and recommends the pruning of multi-destination frame distribution trees based on the location of IP multicast routers and listeners; however, multicast listening is identified by derived MAC addresses as communicated in the Group MAC Address sub-TLV [RFC7176].
TRILLベースプロトコル仕様[RFC6325]は、IPマルチキャストルーターとリスナーの場所に基づいて、マルチ宛先フレーム分散ツリーのプルーニングを提供および推奨しています。ただし、マルチキャストリスニングは、グループMACアドレスサブTLV [RFC7176]で伝達される派生MACアドレスによって識別されます。
TRILL Switches MAY communicate multicast listeners and prune distribution trees based on the actual IPv4 or IPv6 multicast addresses involved. Additional Group Address sub-TLVs are provided in [RFC7176] to carry this information. A TRILL Switch that is only capable of pruning based on derived MAC address SHOULD calculate and use such derived MAC addresses from multicast listener IPv4/IPv6 address information it receives.
TRILLスイッチは、関係する実際のIPv4またはIPv6マルチキャストアドレスに基づいて、マルチキャストリスナーとプルーニング配布ツリーを通信する場合があります。 [RFC7176]には、この情報を伝えるための追加のグループアドレスサブTLVが用意されています。派生MACアドレスに基づいてプルーニングのみが可能なTRILLスイッチは、受信したマルチキャストリスナーIPv4 / IPv6アドレス情報からそのような派生MACアドレスを計算して使用する必要があります（SHOULD）。
Section 4.5.1 of [RFC6325] specifies that, when building distribution tree number j, node (RBridge) N that has multiple possible parents in the tree is attached to possible parent number j mod p. Trees are numbered starting with 1, but possible parents are numbered starting with 0. As a result, if there are two trees and two possible parents, in tree 1, parent 1 will be selected, and in tree 2, parent 0 will be selected.
[RFC6325]のセクション4.5.1は、配布ツリー番号jを構築するときに、ツリー内に複数の可能な親を持つノード（RBridge）Nが、可能な親番号j mod pに接続されることを指定しています。ツリーには1から番号が付けられますが、可能な親には0から番号が付けられます。その結果、2つのツリーと2つの可能な親がある場合、ツリー1では親1が選択され、ツリー2では親0が選択されます。 。
This is changed so that the selected parent MUST be (j-1) mod p. As a result, in the case above, tree 1 will select parent 0, and tree 2 will select parent 1. This change is not backward compatible with [RFC6325]. If all RBridges in a campus do not determine distribution trees in the same way, then for most topologies, the RPFC will drop many multi-destination frames before they have been properly delivered.
これは、選択された親が（j-1）mod pでなければならないように変更されます。その結果、上記の場合、ツリー1は親0を選択し、ツリー2は親1を選択します。この変更は、[RFC6325]との下位互換性がありません。キャンパス内のすべてのRBridgeが配布ツリーを同じ方法で決定しない場合、ほとんどのトポロジでは、RPFCは多数の複数宛先フレームをドロップしてから、それらを正しく配信します。
Distribution tree construction, like other least-cost aspects of TRILL, works even if link costs are asymmetric, so the cost of the hop from RB1 to RB2 is different from the cost of the hop from RB2 to RB1. However, it is essential that all RBridges calculate the same distribution trees, and thus, all must either use the cost away from the tree root or the cost towards the tree root. As corrected in [Err3508], the text in Section 4.5.1 of [RFC6325] is incorrect. It says:
TRILLの他の最小コストの側面と同様に、配信ツリーの構築は、リンクコストが非対称であっても機能するため、RB1からRB2へのホップのコストは、RB2からRB1へのホップのコストとは異なります。ただし、すべてのRBridgeが同じ分散ツリーを計算することが不可欠であり、したがって、すべてがツリールートから離れたコストまたはツリールートに向かうコストを使用する必要があります。 [Err3508]で修正されているように、[RFC6325]のセクション4.5.1のテキストは正しくありません。それは言う：
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from N to R and ...
言い換えると、RをルートとするツリーのNの潜在的な親のセットは、NからRおよび...
but the text should say "from R to N":
しかし、テキストは「RからNへ」と言う必要があります。
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from R to N and ...
言い換えると、RをルートとするツリーのNの潜在的な親のセットは、RからNまでのコストパスが等しく最小になる親で構成されます。
Nickname selection is covered by Section 3.7.3 of [RFC6325]. However, the following should be noted:
ニックネームの選択は、[RFC6325]のセクション3.7.3でカバーされています。ただし、次の点に注意してください。
1. The second sentence in the second bullet item in Section 3.7.3 of [RFC6325] on page 25 is erroneous [Err3002] and is corrected as follows: o The occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
1. 25ページの[RFC6325]のセクション3.7.3の2番目の箇条書きの2番目の文は誤っており、[Err3002]が次のように修正されています。o「IS-IS ID（LAN ID）」の出現箇所は"優先"。
o The occurrence of "IS-IS System ID" is replaced with "seven-byte IS-IS ID (LAN ID)".
o 「IS-ISシステムID」は「7バイトのIS-IS ID（LAN ID）」に置き換えられます。
The resulting corrected sentence in [RFC6325] reads as follows:
[RFC6325]の結果の修正された文は次のようになります。
If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher priority keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher seven-byte IS-IS ID (LAN ID) keeps the nickname, and the other RBridge MUST select a new nickname.
RB1がニックネームxを選択し、RB1が後でRB2のLSPを受信することにより、RB2もxを選択したことを発見した場合、数値がより高い優先度を持つRBridgeまたは疑似ノードがニックネームを保持するか、同点がある場合優先順位、数値が大きい7バイトのIS-IS ID（LAN ID）を持つRBridgeはニックネームを保持し、他のRBridgeは新しいニックネームを選択する必要があります。
2. In examining the link-state database for nickname conflicts, nicknames held by IS-IS unreachable TRILL Switches MUST be ignored, but nicknames held by IS-IS reachable TRILL Switches MUST NOT be ignored even if they are data unreachable.
2. ニックネームの競合についてリンク状態データベースを検査する場合、IS-IS到達不能TRILLスイッチが保持するニックネームは無視する必要がありますが、IS-IS到達可能TRILLスイッチが保持するニックネームは、データが到達不能であっても無視してはなりません。
3. An RBridge may need to select a new nickname, either initially because it has none or because of a conflict. When doing so, the RBridge MUST consider as available all nicknames that do not appear in its link-state database or that appear to be held by IS-IS unreachable TRILL Switches; however, it SHOULD give preference to selecting new nicknames that do not appear to be held by any TRILL Switch in the campus, reachable or unreachable, so as to minimize conflicts if IS-IS unreachable TRILL Switches later become reachable.
3. RBridgeは、最初はニックネームがないか、競合しているため、新しいニックネームを選択する必要がある場合があります。その場合、RBridgeは、リンク状態データベースに表示されない、またはIS-IS到達不能TRILLスイッチによって保持されているように見えるすべてのニックネームを使用可能と見なす必要があります。ただし、IS-IS到達不能TRILLスイッチが後で到達可能になった場合の競合を最小限にするために、キャンパス内のTRILLスイッチによって保持されていないように見える、到達可能または到達不可能な新しいニックネームを選択することを優先する必要があります。
4. An RBridge, even after it has acquired a nickname for which there appears to be no conflicting claimant, MUST continue to monitor for conflicts with the nickname or nicknames it holds. It does so by checking in LSP PDUs it receives that should update its link-state database for the following: any occurrence of any of its nicknames held with higher priority by some other TRILL Switch that is IS-IS reachable from it. If it finds such a conflict, it MUST select a new nickname, even when in overloaded state. (It is possible to receive an LSP that should update the link-state database but does not due to overload.)
4. RBridgeは、競合する要求者がないと思われるニックネームを取得した後でも、保持している1つまたは複数のニックネームとの競合を監視し続ける必要があります。受信するLSP PDUをチェックインすることで、リンク状態データベースを更新します。ニックネームは、IS-ISから到達可能な他のTRILLスイッチによってより高い優先度で保持されているニックネームの発生です。そのような競合が見つかった場合は、オーバーロード状態であっても、新しいニックネームを選択する必要があります。 （リンク状態データベースを更新する必要があるが、過負荷ではないLSPを受信する可能性があります。）
5. In the very unlikely case that an RBridge is unable to obtain a nickname because all valid RBridge nicknames (0x0001 through 0xFFBF inclusive) are in use with higher priority by IS-IS reachable TRILL Switches, it will be unable to act as an ingress, egress, or tree root but will still be able to function as a transit TRILL Switch. Although it cannot be a tree root, such an RBridge is included in distribution trees computed for the campus unless all its neighbors are overloaded. It would not be possible to send a unicast RBridge Channel message specifically to such a TRILL Switch [RFC7178]; however, it will receive unicast Channel messages sent by a neighbor to the Any-RBridge egress nickname and will receive appropriate multi-destination Channel messages.
5.すべての有効なRBridgeニックネーム（0x0001から0xFFBFまでを含む）がIS-IS到達可能TRILLスイッチによってより高い優先度で使用されているため、RBridgeがニックネームを取得できないという非常にまれなケースでは、イングレスとして機能できません。 、出力、またはツリーのルートですが、トランジットTRILLスイッチとして機能できます。ツリールートにすることはできませんが、そのようなRBridgeは、近隣のすべてが過負荷にならない限り、キャンパスに対して計算された分散ツリーに含まれます。特にそのようなTRILLスイッチ[RFC7178]にユニキャストRBridge Channelメッセージを送信することはできません。ただし、ネイバーからAny-RBridge出力ニックネームに送信されたユニキャストチャネルメッセージを受信し、適切な複数宛先チャネルメッセージを受信します。
MTU values in TRILL key off the originatingL1LSPBufferSize value communicated in the IS-IS originatingLSPBufferSize TLV [IS-IS]. The campus-wide value Sz, as described in Section 4.3.1 of [RFC6325], is the minimum value of originatingL1LSPBufferSize for the RBridges in a campus, but not less than 1470. The MTU testing mechanism and limiting LSPs to Sz assures that the LSPs can be flooded by IS-IS and thus that IS-IS can operate properly.
IS-IS originatingLSPBufferSize TLV [IS-IS]で伝達されたoriginatingL1LSPBufferSize値からTRILLキーのMTU値。 [RFC6325]のセクション4.3.1で説明されているキャンパス全体の値Szは、キャンパス内のRBridgeのoriginatingL1LSPBufferSizeの最小値ですが、1470以上です。MTUテストメカニズムとLSPをSzに制限することで、 LSPはIS-ISによってフラッディングされる可能性があるため、そのIS-ISは適切に動作できます。
If nothing is known about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, the originatingL1LSPBufferSize for an RBridge should default to the minimum of the LSP size that its TRILL IS-IS software can handle and the minimum MTU of the ports that it might use to receive or transmit LSPs. If an RBridge does have knowledge of link MTUs or other RBridge originatingL1LSPBufferSize, then, to avoid the necessity to regenerate the local LSPs using a different maximum size, the RBridge's originatingL1LSPBufferSize SHOULD be configured to the minimum of (1) the smallest value that other RBridges are or will be announcing as their originatingL1LSPBufferSize and (2) a value small enough that the campus will not partition due to a significant number of links with limited MTU. However, as provided in [RFC6325], in no case can originatingL1LSPBufferSize be less than 1470. In a well-configured campus, to minimize any LSP regeneration due to re-sizing, it is desirable for all RBridges to be configured with the same originatingL1LSPBufferSize.
リンクのMTUまたはキャンパス内の他のRBridgeのoriginatingL1LSPBufferSizeについて何もわかっていない場合、RBridgeのoriginatingL1LSPBufferSizeは、そのTRILL IS-ISソフトウェアが処理できるLSPサイズとポートの最小MTUの最小値にデフォルト設定する必要がありますLSPの受信または送信に使用される可能性があります。 RBridgeがリンクMTUまたは他のRBridge originatingL1LSPBufferSizeの知識を持っている場合、別の最大サイズを使用してローカルLSPを再生成する必要を回避するために、RBridgeのoriginatingL1LSPBufferSizeは、他のRBridgeの最小値（1）の最小値に設定する必要があります（SHOULD）。それらはoriginatingL1LSPBufferSizeおよび（2）限定されたMTUを持つ多数のリンクが原因でキャンパスが分割されないほど小さい値であるか、または発表される予定です。ただし、[RFC6325]で規定されているように、originatingL1LSPBufferSizeを1470未満にすることはできません。適切に構成されたキャンパスでは、サイズ変更によるLSPの再生成を最小限に抑えるため、すべてのRBridgeを同じoriginatingL1LSPBufferSizeで構成することが望ましい。
Section 5.1 below corrects errata in [RFC6325], and Section 5.2 clarifies the meaning of various MTU limits for TRILL Ethernet links.
以下のセクション5.1は[RFC6325]のエラッタを修正し、セクション5.2はTRILLイーサネットリンクのさまざまなMTU制限の意味を明確にします。
Three MTU-related errata in [RFC6325] are corrected in the subsections below.
[RFC6325]の3つのMTU関連のエラッタは、以下のサブセクションで修正されています。
Section 4.3.2 of [RFC6325] incorrectly states that multi-destination MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links with the All-RBridges multicast address as the Outer.MacDA [Err3004]. As TRILL IS-IS PDUs, when multicast on an Ethernet link, they MUST be sent to the All-IS-IS-RBridges multicast address.
[RFC6325]のセクション4.3.2は、All-RBridgesマルチキャストアドレスがOuter.MacDA [Err3004]であるイーサネットリンク上で、マルチ宛先MTUプローブおよびMTU-ack TRILL IS-IS PDUが送信されると誤って述べています。 TRILL IS-IS PDUとして、イーサネットリンクでマルチキャストする場合、それらはAll-IS-IS-RBridgesマルチキャストアドレスに送信する必要があります。
As discussed in [RFC6325] and, in more detail, in [RFC6327], MTU-probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of [RFC6325] erroneously does not allow for this possibility [Err3003]. It is corrected by replacing Item numbered "1" in Section 4.6.2 of [RFC6325] with the following quoted text to which TRILL Switches MUST conform:
[RFC6325]で、より詳細には[RFC6327]で説明されているように、MTUプローブとMTU-ack PDUはユニキャストである場合があります。ただし、[RFC6325]のセクション4.6では、この可能性を誤って許可していません[Err3003]。 [RFC6325]のセクション4.6.2の「1」の番号が付いた項目を、TRILLスイッチが準拠する必要がある次の引用テキストに置き換えることで修正されています。
"1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either All-IS-IS-RBridges or the unicast MAC address of the receiving RBridge port, the frame is handled as described in Section 4.6.2.1"
「1. EthertypeがL2-IS-ISで、Outer.MacDAがAll-IS-IS-RBridgesまたは受信RBridgeポートのユニキャストMACアドレスの場合、フレームはセクション4.6.2.1で説明されているように処理されます。
The reference to "Section 4.6.2.1" in the above quoted text is to that section in [RFC6325].
上記の引用テキストの「セクション4.6.2.1」への参照は、[RFC6325]のそのセクションへの参照です。
The last two sentences of Section 4.3.2 of [RFC6325] have errors [Err3053]. They currently read:
[RFC6325]のセクション4.3.2の最後の2つの文にエラーがあります[Err3053]。彼らは現在読んでいます：
If X is not greater than Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
XがSz以下の場合、RB1はRB1のHelloでRB2の「失敗した最小MTUテスト」フラグを設定します。サイズXが成功し、X> Szの場合、RB1は、そのリンクでTRILL Hellos RB1が送信する隣接ごとにテストされた最大のXをアドバタイズし、RB1は、RB1のLSPのRB2へのリンクの属性としてXをアドバタイズできます（MAY）。
They should read:
彼らは読むべきです：
If X is not greater than or equal to Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X >= Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
XがSz以下の場合、RB1はRB1のHelloでRB2の「失敗した最小MTUテスト」フラグを設定します。サイズXが成功し、X> = Szの場合、RB1は、そのリンクでTRILL Hellos RB1が送信する隣接ごとにテストされた最大のXをアドバタイズし、RB1は、RB1のLSPのRB2へのリンクの属性としてXをアドバタイズできます（MAY）。
originatingL1LSPBufferSize is the maximum permitted size of LSPs starting with the 0x83 Intradomain Routeing Protocol Discriminator byte. In Layer 3 IS-IS, originatingL1LSPBufferSize defaults to 1492 bytes. (This is because, in its previous life as DECnet Phase V, IS-IS was encoded using the SNAP SAP (Subnetwork Access Protocol Service Access Point) [RFC7042] format, which takes 8 bytes of overhead and 1492 + 8 = 1500, the classic Ethernet maximum. When standardized by ISO/IEC [IS-IS] to use Logical Link Control (LLC) encoding, this default could have been increased by a few bytes but was not.)
originatingL1LSPBufferSizeは、0x83ドメイン内ルーティングプロトコルディスクリミネーターバイトで始まるLSPの最大許容サイズです。レイヤ3 IS-ISでは、originatingL1LSPBufferSizeのデフォルトは1492バイトです。 （これはDECnetフェーズVとしての以前の人生では、IS-ISは8バイトのオーバーヘッドと1492 + 8 = 1500を必要とするSNAP SAP（サブネットワークアクセスプロトコルサービスアクセスポイント）[RFC7042]形式を使用してエンコードされていたためです。クラシックイーサネットの最大値。論理リンク制御（LLC）エンコーディングを使用するようにISO / IEC [IS-IS]で標準化されている場合、このデフォルトは数バイト増加する可能性がありますが、増加しませんでした。）
In TRILL, originatingL1LSPBufferSize defaults to 1470 bytes. This allows 27 bytes of headroom or safety margin to accommodate legacy devices with the classic Ethernet maximum MTU despite headers such as an Outer.VLAN.
TRILLでは、originatingL1LSPBufferSizeのデフォルトは1470バイトです。これにより、27バイトのヘッドルームまたは安全マージンにより、Outer.VLANなどのヘッダーにもかかわらず、従来のイーサネット最大MTUを持つレガシーデバイスに対応できます。
Assuming the campus-wide minimum link MTU is Sz, RBridges on Ethernet links MUST limit most TRILL IS-IS PDUs so that PDUz (the length of the PDU starting just after the L2-IS-IS Ethertype and ending just before the Ethernet Frame Check Sequence (FCS)) does not to exceed Sz. The PDU exceptions are TRILL Hello PDUs, which MUST NOT exceed 1470 bytes, and MTU-probe and MTU-ack PDUs that are padded, depending on the size being tested (which may exceed Sz).
キャンパス全体の最小リンクMTUがSzであると仮定すると、イーサネットリンクのRBridgeは、ほとんどのTRILL IS-IS PDUを制限する必要があるため、PDUz（L2-IS-IS Ethertypeの直後から始まり、イーサネットフレームチェックの直前に終了するPDUの長さ）シーケンス（FCS））はSzを超えません。 PDUの例外は、1470バイトを超えてはならないTRILL Hello PDUと、テストされるサイズに応じてパディングされたMTUプローブPDUおよびMTU-ack PDUです（Szを超える場合があります）。
Sz does not limit TRILL Data frames. They are only limited by the MTU of the devices and links that they actually pass through; however, links that can accommodate IS-IS PDUs up to Sz would accommodate, with a generous safety margin, TRILL Data frame payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS. Most modern Ethernet equipment has ample headroom for frames with extensive headers and is sometimes engineered to accommodate 9K byte jumbo frames.
SzはTRILLデータフレームを制限しません。それらは、実際に通過するデバイスとリンクのMTUによってのみ制限されます。ただし、SzまでのIS-IS PDUに対応できるリンクは、Inner.VLANの後に始まり、FCSの直前に終了する（Sz-24）バイトのTRILLデータフレームペイロードに十分な安全マージンを提供します。最新のイーサネット機器のほとんどは、広範なヘッダーを持つフレーム用の十分なヘッドルームがあり、9Kバイトのジャンボフレームに対応するように設計されている場合があります。
Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports but may not be completely clear on the effects of various combinations of bits.
[RFC6325]のセクション4.9.1は、RBridgeポートの4つのモードビットを指定していますが、ビットのさまざまな組み合わせの影響について完全に明確ではない場合があります。
The table below explicitly indicates the effect of all possible combinations of the TRILL port mode bits. "*" in one of the first four columns indicates that the bit can be either zero or one. The following columns indicate allowed frame types. The Disable bit normally disables all frames, but, as an implementation choice, some or all low-level Layer 2 control frames (as specified in [RFC6325], Section 1.4) can still be sent or received.
以下の表は、TRILLポートモードビットのすべての可能な組み合わせの影響を明示的に示しています。最初の4列のうちの1つにある「*」は、ビットが0または1のいずれかであることを示します。次の列は、許可されるフレームタイプを示しています。通常、Disableビットはすべてのフレームを無効にしますが、実装の選択として、一部またはすべての低レベルレイヤー2コントロールフレーム（[RFC6325]、セクション1.4で指定）は引き続き送受信できます。
+-+-+-+-+--------+-------+-----+-----+-----+
|D| | | | | | | | |
|i| |A| | | |TRILL| | |
|s| |c|T| | |Data | | |
|a| |c|r| | | | | |
|b|P|e|u| |native | LSP | | |
|l|2|s|n|Layer 2 |ingress| SNP |TRILL| P2P |
|e|P|s|k|Control |egress | MTU |Hello|Hello|
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|0| Yes | Yes | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|0|1| Yes | No | Yes | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|0| Yes | Yes | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|0|1|1| Yes | No | No | Yes | No |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|0|*| Yes | No | Yes | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|0|1|1|*| Yes | No | No | No | Yes |
+-+-+-+-+--------+-------+-----+-----+-----+
|1|*|*|*|Optional| No | No | No | No |
+-+-+-+-+--------+-------+-----+-----+-----+
(The formal name of the "access bit" is the "TRILL traffic disable bit", and the formal name of the "trunk bit" is the "end-station service disable bit" [RFC6325].)
（「アクセスビット」の正式名は「TRILLトラフィック無効ビット」であり、「トランクビット」の正式名は「端末サービス無効ビット」です[RFC6325]。）
In May 2011, the IEEE promulgated [802.1Q-2011], which changes the meaning of the bit between the priority and VLAN ID bits in the payload of C-VLAN tags. Previously, this bit was called the CFI (Canonical Format Indicator) bit [802] and had a special meaning in connection with IEEE 802.5 (Token Ring) frames. Now, under [802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar to that bit in S-VLAN/B-VLAN tags where this bit has always been a DEI bit.
2011年5月、IEEEは[802.1Q-2011]を公布し、C-VLANタグのペイロードの優先度とVLAN IDビットの間のビットの意味を変更しました。以前は、このビットはCFI（Canonical Format Indicator）ビット[802]と呼ばれ、IEEE 802.5（トークンリング）フレームに関連して特別な意味がありました。現在、[802.1Q-2011]では、これはDEI（ドロップ適格性インジケータ）ビットであり、S-VLAN / B-VLANタグのビットと似ていますが、このビットは常にDEIビットでした。
The TRILL base protocol specification [RFC6325] assumed, in effect, that the link by which end stations are connected to TRILL Switches and the restricted virtual link provided by the TRILL Data frame are IEEE 802.3 Ethernet links on which the CFI bit is always zero. Should an end station be attached by some other type of link, such as a Token Ring link, [RFC6325] implicitly assumed that such frames would be canonicalized to 802.3 frames before being ingressed, and similarly, on egress, such frames would be converted from 802.3 to the appropriate frame type for the link. Thus, [RFC6325] required that the CFI bit in the Inner.VLAN, which is shown as the "C" bit in Section 4.1.1 of [RFC6325], always be zero.
TRILL基本プロトコル仕様[RFC6325]は、実際には、端末がTRILLスイッチに接続されるリンクとTRILLデータフレームによって提供される制限付き仮想リンクが、CFIビットが常にゼロであるIEEE 802.3イーサネットリンクであると想定しています。エンドステーションがトークンリングリンクなどの他のタイプのリンクによって接続されている場合、[RFC6325]は、そのようなフレームがイングレスされる前に802.3フレームに正規化されると暗黙的に想定し、同様に、出口では、そのようなフレームは802.3をリンクの適切なフレームタイプに変更します。したがって、[RFC6325]では、[RFC6325]のセクション4.1.1で「C」ビットとして示されているInner.VLANのCFIビットを常にゼロにする必要がありました。
However, for TRILL Switches with ports conforming to the change incorporated in the IEEE 802.1Q-2011 standard, the bit in the Inner.VLAN, now a DEI bit, MUST be set to the DEI value provided by the EISS (Enhanced Internal Sublayer Service) interface on ingressing a native frame. Similarly, this bit MUST be provided to the EISS when transiting or egressing a TRILL Data frame. As with the 3-bit Priority field, the DEI bit to use in forwarding a transit frame MUST be taken from the Inner.VLAN. The exact effect on the Outer.VLAN DEI and priority bits and whether or not an Outer.VLAN appears at all on the wire for output frames may depend on output port configuration.
ただし、IEEE 802.1Q-2011規格に組み込まれた変更に準拠したポートを備えたTRILLスイッチの場合、Inner.VLANのビット（現在のDEIビット）は、EISS（Enhanced Internal Sublayer Service）によって提供されるDEI値に設定する必要があります。 ）ネイティブフレームの入力に関するインターフェイス。同様に、このビットは、TRILLデータフレームを送信または送信するときにEISSに提供する必要があります。 3ビットの優先度フィールドと同様に、トランジットフレームの転送に使用するDEIビットは、Inner.VLANから取得する必要があります。 Outer.VLAN DEIと優先ビットへの正確な影響、およびOuter.VLANが出力フレームのワイヤーにまったく表示されるかどうかは、出力ポートの構成によって異なります。
TRILL campuses with a mixture of ports, some compliant with [802.1Q-2011] and some compliant with pre-802.1Q-2011 standards, especially if they have actual Token Ring links, may operate incorrectly and may corrupt data, just as a bridged LAN with such mixed ports and links would.
[802.1Q-2011]に準拠したポートと802.1Q-2011より前の標準に準拠したポートが混在するTRILLキャンパスは、特に実際のトークンリングリンクがある場合、ブリッジと同様に正しく動作せず、データが破損する可能性があります。このようなポートとリンクが混在するLANでは、
TRILL Switches SHOULD support the features specified in [RFC5306], which describes a mechanism for a restarting IS-IS router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating link-state database synchronization.
TRILLスイッチは、[RFC5306]で指定されている機能をサポートする必要があります。これは、再起動中のIS-ISルーターが再起動中であることをネイバーに通知し、ダウン状態を循環せずに隣接関係を再確立できるメカニズムを説明します。リンク状態データベースの同期。
[RFC6327] provides for multiple states of the potential adjacency between two TRILL Switches. It makes clear that only an adjacency in the "Report" state is reported in LSPs. LSP synchronization (LSP and Subnetwork Point (SNP) transmission and receipt), however, is performed if and only if there is at least one adjacency on the link in either the "2-Way" or "Report" state.
[RFC6327]は、2つのTRILLスイッチ間の潜在的な隣接の複数の状態を提供します。 「レポート」状態の隣接のみがLSPで報告されることは明らかです。ただし、LSP同期（LSPおよびサブネットワークポイント（SNP）の送信と受信）は、リンクに "双方向"または "レポート"状態の隣接が少なくとも1つある場合にのみ実行されます。
To support the PORT-TRILL-VER sub-TLV specified in [RFC7176], the following updates are made to [RFC6327]:
[RFC7176]で指定されているPORT-TRILL-VERサブTLVをサポートするために、[RFC6327]に対して次の更新が行われています。
1. The first sentence of the last paragraph in [RFC6327] Section 3.1 is modified from
1. [RFC6327]セクション3.1の最後の段落の最初の文は、
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, and Port ID, regardless of the VLAN in which the Hello is sent.
特定のポートのRBridgeによって発行されるすべてのTRILL LAN Helloは、Helloが送信されるVLANに関係なく、同じ送信元MACアドレス、優先度、必要な指定VLAN、およびポートIDを持つ必要があります。
to
と
All TRILL LAN Hellos issued by an RBridge on a particular port MUST have the same source MAC address, priority, desired Designated VLAN, Port ID, and PORT-TRILL-VER sub-TLV [RFC7176] if included, regardless of the VLAN in which the Hello is sent.
特定のポートのRBridgeによって発行されたすべてのTRILL LAN Helloは、含まれているVLANに関係なく、同じ送信元MACアドレス、優先度、必要な指定VLAN、ポートID、および含まれている場合はPORT-TRILL-VERサブTLV [RFC7176]を持つ必要がありますHelloが送信されます。
2. An additional bullet item is added to the end of Section 3.2 of [RFC6327] as follows:
2. [RFC6327]のセクション3.2の最後に、次のように追加の箇条書き項目が追加されます。
o The five bytes of PORT-TRILL-VER sub-TLV data received in the most recent TRILL Hello from the neighbor RBridge.
o ネイバーRBridgeから最新のTRILL Helloで受信した5バイトのPORT-TRILL-VERサブTLVデータ。
3. In Section 3.3 of [RFC6327], near the bottom of page 12, a bullet item as follows is added:
3. [RFC6327]のセクション3.3の12ページの下部近くに、次のような箇条書き項目が追加されています。
o The five bytes of PORT-TRILL-VER sub-TLV data are set from that sub-TLV in the Hello or set to zero if that sub-TLV does not occur in the Hello.
o 5バイトのPORT-TRILL-VERサブTLVデータは、HelloでそのサブTLVから設定されるか、HelloでそのサブTLVが発生しない場合はゼロに設定されます。
4. At the beginning of Section 4 of [RFC6327], a bullet item is added to the list as follows:
4. [RFC6327]のセクション4の冒頭で、箇条書きの項目が次のようにリストに追加されます。
o The five bytes of PORT-TRILL-VER sub-TLV data used in TRILL Hellos sent on the port.
o ポートで送信されるTRILL Helloで使用される5バイトのPORT-TRILL-VERサブTLVデータ。
An optional method of Hello reduction is specified in Section 10.1 below and a recommendation on forwarder appointments in the face of overload is given in Section 10.2.
Helloリダクションのオプションの方法は、以下のセクション10.1で指定されており、過負荷に直面した場合のフォワーダーのアポイントメントに関する推奨事項は、セクション10.2で提供されています。
If a network manager has sufficient confidence that it knows the configuration of bridges, ports, and the like, within a link, it may be able to reduce the number of TRILL Hellos sent on that link; for example, if all RBridges on the link will see all Hellos regardless of VLAN constraints, Hellos could be sent on fewer VLANs. However, because adjacencies are established in the Designated VLAN, an RBridge MUST always attempt to send Hellos in the Designated VLAN. Hello reduction makes TRILL less robust in the face of decreased VLAN connectivity in a link such as partitioned VLANs, many 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, 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 and no native frame end-station service is provided.)
ネットワーク管理者が、リンク内のブリッジ、ポートなどの構成を知っているという十分な自信がある場合、そのリンクで送信されるTRILL Helloの数を減らすことができる場合があります。たとえば、リンク上のすべてのRBridgeがVLANの制約に関係なくすべてのHelloを見る場合、Helloはより少ないVLANで送信される可能性があります。ただし、指定VLANで隣接関係が確立されているため、RBridgeは常に指定VLANでHelloを送信しようとする必要があります。 Hello削減により、パーティション化されたVLAN、多くのVLANがポートで無効になっている、または指定VLANでの不一致など、リンクのVLAN接続が減少した場合にTRILLの堅牢性が低下します。ただし、リンク上のすべてのRBridgeポートが同じ指定VLANに設定され、そのVLAN内の互いのフレームを確認でき、以下に指定されたメカニズムを利用してVLAN禁止タイマーを更新できる限り、操作は安全です。 （これらの考慮事項は、ポイントツーポイントとして構成されているRBridge間のリンクでは発生しません。その場合、各RBridgeはポイントツーポイントのHello、他のTRILL IS-IS PDU、およびTRILLデータフレームを送信します。はリンクの指定VLANであると考えられ、ネイティブフレームエンドステーションサービスは提供されません。
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 [RFC6439] is still required. Under Section 3 of [RFC6439], 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, thus extending Section 3, Item 4, of [RFC6439]. Two such mechanisms are specified below. Support for both of these mechanisms is indicated by a capability bit in the PORT-TRILL-VER sub-TLV (see Section 9 above and [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 [RFC6327]) indicate support of these mechanisms and these mechanisms are in use.
ときどきフレームが失われる、RBridgeの障害、リンクの障害、リンクで発生する新しいRBridgeなどに直面してもループの安全性を維持するには、[RFC6439]で指定されている抑制メカニズムが依然として必要です。 [RFC6439]のセクション3で、VLAN禁止タイマーは、そのVLANで送受信されたHelloを受信することによってのみ設定できます。したがって、少ない数のVLANで少ない数のTRILL Helloを安全に送信するには、RBridgeでVLAN禁止タイマーを設定する追加のメカニズムが必要で、[RFC6439]のセクション3、アイテム4を拡張します。そのような2つのメカニズムを以下に示します。これらのメカニズムの両方のサポートは、PORT-TRILL-VERサブTLVの機能ビットによって示されます（上記のセクション9および[RFC7176]を参照）。リンク上のすべての隣接関係（ダウン状態の[RFC6327]を除く）がこれらのメカニズムのサポートを示していない限り、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 Appointed Forwarder sub-TLV MUST be the same as the Sender Nickname in the Special VLANs and Flags sub-TLV in the TRILL Hello. This indicates the sending RBridge believes it is Appointed Forwarder for those VLANs. An RBridge receiving such a sub-TLV sets each of its VLAN inhibition timers for every VLAN in the block or blocks listed in the Appointed Forwarders sub-TLV to the maximum of its current value and the Holding Time of the Hello containing the sub-TLV. This is backward compatible because such sub-TLVs will have no effect on any receiving RBridge not implementing this mechanism unless RB2 is the DRB (Designated RBridge) sending Hello on the Designated VLAN, in which case, as specified in [RFC6439], RB2 MUST include in the Hello all forwarder appointments, if any, for RBridges other than itself on the link.
1. RBridge RB2は、1つ以上のVLANの範囲に自分自身を指定する任意のTRILL Hello Appointed Forwarders sub-TLV [RFC7176]に含めることができます（MAY）。 Appointed ForwarderサブTLVのAppointee Nicknameフィールドは、TRILL HelloのSpecial VLANs and FlagsサブTLVのSender Nicknameと同じでなければなりません。これは、送信RBridgeがそれらのVLANのAppointed Forwarderであると信じていることを示しています。そのようなサブTLVを受信するRBridgeは、Appointed ForwardersサブTLVにリストされているブロック内のすべてのVLANの各VLAN抑制タイマーを、現在の値とサブTLVを含むHelloの最大保持時間に設定します。これは下位互換性があります。RB2がDRB（指定RBridge）が指定VLANでHelloを送信しない限り、このメカニズムを実装していない受信RBridgeには影響がないため、この場合、[RFC6439]で指定されているように、RB2は必須です。 Helloに、リンク上の自分以外のRBridgeのすべてのフォワーダーの予定があれば含めます。
2. An RBridge MAY use the new 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 the maximum of its current value and the Holding Time of the TRILL Hello containing the VLANs Appointed sub-TLV. 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は、新しいVLAN Appointed sub-TLV [RFC7176]を使用してもよい（MAY）。 RB1は、任意のVLAN上のRB2からTRILL HelloでVLAN Appointed Sub-TLVを受信すると、RB2がそのサブTLVにリストするすべてのVLANのVLAN抑制タイマーを、RB2がAppointed ForwarderであるVLANとして更新します。そのような各タイマーは、現在の値の最大値と、VLANが指定したサブTLVを含むTRILL Helloの保持時間に更新されます。このサブTLVは、RBridgeが実装していない未知のサブTLVであり、そのようなRBridgeはそれを無視します。 DRBが指定VLANで送信するTRILL Helloに1つ以上のVLAN Appointed Sub-TLVが含まれている場合でも、Appointed ForwardersサブTLVが表示されない限り、Helloはすべてのフォワーダーの予定を示す必要はありません。
Two different encodings are providing 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 it is Appointed Forwarder for the VLAN in which the Hello is sent. 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 MUST be 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 it is Appointed Forwarder in a Hello sent on the Designated VLAN three times per Holding Time.
VLANのリストを最適化するために、上記の2つの異なるエンコーディングが提供されています。隣接するVLANの大きなブロックはAppointed ForwardersサブTLVでより効率的にエンコードされ、分散したVLANはVLAN AppointedサブTLVでより効率的にエンコードされます。これらのエンコーディングは、同じHelloに混在させることができます。これらのサブTLVの使用は、Helloが送信されるVLANのAppointed Forwarderであると元のRBridgeが判断した場合に、特別なVLANおよびフラグサブTLVの「AF」ビットを設定する必要があるという要件に影響しません。上記のメカニズムがリンクで使用されている場合、リンク上の各RBridgeは、1つ以上のVLANでHelloを送信する必要があります（そのようなVLANが指定されたサブTLVおよび/または自己指定の指定されたフォワーダーサブTLV）。 「AF」ビットは、3つ以上のHelloが失われない限り、VLAN抑制タイマーが不適切に期限切れにならないように適切に設定する必要があります。たとえば、RBridgeは、指定されたVLAN上で保持時間ごとに3回送信されるHelloでAppointed Forwarderであると考えるすべてのVLANをアナウンスすることができます。
An RBridge in overload (see Section 2) will, in general, do a poorer job of ingressing and forwarding frames than an RBridge not in overload that has full knowledge of the campus topology. For example, an overloaded RBridge may not be able to distribute multi-destination TRILL Data frames at all.
過負荷状態のRBridge（セクション2を参照）は、一般に、キャンパストポロジーを完全に把握している過負荷状態でないRBridgeよりも、フレームの入力と転送に不十分です。たとえば、過負荷のRBridgeは、複数の宛先のTRILLデータフレームをまったく配信できない場合があります。
Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an Appointed Forwarder unless there is no alternative. Furthermore, if an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign VLANs from the overloaded RBridge to another RBridge on the link that is not overloaded, if one is available. DRB election is not affected by overload.
したがって、DRBは、代替手段がない限り、過負荷のRBridgeをAppointed Forwarderとして指定しないでください（SHOULD NOT）。さらに、Appointed Forwarderが過負荷になった場合、DRBは、オーバーロードされたRBridgeから、オーバーロードされていないリンク上の別のRBridge（使用可能な場合）にVLANを再割り当てする必要があります（SHOULD）。 DRBの選択は過負荷の影響を受けません。
A counter-example would be if all campus end stations in VLAN-x were on links attached to RB1 via ports where VLAN-x was enabled. In such a case, RB1 SHOULD be made the VLAN-x Appointed Forwarder on all such links even if RB1 is overloaded.
反例は、VLAN-xのすべてのキャンパスエンドステーションが、VLAN-xが有効になっているポートを介してRB1に接続されたリンク上にある場合です。そのような場合、たとえRB1が過負荷になっていても、そのようなすべてのリンクでRB1をVLAN-x Appointed Forwarderにする必要があります（SHOULD）。
The following IANA actions have been completed.
次のIANAアクションが完了しました。
1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated for use in the TRILL Header Egress Nickname field to indicate an OOMF (Overload Originated Multi-destination Frame).
1. [RFC6325]によって予約されたニックネーム0xFFC1は、TRMFヘッダー出力ニックネームフィールドで使用するために割り当てられ、OOMF（過負荷発信マルチ宛先フレーム）を示します。
2. Bit 1 from the seven previously reserved (RESV) bits in the per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176] is allocated to indicate that the RBridge sending the TRILL Hello volunteers to provide the OOMF forwarding service described in Section 2.4.2 to such frames originated by the TRILL Switch whose SNPA (MAC address) appears in that Neighbor RECORD. The description of this bit is "Offering OOMF service".
2. TRILL Neighbor TLV [RFC7176]のネイバーごとの「Neighbor RECORD」の以前に予約された7つの（RESV）ビットのビット1は、TRILL Helloボランティアを送信するRBridgeがセクション2.4で説明するOOMF転送サービスを提供することを示すために割り当てられます.2 SNPA（MACアドレス）がそのNeighbor RECORDに現れるTRILLスイッチによって発信されたフレームへ。このビットの説明は、「OOMFサービスの提供」です。
3. Bit 0 is allocated from the Capability bits in the PORT-TRILL-VER sub-TLV [RFC7176] to indicate support of the VLANs Appointed sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms specified in Section 10.1. The description of this bit is "Hello reduction support".
3. ビット0は、PORT-TRILL-VERサブTLV [RFC7176]の機能ビットから割り当てられ、指定されたVLANのサブTLV [RFC7176]およびセクション10.1で指定されたVLAN禁止設定メカニズムのサポートを示します。このビットの説明は、「Helloリダクションサポート」です。
This memo improves the documentation of the TRILL protocol, corrects five errata in [RFC6325], and updates [RFC6325], [RFC6327], and [RFC6439]. It does not change the security considerations of these RFCs.
このメモは、TRILLプロトコルのドキュメントを改善し、[RFC6325]の5つのエラッタを修正し、[RFC6325]、[RFC6327]、および[RFC6439]を更新します。これらのRFCのセキュリティに関する考慮事項は変更されません。
The contributions of the following individuals are gratefully acknowledged: Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Mike Shand, Meral Shirazipour, and Varun Varshah.
Somnath Chatterjee、Weiguo Hao、Rakesh Kumar、Yizhou Li、Radia Perlman、Mike Shand、Meral Shirazipour、Varun Varshahの各個人の貢献に感謝します。
[802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q-2011] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q-2011、August 2011。
[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", Second Edition, November 2002.
[IS-IS]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システム間ドメイン内ルーティング情報交換プロトコル」、第2版、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, October 2008.
[RFC5306] Shand、M。、およびL. Ginsberg、「Restart Signaling for IS-IS」、RFC 5306、2008年10月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011.
[RFC6327] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Dutt、D.、and V. Manral、 "Routing Bridges（RBridges）：Adjacency"、RFC 6327、July 2011。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A。、およびF. Hu、「Routing Bridges（RBridges）：Appointed Forwarders」、RFC 6439、2011年11月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、May 2014。
[802] IEEE 802, "IEEE Standard for Local and metropolitan area networks: Overview and Architecture", IEEE Std 802.1-2001, 8 March 2002.
[802] IEEE 802、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：概要とアーキテクチャ」、IEEE Std 802.1-2001、2002年3月8日。
[Err3002] RFC Errata, Errata ID 3002, RFC 6325, <http://www.rfc-editor.org>.
[Err3002] RFC Errata、Errata ID 3002、RFC 6325、<http://www.rfc-editor.org>。
[Err3003] RFC Errata, Errata ID 3003, RFC 6325, <http://www.rfc-editor.org>.
[Err3003] RFC Errata、Errata ID 3003、RFC 6325、<http://www.rfc-editor.org>。
[Err3004] RFC Errata, Errata ID 3004, RFC 6325, <http://www.rfc-editor.org>.
[Err3004] RFC Errata、Errata ID 3004、RFC 6325、<http://www.rfc-editor.org>。
[Err3052] RFC Errata, Errata ID 3052, RFC 6325, <http://www.rfc-editor.org>.
[Err3052] RFC Errata、Errata ID 3052、RFC 6325、<http://www.rfc-editor.org>。
[Err3053] RFC Errata, Errata ID 3053, RFC 6325, <http://www.rfc-editor.org>.
[Err3053] RFC Errata、Errata ID 3053、RFC 6325、<http://www.rfc-editor.org>。
[Err3508] RFC Errata, Errata ID 3508, RFC 6325, <http://rfc-editor.org>.
[Err3508] RFC Errata、Errata ID 3508、RFC 6325、<http://rfc-editor.org>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、2013年10月。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、May 2014 。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757 USA
ドナルドイーストレイク3rd Huawei R＆D USA 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies Co., Ltd Huawei Building, No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District, Beijing 100095 P.R. China
Mingui Zhang Huawei Technologies Co.、Ltd Huawei Building、No.156 Beiqing Rd。Z-park、Shi-Chuang-Ke-Ji-Shi-Fan-Yuan、Hai-Dian District、Beijing 100095 P.R. China
EMail: zhangmingui@huawei.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054 USA
EMail: anoop@alumni.duke.edu
Vishwas Manral Ionos Corp. 4100 Moorpark Ave. San Jose, CA 95117 USA
ビスワスミネラルニーニョスカップ。 4100 Murky Av。 95117彼
EMail: vishwas@ionosnetworks.com
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
Ayan Banerjee Cumulus Networks 1089 West Evelyn Avenue Sunnyvale、CA 94086 USA
EMail: ayabaner@gmail.com