[要約] 要約： RFC 7780は、TRILL（Transparent Interconnection of Lots of Links）プロトコルに関する説明、修正、更新を提供しています。目的： RFC 7780の目的は、TRILLプロトコルの実装や運用に関する誤解や問題を解決し、より効果的なネットワーク接続を実現するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7780 M. Zhang
Obsoletes: 7180 Huawei
Updates: 6325, 7177, 7179 R. Perlman
Category: Standards Track EMC
ISSN: 2070-1721 A. Banerjee
Cisco
A. Ghanwani
Dell
S. Gupta
IP Infusion
February 2016
Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates
多数のリンクの透過的な相互接続（TRILL）：明確化、修正、および更新
Abstract
概要
Since the publication of the TRILL (Transparent Interconnection of Lots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station Address Distribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs 6325, 7177, and 7179.
2011年にTRILL（多くのリンクの透過的相互接続）ベースプロトコルが公開されて以来、TRILLの積極的な開発と展開により、RFC 6325のエラッタと、説明または更新を使用できる領域が明らかになりました。 RFC 7177、RFC 7357、およびRFC 6439の意図された置き換えは、隣接関係、TRILL ESADI（End Station Address Distribution Information）プロトコル、およびAppointed Forwarderに関する説明と更新をそれぞれ提供します。このドキュメントでは、その他の既知の説明、修正、および更新について説明します。 RFC 7180（以前の「TRILLの明確化、修正、および更新」RFC）を廃止し、RFC 6325、7177、および7179を更新します。
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/rfc7780.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7780で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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 (Changed) ..........................................5
1.1. Precedence (Changed) .......................................5
1.2. Changes That Are Not Backward Compatible (Unchanged) .......6
1.3. Terminology and Acronyms (Changed) .........................6
2. Overloaded and/or Unreachable RBridges (Unchanged) ..............7
2.1. Reachability ...............................................8
2.2. Distribution Trees .........................................8
2.3. Overloaded Receipt of TRILL Data Packets ...................9
2.3.1. Known Unicast Receipt ...............................9
2.3.2. Multi-Destination Receipt ...........................9
2.4. Overloaded Origination of TRILL Data Packets ...............9
2.4.1. Known Unicast Origination ..........................10
2.4.2. Multi-Destination Origination ......................10
2.4.2.1. An Example Network ........................10
2.4.2.2. Indicating OOMF Support ...................11
2.4.2.3. Using OOMF Service ........................11
3. Distribution Trees and RPF Check (Changed) .....................12
3.1. Number of Distribution Trees (Unchanged) ..................12
3.2. Distribution Tree Update Clarification (Unchanged) ........12
3.3. Multicast Pruning Based on IP Address (Unchanged) .........13
3.4. Numbering of Distribution Trees (Unchanged) ...............13
3.5. Link Cost Directionality (Unchanged) ......................13
3.6. Alternative RPF Check (New) ...............................14
3.6.1. Example of the Potential Problem ...................14
3.6.2. Solution and Discussion ............................15
4. Nickname Selection (Unchanged) .................................17
5. MTU (Maximum Transmission Unit) (Unchanged) ....................18
5.1. MTU-Related Errata in RFC 6325 ............................19
5.1.1. MTU PDU Addressing .................................19
5.1.2. MTU PDU Processing .................................20
5.1.3. MTU Testing ........................................20
5.2. Ethernet MTU Values .......................................20
6. TRILL Port Modes (Unchanged) ...................................21
7. The CFI/DEI Bit (Unchanged) ....................................22
8. Other IS-IS Considerations (Changed) ...........................23
8.1. E-L1FS Support (New) ......................................24
8.1.1. Backward Compatibility .............................24
8.1.2. E-L1FS Use for Existing (Sub-)TLVs .................25
8.2. Control Packet Priorities (New) ...........................26
8.3. Unknown PDUs (New) ........................................27
8.4. Nickname Flags APPsub-TLV (New) ...........................27
8.5. Graceful Restart (Unchanged) ..............................29
8.6. Purge Originator Identification (New) .....................29
9. Updates to RFC 7177 (Adjacency) (Changed) ......................30
10. TRILL Header Update (New) .....................................31
10.1. Color Bit ................................................32
10.2. Flags Word Changes (Update to RFC 7179) ..................32
10.2.1. Extended Hop Count ................................32
10.2.1.1. Advertising Support ......................33
10.2.1.2. Ingress Behavior .........................33
10.2.1.3. Transit Behavior .........................33
10.2.1.4. Egress Behavior ..........................34
10.2.2. Extended Color Field ..............................34
10.3. Updated Flags Word Summary ...............................35
11. Appointed Forwarder Status Lost Counter (New) .................35
12. IANA Considerations (Changed) .................................37
12.1. Previously Completed IANA Actions (Unchanged) ............37
12.2. New IANA Actions (New) ...................................37
12.2.1. Reference Updated .................................37
12.2.2. The "E" Capability Bit ............................37
12.2.3. NickFlags APPsub-TLV Number and Registry ..........38
12.2.4. Updated TRILL Extended Header Flags ...............38
12.2.5. TRILL-VER Sub-TLV Capability Flags ................39
12.2.6. Example Nicknames .................................39
13. Security Considerations (Changed) .............................39
14. References ....................................................40
14.1. Normative References .....................................40
14.2. Informative References ...................................42
Appendix A. Life Cycle of a TRILL Switch Port (New) ...............45
Appendix B. Example TRILL PDUs (New) ..............................48
B.1. LAN Hello over Ethernet ...................................48
B.2. LSP over PPP ..............................................50
B.3. TRILL Data over Ethernet ..................................51
B.4. TRILL Data over PPP .......................................52
Appendix C. Changes to Previous RFCs (New) ........................53
C.1. Changes to Obsoleted RFC 7180 .............................53
C.1.1. Changes ..............................................53
C.1.2. Additions ............................................53
C.1.3. Deletions ............................................54
C.2. Changes to RFC 6325 .......................................55
C.3. Changes to RFC 7177 .......................................55
C.4. Changes to RFC 7179 .......................................55
Acknowledgments ...................................................56
Authors' Addresses ................................................56
Since the TRILL base protocol [RFC6325] was published in 2011, active development and deployment of TRILL have revealed errors in the specification [RFC6325] and several areas that could use clarifications or updates.
2011年にTRILLベースプロトコル[RFC6325]が公開されて以来、TRILLの積極的な開発と展開により、仕様[RFC6325]と、説明や更新を使用できるいくつかの領域にエラーが明らかになっています。
[RFC7177], [RFC7357], and [RFC6439bis] provide clarifications and
updates with respect to adjacency, the TRILL ESADI (End Station
Address Distribution Information) protocol, and Appointed Forwarders,
respectively. This document provides other known clarifications,
corrections, and updates to [RFC6325], [RFC7177], and [RFC7179].
This document obsoletes [RFC7180] (the previous TRILL
"clarifications, corrections, and updates" document), updates
[RFC6325], updates [RFC7177] as described in Section 9, and updates
[RFC7179] as described in Sections 10.2 and 10.3. The changes to
these RFCs are summarized in Appendix C.
Sections of this document are annotated as to whether they are "New" technical material, material that has been technically "Changed", or material that is technically "Unchanged", by the appearance of one of these three words in parentheses at the end of the section header. A section with only editorial changes is annotated as "(Unchanged)". If no such notation appears, then the first notation encountered on going to successively higher-level section headers (those with shorter section numbers) applies. Appendix C describes changes, summarizes material added, and lists material deleted.
このドキュメントのセクションは、「新しい」技術資料、技術的に「変更」された資料、または技術的に「変更なし」の資料のいずれであるかについて、これらの3つの単語の1つが括弧の最後に括弧で囲まれて示されています。セクションヘッダー。編集上の変更のみのセクションには、「（変更なし）」という注釈が付けられています。そのような表記法が表示されない場合は、より高いレベルのセクションヘッダー（セクション番号が短いもの）に連続して行くときに最初に現れる表記法が適用されます。付録Cでは、変更について説明し、追加された資料を要約し、削除された資料をリストしています。
In the event of any conflicts between this document and [RFC6325], [RFC7177], or [RFC7179], this document takes precedence.
このドキュメントと[RFC6325]、[RFC7177]、または[RFC7179]との間に矛盾がある場合、このドキュメントが優先されます。
In addition, Section 1.2 of [RFC6325] ("Normative Content and Precedence") is updated to provide a more complete precedence ordering of the sections of [RFC6325], as shown below, where sections to the left take precedence over sections to their right. There are no known conflicts between these sections; however, Sections 1 and 2 are less detailed and do not mention every corner case, while subsequent sections of [RFC6325] are more detailed. This precedence is specified as a fallback in case some conflict is found in the future.
さらに、[RFC6325]のセクション1.2（「規範的コンテンツおよび優先順位」）が更新され、[RFC6325]のセクションのより完全な優先順位が提供されます。以下に示すように、左側のセクションが右側のセクションよりも優先されます。 。これらのセクション間に既知の競合はありません。ただし、セクション1と2はそれほど詳細ではなく、すべてのコーナーケースについて言及していませんが、[RFC6325]の後続のセクションはより詳細です。この優先順位は、将来競合が発生した場合のフォールバックとして指定されています。
4 > 3 > 7 > 5 > 2 > 6 > 1
The change made by Section 3.4 below (unchanged from Section 3.4 of [RFC7180]) is not backward compatible with [RFC6325] but has nevertheless been adopted to reduce distribution tree changes resulting from topology changes.
以下のセクション3.4で行われた変更（[RFC7180]のセクション3.4から変更なし）は、[RFC6325]との下位互換性はありませんが、トポロジの変更による配布ツリーの変更を減らすために採用されています。
Several other changes herein that are fixes to errata for [RFC6325] -- [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508] -- may not be backward compatible with previous implementations that conformed to errors in the specification.
[RFC6325]のエラッタに対する修正である他のいくつかの変更-[Err3002]、[Err3003]、[Err3054]、[Err3052]、[Err3508]-以前の実装との下位互換性がない可能性があります仕様のエラーに準拠。
This document uses the acronyms defined in [RFC6325], some of which are repeated below for convenience, along with some additional acronyms and terms, as follows:
このドキュメントでは、[RFC6325]で定義された頭字語を使用します。その一部は、以下のように、いくつかの追加の頭字語と用語とともに、便宜上以下で繰り返されます。
BFD - Bidirectional Forwarding Detection.
BFD-双方向転送検出。
Campus - A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
キャンパス-エンドステーションとIPルーターによって境界が定められたTRILLスイッチ、リンク、およびブリッジで構成されるTRILLネットワーク。 TRILLの場合、「キャンパス」という名前には「学問的」な意味合いはありません。
CFI - Canonical Format Indicator [802].
CFI-Canonical Format Indicator [802]。
CSNP - Complete Sequence Number PDU.
CSNP-完全なシーケンス番号PDU。
DEI - Drop Eligibility Indicator [802.1Q-2014].
DEI-適格性指標の削除[802.1Q-2014]。
FGL - Fine-Grained Labeling [RFC7172].
FGL-きめの細かいラベル付け[RFC7172]。
FS-LSP - Flooding Scope LSP.
FS-LSP-フラッディングスコープLSP。
OOMF - Overload Originated Multi-destination Frame.
OOMF-オーバーロード発信マルチ宛先フレーム。
P2P - Point-to-point.
P2P-ポイントツーポイント。
PDU - Protocol Data Unit.
PDU-プロトコルデータユニット。
PSNP - Partial Sequence Number PDU.
PSNP-部分シーケンス番号PDU。
RBridge - Routing Bridge, an alternative name for a TRILL switch.
RBridge-Routing Bridge、TRILLスイッチの別名。
RPFC - Reverse Path Forwarding Check.
RPFC-リバースパス転送チェック。
SNPA - Subnetwork Point of Attachment (for example, Media Access Control (MAC) address).
SNPA-アタッチメントのサブネットワークポイント（たとえば、メディアアクセス制御（MAC）アドレス）。
ToS - Type of Service.
ToS-サービスの種類。
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の別名。
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]で説明されているように解釈されます。
In this document, a "packet" usually refers to a TRILL Data packet or TRILL IS-IS packet received from or sent to a TRILL switch, while a "frame" usually refers to a native frame being received from or sent to an end station. (The word "frame" also occurs in other contexts, such as the "Frame Check Sequence" that is at the end of Ethernet transmissions.)
このドキュメントでは、「パケット」は通常、TRILLスイッチから受信または送信されるTRILLデータパケットまたはTRILL IS-ISパケットを指しますが、「フレーム」は通常、端末から受信または送信されるネイティブフレームを指します。 （「フレーム」という言葉は、イーサネット送信の最後にある「フレームチェックシーケンス」などの他のコンテキストでも使用されます。）
In this section, the term "neighbor" refers only to actual RBridges and ignores pseudonodes.
このセクションでは、「ネイバー」という用語は実際のRBridgeのみを指し、疑似ノードは無視します。
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 very large campus included one or more low-end TRILL switches.
LSP（Link State PDU）の[IS-IS]過負荷フラグが示すように、RBridgeが過負荷になっている可能性があります。つまり、（1）リンク状態データベース全体を保持できず、トポロジ全体を表示できないか、（2）過負荷ビットが設定されるように構成されているかのいずれかです。実際のリンク状態の過負荷を回避するようにネットワークを設計する必要がありますが、非常に大規模なキャンパスに1つ以上のローエンドTRILLスイッチが含まれている場合など、さまざまな状況で発生する可能性があります。
It is a common operational practice to set the overload bit in an [IS-IS] router (such as a TRILL switch) when performing maintenance on that router that might affect its ability to correctly forward packets; 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]ルーター（TRILLスイッチなど）で過負荷ビットを設定することは、パケットを正しく転送する機能に影響を与える可能性のあるルーターのメンテナンスを実行するときによく行われます。これにより、通常、ルータはメンテナンストラフィックに到達可能になりますが、トランジットトラフィックはルーティングされません。 （また、場合によっては、TRILLはリンクの疑似ノードで過負荷ビットを設定して、アクセスリンク上のTRILLデータトラフィックを停止することを提供します（[RFC6325]のセクション4.9.1を参照）。）
[IS-IS] and TRILL make a reasonable effort to do what they can, even if some TRILL switches/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 TRILL switches are in overload.
[IS-IS]とTRILLは、一部のTRILLスイッチ/ルーターが過負荷になっている場合でも、できる限りのことを行うように合理的な努力をします。散在するいくつかのノードが過負荷になっている場合、それらはかなりうまく機能します。ただし、TRILLスイッチが過負荷の場合、実際の最小コストのパスは保証されなくなります。
For the effect of overload on the appointment of forwarders, see [RFC6439bis].
フォワーダーの任命に対する過負荷の影響については、[RFC6439bis]を参照してください。
Packets are not least-cost routed through an overloaded TRILL switch, although they may originate or terminate at an overloaded TRILL switch. In addition, packets will not be least-cost routed over links with cost 2**24 - 1 [RFC5305]; such links are reserved for traffic-engineered packets, 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 either through a link with cost 2**24 - 1 or through an overloaded RBridge. For example, an RBridge (TRILL switch) 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（TRILLスイッチ）RB1は、そのすべてのネイバーがコスト2 ** 24-1のリンクによってRB1に接続されている場合、TRILLデータから到達できません。そのようなRBridgeは「データ到達不能」と呼ばれます。
The link-state database at an RBridge -- for example, 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 from RB1. 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スイッチに関する情報も含まれている場合があります。このような障害がキャンパスを分割する場合、RB1がLSPを更新して接続の欠如を示し、RB1がそれらの更新を受信するため、TRILLは障害に隣接し、障害の同じ側に切り替わります。その結果、RB1はパーティションを認識します。パーティションの向こう側のノードは、IS-ISに到達できず、RB1からデータに到達できません。ただし、障害の向こう側にある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 packets. 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 packets.
過負荷の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 packets, an RBridge such as RB1 MAY, to avoid calculating unnecessary RPFC state information, ignore any trees that cannot reach RB1, even if other RBridges list those trees as trees that other TRILL switches might use. (However, see Section 3.)
RBridgeが、計算する分散ツリーのルートとして使用するニックネームを決定するとき、過負荷状態にある、またはデータに到達できないTRILLスイッチが保持するすべてのニックネームを無視する必要があります。複数の宛先パケットのRPFCを計算するとき、RB1などのRBridgeは、不要なRPFC状態情報の計算を回避するために、他のRBridgeがそれらのツリーを他のTRILLスイッチが使用するツリーとしてリストしている場合でも、RB1に到達できないツリーを無視します。 （ただし、セクション3を参照してください。）
The receipt of TRILL Data packets by overloaded RBridge RB2 is discussed in the subsections below. In all cases, the normal Hop Count decrement is performed, and the TRILL Data packets are 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 packets unless it is the egress, in which case it egresses and delivers the data normally. If RB2 receives a unicast TRILL Data packet for which it is not the egress, perhaps because a neighbor does not yet know it is in overload, RB2 MUST NOT discard the packet 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 packet is not overloaded, it MUST attempt to forward the packet to one of those neighbors selected at random [RFC4086]. If there is no such neighbor, the packet is discarded.
RB2は、それが出力である場合を除いて、通常はユニキャストTRILLデータパケットを受信しません。 RB2がそれが出力ではないユニキャストTRILLデータパケットを受信した場合、おそらくネイバーがそれが過負荷状態であることをまだ認識していないため、RB2はパケットを破棄してはなりません。過負荷状態によるニックネーム。パケットを受信したネイバー以外のネイバーが過負荷でない場合、ランダムに選択されたネイバーの1つにパケットを転送しようとする必要があります[RFC4086]。そのようなネイバーがない場合、パケットは廃棄されます。
If RB2 in overload receives a multi-destination TRILL Data packet, RB2 MUST NOT apply an RPFC because, due to overload, it might not do so correctly. RB2 egresses and delivers the frame locally where it is Appointed Forwarder for the frame's VLAN (or, if the packet is FGL, for the VLAN that FGL maps to at the port), subject to any multicast pruning. But because, as stated above, RB2 can only be the leaf of a distribution tree, it MUST NOT forward a multi-destination TRILL Data packet (except as an egressed native frame where RB2 is Appointed Forwarder).
過負荷のRB2が複数の宛先のTRILLデータパケットを受信した場合、RB2はRPFCを適用してはなりません。これは、過負荷のために正しく行われない可能性があるためです。 RB2はフレームをローカルに出力および配信し、フレームのVLAN（またはパケットがFGLの場合は、FGLがポートでマッピングするVLAN）の場合、マルチキャストプルーニングの対象となります。ただし、上記のように、RB2は配布ツリーのリーフにしかなり得ないため、マルチ宛先TRILLデータパケットを転送してはなりません（RB2がAppointed Forwarderである出力ネイティブフレームを除く）。
Overloaded origination of unicast TRILL Data packets with known egress and of multi-destination packets is discussed in the subsections below.
送信が既知であるユニキャストTRILLデータパケットとマルチ宛先パケットの過負荷発生については、以下のサブセクションで説明します。
When RB2, an overloaded RBridge, ingresses or creates a known destination unicast data packet, it delivers it locally if the destination 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が既知の宛先ユニキャストデータパケットを入力または作成するとき、宛先がローカルの場合はローカルにそれを配信します。それ以外の場合、RB2は、過負荷になっていない近隣のTRILLスイッチにそれをユニキャストします。ネイバーの選択に役立つルーティング情報を使用する場合があります。
Overloaded RBridge RB2 ingressing or creating a multi-destination data packet presents a more complex scenario than that of the known unicast case, as discussed below.
以下で説明するように、マルチロードされたRBridge RB2の入力またはマルチデスティネーションデータパケットの作成は、既知のユニキャストの場合よりも複雑なシナリオを示します。
For example, consider the network diagram below in which, for simplicity, end stations and any bridges are not shown. There is one distribution tree of which RB4 is the root, as 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 service for multi-destination native frames. So, RB2 tunnels the frame in a TRILL Data packet 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 the OOMF (Overload Originated Multi-destination Frame) service.
RB2は過負荷になっているため、ネットワークの配信ツリーが何であるかはわかりません。したがって、複数の宛先のネイティブフレームに通常のTRILLデータサービスを提供する方法はありません。したがって、RB2は、このサービスを提供する意思があることを通知したネイバーがいる場合、過負荷にならないネイバーにTRILLデータパケットのフレームをトンネルします。 RBridgeは、以下に説明するように、Helloでこれを示します。このサービスは、OOMF（過負荷発信マルチ宛先フレーム）サービスと呼ばれます。
- The multi-destination frame MUST NOT be locally distributed in native form at RB2, because this would cause the frame to be delivered twice. Instead, it is tunneling to a neighbor as described in this section. 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 packet 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 the IANA Considerations section). Overloaded RBridge RB2 can only distribute multi-destination TRILL Data packets 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 packets 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 HelloのTRILLネイバーTLVのRB2にOOMFサービスを提供する意思を示します（リンクを参照）。 IANAの考慮事項セクション）。過負荷の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 that is beyond the scope of this document. Assuming that RB2 selects RB3 to handle multi-destination packets 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が発信するマルチ宛先パケットを処理するためにRB2がRB3を選択すると仮定すると、RBFCは、RPFCがキャンパスの残りの部分で機能するように、RB3がアドバタイズする配信ツリーのいずれかを使用する可能性があることをLSPでアドバタイズする必要があります。したがって、その過負荷状態にもかかわらず、RB2は、RB3に直接接続されているため、受信するRB3 LSPからのこの情報を保持する必要があります。
RB2 then encapsulates such frames as TRILL Data packets 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 packet (see the IANA Considerations section). RB2 then unicasts this TRILL Data packet 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.) On receipt of such a packet, RB3 does the following:
次に、RB2は、TRILLデータパケットなどのフレームを次のようにRB3にカプセル化します。ホップカウント= 2; Ingress Nickname = RB2が保持するニックネーム。また、RB2はRB3が使用する配布ツリーを判別できないため、出力ニックネーム= OOMFパケットを示す特別なニックネーム（IANAの考慮事項のセクションを参照）。次に、RB2はこのTRILLデータパケットをRB3にユニキャストします。 （以下のセクション4の項目4の実装は、その過負荷状態にもかかわらず、RB2によって使用される入力ニックネームが、少なくともRB2からIS-ISに到達可能なキャンパスの部分内で一意であることを合理的に保証します。）パケットの場合、RB3は次のことを行います。
- changes the Egress Nickname field to designate a distribution tree that RB3 normally uses,
- Egress Nicknameフィールドを変更して、RB3が通常使用する配布ツリーを指定します。
- sets the "M" bit to one,
- 「M」ビットを1に設定し、
- changes the Hop Count to the value it would normally use if it were the ingress, and
- ホップカウントを、入力の場合に通常使用する値に変更します。
- forwards the TRILL Data packet on that tree.
- そのツリーでTRILLデータパケットを転送します。
RB3 MAY rate-limit the number of packets for which it is providing this service by discarding some such packets 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からそのようなパケットを破棄することにより、このサービスを提供するパケットの数をレート制限することができます（MAY）。おそらく低速パスを介した、RB3によるOOMFの限られた帯域幅の提供も、RB2またはRB2に接続されたエンドステーションでのサービスのブートストラップに重要である可能性があります。たとえば、DHCPやARP / ND（アドレス解決プロトコル/近隣探索）のサポートなどです。 ）。 （誰もが地面から降りるために、少しOOMF（発音は "oomph"）を必要とする場合があります。）
Two corrections, a clarification, and two updates related to distribution trees appear in the subsections below, along with an alternative, stronger RPF (Reverse Path Forwarding) check. See also Section 2.2.
2つの修正、明確化、および配布ツリーに関連する2つの更新が、代替のより強力なRPF（Reverse Path Forwarding）チェックと共に、以下のサブセクションに表示されます。セクション2.2も参照してください。
In [RFC6325], Section 4.5.2, page 56, point 2, fourth 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), several possible types of change can occur. 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 packets 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 packet 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 addresses SHOULD calculate and use such derived MAC addresses from the multicast listener IPv4 or IPv6 address information it receives.
TRILLスイッチは、関連する実際のIPv4またはIPv6マルチキャストアドレスに基づいて、マルチキャストリスナーとプルーニング配布ツリーを通信できます（MAY）。 [RFC7176]には、この情報を伝えるための追加のグループアドレスサブTLVが用意されています。導出されたMACアドレスに基づいてのみプルーニングが可能なTRILLスイッチは、受信したマルチキャストリスナーIPv4またはIPv6アドレス情報から、そのような導出されたMACアドレスを計算して使用する必要があります。
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, then 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 packets 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 use either the cost away from the tree root or the cost towards the tree root. The text in Section 4.5.1 of [RFC6325] is incorrect, as documented in [Err3508]. The text 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までのコストパスが等しく最小になる親で構成されます。
[RFC6325] mandates a Reverse Path Forwarding (RPF) check on multi-destination TRILL Data packets to avoid possible multiplication and/or looping of multi-destination traffic during TRILL campus topology transients. This check is logically performed at each TRILL switch input port and determines whether it is arriving on the expected port based on where the packet started (the ingress nickname) and the tree on which it is being distributed. If not, the packet is silently discarded. This check is fine for point-to-point links; however, there are rare circumstances involving multi-access ("broadcast") links where a packet can be duplicated despite this RPF check and other checks performed by TRILL.
[RFC6325] TRILLキャンパストポロジのトランジェント中にマルチデスティネーショントラフィックの乗算やループが発生する可能性を回避するために、マルチデスティネーションTRILLデータパケットのリバースパス転送（RPF）チェックを義務付けています。このチェックは各TRILLスイッチの入力ポートで論理的に実行され、パケットが開始された場所（入力ニックネーム）とパケットが配信されているツリーに基づいて、ポートが予想されるポートに到着するかどうかを判断します。そうでない場合、パケットは通知なく破棄されます。このチェックは、ポイントツーポイントリンクでは問題ありません。ただし、このRPFチェックおよびTRILLによって実行されるその他のチェックにもかかわらず、パケットが複製される可能性のあるマルチアクセス（「ブロードキャスト」）リンクに関連するまれな状況があります。
Section 3.6.1 gives an example of the potential problem, and Section 3.6.2 specifies a solution. This solution is an alternative, stronger RPF check that TRILL switches can implement in place of the RPF check discussed in [RFC6325].
セクション3.6.1は潜在的な問題の例を示し、セクション3.6.2は解決策を示します。このソリューションは、[RFC6325]で説明されているRPFチェックの代わりにTRILLスイッチを実装できる、代替のより強力なRPFチェックです。
Consider this network:
このネットワークを考えてみましょう：
F--A--B--C--o--D | E
F--A--B--C--o--D | E
All the links except the link between C, D, and E are point-to-point links. C, D, and E are connected over a broadcast link represented by the pseudonode "o". For example, they could be connected by a bridged LAN. (Bridged LANs are transparent to TRILL.)
C、D、E間のリンクを除くすべてのリンクは、ポイントツーポイントリンクです。 C、D、およびEは、疑似ノード「o」で表されるブロードキャストリンクを介して接続されます。たとえば、これらはブリッジLANで接続できます。 （ブリッジLANはTRILLに対して透過的です。）
Although the choice of root is unimportant here, assume that D or F is chosen as the root of a distribution tree so that it is obvious that the tree looks just like the diagram above.
ルートの選択はここでは重要ではありませんが、ツリーが上図のように見えることは明らかであるように、DまたはFが配布ツリーのルートとして選択されていると想定します。
Now assume that a link comes up from A to the same bridged LAN. The network then looks like this:
ここで、リンクがAから同じブリッジLANにアップすると想定します。ネットワークは次のようになります。
+--------+
| |
F--A--B--C--o--D
|
E
Let's say the resulting tree in steady state includes all links except the B-C link. After the network has converged, a packet that starts from F will go F->A. Then A will send one copy on the A-B link and another copy into the bridged LAN from which it will be received by C and D.
定常状態の結果のツリーに、B-Cリンクを除くすべてのリンクが含まれているとしましょう。ネットワークが収束した後、Fから始まるパケットはF-> Aになります。次に、Aは1つのコピーをA-Bリンクに送信し、別のコピーをブリッジされたLANに送信して、そこからCとDが受信します。
Now consider a transition stage where A and D have acted on the new LSPs and programmed their forwarding plane, while B and C have not yet done so. This means that B and C both consider the link between them to still be part of the tree. In this case, a packet that starts out from F and reaches A will be copied by A into the A-B link and to the bridged LAN. D's RPF check says to accept packets on this tree coming from F over its port on the bridged LAN, so it gets accepted. D is also adjacent to A on the tree, so the tree adjacency check, a separate check mandated by [RFC6325], also passes.
次に、AとDが新しいLSPに作用し、フォワーディングプレーンをプログラムしたが、BとCはまだそうしていない移行ステージについて考えます。これは、BとCの両方がそれらの間のリンクをまだツリーの一部であると見なしていることを意味します。この場合、Fから始まりAに到達するパケットは、AによってA-BリンクとブリッジLANにコピーされます。 DのRPFチェックは、ブリッジされたLAN上のポートを介してFから来るこのツリーのパケットを受け入れるように言っているため、受け入れられます。 Dはツリー上のAにも隣接しているため、[RFC6325]によって義務付けられている個別のチェックであるツリー隣接チェックもパスします。
However, the packet that gets to B gets sent out by B to C. C's RPF check still has the old state, and it thinks the packet is OK. C sends the packet along the old tree, which sends the packet into the bridged LAN. D receives one more packet, but the tree adjacency check passes at D because C is adjacent to D in the new tree as well. The RPF check also passes at D because D's port on the bridged LAN is OK for receiving packets from F.
ただし、Bに到達したパケットはBからCに送信されます。CのRPFチェックはまだ古い状態であり、パケットはOKであると見なします。 Cは古いツリーに沿ってパケットを送信し、古いツリーはブリッジドLANにパケットを送信します。 Dはもう1つのパケットを受信しますが、Cは新しいツリーでもDに隣接しているため、ツリー隣接チェックはDでパスします。ブリッジングされたLAN上のDのポートはFからのパケットの受信に問題がないため、RPFチェックはDでもパスします。
So, during this transient state, D gets duplicates of every multi-destination packet ingressed at F (unless the packet gets pruned) until B and C act on the new LSPs and program their forwarding tables.
したがって、この一時的な状態では、BとCが新しいLSPに作用して転送テーブルをプログラムするまで、DはFで入力されたすべての複数宛先パケットの複製を取得します（パケットが整理されない限り）。
The problem stems from the RPF check described in [RFC6325] depending only on the port at which a TRILL Data packet is received, the ingress nickname, and the tree being used, that is, a check if {ingress nickname, tree, input port} is a valid combination according to the receiving TRILL switch's view of the campus topology. A multi-access link actually has multiple adjacencies overlaid on one physical link, and to avoid the problem shown in Section 3.6.1, a stronger check is needed that includes the Layer 2 source address of the TRILL Data packet being received. (TRILL is a Layer 3 protocol, and TRILL switches are true routers that logically strip the Layer 2 header from any arriving TRILL Data packets and add the appropriate new Layer 2 header to any outgoing TRILL Data packet to get it to the next TRILL switch, so the Layer 2 source address in a TRILL Data packet identifies the immediately previous TRILL switch that forwarded the packet.)
この問題は、[RFC6325]で説明されているRPFチェックに起因します。これは、TRILLデータパケットが受信されるポート、入力ニックネーム、および使用されているツリーのみに依存します。つまり、{入力ニックネーム、ツリー、入力ポート}は、キャンパストポロジの受信TRILLスイッチのビューによると、有効な組み合わせです。マルチアクセスリンクは、実際には1つの物理リンク上に複数の隣接関係が重なっています。セクション3.6.1に示す問題を回避するには、受信されるTRILLデータパケットのレイヤ2送信元アドレスを含むより強力なチェックが必要です。 （TRILLはレイヤー3プロトコルであり、TRILLスイッチは、到着するTRILLデータパケットからレイヤー2ヘッダーを論理的に削除し、適切な新しいレイヤー2ヘッダーを送信TRILLデータパケットに追加して、次のTRILLスイッチに到達させる真のルーターです。そのため、TRILLデータパケットのレイヤ2送信元アドレスは、パケットを転送した直前のTRILLスイッチを識別します）。
What is needed, instead of checking the validity of the triplet {ingress nickname, tree, input port}, is to check that the quadruplet {ingress nickname, source SNPA, tree, input port} is valid (where "source SNPA" (Subnetwork Point of Attachment) is the Outer.MacSA for an Ethernet link). Although it is true that [RFC6325] also requires a check to ensure that a multi-destination TRILL Data packet is from a TRILL switch that is adjacent in the distribution tree being used, this check is separate from the RPF check, and these two independent checks are not as powerful as the single unified check for a valid quadruplet.
必要なのは、トリプレット{入力ニックネーム、ツリー、入力ポート}の有効性をチェックする代わりに、4つ組{入力ニックネーム、ソースSNPA、ツリー、入力ポート}が有効であることをチェックすることです（「ソースSNPA」（サブネットワーク接続点）は、イーサネットリンクのOuter.MacSAです）。 [RFC6325]では、複数の宛先のTRILLデータパケットが、使用されている配布ツリー内で隣接するTRILLスイッチからのものであることを確認するためのチェックも必要ですが、このチェックはRPFチェックとは異なり、これら2つの独立したチェックは、有効な4つの要素に対する単一の統合チェックほど強力ではありません。
_______
/ \
RB1 ------ o ----- RB2
\_______/
However, this stronger RPF check is not without cost. In the simple case of a multi-access link where each TRILL switch has only one port on the link, it merely increases the size of validity entries by adding the source SNPA (Outer.MacSA). However, assume that some TRILL switch RB1 has multiple ports attached to a multi-access link. In the figure above, RB1 is shown with three ports on the multi-access link. RB1 is permitted to load split multi-destination traffic it is sending into the multi-access link across those ports (Section 4.4.4 of [RFC6325]). Assume that RB2 is another TRILL switch on the link and RB2 is adjacent to RB1 in the distribution tree. The number of validity quadruplets at RB2 for ingress nicknames whose multi-destination traffic would arrive through RB1 is multiplied by the number of ports RB1 has on the access link, because RB2 has to accept such traffic from any such ports. Although such instances seem to be very rare in practice, the number of ports an RBridge has on a link could in principle be tens or even a hundred or more ports, vastly increasing the RPF check state at RB2 when this stronger RPF check is used.
ただし、このより強力なRPFチェックにはコストがないわけではありません。各TRILLスイッチがリンク上にポートを1つだけ持つマルチアクセスリンクの単純なケースでは、ソースSNPA（Outer.MacSA）を追加することにより、有効性エントリのサイズを増やすだけです。ただし、一部のTRILLスイッチRB1にマルチアクセスリンクに接続された複数のポートがあると仮定します。上の図では、マルチアクセスリンクに3つのポートがあるRB1が示されています。 RB1は、これらのポートを介してマルチアクセスリンクに送信する分割された複数の宛先のトラフィックをロードすることが許可されています（[RFC6325]のセクション4.4.4）。 RB2がリンク上の別のTRILLスイッチであり、RB2が配布ツリーでRB1に隣接していると想定します。複数の宛先トラフィックがRB1経由で到着する入力ニックネームのRB2での有効な4つ組の数は、RB2がそのようなトラフィックをそのようなポートから受け入れる必要があるため、RB1がアクセスリンク上に持つポートの数で乗算されます。そのようなインスタンスは実際には非常にまれに思われますが、RBridgeがリンク上に持つポートの数は、原則として数十または100以上のポートになる可能性があり、このより強力なRPFチェックを使用すると、RB2でのRPFチェック状態が大幅に増加します。
Another potential cost of the stronger RPF check is increased transient loss of multi-destination TRILL Data packets during a topology change. For TRILL switch D, the new stronger RPF check is (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1), while the old one was (tree->A, Outer.MacSA=C, ingress=A, arrival port=if1).
強力なRPFチェックのもう1つの潜在的なコストは、トポロジ変更中の複数宛先TRILLデータパケットの一時的な損失の増加です。 TRILLスイッチDの場合、新しいより強力なRPFチェックは（tree-> A、Outer.MacSA = A、ingress = A、arrival port = if1）ですが、古いチェックは（tree-> A、Outer.MacSA = C、 ingress = A、arrival port = if1）。
Suppose that both A and B have switched to the new tree for multicast forwarding but D has not updated its RPF check yet; the multicast packet will then be dropped at D's input port, because D still expects a packet from "Outer.MacSA=C". But we do not have this packet loss issue if the weaker triplet check (tree->A, ingress=A, arrival port=if1) is used. Thus, the stronger check can increase the RPF check discard of multi-destination packets during topology transients.
AとBの両方がマルチキャスト転送のために新しいツリーに切り替えたが、DはそのRPFチェックをまだ更新していないとします。その後、Dは「Outer.MacSA = C」からのパケットを予期しているため、マルチキャストパケットはDの入力ポートでドロップされます。しかし、より弱いトリプレットチェック（tree-> A、ingress = A、arrival port = if1）が使用されている場合、このパケット損失の問題はありません。したがって、より強力なチェックを使用すると、トポロジの一時的な発生時に、マルチ宛先パケットのRPFチェックによる廃棄を増やすことができます。
Because of these potential costs, implementation of this stronger RPF check is optional. The TRILL base protocol is updated to provide that TRILL switches MUST, for multi-destination packets, either implement the RPF and other checks as described in [RFC6325] or implement this stronger RPF check as a substitute for the [RFC6325] RPF and tree adjacency checks. There is no problem with a campus having a mixture of TRILL switches, some of which implement one of these RPF checks and some of which implement the other.
これらの潜在的なコストのため、このより強力なRPFチェックの実装はオプションです。 TRILLスイッチは、マルチ宛先パケットに対して、[RFC6325]で説明されているようにRPFおよびその他のチェックを実装するか、[RFC6325] RPFおよびツリー隣接の代わりにこのより強力なRPFチェックを実装するように更新されます。チェック。キャンパスにTRILLスイッチが混在していても問題はありません。これらのスイッチの一部はこれらのRPFチェックの1つを実装し、一部は他のRPFチェックを実装しています。
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:
1. 25ページの[RFC6325]のセクション3.7.3の2番目の箇条書き項目の2番目の文は誤っており[Err3002]、次のように修正されています。
o The occurrence of "IS-IS ID (LAN ID)" is replaced with "priority".
o 「IS-IS ID（LAN ID）」の出現を「優先」に置き換えます。
o The occurrence of "IS-IS System ID" is replaced with "7-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 7-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 monitoring any received LSPs that should update its link-state database for 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 do so due to overload.)
4. RBridgeは、競合する要求者がないと思われるニックネームを取得した後でも、保持している1つまたは複数のニックネームとの競合を監視し続ける必要があります。これは、リンク状態データベースを更新する必要のある受信LSPを監視して、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 RBridge Channel messages sent by a neighbor to the Any-RBridge egress nickname and will receive appropriate multi-destination RBridge Channel messages.
5. すべての有効なRBridgeニックネーム（0x0001から0xFFBFまでを含む）がIS-IS到達可能TRILLスイッチによってより高い優先度で使用されているため、RBridgeがニックネームを取得できないという非常にまれなケースでは、入力、出力として機能できません。 、またはツリールートですが、トランジットTRILLスイッチとして機能できます。ツリールートにすることはできませんが、そのようなRBridgeは、その近隣のすべてが過負荷にならない限り、キャンパスに対して計算される分散ツリーに含まれます。特にそのようなTRILLスイッチ[RFC7178]にユニキャストRBridge Channelメッセージを送信することはできません。ただし、ネイバーがAny-RBridge出力ニックネームに送信したユニキャストRBridge Channelメッセージを受信し、適切な複数の宛先のRBridge Channelメッセージを受信します。
MTU values in TRILL are derived from 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 assure that the LSPs can be flooded by IS-IS and thus that IS-IS can operate properly.
TRILLのMTU値は、IS-IS originatingLSPBufferSize TLV [IS-IS]で伝達されるoriginatingL1LSPBufferSize値から導出されます。 [RFC6325]のセクション4.3.1で説明されているキャンパス全体の値Szは、キャンパス内のRBridgeのoriginatingL1LSPBufferSizeの最小値ですが、1470以上です。MTUテストメカニズムとLSPをSzに制限することで、 LSPはIS-ISによってフラッディングされる可能性があるため、そのIS-ISは適切に動作できます。
If an RBridge knows nothing about the MTU of the links or the originatingL1LSPBufferSize of other RBridges in a campus, the originatingL1LSPBufferSize for that 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 of regenerating 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 MTUs. However, as specified in [RFC6325], in no case can originatingL1LSPBufferSize be less than 1470. In a well-configured campus, to minimize any LSP regeneration due to resizing, all RBridges will be configured with the same originatingL1LSPBufferSize.
RBridgeがリンクの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, these multi-destination MTU-probe and MTU-ack PDUs 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として、イーサネットリンクでマルチキャストする場合、これらのマルチ宛先MTUプローブおよびMTU-ack PDUは、All-IS-IS-RBridgesマルチキャストアドレスに送信する必要があります。
As discussed in [RFC6325] and (in more detail) [RFC7177], 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 1 in Section 4.6.2 of [RFC6325] with the following text, to which TRILL switches MUST conform:
[RFC6325]および（より詳細には）[RFC7177]で説明されているように、MTU-probeおよび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 text is to that section in [RFC6325].
上記のテキストの「セクション4.6.2.1」への参照は、[RFC6325]のそのセクションへの参照です。
The last two sentences of Section 4.3.2 of [RFC6325] contain errors [Err3053]. They currently read as follows:
[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は、そのリンクでRB1が送信するTRILL Hellosの隣接ごとにテストされた最大のXをアドバタイズし、RB1は、RB1のLSPのRB2へのリンクの属性としてXをアドバタイズできます。
They should read as follows:
彼らは次のように読む必要があります：
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 and including the IS-IS 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.) 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.
originatingL1LSPBufferSizeは、IS-IS 0x83 "ドメイン内ルーティングプロトコル識別子"バイトで始まり、これを含むLSPの最大許容サイズです。レイヤ3 IS-ISでは、originatingL1LSPBufferSizeのデフォルトは1492バイトです。 （これはDECnetフェーズVとしての以前の人生では、IS-ISは8バイトのオーバーヘッドと1492 + 8 = 1500を必要とするSNAP SAP（サブネットワークアクセスプロトコルサービスアクセスポイント）[RFC7042]形式を使用してエンコードされていたためです。クラシックイーサネットの最大値。論理リンク制御（LLC）エンコーディングを使用するようにISO / IEC [IS-IS]で標準化されている場合、このデフォルトは数バイト増加する可能性がありますが、増加されませんでした。これにより、27バイトのヘッドルームまたは安全マージンにより、Outer.VLANなどのヘッダーにもかかわらず、従来のイーサネット最大MTUを持つレガシーデバイスに対応できます。
Assuming that 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 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 by an amount that depends 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と、テスト対象のサイズに依存する量（Szを超える可能性がある）が埋め込まれたMTU-probeおよびMTU-ack PDUです。
Sz does not limit TRILL Data packets. 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 packet payloads of (Sz - 24) bytes, starting after the Inner.VLAN and ending just before the FCS.
SzはTRILLデータパケットを制限しません。それらは、実際に通過するデバイスとリンクのMTUによってのみ制限されます。ただし、SzまでのIS-IS PDUに対応できるリンクは、Inner.VLANの後に始まり、FCSの直前に終了する（Sz-24）バイトのTRILLデータパケットペイロードに十分な安全マージンを提供します。
Most modern Ethernet equipment has ample headroom for frames with extensive headers and is sometimes engineered to accommodate 9 KB jumbo frames.
最新のイーサネット機器の多くは、ヘッダーが豊富なフレーム用に十分なヘッドルームがあり、9 KBのジャンボフレームに対応するように設計されている場合があります。
Section 4.9.1 of [RFC6325] specifies four mode bits for RBridge ports but may not be completely clear on the effects of all combinations of bits in terms of allowed frame types.
[RFC6325]のセクション4.9.1は、RBridgeポートの4つのモードビットを指定していますが、許可されたフレームタイプの観点から、ビットのすべての組み合わせの影響について完全に明確ではない場合があります。
The table below explicitly indicates the effects 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 remaining columns indicate allowed frame types. The "disable bit" normally disables all frames; however, as an implementation choice, some or all low-level Layer 2 control messages can still be sent or received. Examples of Layer 2 control messages are those control frames for Ethernet identified in Section 1.4 of [RFC6325] or PPP link negotiation messages [RFC6361].
以下の表は、TRILLポートモードビットのすべての可能な組み合わせの影響を明示的に示しています。最初の4列のうちの1つにある「*」は、ビットが0または1のいずれかであることを示します。残りの列は、許可されたフレームタイプを示します。 「無効ビット」は通常、すべてのフレームを無効にします。ただし、実装の選択として、一部またはすべての低レベルのレイヤ2制御メッセージを引き続き送受信できます。レイヤ2制御メッセージの例は、[RFC6325]のセクション1.4で識別されるイーサネット用の制御フレームまたはPPPリンクネゴシエーションメッセージ[RFC6361]です。
+-+-+-+-+--------+-------+-------+-------+-------+
|D| | | | | | | | |
|i| |A| | | | TRILL | | |
|s| |c|T| |Native | Data | | |
|a| |c|r| |Ingress| | | |
|b|P|e|u| | | LSP | | |
|l|2|s|n|Layer 2 |Native | 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" above is the "TRILL traffic disable bit". The formal name of the "trunk bit" is the "end-station service disable bit" [RFC6325].
上記の「アクセスビット」の正式名称は「TRILLトラフィック無効ビット」です。 「トランクビット」の正式名称は「端末サービス無効ビット」[RFC6325]です。
In May 2011, the IEEE promulgated IEEE Std 802.1Q-2011, which changed 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. After 802.1Q-2011 and in subsequent versions of 802.1Q -- the most current of which is
2011年5月、IEEEはIEEE Std 802.1Q-2011を公布し、C-VLANタグのペイロードの優先度とVLAN IDビット間のビットの意味を変更しました。以前は、このビットはCFI（Canonical Format Indicator）ビット[802]と呼ばれ、IEEE 802.5（トークンリング）フレームに関連して特別な意味がありました。 802.1Q-2011以降および以降のバージョンの802.1Q-最新のものは
[802.1Q-2014] -- this bit is now the DEI (Drop Eligibility Indicator) bit. (The corresponding bit in S-VLAN/B-VLAN tags has always been a DEI bit.)
[802.1Q-2014]-このビットは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 packet 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 port interface on ingressing a native frame. Similarly, this bit MUST be provided to the port when transiting or egressing a TRILL Data packet. As with the 3-bit Priority field, the DEI bit to use in forwarding a transit packet 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ビットは、ネイティブの入力時にポートインターフェイスによって提供されるDEI値に設定する必要があります。フレーム。同様に、このビットは、TRILLデータパケットを送信または出力するときにポートに提供する必要があります。 3ビットの優先度フィールドと同様に、中継パケットの転送に使用するDEIビットは、Inner.VLANから取得する必要があります。 Outer.VLAN DEIと優先度ビットへの正確な影響、およびOuter.VLANが出力フレームのワイヤにまったく表示されるかどうかは、出力ポートの構成によって異なります。
TRILL campuses with a mixture of ports, some compliant with versions of 802.1Q from IEEE Std 802.1Q-2011 onward 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.
特に、実際のトークンリングリンクがある場合は、IEEE Std 802.1Q-2011以降の802.1Qのバージョンに準拠し、802.1Q-2011以前の標準に準拠しているポートが混在するTRILLキャンパスは、正しく動作せず、破損する可能性があります。このようなポートとリンクが混在するブリッジLANと同様に、データ。
This section covers Extended Level 1 Flooding Scope (E-L1FS) support, control packet priorities, unknown PDUs, the Nickname Flags APPsub-TLV, graceful restart, and the Purge Originator Identification TLV.
このセクションでは、拡張レベル1フラッディングスコープ（E-L1FS）のサポート、制御パケットの優先度、不明なPDU、ニックネームフラグAPPsub-TLV、グレースフルリスタート、およびパージオリジネーター識別TLVについて説明します。
TRILL switches MUST support E-L1FS PDUs [RFC7356] and MUST include a Scope Flooding Support TLV [RFC7356] in all TRILL Hellos they send indicating support for this scope and any other FS-LSP scopes that they support. This support increases the number of fragments available for link-state information by over two orders of magnitude. (See Section 9 for further information on support of the Scope Flooding Support TLV.)
TRILLスイッチはE-L1FS PDU [RFC7356]をサポートする必要があり、このスコープおよびサポートする他のFS-LSPスコープのサポートを示す、送信するすべてのTRILL HelloにスコープフラッディングサポートTLV [RFC7356]を含める必要があります。このサポートにより、リンク状態情報に使用できるフラグメントの数が2桁以上増加します。 （スコープフラッディングサポートTLVのサポートの詳細については、セクション9を参照してください。）
In addition, TRILL switches MUST advertise their support of E-L1FS flooding in a TRILL-VER sub-TLV Capability Flag (see [RFC7176] and Section 12.2). This flag is used by a TRILL switch, say RB1, to determine support for E-L1FS by some remote RBx. The alternative of simply looking for an E-L1FS FS-LSP originated by RBx fails because (1) RBx might support E-L1FS flooding but is not originating any E-L1FS FS-LSPs and (2) even if RBx is originating E-L1FS FS-LSPs there might, due to legacy TRILL switches in the campus, be no path between RBx and RB1 through TRILL switches supporting E-L1FS flooding. If that were the case, no E-L1FS FS-LSP originated by RBx could get to RB1.
さらに、TRILLスイッチは、TRILL-VERサブTLV機能フラグでE-L1FSフラッディングのサポートを通知する必要があります（[RFC7176]およびセクション12.2を参照）。このフラグは、RB1などのTRILLスイッチによって使用され、一部のリモートRBxによるE-L1FSのサポートを決定します。 （1）RBxがE-L1FSフラッディングをサポートしている可能性があるが、E-L1FS FS-LSPを発信していないため、および（2）RBxが発信している場合でもE-L1FS FS-LSPを単に探す代わりに失敗するL1FS FS-LSPは、キャンパス内のレガシーTRILLスイッチが原因で、E-L1FSフラッディングをサポートするTRILLスイッチを介してRBxとRB1の間にパスがない可能性があります。その場合、RBxから発信されたE-L1FS FS-LSPはRB1に到達できません。
E-L1FS will commonly be used to flood TRILL GENINFO TLVs and enclosed TRILL APPsub-TLVs [RFC7357]. For robustness, E-L1FS fragment zero MUST NOT exceed 1470 bytes in length; however, if such a fragment is received that is larger, it is processed normally. It is anticipated that in the future some particularly important TRILL APPsub-TLVs will be specified as being flooded in E-L1FS fragment zero. TRILL GENINFO TLVs MUST NOT be sent in LSPs; however, if one is received in an LSP, it is processed normally.
E-L1FSは通常、TRILL GENINFO TLVと囲まれたTRILL APPsub-TLV [RFC7357]をフラッディングするために使用されます。堅牢性のために、E-L1FSフラグメントゼロは長さが1470バイトを超えてはなりません。ただし、そのようなフラグメントが受信された場合、それは正常に処理されます。将来、いくつかの特に重要なTRILL APPsub-TLVがE-L1FSフラグメント0でフラッディングされるように指定されることが予想されます。 TRILL GENINFO TLVはLSPで送信してはなりません。ただし、LSPで受信した場合は、通常どおり処理されます。
A TRILL campus might contain TRILL switches supporting E-L1FS flooding and legacy TRILL switches that do not support E-L1FS or perhaps do not support any [RFC7356] scopes.
TRILLキャンパスには、E-L1FSフラッディングをサポートするTRILLスイッチと、E-L1FSをサポートしない、またはおそらく[RFC7356]スコープをサポートしないレガシーTRILLスイッチが含まれる場合があります。
A TRILL switch conformant to this document can always tell which adjacent TRILL switches support E-L1FS flooding from the adjacency table entries on its ports (see Section 9). In addition, such a TRILL switch can tell which remote TRILL switches in a campus support E-L1FS by the presence of a TRILL version sub-TLV in that TRILL switch's LSP with the E-L1FS support bit set in the Capabilities field; this capability bit is ignored for adjacent TRILL switches for which only the adjacency table entry is consulted to determine E-L1FS support.
このドキュメントに準拠するTRILLスイッチは、ポートの隣接テーブルエントリからのE-L1FSフラッディングをサポートする隣接TRILLスイッチを常に通知できます（セクション9を参照）。さらに、このようなTRILLスイッチは、E-L1FSサポートビットが機能フィールドに設定されたTRILLスイッチのLSPにTRILLバージョンサブTLVが存在することにより、キャンパス内のどのリモートTRILLスイッチがE-L1FSをサポートするかを通知できます。この機能ビットは、隣接テーブルエントリだけがE-L1FSサポートを決定するために参照される隣接TRILLスイッチでは無視されます。
TRILL specifications making use of E-L1FS MUST specify how situations involving a mixed TRILL campus of TRILL switches will be handled.
E-L1FSを使用するTRILL仕様は、TRILLスイッチの混合TRILLキャンパスを含む状況がどのように処理されるかを指定する必要があります。
In a campus where all TRILL switches support E-L1FS, all TRILL sub-TLVs listed in Section 2.3 of [RFC7176], except the TRILL version sub-TLV, MAY be advertised by inclusion in Router Capability or MT-Capability TLVs in E-L1FS FS-LSPs [RFC7356]. (The TRILL version sub-TLV still MUST appear in an LSP fragment zero.)
すべてのTRILLスイッチがE-L1FSをサポートするキャンパスでは、[RFC7176]のセクション2.3に記載されているすべてのTRILLサブTLVを、TRILLバージョンのサブTLVを除いて、ルーター機能またはE-のMT機能TLVに含めることで宣伝できます。 L1FS FS-LSP [RFC7356]。 （TRILLバージョンのサブTLVは、LSPフラグメント0に表示される必要があります。）
In a mixed campus where some TRILL switches support E-L1FS and some do not, then only the following four sub-TLVs of those listed in Section 2.3 of [RFC7176] can appear in E-L1FS, and then only under the conditions discussed below. In the following list, each sub-TLV is preceded by an abbreviated acronym used only in this section of this document:
一部のTRILLスイッチがE-L1FSをサポートし、一部がサポートしない混合キャンパスでは、[RFC7176]のセクション2.3にリストされているもののうち、次の4つのサブTLVのみがE-L1FSに表示され、以下で説明する条件下でのみ表示されます。 。次のリストでは、各サブTLVの前に、このドキュメントのこのセクションでのみ使用される省略された頭字語が付いています。
IV: Interested VLANs and Spanning Tree Roots sub-TLV VG: VLAN Group sub-TLV IL: Interested Labels and Spanning Tree Roots sub-TLV LG: Label Group sub-TLV
IV：関心のあるVLANおよびスパニングツリールートのサブTLV VG：VLANグループのサブTLV IL：関心のあるラベルおよびスパニングツリールートのサブTLV LG：ラベルグループのサブTLV
An IV or VG sub-TLV MUST NOT be advertised by TRILL switch RB1 in an E-L1FS FS-LSP (and should instead be advertised in an LSP) unless the following conditions are met:
IVまたはVGサブTLVは、次の条件が満たされない限り、E-L1FS FS-LSPのTRILLスイッチRB1によってアドバタイズされてはなりません（代わりにLSPでアドバタイズされるべきです）。
- E-L1FS is supported by all of the TRILL switches that are data reachable from RB1 and are interested in the VLANs mentioned in the IV or VG sub-TLV, and
- E-L1FSは、RB1からデータに到達可能で、IVまたはVGサブTLVで言及されているVLANに関心があるすべてのTRILLスイッチでサポートされています。
- there is E-L1FS connectivity between all such TRILL switches in the campus interested in the VLANs mentioned in the IV or VG sub-TLV (connectivity involving only intermediate TRILL switches that also support E-L1FS).
- IVまたはVGサブTLVで言及されているVLANに関心のあるキャンパス内のすべてのそのようなTRILLスイッチ間にE-L1FS接続があります（E-L1FSもサポートする中間TRILLスイッチのみを含む接続）。
Any IV and VG sub-TLVs MAY still be advertised via core TRILL IS-IS LSPs by any TRILL switch that has enough room in its LSPs.
IVおよびVGサブTLVは、LSPに十分なスペースがあるTRILLスイッチによってコアTRILL IS-IS LSPを介して引き続きアドバタイズできます（MAY）。
The conditions for using E-L1FS for the IL and LG sub-TLVs are the same as for IV and VG, but with Fine-Grained Labels [RFC7172] substituted for VLANs.
ILおよびLGサブTLVにE-L1FSを使用するための条件は、IVおよびVGと同じですが、VLANの代わりに細かいラベル[RFC7172]を使用します。
Note, for example, that the above would permit a contiguous subset of the campus that supported Fine-Grained Labels and E-L1FS to use E-L1FS to advertise IL and LG sub-TLVs, even if the remainder of the campus did not support Fine-Grained Labels or E-L1FS.
たとえば、上記では、ファイングレインラベルとE-L1FSをサポートするキャンパスの隣接するサブセットがE-L1FSを使用してILとLGサブTLVをアドバタイズすることを許可することに注意してください。きめの細かいラベルまたはE-L1FS。
When deciding what packet to send out a port, control packets used to establish and maintain adjacency between TRILL switches SHOULD be treated as being in the highest-priority category. This includes TRILL IS-IS Hello and MTU PDUs, and possibly other adjacency [RFC7177] or link-technology-specific packets. Other control and data packets SHOULD be given lower priority so that a flood of such other packets cannot lead to loss of, or inability to establish, adjacency. Loss of adjacency causes a topology transient that can result in reduced throughput; reordering; increased probability of loss of data; and, in the worst case, network partition if the adjacency is a cut point.
どのパケットをポートに送信するかを決定するとき、TRILLスイッチ間の隣接を確立および維持するために使用される制御パケットは、最高の優先度のカテゴリにあるものとして扱われる必要があります。これには、TRILL IS-IS HelloとMTU PDU、および場合によっては他の隣接[RFC7177]またはリンク技術固有のパケットが含まれます。他の制御パケットとデータパケットには低い優先度を与える必要があるため、そのような他のパケットのフラッドが隣接性の喪失や確立の不能につながることはありません。隣接性が失われるとトポロジーが一時的になり、スループットが低下する可能性があります。並べ替え;データ損失の可能性の増加;最悪の場合、隣接がカットポイントである場合はネットワークパーティション。
Other important control packets should be given second-highest priority. Lower priorities should be given to data or less important control packets.
その他の重要な制御パケットには、2番目に高い優先順位を与える必要があります。より低い優先順位は、データまたはそれほど重要でない制御パケットに与えられるべきです。
Based on the above, control packets can be ordered into priority categories as shown below, based on the relative criticality of these types of messages, where the most critical control packets relate to the core routing between TRILL switches and the less critical control packets are closer to "application" information. (There may be additional control packets, not specifically listed in any category below, that SHOULD be handled as being in the most nearly analogous category.) Although few implementations will actually treat these four categories with different priority, an implementation MAY choose to prioritize more critical messages over less critical. However, an implementation SHOULD NOT send control packets in a lower-priority category with a priority above those in a higher-priority category because, under sufficiently congested conditions, this could block control packets in a higher-priority category, resulting in network disruption.
上記に基づいて、これらのタイプのメッセージの相対的な重要度に基づいて、以下に示すように制御パケットを優先度のカテゴリに並べることができます。最も重要な制御パケットは、TRILLスイッチ間のコアルーティングに関連し、重要度の低い制御パケットはより近くなります。 「アプリケーション」情報へ。 （以下のどのカテゴリにも具体的にリストされていない追加の制御パケットがあり、最も類似したカテゴリにあるものとして処理される必要があります。）実際にはこれらの4つのカテゴリを異なる優先度で処理する実装はほとんどありませんが、実装はより優先することを選択できます（MAY）。それほど重要ではない重要なメッセージ。ただし、十分に輻輳した状態では、これにより優先度の高いカテゴリの制御パケットがブロックされ、ネットワークが中断する可能性があるため、実装では優先度の低いカテゴリの制御パケットを送信しないでください。
Priority
Category Description
-------- --------------
4. Hello, MTU-probe, MTU-ack, and other packets critical to establishing and maintaining adjacency. (Normally sent with highest priority, which is priority 7.)
4. Hello、MTU-probe、MTU-ack、および隣接関係の確立と維持に重要なその他のパケット。 （通常、最高の優先順位（優先順位7）で送信されます。）
3. LSPs, CSNPs/PSNPs, and other important control packets.
3. LSP、CSNP / PSNP、およびその他の重要な制御パケット。
2. Circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.
2. 回路スコープのFS-LSP、FS-CSNP、およびFS-PSNP。
1. Non-circuit scoped FS-LSPs, FS-CSNPs, and FS-PSNPs.
1. 非回路スコープFS-LSP、FS-CSNP、およびFS-PSNP。
TRILL switches MUST silently discard [IS-IS] PDUs they receive with PDU numbers they do not understand, just as they ignore TLVs and sub-TLVs they receive that have unknown Types and sub-Types; however, they SHOULD maintain a counter of how many such PDUs have been received, on a per-PDU-number basis. (This is not burdensome, as the PDU number is only a 5-bit field.)
TRILLスイッチは、不明なタイプとサブタイプを持つTLVとサブTLVを無視するのと同様に、理解できないPDU番号で受信した[IS-IS] PDUをサイレントに破棄する必要があります。ただし、それらは、PDU番号ごとに、受信されたそのようなPDUの数のカウンターを維持する必要があります（SHOULD）。 （PDU番号は5ビットのフィールドにすぎないため、これは煩わしいことではありません。）
Note: The set of valid [IS-IS] PDUs was stable for so long that some IS-IS implementations may treat PDUs with unknown PDU numbers as a serious error and, for example, an indication that other valid PDUs from the sender are not to be trusted or that they should drop adjacency to the sender if it was adjacent. However, the MTU-probe and MTU-ack PDUs were added by [RFC7176], and now [RFC7356] has added three more new PDUs. Although the authors of this document are not aware of any Internet-Drafts calling for further PDUs, the eventual addition of further new PDUs should not be surprising.
注：一連の有効な[IS-IS] PDUは長期間安定していたため、一部のIS-IS実装では、不明なPDU番号のPDUを重大なエラーとして扱い、たとえば、送信者からの他の有効なPDUが信頼できるようにする、または送信者が隣接している場合は隣接関係を送信者にドロップする必要があるただし、MTUプローブとMTU-ack PDUは[RFC7176]によって追加され、[RFC7356]はさらに3つの新しいPDUを追加しました。このドキュメントの作成者は、追加のPDUを要求するインターネットドラフトについては認識していませんが、最終的にさらに新しいPDUを追加することは驚くべきことではありません。
An optional Nickname Flags APPsub-TLV within the TRILL GENINFO TLV [RFC7357] is specified below.
TRILL GENINFO TLV [RFC7357]内のオプションのニックネームフラグAPPsub-TLVを以下に指定します。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = NickFlags (6) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length = 4*K | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKFLAG RECORD K (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each NICKFLAG RECORD has the following format:
各NICKFLAG RECORDの形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: NickFlags TRILL APPsub-TLV, set to 6 (NICKFLAGS).
o Length: 4 times the number of NICKFLAG RECORDS present.
o 長さ：存在するNICKFLAG RECORDSの数の4倍。
o Nickname: A 16-bit TRILL nickname held by the advertising TRILL switch ([RFC6325] and Section 4).
o ニックネーム：広告TRILLスイッチ（[RFC6325]およびセクション4）が保持する16ビットTRILLニックネーム。
o IN: Ingress. If this flag is one, it indicates that the advertising TRILL switch may use the nickname in the NICKFLAG RECORD as the Ingress Nickname of TRILL Headers it creates. If the flag is zero, that nickname will not be used for that purpose.
o IN：イングレス。このフラグが1の場合、広告TRILLスイッチが、作成するTRILLヘッダーの入力ニックネームとしてNICKFLAG RECORDのニックネームを使用できることを示します。フラグがゼロの場合、そのニックネームはその目的には使用されません。
o RESV: Reserved for additional flags to be specified in the future. MUST be sent as zero and ignored on receipt.
o RESV：将来指定される追加のフラグ用に予約されています。ゼロとして送信し、受信時に無視する必要があります。
The entire NickFlags APPsub-TLV is ignored if the Length is not a multiple of 4. A NICKFLAG RECORD is ignored if the nickname it lists is not a nickname owned by the TRILL switch advertising the enclosing NickFlags APPsub-TLV.
長さが4の倍数でない場合、NickFlags APPsub-TLV全体が無視されます。NICKFLAGRECORDは、それがリストするニックネームが、外側のNickFlags APPsub-TLVをアドバタイズするTRILLスイッチが所有するニックネームでない場合は無視されます。
If a TRILL switch intends to use a nickname in the Ingress Nickname field of TRILL Headers it constructs, it can advertise this through E-L1FS FS-LSPs (see Section 8.1) using a NickFlags APPsub-TLV entry with the IN flag set. If it owns only one nickname, there is no reason to do this because, if a TRILL switch advertises no NickFlags APPsub-TLVs with the IN flag set for nicknames it owns, it is assumed that the TRILL switch might use any or all nicknames it owns as the Ingress Nickname in TRILL Headers it constructs. If a TRILL switch advertises any NickFlags APPsub-TLV entries with the IN flag set, then it MUST NOT use any other nickname(s) it owns as the Ingress Nickname in TRILL Headers it constructs.
TRILLスイッチが、作成するTRILLヘッダーのIngress Nicknameフィールドでニックネームを使用する場合、INフラグが設定されたNickFlags APPsub-TLVエントリを使用して、E-L1FS FS-LSP（セクション8.1を参照）を通じてこれをアドバタイズできます。ニックネームを1つしか所有していない場合、TRILLスイッチが所有するニックネームにINフラグが設定されたNickFlags APPsub-TLVをアドバタイズしない場合、TRILLスイッチがニックネームの一部またはすべてを使用する可能性があるため、これを行う理由はありません。構築するTRILLヘッダーのIngress Nicknameとして所有します。 TRILLスイッチがINフラグが設定されたNickFlags APPsub-TLVエントリをアドバタイズする場合、それが所有する他のニックネームを、構築するTRILLヘッダーのIngress Nicknameとして使用してはなりません（MUST NOT）。
Every reasonable effort should be made to be sure that Nickname sub-TLVs [RFC7176] and NickFlags APPsub-TLVs remain in sync. If all TRILL switches in a campus support E-L1FS, so that Nickname sub-TLVs can be advertised in E-L1FS FS-LSPs, then the Nickname sub-TLV and any NickFlags APPsub-TLVs for any particular nickname SHOULD be advertised in the same fragment. If they are not in the same fragment, then, to the extent practical, all fragments involving those sub-TLVs for the same nickname should be propagated as an atomic action. If a TRILL switch sees multiple NickFlags APPsub-TLV entries for the same nickname, it assumes that that nickname might be used as the ingress in a TRILL Header if any of the NickFlags APPsub-TLV entries have the IN bit set.
NicknameサブTLV [RFC7176]とNickFlags APPサブTLVの同期が維持されるように、あらゆる合理的な努力を払う必要があります。キャンパス内のすべてのTRILLスイッチがE-L1FSをサポートしているため、ニックネームサブTLVをE-L1FS FS-LSPでアドバタイズできる場合、特定のニックネームのニックネームサブTLVとNickFlags APPサブTLVは、同じフラグメント。それらが同じフラグメント内にない場合、実用的な範囲で、同じニックネームのそれらのサブTLVを含むすべてのフラグメントは、アトミックアクションとして伝播する必要があります。 TRILLスイッチが同じニックネームの複数のNickFlags APPsub-TLVエントリーを検出した場合、NickFlags APPsub-TLVエントリーのいずれかにINビットが設定されている場合、そのニックネームがTRILLヘッダーの入力として使用される可能性があると想定します。
It is possible that a NickFlags APPsub-TLV would not be propagated throughout the TRILL campus due to legacy TRILL switches not supporting E-L1FS. In that case, Nickname sub-TLVs MUST be advertised in LSPs, and TRILL switches not receiving NickFlags APPsub-TLVs having entries with the IN flag set will simply assume that the source TRILL switch might use any of its nicknames as the ingress in constructing TRILL Headers. Thus, the use of this optional APPsub-TLV is backward compatible with legacy lack of E-L1FS support.
従来のTRILLスイッチがE-L1FSをサポートしていないため、NickFlags APPsub-TLVがTRILLキャンパス全体に伝播されない可能性があります。その場合、ニックネームサブTLVはLSPでアドバタイズされる必要があり、INフラグが設定されたエントリを持つNickFlags APPサブTLVを受信しないTRILLスイッチは、TRILLを構築する際の入口として、ソースTRILLスイッチがそのニックネームのいずれかを使用する可能性があると想定します。ヘッダー。したがって、このオプションのAPPsub-TLVの使用は、従来のE-L1FSサポートの欠如と下位互換性があります。
(Additional flags are assigned from those labeled RESV above and specified in [TRILL-L3-GW] and [Centralized-Replication].)
（追加のフラグは、上記のRESVというラベルの付いたフラグから割り当てられ、[TRILL-L3-GW]および[Centralized-Replication]で指定されています。）
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. If this feature is not supported, it may increase the number of topology transients caused by a TRILL switch rebooting due to errors or maintenance.
TRILLスイッチは、[RFC5306]で指定されている機能をサポートする必要があります。これは、再起動中のIS-ISルーターが再起動中であることをネイバーに通知し、ダウン状態を循環せずに隣接関係を再確立できるメカニズムを記述します。リンク状態データベースの同期。この機能がサポートされていない場合、エラーまたはメンテナンスのためにTRILLスイッチが再起動することにより発生するトポロジの一時的なエラーの数が増える可能性があります。
To ease debugging of any purge-related problems, TRILL switches SHOULD include the Purge Originator Identification TLV [RFC6232] in all purge PDUs in TRILL IS-IS. This includes Flooding Scope LSPs [RFC7356] and ESADI LSPs [RFC7357].
パージ関連の問題のデバッグを容易にするために、TRILLスイッチは、TRILL IS-ISのすべてのパージPDUにパージ発信元識別TLV [RFC6232]を含める必要があります（SHOULD）。これには、フラッディングスコープLSP [RFC7356]およびESADI LSP [RFC7357]が含まれます。
To support the E-L1FS flooding scope [RFC7356] mandated by Section 8.1 and backward compatibility with legacy RBridges not supporting E-L1FS flooding, this document updates [RFC7177] as follows:
セクション8.1で義務付けられているE-L1FSフラッディングスコープ[RFC7356]と、E-L1FSフラッディングをサポートしていないレガシーRBridgeとの下位互換性をサポートするために、このドキュメントは[RFC7177]を次のように更新します。
1. The list in the second paragraph of Section 3.1 of [RFC7177] is updated by adding the following item:
1. [RFC7177]のセクション3.1の2番目の段落のリストは、次の項目を追加することによって更新されます。
o The Scope Flooding Support TLV.
o スコープフラッディングサポートTLV。
In addition, the sentence immediately after that list is updated by this document to read as follows:
さらに、そのリストの直後の文は、このドキュメントによって次のように更新されます。
Of course, (a) the priority, (b) the Desired Designated VLAN, (c) the Scope Flooding Support TLV, and whether or not the (d) PORT-TRILL-VER sub-TLV and/or (e) BFD-Enabled TLV are included, and their value if included, could change on occasion. However, if these change, the new value(s) must similarly be used in all TRILL Hellos on the LAN port, regardless of VLAN.
もちろん、（a）優先度、（b）希望する指定VLAN、（c）スコープフラッディングサポートTLV、および（d）PORT-TRILL-VERサブTLVや（e）BFD-有効なTLVが含まれており、含まれている場合はその値が変更される場合があります。ただし、これらが変更された場合、VLANに関係なく、LANポート上のすべてのTRILL Helloで新しい値を同様に使用する必要があります。
2. This document adds another bullet item to the end of Section 3.2 of [RFC7177], as follows:
2. このドキュメントでは、次のように[RFC7177]のセクション3.2の最後に別の箇条書き項目を追加しています。
o The value from the Scope Flooding Support TLV, or a null string if none was included.
o スコープフラッディングサポートTLVからの値。含まれていない場合はnull文字列。
3. Near the bottom of Section 3.3 of [RFC7177], this document adds the following bullet item:
3. [RFC7177]のセクション3.3の下部近くに、このドキュメントは次の箇条書き項目を追加します。
o The variable-length value part of the Scope Flooding Support TLV in the Hello, or a null string if that TLV does not occur in the Hello.
o HelloのスコープフラッディングサポートTLVの可変長の値の部分、またはそのTLVがHelloで発生しない場合はnull文字列。
4. At the beginning of Section 4 of [RFC7177], this document adds a bullet item to the list, as follows:
4. [RFC7177]のセクション4の冒頭で、このドキュメントは次のように箇条書き項目をリストに追加します。
o The variable-length value part of the Scope Flooding Support TLV used in TRILL Hellos sent on the port.
o ポートで送信されるTRILL Helloで使用されるスコープフラッディングサポートTLVの可変長の値の部分。
5. This document adds a line to Table 4 ("TRILL Hello Contents") in Section 8.1 of [RFC7177], as follows:
5. このドキュメントは、[RFC7177]のセクション8.1の表4（ "TRILL Hello Contents"）に次のように1行追加します。
LAN P2P Number Content Item
--- --- ------ ---------------------------
M M 1 Scope Flooding Support TLV
M M 1スコープフラッディングサポートTLV
The TRILL Header has been updated from its original specification in [RFC6325] by [RFC7455] and [RFC7179] and is further updated by this document. The TRILL Header is now as shown in the figure below (which is followed by references for all of the fields). Those fields for which the reference is only to [RFC6325] are unchanged from that RFC.
TRILLヘッダーは、[RFC6325]の元の仕様から[RFC7455]および[RFC7179]によって更新され、このドキュメントによってさらに更新されています。 TRILLヘッダーは次の図に示すようになります（すべてのフィールドの参照が続きます）。 [RFC6325]のみを参照しているフィールドは、そのRFCから変更されていません。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |A|C|M| RESV |F| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional Flags Word :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In calculating a TRILL Data packet hash as part of equal-cost multipath selection, a TRILL switch MUST ignore the value of the "A" and "C" bits.
等コストマルチパス選択の一部としてTRILLデータパケットハッシュを計算する場合、TRILLスイッチは「A」および「C」ビットの値を無視する必要があります。
In [RFC6325] and [RFC7179], there is a TRILL Header Extension Length field called "Op-Length", which is hereby changed to consist of the RESV field and "F" bit shown above.
[RFC6325]と[RFC7179]には、 "Op-Length"と呼ばれるTRILLヘッダー拡張フィールドがあり、これは上記のRESVフィールドと "F"ビットで構成されるように変更されています。
o V (Version): 2-bit unsigned integer. See Section 3.2 of [RFC6325].
o V（バージョン）：2ビット符号なし整数。 [RFC6325]のセクション3.2をご覧ください。
o A (Alert): 1 bit. See [RFC7455].
o A（アラート）：1ビット。 [RFC7455]を参照してください。
o C (Color): 1 bit. See Section 10.1.
o C（カラー）：1ビット。セクション10.1を参照してください。
o M (Multi-destination): 1 bit. See Section 3.4 of [RFC6325].
o M（マルチ宛先）：1ビット。 [RFC6325]のセクション3.4をご覧ください。
o RESV: 4 bits. These bits are reserved and MUST be sent as zero. Due to the previous use of these bits as specified in [RFC6325], most TRILL "fast path" hardware implementations trap and do not forward TRILL Data packets with these bits non-zero. A TRILL switch receiving a TRILL Data packet with any of these bits non-zero MUST discard the packet unless the non-zero bit or bits have some future use specified that the TRILL switch understands.
o RESV：4ビット。これらのビットは予約されており、ゼロとして送信する必要があります。 [RFC6325]で指定されているこれらのビットの以前の使用により、ほとんどのTRILL「高速パス」ハードウェア実装はトラップし、これらのビットがゼロ以外のTRILLデータパケットを転送しません。これらのビットがゼロ以外であるTRILLデータパケットを受信するTRILLスイッチは、0以外のビットがTRILLスイッチが理解できる将来の使用が指定されていない限り、パケットを破棄する必要があります。
o F: 1 bit. If this field is non-zero, then the optional flags word described in Section 10.2 is present. If it is zero, the flags word is not present.
o F：1ビット。このフィールドがゼロ以外の場合、セクション10.2で説明されているオプションのフラグワードが存在します。ゼロの場合、フラグワードは存在しません。
o Hop Count: 6 bits. See Section 3.6 of [RFC6325] and Section 10.2.1 below.
o ホップ数：6ビット。 [RFC6325]のセクション3.6と下記のセクション10.2.1を参照してください。
o Egress Nickname: See Section 3.7.1 of [RFC6325].
o 出力ニックネーム：[RFC6325]のセクション3.7.1を参照してください。
o Ingress Nickname: See Section 3.7.2 of [RFC6325].
o Ingress Nickname：[RFC6325]のセクション3.7.2を参照してください。
o Optional Flags Word: See [RFC7179] and Section 10.2.
o オプションのフラグワード：[RFC7179]およびセクション10.2を参照してください。
The Color bit provides an optional way by which ingress TRILL switches MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change this bit. Transit and egress TRILL switches MAY use the Color bit for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis.
Colorビットは、入力TRILLスイッチが実装固有の目的でTRILLデータパケットにマークを付けることができるオプションの方法を提供します。通過TRILLスイッチはこのビットを変更してはなりません。通過および出力TRILLスイッチは、実装に依存するトラフィックのラベル付け、または統計分析やその他のタイプのトラフィックの調査や分析にカラービットを使用する場合があります。
When the "F" bit in the TRILL Header is non-zero, the first 32 bits after the Ingress Nickname field provide additional flags. These bits are as specified in [RFC7179], except as changed by the subsections below, in which the Extended Hop Count and Extended Color fields are described. See Section 10.3 for a diagram and summary of these fields.
TRILLヘッダーの「F」ビットがゼロ以外の場合、入力ニックネームフィールドの後の最初の32ビットは追加のフラグを提供します。これらのビットは、[RFC7179]で指定されているとおりですが、拡張ホップカウントと拡張カラーフィールドが説明されている以下のサブセクションで変更されている場合を除きます。これらのフィールドの図と概要については、セクション10.3を参照してください。
The TRILL base protocol [RFC6325] specifies the Hop Count field in the header, to avoid packets persisting in the network due to looping or the like. However, the Hop Count field size (6 bits) limits the maximum hops a TRILL Data packet can traverse to 64. Optionally, TRILL switches can use a field composed of bits 14 through 16 in the flags word, as specified below, to extend this field to 9 bits. This increases the maximum Hop Count to 512. Except in rare circumstances, reliable use of Hop Counts in excess of 64 requires support of this optional capability at all TRILL switches along the path of a TRILL Data packet.
TRILLベースプロトコル[RFC6325]は、ループなどによってパケットがネットワーク内に存続することを回避するために、ヘッダーのホップカウントフィールドを指定します。ただし、ホップカウントフィールドサイズ（6ビット）は、TRILLデータパケットが通過できる最大ホップを64に制限します。オプションで、TRILLスイッチは、フラグワードのビット14〜16で構成されるフィールドを使用して、これを以下のように拡張できますフィールドを9ビットに。これにより、最大ホップカウントが512に増加します。まれな状況を除いて、64を超えるホップカウントを確実に使用するには、TRILLデータパケットのパスに沿ったすべてのTRILLスイッチでこのオプション機能をサポートする必要があります。
It may be that not all the TRILL switches support the Extended Hop Count mechanism in a TRILL campus and in that campus more than 64 hops are required either for the distribution tree calculated path or for the unicast calculated path plus a reasonable allowance for alternate pathing. As such, it is required that TRILL switches advertise their support by setting bit 14 in the TRILL Version Sub-TLV Capabilities and Header Flags Supported field [RFC7176]; bits 15 and 16 of that field are now specified as Unassigned (see Section 12.2.5).
すべてのTRILLスイッチがTRILLキャンパスの拡張ホップカウントメカニズムをサポートしているとは限りません。そのキャンパスでは、配布ツリーの計算パスまたはユニキャストの計算パスに加えて、代替パスの妥当な許容量のために64ホップを超えるホップが必要です。そのため、TRILLスイッチは、TRILLバージョンのサブTLV機能とサポートされているヘッダーフラグフィールド[RFC7176]のビット14を設定して、サポートを通知する必要があります。そのフィールドのビット15と16は、未割り当てとして指定されます（セクション12.2.5を参照）。
If an ingress TRILL switch determines that it should set the Hop Count for a TRILL Data packet to 63 or less, then behavior is as specified in the TRILL base protocol [RFC6325]. If the optional TRILL Header flags word is present, bits 14, 15, and 16 and the critical reserved bit of the critical summary bits are zero.
入力TRILLスイッチがTRILLデータパケットのホップカウントを63以下に設定する必要があると判断した場合、動作はTRILLベースプロトコル[RFC6325]で指定されているとおりです。オプションのTRILLヘッダーフラグワードが存在する場合、ビット14、15、16、およびクリティカルサマリビットのクリティカル予約ビットはゼロです。
If the Hop Count for a TRILL Data packet should be set to some value greater than 63 but less than 512 and all TRILL switches that the packet is reasonably likely to encounter support Extended Hop Count, then the resulting TRILL Header has the flags word extension present, the high-order 3 bits of the desired Hop Count are stored in the Extended Hop Count field in the flags word, the low-order 5 bits are stored in the Hop Count field in the first word of the TRILL Header, and bit two (the critical reserved bit of the critical summary bits) in the flags word is set to one.
TRILLデータパケットのホップカウントを63より大きく512未満の値に設定する必要があり、パケットがすべて拡張ホップカウントのサポートに遭遇する可能性が高いすべてのTRILLスイッチの場合、結果のTRILLヘッダーにフラグワード拡張が存在します。 、目的のホップカウントの上位3ビットがフラグワードの拡張ホップカウントフィールドに格納され、下位5ビットがTRILLヘッダーの最初のワードのホップカウントフィールドに格納され、ビット2フラグワードの（クリティカルサマリビットのクリティカル予約ビット）が1に設定されます。
For known unicast traffic (TRILL Header "M" bit zero), an ingress TRILL switch discards the frame if it determines that the least-cost path to the egress is (1) more than 64 hops and not all TRILL switches on that path support the Extended Hop Count feature or (2) more than 512 hops.
既知のユニキャストトラフィック（TRILLヘッダー "M"ビット0）では、出力への最小コストパスが（1）64ホップを超え、そのパスのすべてのTRILLスイッチがサポートされているわけではないと、入力TRILLスイッチがフレームを破棄します。拡張ホップカウント機能、または（2）512ホップ以上。
For multi-destination traffic, when a TRILL switch determines that one or more tree paths from the ingress are more than 64 hops and not all TRILL switches in the campus support the Extended Hop Count feature, the encapsulation uses a total Hop Count of 63 to obtain at least partial distribution of the traffic.
複数の宛先のトラフィックの場合、入口からの1つ以上のツリーパスが64ホップを超えていて、キャンパス内のすべてのTRILLスイッチが拡張ホップカウント機能をサポートしているわけではないとTRILLスイッチが判断した場合、カプセル化では63の合計ホップカウントを使用します。トラフィックの少なくとも部分的な分布を取得します。
A transit TRILL switch supporting Extended Hop Count behaves like a base protocol [RFC6325] TRILL switch in decrementing the Hop Count, except that it considers the Hop Count to be a 9-bit field where the Extended Hop Count field constitutes the high-order 3 bits.
拡張ホップカウントをサポートするトランジットTRILLスイッチは、ホップカウントのデクリメントにおいて基本プロトコル[RFC6325] TRILLスイッチのように動作します。ただし、ホップカウントは、拡張ホップカウントフィールドが上位3を構成する9ビットフィールドであると見なされます。ビット。
To be more precise: a TRILL switch supporting Extended Hop Count takes the first of the following actions that is applicable:
より正確に言うと、Extended Hop CountをサポートするTRILLスイッチは、適用可能な次の最初のアクションを実行します。
1. If both the Hop Count and Extended Hop Count fields are zero, the packet is discarded.
1. ホップカウントと拡張ホップカウントの両方のフィールドがゼロの場合、パケットは破棄されます。
2. If the Hop Count is non-zero, it is decremented. As long as the Extended Hop Count is non-zero, no special action is taken. If the result of this decrement is zero, the packet is processed normally.
2. ホップカウントがゼロ以外の場合、デクリメントされます。 Extended Hop Countがゼロでない限り、特別なアクションは行われません。このデクリメントの結果がゼロの場合、パケットは正常に処理されます。
3. If the Hop Count is zero, it is set to the maximum value of 63, and the Extended Hop Count is decremented. If this results in the Extended Hop Count being zero, the critical reserved bit in the critical summary bits is set to zero.
3. ホップカウントがゼロの場合は、最大値63に設定され、拡張ホップカウントが減分されます。この結果、拡張ホップカウントがゼロになると、クリティカルサマリビットのクリティカル予約ビットがゼロに設定されます。
No special behavior is required when egressing a TRILL Data packet that uses the Extended Hop Count. The flags word, if present, is removed along with the rest of the TRILL Header during decapsulation.
拡張ホップカウントを使用するTRILLデータパケットを出力する場合、特別な動作は必要ありません。フラグワードが存在する場合、カプセル化解除中にTRILLヘッダーの残りとともに削除されます。
Flags word bits 27 and 28 are specified to be a 2-bit Extended Color field (see Section 10.3). These bits are in the non-critical ingress-to-egress region of the flags word.
フラグワードビット27および28は、2ビットの拡張カラーフィールドとして指定されています（セクション10.3を参照）。これらのビットは、フラグワードの非クリティカルな入出力領域にあります。
The Extended Color field provides an optional way by which ingress TRILL switches MAY mark TRILL Data packets for implementation-specific purposes. Transit TRILL switches MUST NOT change these bits. Transit and egress TRILL switches MAY use the Extended Color bits for implementation-dependent traffic labeling, or for statistical analysis or other types of traffic study or analysis.
Extended Colorフィールドは、入力TRILLスイッチが実装固有の目的のためにTRILLデータパケットをマークできるオプションの方法を提供します。 Transit TRILLスイッチはこれらのビットを変更してはなりません。通過および出力TRILLスイッチは、実装依存のトラフィックラベル付け、または統計分析やその他のタイプのトラフィックの調査や分析に拡張カラービットを使用する場合があります。
Per Section 2.3.1 of [RFC7176], support for these bits is indicated by the same bits (27 and 28) in the Capabilities and Header Flags Supported field of the TRILL version sub-TLV. If these bits are zero in those capabilities, Extended Color is not supported. A TRILL switch that does not support Extended Color will ignore the corresponding bits in any TRILL Header flags word it receives as part of a TRILL Data packet and will set those bits to zero in any TRILL Header flags word it creates. A TRILL switch that sets or senses the Extended Color field on transmitting or receiving TRILL Data packets MUST set the corresponding 2-bit field in the TRILL version sub-TLV to a non-zero value. Any difference in the meaning of the three possible non-zero values of this 2-bit capability field (0b01, 0b10, or 0b11) is implementation dependent.
[RFC7176]のセクション2.3.1に従って、これらのビットのサポートは、TRILLバージョンのサブTLVのCapabilities and Header Flags Supportedフィールドの同じビット（27および28）で示されます。これらの機能でこれらのビットがゼロの場合、拡張カラーはサポートされません。拡張カラーをサポートしないTRILLスイッチは、TRILLデータパケットの一部として受信するTRILLヘッダーフラグワードの対応するビットを無視し、作成するTRILLヘッダーフラグワードでこれらのビットをゼロに設定します。 TRILLデータパケットの送信または受信時に拡張カラーフィールドを設定または感知するTRILLスイッチは、TRILLバージョンのサブTLVの対応する2ビットフィールドをゼロ以外の値に設定する必要があります。この2ビット機能フィールドの可能性のある3つのゼロ以外の値（0b01、0b10、または0b11）の意味の違いは、実装によって異なります。
With the changes above, the 32-bit flags word extension to the TRILL Header [RFC7179], which is detailed in the "TRILL Extended Header Flags" registry on the "Transparent Interconnection of Lots of Links (TRILL) Parameters" IANA web page, is now as follows:
上記の変更により、TRILLヘッダー[RFC7179]への32ビットフラグワード拡張。これは、「リンクの透過的な相互接続（TRILL）パラメーター」の透過的相互接続IANA Webページの「TRILL拡張ヘッダーフラグ」レジストリで詳しく説明されています。現在は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Crit.| CHbH | NCHbH |CRSV | NCRSV | CItE | NCItE |
|.....|.........|...........|.....|.......|...........|.........|
|C|C|C| |C|N| | Ext | | |Ext| |
|R|R|R| |R|C| | Hop | | |Clr| |
|H|I|R| |C|C| | Cnt | | | | |
|b|t|s| |A|A| | | | | | |
|H|E|v| |F|F| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bits 0, 1, and 2 are the critical summary bits, as specified in [RFC7179], consisting of the critical hop-by-hop, critical ingress-to-egress, and critical reserved bits, respectively. The next two fields are specific critical and non-critical hop-by-hop bits -- CHbH and NCHbH, respectively -- containing the Critical and Non-critical Channel Alert flags as specified in [RFC7179]. The next field is the critical reserved bits (CRSV), which are specified herein to be the Extended Hop Count. The non-critical reserved bits (NCRSV) and the critical ingress-to-egress bits (CItE) as specified in [RFC7179] follow. Finally, there is the non-critical ingress-to-egress field, including bits 27 and 28, which are specified herein as the Extended Color field.
ビット0、1、および2は、[RFC7179]で指定されているクリティカルサマリービットであり、クリティカルホップバイホップ、クリティカルな入力から出力、およびクリティカルな予約ビットでそれぞれ構成されています。次の2つのフィールドは、[RFC7179]で指定されているクリティカルおよび非クリティカルチャネルアラートフラグを含む、特定のクリティカルおよび非クリティカルホップバイホップビット（それぞれCHbHおよびNCHbH）です。次のフィールドはクリティカル予約ビット（CRSV）であり、拡張ホップカウントとしてここで指定されています。 [RFC7179]で指定されている非クリティカル予約ビット（NCRSV）とクリティカル入出力ビット（CItE）は次のとおりです。最後に、ビット27と28を含む非クリティカルな入力から出力へのフィールドがあり、ここでは拡張カラーフィールドとして指定されています。
Strict conformance to the provisions of Section 4.8.3 of [RFC6325] on the value of the Appointed Forwarder Status Lost Counter can result in the splitting of Interested VLANs and Spanning Tree Roots sub-TLVs [RFC7176] (or the corresponding Interested Labels and Spanning Tree Roots sub-TLVs where a VLAN is mapped to an FGL) due to differences in this counter value for adjacent VLAN IDs (or 24-bit FGLs). This counter is a mechanism to optimize data-plane learning by trimming the expiration timer for learned addresses on a per-VLAN/FGL basis under some circumstances.
Appointed Forwarder Status Lost Counterの値に関する[RFC6325]のセクション4.8.3の規定に厳密に準拠すると、関係するVLANとスパニングツリールートのサブTLV [RFC7176]（または対応する関係するラベルとスパニング）が分割される可能性があります。隣接するVLAN ID（または24ビットFGL）のこのカウンター値の違いによるツリールートサブTLV（VLANがFGLにマップされる）。このカウンタは、状況によっては、VLAN / FGLごとに学習済みアドレスの有効期限タイマーをトリミングして、データプレーン学習を最適化するメカニズムです。
The requirement to increment this counter by one whenever a TRILL switch loses Appointed Forwarder status on a port is hereby changed from the mandatory provisions of [RFC6325] to the enumerated provisions below. To the extent that this might cause the Appointed Forwarder Status Lost Counter to be increased when [RFC6325] indicates that it should not, this will cause data-plane address learning timeouts at remote TRILL switches to be reduced. To the extent that this might cause the Appointed Forwarder Status Lost Counter to remain unchanged when [RFC6325] indicates that it should be increased, this will defeat a reduction in such timeouts that would otherwise occur.
これにより、ポートでTRILLスイッチがAppointed Forwarderステータスを失うたびにこのカウンターを1つ増やす要件は、[RFC6325]の必須の規定から以下の列挙された規定に変更されます。これにより、Appointed Forwarder Status Lost Counterが増加しないように[RFC6325]が増加しないように指示した場合、リモートTRILLスイッチでのデータプレーンアドレス学習タイムアウトが減少します。これにより、Appointed Forwarder Status Lost Counterが変更されないままになる可能性があるため、[RFC6325]で増加する必要があると示されている場合、そうしないと発生するようなタイムアウトの削減が無効になります。
(1) If any of the following apply, either data-plane address learning is not in use or Appointed Forwarder status is irrelevant. In these cases, the Appointed Forwarder Status Lost Counter MAY be left at zero or set to any convenient value such as the value of the Appointed Forwarder Status Lost Counter for an adjacent VLAN ID or FGL.
（1）次のいずれかに該当する場合、データプレーンアドレスラーニングが使用されていないか、Appointed Forwarderステータスが無関係です。これらの場合、Appointed Forwarder Status Lost Counterは0のままにするか、隣接するVLAN IDまたはFGLのAppointed Forwarder Status Lost Counterの値などの便利な値に設定できます。
(1a) The TRILL switch port has been configured with the "end-station service disable" bit (also known as the trunk bit) on.
（1a）TRILLスイッチポートは、「end-station service disable」ビット（別名トランクビット）がオンに設定されています。
(1b) The TRILL switch port has been configured in IS-IS as an IS-IS point-to-point link.
（1b）TRILLスイッチポートがIS-ISでIS-ISポイントツーポイントリンクとして構成されている。
(1c) The TRILL switch is relying on ESADI [RFC7357] or Directory Assist [RFC7067] and not using data-plane learning.
（1c）TRILLスイッチは、ESADI [RFC7357]またはDirectory Assist [RFC7067]に依存しており、データプレーン学習を使用していません。
(2) In cases other than those enumerated in point 1 above, the Appointed Forwarder Status Lost Counter SHOULD be incremented as described in [RFC6325]. Such incrementing has the advantage of optimizing data-plane learning. Alternatively, the value of the Appointed Forwarder Status Lost Counter can deviate from that value -- for example, to make it match the value for an adjacent VLAN ID (or FGL), so as to permit greater aggregation of Interested VLANs and Spanning Tree Roots sub-TLVs.
（2）上記のポイント1で列挙されたもの以外の場合、Appointed Forwarder Status Lost Counterは、[RFC6325]で説明されているようにインクリメントされる必要があります。このような増分には、データプレーン学習を最適化するという利点があります。または、Appointed Forwarder Status Lost Counterの値がその値から逸脱している可能性があります。たとえば、隣接するVLAN ID（またはFGL）の値と一致させて、関係するVLANとスパニングツリールートの集約を増やすことができます。サブTLV。
This section lists IANA actions previously completed and new IANA actions.
このセクションでは、以前に完了したIANAアクションと新しいIANAアクションをリストします。
The following IANA actions were completed as part of [RFC7180] and are included here for completeness, since this document obsoletes [RFC7180].
次のIANAアクションは[RFC7180]の一部として完了しましたが、このドキュメントは[RFC7180]を廃止したため、完全を期すためにここに含めています。
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は、OOMF（過負荷発信マルチ宛先フレーム）を示すためにTRILLヘッダー出力ニックネームフィールドで使用するために割り当てられます。
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 [RFC6439bis]. The description of this bit is "Hello reduction support".
3. ビット0は、PORT-TRILL-VERサブTLV [RFC7176]の機能ビットから割り当てられ、指定されたVLANのサブTLV [RFC7176]および[RFC6439bis]で指定されたVLAN禁止設定メカニズムのサポートを示します。このビットの説明は、「Helloリダクションサポート」です。
The following are new IANA actions for this document.
このドキュメントの新しいIANAアクションは次のとおりです。
All references to [RFC7180] in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry have been replaced with references to this document, except that the Reference for bit 0 in the PORT-TRILL-VER Sub-TLV Capability Flags has been changed to [RFC6439bis].
「リンクの透過的相互接続（TRILL）パラメータ」レジストリの[RFC7180]への参照はすべて、このドキュメントへの参照に置き換えられました。ただし、PORT-TRILL-VERサブTLV機能フラグのビット0の参照には、 [RFC6439bis]に変更されました。
There is an existing TRILL version sub-TLV, sub-TLV #13, under both TLV #242 and TLV #144 [RFC7176]. This TRILL version sub-TLV contains a capability bits field for which assignments are documented in the "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters IANA web page. IANA has allocated 4 from the previously reserved bits in this "TRILL-VER Sub-TLV Capability Flags" registry to indicate support of the E-L1FS flooding scope as specified in Section 8.1. This capability bit is referred to as the "E" bit. The following is the addition to the "TRILL-VER Sub-TLV Capability Flags" registry:
TLV＃242とTLV＃144 [RFC7176]の両方の下に、既存のTRILLバージョンのサブTLV、サブTLV＃13があります。このTRILLバージョンのサブTLVには、割り当てがTRILL Parameters IANA Webページの「TRILL-VER Sub-TLV Capability Flags」レジストリに記載されている機能ビットフィールドが含まれています。 IANAは、この「TRILL-VER Sub-TLV Capability Flags」レジストリで以前に予約されていたビットから4を割り当てて、セクション8.1で指定されているE-L1FSフラッディングスコープのサポートを示しています。この機能ビットは「E」ビットと呼ばれます。以下は、「TRILL-VER Sub-TLV Capability Flags」レジストリへの追加です。
Bit Description References
---- --------------------- ---------------
4 E-L1FS FS-LSP support [RFC7356], RFC 7780
IANA has assigned an APPsub-TLV number, as follows, under the TRILL GENINFO TLV from the range less than 255.
IANAは、255未満の範囲からTRILL GENINFO TLVの下で、次のようにAPPsub-TLV番号を割り当てました。
Type Name References
---- --------- -----------
6 NICKFLAGS RFC 7780
In addition, IANA has created a registry on its TRILL Parameters web page for NickFlags bit assignments, as follows:
さらに、IANAは、NickFlagsビット割り当て用のTRILLパラメータWebページに次のようにレジストリを作成しました。
Name: NickFlags Bits Registration Procedure: IETF Review [RFC5226] Reference: RFC 7780
名前：NickFlagsビット登録手順：IETFレビュー[RFC5226]リファレンス：RFC 7780
Bit Mnemonic Description Reference
----- -------- ----------- ---------
0 IN Used as ingress RFC 7780
1-15 - Unassigned RFC 7780
The "TRILL Extended Header Flags" registry has been updated as follows:
"TRILL Extended Header Flags"レジストリが次のように更新されました。
Bits Purpose Reference
----- ---------------------------------------- ------------
14-16 Extended Hop Count RFC 7780
14-16拡張ホップカウントRFC 7780
27-28 Extended Color RFC 7780
27-28拡張カラーRFC 7780
29-31 Available non-critical ingress-to-egress [RFC7179], RFC 7780 flags
29-31利用可能な重要でない入力から出力[RFC7179]、RFC 7780フラグ
The "TRILL-VER Sub-TLV Capability Flags" registry has been updated as follows:
"TRILL-VER Sub-TLV Capability Flags"レジストリが次のように更新されました。
Bit Description Reference
----- -------------------------- ----------------
14 Extended Hop Count support RFC 7780
14 Extended Hop CountサポートRFC 7780
15-16 Unassigned RFC 7780
15-16未割り当てRFC 7780
27-28 Extended Color support RFC 7780
27-28拡張カラーサポートRFC 7780
29-31 Extended header flag support [RFC7179], RFC 7780
29-31拡張ヘッダーフラグのサポート[RFC7179]、RFC 7780
As shown in the table below, IANA has assigned a block of eight nicknames for use as examples in documentation. Appendix B shows a use of some of these nicknames. The "TRILL Nicknames" registry has been updated by changing the previous "0xFFC2-0xFFFE Unassigned" line to the following:
以下の表に示すように、IANAはドキュメントの例として使用するために、8つのニックネームのブロックを割り当てています。付録Bは、これらのニックネームの一部の使用法を示しています。 "TRILL Nicknames"レジストリは、以前の "0xFFC2-0xFFFE Unassigned"行を次のように変更することで更新されました。
Name Description Reference
------------- -------------- -----------
0xFFC2-0xFFD7 Unassigned
0xFFD8-0xFFDF For use in documentation examples RFC 7780
0xFFE0-0xFFFE Unassigned
See [RFC6325] for general TRILL security considerations.
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
This memo improves the documentation of the TRILL protocol; corrects six errata in [RFC6325]; updates [RFC6325], [RFC7177], and [RFC7179]; and obsoletes [RFC7180]. It does not change the security considerations of those RFCs, except as follows:
このメモはTRILLプロトコルのドキュメントを改善します。 [RFC6325]の6つのエラッタを修正しました。 [RFC6325]、[RFC7177]、および[RFC7179]を更新します。廃止されました[RFC7180]。次の場合を除き、これらのRFCのセキュリティに関する考慮事項は変更されません。
o E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310], that is, through the inclusion of an IS-IS Authentication TLV in E-L1FS PDUs.
o E-L1FS FS-LSPは、IS-ISセキュリティ[RFC5310]で、つまりE-L1FS PDUにIS-IS認証TLVを含めることで認証できます。
o As discussed in Section 3.6, when using an allowed weaker RPF check under very rare topologies and transient conditions, multi-destination TRILL Data packets can be duplicated; this could have security consequences for some protocols.
o セクション3.6で説明したように、非常にまれなトポロジーと一時的な条件で許可された弱いRPFチェックを使用すると、複数の宛先のTRILLデータパケットが複製される可能性があります。これは、一部のプロトコルにセキュリティ上の結果をもたらす可能性があります。
[802.1Q-2014] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2014.6991462, IEEE Std 802.1Q-2014.
[802.1Q-2014] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks」、DOI 10.1109 / IEEESTD.2014.6991462、IEEE Std 802.1Q-2014。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- 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)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、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>。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<http://www.rfc-editor.org/info/rfc5305> 。
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", RFC 5306, DOI 10.17487/RFC5306, October 2008, <http://www.rfc-editor.org/info/rfc5306>.
[RFC5306] Shand、M。およびL. Ginsberg、「Restart Signaling for IS-IS」、RFC 5306、DOI 10.17487 / RFC5306、2008年10月、<http://www.rfc-editor.org/info/rfc5306>。
[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>。
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, <http://www.rfc-editor.org/info/rfc6232>.
[RFC6232] Wei、F.、Qin、Y.、Li、Z.、Li、T。、およびJ. Dong、「IS-ISのパージ発信者識別TLV」、RFC 6232、DOI 10.17487 / RFC6232、2011年5月、 <http://www.rfc-editor.org/info/rfc6232>。
[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>。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <http://www.rfc-editor.org/info/rfc6361>.
[RFC6361]カールソン、J。およびD.イーストレイク3rd、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、DOI 10.17487 / RFC6361、2011年8月、<http：//www.rfc-editor .org / info / rfc6361>。
[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>。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, DOI 10.17487/RFC7179, May 2014, <http://www.rfc-editor.org/info/rfc7179>.
[RFC7179] Eastlake 3rd、D.、Ghanwani、A.、Manral、V.、Li、Y.、and C. Bestler、 "Transparent Interconnection of Lots of Links（TRILL）：Header Extension"、RFC 7179、DOI 10.17487 / RFC7179、2014年5月、<http://www.rfc-editor.org/info/rfc7179>。
[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フラッディングスコープリンクステートPDU（LSP）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// www。 rfc-editor.org/info/rfc7356>。
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
[RFC7455] Senevirathne、T.、Finn、N.、Salam、S.、Kumar、D.、Eastlake 3rd、D.、Aldrin、S。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：障害管理」、RFC 7455、DOI 10.17487 / RFC7455、2015年3月、<http://www.rfc-editor.org/info/rfc7455>。
[802] IEEE 802, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.
[802] IEEE 802、「IEEE Standard for Local and Metropolitan Area Networks：Overview and Architecture」、DOI 10.1109 / IEEESTD.2014.6847097、IEEE Std 802-2014。
[Centralized-Replication] Hao, W., Li, Y., Durrani, M., Gupta, S., Qu, A., and T. Han, "Centralized Replication for BUM traffic in active-active edge connection", Work in Progress, draft-ietf-trill-centralized-replication-03, November 2015.
[集中レプリケーション] Hao、W.、Li、Y.、Durrani、M.、Gupta、S.、Qu、A.、T。Han、「アクティブ-アクティブエッジ接続でのBUMトラフィックの集中レプリケーション」、作業進行中、draft-ietf-trill-centralized-replication-03、2015年11月。
[Err3002] RFC Errata, Erratum ID 3002, RFC 6325.
[Err3002] RFC Errata、Erratum ID 3002、RFC 6325。
[Err3003] RFC Errata, Erratum ID 3003, RFC 6325.
[Err3003] RFC Errata、Erratum ID 3003、RFC 6325。
[Err3004] RFC Errata, Erratum ID 3004, RFC 6325.
[Err3004] RFC Errata、Erratum ID 3004、RFC 6325。
[Err3052] RFC Errata, Erratum ID 3052, RFC 6325.
[Err3052] RFC Errata、Erratum ID 3052、RFC 6325。
[Err3053] RFC Errata, Erratum ID 3053, RFC 6325.
[Err3053] RFC Errata、Erratum ID 3053、RFC 6325。
[Err3508] RFC Errata, Erratum ID 3508, RFC 6325.
[Err3508] RFC Errata、Erratum ID 3508、RFC 6325。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<http://www.rfc-editor.org/info/rfc792>。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[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>。
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 6327, DOI 10.17487/RFC6327, July 2011, <http://www.rfc-editor.org/info/rfc6327>.
[RFC6327] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Dutt、D.、and V. Manral、 "Routing Bridges（RBridges）：Adjacency"、RFC 6327、DOI 10.17487 / RFC6327、July 2011、 <http://www.rfc-editor.org/info/rfc6327>。
[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>。
[RFC6439bis] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and H. Fangwei, "TRILL: Appointed Forwarders", Work in Progress, draft-ietf-trill-rfc6439bis-01, January 2016.
[RFC6439bis] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and H. Fangwei、 "TRILL：Appointed Forwarders"、Work in Progress、draft-ietf-trill-rfc6439bis-01、 2016年1月。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<http：//www.rfc -editor.org/info/rfc7042>。
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067] Dunbar、L.、Eastlake 3rd、D.、Perlman、R。、およびI. Gashinsky、「Directory Assistance Problem and High-Level Design Proposal」、RFC 7067、DOI 10.17487 / RFC7067、2013年11月、<http： //www.rfc-editor.org/info/rfc7067>。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「多数のリンクの透過的相互接続（TRILL）：双方向転送検出（BFD）サポート」、RFC 7175、DOI 10.17487 / RFC7175、2014年5月、<http://www.rfc-editor.org/info/rfc7175>。
[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>。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, DOI 10.17487/RFC7180, May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、DOI 10.17487 / RFC7180、2014年5月、<http://www.rfc-editor.org/info/rfc7180>。
[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>。
[TRILL-L3-GW] Hao, W., Li, Y., Qu, A., Durrani, M., Sivamurugan, P., and L. Xia, "TRILL Distributed Layer 3 Gateway", Work in Progress, draft-ietf-trill-irb-10, January 2016.
[TRILL-L3-GW] Hao、W.、Li、Y.、Qu、A.、Durrani、M.、Sivamurugan、P。、およびL. Xia、「TRILL Distributed Layer 3 Gateway」、作業中、ドラフト-ietf-trill-irb-10、2016年1月。
Appendix A. Life Cycle of a TRILL Switch Port (New)
付録A. TRILLスイッチポートのライフサイクル（新規）
Text from <http://www.ietf.org/mail-archive/web/trill/ current/msg06355.html> is paraphrased in this informational appendix.
<http://www.ietf.org/mail-archive/web/trill/ current / msg06355.html>からのテキストは、この情報付録で言い換えられています。
Question: Suppose we are developing a TRILL implementation to run on different machines. Then what happens first? Is LSP flooding or ESADI started first? -> Link-state database creation -> Designated RBridge election (How to set priority? Any fixed process that depends on user settings?) -> etc.
質問：さまざまなマシンで実行するTRILL実装を開発しているとします。次に、最初に何が起こりますか？ LSPフラッディングまたはESADIが最初に開始されますか？ ->リンクステートデータベースの作成->指定されたRBridge選択（優先度の設定方法？ユーザー設定に依存する固定プロセス？）->など
Answer: The first thing that happens on a port/link is any link setup that is needed. For example, on a PPP link [RFC6361], you need to negotiate that you will be using TRILL. However, if you have Ethernet links [RFC6325], which are probably the most common type, there isn't any link setup needed.
回答：ポート/リンクで最初に発生するのは、必要なリンク設定です。たとえば、PPPリンク[RFC6361]では、TRILLを使用することを交渉する必要があります。ただし、おそらく最も一般的なタイプであるイーサネットリンク[RFC6325]がある場合、リンクの設定は必要ありません。
As soon as the port is set up, it can ingress or egress native frames if end-station service is being offered on that port. Offering end-station service is the default. However, if the port trunk bit (end-station service disable) is set or the port is configured as an IS-IS point-to-point link port, then end-station service is not offered; therefore, native frames received are ignored, and native frames are not egressed.
ポートがセットアップされるとすぐに、そのポートで端末サービスが提供されている場合は、ネイティブフレームに出入りできます。端末サービスを提供することがデフォルトです。ただし、ポートトランクビット（エンドステーションサービスの無効化）が設定されている場合、またはポートがIS-ISポイントツーポイントリンクポートとして構成されている場合、エンドステーションサービスは提供されません。したがって、受信されたネイティブフレームは無視され、ネイティブフレームは出力されません。
TRILL IS-IS Hellos then get sent out the port to be exchanged with any other TRILL switches on the link [RFC7177]. Only the Hellos are required; optionally, you might also exchange MTU-probe/ack PDUs [RFC7177], BFD PDUs [RFC7175], or other link test packets.
TRILL IS-IS Hellosはポートから送信され、リンク上の他のTRILLスイッチと交換されます[RFC7177]。 Helloのみが必要です。オプションで、MTU-probe / ack PDU [RFC7177]、BFD PDU [RFC7175]、または他のリンクテストパケットを交換することもできます。
TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the port to the link, except for Hellos, until the link gets to the 2-Way or Report state [RFC7177].
TRILLは、Helloを除いて、リンクが双方向またはレポート状態になるまで、TRILLデータまたはTRILL IS-ISパケットをポートからリンクに送信しません[RFC7177]。
If a link is configured as a point-to-point link, there is no Designated RBridge (DRB) election. By default, an Ethernet link is considered a LAN link, and the DRB election occurs when the link is in any state other than Down. You don't have to configure priorities for each TRILL switch (RBridge) to be the DRB. Things will work fine with all the RBridges on a link using default priority. But if the network manager wants to control this, there should be a way for them to configure the priority to be the DRB of the TRILL switch ports on the link.
リンクがポイントツーポイントリンクとして構成されている場合、指定RBridge（DRB）の選択は行われません。デフォルトでは、イーサネットリンクはLANリンクと見なされ、リンクがダウン以外の状態のときにDRB選定が行われます。各TRILLスイッチ（RBridge）がDRBになるように優先順位を構成する必要はありません。デフォルトの優先順位を使用して、リンク上のすべてのRBridgeで正常に動作します。しかし、ネットワーク管理者がこれを制御したい場合は、リンク上のTRILLスイッチポートのDRBになるように優先度を構成する方法が必要です。
(To avoid complexity, this appendix generally describes the life cycle for a link that only has two TRILL switches on it. But TRILL works fine as currently specified on a broadcast link with multiple TRILL switches on it -- actually, multiple TRILL switch ports -- since a TRILL switch can have multiple ports connected to the same link. The most likely way to get such a multi-access link with current technology and the existing TRILL standards is to have more than two TRILL switch Ethernet ports connected to a bridged LAN. The TRILL protocol operates above all bridging; in general, the bridged LAN looks like a transparent broadcast link to TRILL.)
（複雑さを回避するために、この付録では一般に、2つのTRILLスイッチのみが存在するリンクのライフサイクルについて説明します。ただし、現在TRILLスイッチが複数あるブロードキャストリンクで指定されているとおり、TRILLは正常に機能します。実際には、複数のTRILLスイッチポート- -TRILLスイッチは複数のポートを同じリンクに接続できるため、現在のテクノロジーと既存のTRILL標準でこのようなマルチアクセスリンクを取得する最も可能性の高い方法は、ブリッジLANに接続された3つ以上のTRILLスイッチイーサネットポートを使用することです。 。TRILLプロトコルはすべてのブリッジングよりも上で動作します。一般に、ブリッジドLANはTRILLへの透過的なブロードキャストリンクのように見えます。）
When a link gets to the 2-Way or Report state, LSPs, CSNPs, and PSNPs will start to flow on the link (as well as FS-LSPs, FS-CSNPs, and FS-PSNPs for E-L1FS (see Section 8.1)).
リンクが2-WayまたはReport状態になると、LSP、CSNP、およびPSNPがリンク（およびE-L1FSのFS-LSP、FS-CSNP、およびFS-PSNPと同様に）を流れ始めます（セクション8.1を参照） ））。
When a link gets to the Report state, there is adjacency. The existence of that adjacency is flooded (reported) to the campus in LSPs. TRILL Data packets can then start to flow on the link as TRILL switches recalculate the least-cost paths and distribution trees to take the new adjacency into account. Until it gets to the Report state, there is no adjacency, and no TRILL Data packets can flow over that link (with the minor corner case exception that an RBridge Channel message can, for its first hop only, be sent on a port where there is no adjacency (Section 2.4 of [RFC7178]). (Although this paragraph seems to be talking about link state, it is actually port state. It is possible for different TRILL switch ports on the same link to temporarily be in different states. The adjacency state machinery runs independently on each port.)
リンクがReport状態になると、隣接関係があります。その隣接の存在は、LSPのキャンパスにフラッディング（報告）されます。 TRILLスイッチが最小隣接パスと分散ツリーを再計算して新しい隣接関係を考慮に入れると、TRILLデータパケットはリンク上を流れ始めます。 Report状態になるまで、隣接関係はなく、TRILLデータパケットはそのリンクを介してフローできません（マイナーなコーナーケースの例外を除いて、RBridgeチャネルメッセージは、最初のホップについてのみ、そのポートに送信できますは隣接していません（[RFC7178]のセクション2.4）。（この段落はリンク状態について話しているようですが、実際にはポートの状態です。同じリンク上の異なるTRILLスイッチポートが一時的に異なる状態になる可能性があります。隣接状態機構は、各ポートで独立して実行されます。）
ESADI [RFC7357] is built on top of the regular TRILL Data routing. Since ESADI PDUs look, to transit TRILL switches, like regular TRILL Data packets, no ESADI PDUs can flow until adjacencies are established and TRILL Data is flowing. Of course, ESADI is optional and is not used unless configured.
ESADI [RFC7357]は、通常のTRILLデータルーティングの上に構築されています。 ESADI PDUは通常のTRILLデータパケットのようにTRILLスイッチを通過するように見えるため、隣接関係が確立されてTRILLデータが流れるまでESADI PDUは流れません。もちろん、ESADIはオプションであり、構成されない限り使用されません。
Question: Does it require TRILL Full Headers at the time TRILL LSPs start being broadcast on a link? Because at that time it's not defined egress and ingress nicknames.
質問：TRILL LSPがリンクでブロードキャストを開始するときに、TRILLフルヘッダーが必要ですか？なぜならそれは下りと上りのニックネームが定義されていないからです。
Answer: TRILL Headers are only for TRILL Data packets. TRILL IS-IS packets, such as TRILL LSPs, are sent in a different way that does not use a TRILL Header and does not depend on nicknames.
回答：TRILLヘッダーはTRILLデータパケット専用です。 TRILL LSPなどのTRILL IS-ISパケットは、TRILLヘッダーを使用せず、ニックネームに依存しない別の方法で送信されます。
Probably, in most implementations, a TRILL switch will start up using the same nickname it had when it shut down or last got disconnected from a campus. If you want, you can implement TRILL to come up initially not reporting any nickname (by not including a Nickname sub-TLV in its LSPs) until you get the link-state database or most of the link-state database, and then choose a nickname no other TRILL switch in the campus is using. Of course, if a TRILL switch does not have a nickname, then it cannot ingress data, cannot egress known unicast data, and cannot be a tree root.
おそらく、ほとんどの実装では、TRILLスイッチは、シャットダウンしたとき、または最後にキャンパスから切断されたときと同じニックネームを使用して起動します。必要に応じて、リンク状態データベースまたはほとんどのリンク状態データベースを取得するまで、ニックネームサブTLVをLSPに含めないことでニックネームを報告せずに起動するようにTRILLを実装できます。キャンパス内の他のTRILLスイッチが使用しているニックネーム。もちろん、TRILLスイッチにニックネームがない場合、データを入力できず、既知のユニキャストデータを出力できず、ツリールートになることもできません。
TRILL IS-IS PDUs such as LSPs, and the link-state database, all work based on the 7-byte IS-IS System ID (sometimes called the LAN ID [IS-IS]). Since topology determination uses System IDs, which are always unique across the campus, it is not affected by the nickname assignment state. The nickname system is built on top of that.
LSPなどのTRILL IS-IS PDUやリンク状態データベースは、すべて7バイトのIS-ISシステムID（LAN ID [IS-IS]と呼ばれることもある）に基づいて機能します。トポロジーの決定には、キャンパス全体で常に一意のシステムIDが使用されるため、ニックネームの割り当て状態の影響を受けません。ニックネームシステムはその上に構築されます。
Appendix B. Example TRILL PDUs (New)
付録B. TRILL PDUの例（新規）
This appendix shows example TRILL IS-IS PDUs. The primary purpose of these examples is to clarify issues related to bit ordering.
この付録では、TRILL IS-IS PDUの例を示します。これらの例の主な目的は、ビット順序に関連する問題を明確にすることです。
The examples in this appendix concentrate on the format of the packet header and trailer. There are frequently unspecified optional items or data in the packet that would affect header or trailer fields like the packet length or checksum. Thus, an "Xed out" placeholder is used for such fields, where each X represents one hex nibble.
この付録の例は、パケットのヘッダーとトレーラーのフォーマットに集中しています。パケットの長さやチェックサムなどのヘッダーまたはトレーラーフィールドに影響を与えるパケットには、多くの場合、指定されていないオプションの項目またはデータがあります。したがって、そのようなフィールドには「Xed out」プレースホルダーが使用され、各Xは1つの16進ニブルを表します。
A TRILL Hello sent from a TRILL switch (RBridge) with 7-byte System ID 0x30033003300300 holding nickname 0xFFDE over Ethernet from a port with MAC address 0x00005E0053DE on VLAN 1 at priority 7. There is one neighbor that is the DRB. The neighbor's port MAC is 0x00005E0053E3, and the neighbor's System ID is 0x44444444444400.
VLAN 1のMACアドレス0x00005E0053DEを持つポートからイーサネット経由でニックネーム0xFFDEを保持する7バイトのシステムID 0x30033003300300を持つTRILLスイッチ（RBridge）から優先度7で送信されたTRILLHello。DRBであるネイバーが1つあります。ネイバーのポートMACは0x00005E0053E3であり、ネイバーのシステムIDは0x44444444444400です。
Ethernet Header Outer.MacDA, Outer.MacSA 0x0180C2000041 All-IS-IS-RBridges Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0xE001 Priority 7, Outer.VLAN IS-IS 0x22F4 L2-IS-IS Ethertype IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x0F PDU Type (Level 1 LAN Hello) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses Hello PDU Specific Fields 0x01 Circuit Type (Level 1) 0x30033003300300 Source System ID 0x0009 Holding Time 0xXXXX PDU Length 0x40 Priority to be DRB 0x44444444444400 LAN ID TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant)
イーサネットヘッダーOuter.MacDA、Outer.MacSA 0x0180C2000041 All-IS-IS-RBridges Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag（optional）0x8100 C-VLAN Ethertype [802.1Q-2014] 0xE001 Priority 7、Outer.VLAN IS- IS 0x22F4 L2-IS-IS Ethertype IS-IS Payload Common Header 0x83 Intradomain Routing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x0F PDU Type（Level 1 LAN Hello）0x01 Version 0x00 Reserved 0x01 Maximum AreaアドレスHello PDU固有のフィールド0x01回線タイプ（レベル1）0x30033003300300送信元システムID 0x0009保持時間0xXXXX PDU長さ0x40優先度はDRB 0x44444444444400 LAN ID TLV（次のTLVまたはTLVのサブTLVの順序は重要ではありません）
Area Addresses TLV 0x01 Area Addresses Type 0x02 Length of Value 0x01 Length of Address 0x00 The fixed TRILL Area Address MT Port Capabilities TLV 0x8F MT Port Capabilities Type 0x0011 Length of Value 0x0000 Topology Special VLANs and Flags Sub-TLV 0x01 Sub-TLV Type 0x08 Length 0x0123 Port ID 0xFFDE Sender Nickname 0x0001 Outer.VLAN 0x0001 Designated VLAN Enabled VLANs Sub-TLV (optional) 0x02 Sub-TLV Type 0x03 Length 0x0001 Start VLAN 1 0x80 VLAN 1 TRILL Neighbor TLV 0x91 Neighbor Type 0x0A Length of Value 0xC0 S Flag = 1, L Flag = 1, SIZE field 0 NEIGHBOR RECORD 0x00 Flags 0x2328 MTU = 9 KB 0x00005E0053E3 Neighbor MAC Address Scope Flooding Support TLV 0xF3 Scope Flooding Support Type 0x01 Length of Value 0x40 E-L1FS Flooding Scope More TLVs (optional) ... Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
エリアアドレスTLV 0x01エリアアドレスタイプ0x02値の長さ0x01アドレスの長さ0x00固定TRILLエリアアドレスMTポート機能TLV 0x8F MTポート機能タイプ0x0011値の長さ0x0000トポロジ特殊なVLANおよびフラグサブTLV 0x01サブTLVタイプ0x08長さ0x0123ポートID 0xFFDE送信者ニックネーム0x0001 Outer.VLAN 0x0001指定VLAN有効VLANサブTLV（オプション）0x02サブTLVタイプ0x03長さ0x0001開始VLAN 1 0x80 VLAN 1 TRILLネイバーTLV 0x91ネイバータイプ0x0A値の長さ0xC0 Sフラグ= 1 、Lフラグ= 1、SIZEフィールド0 NEIGHBOR RECORD 0x00フラグ0x2328 MTU = 9 KB 0x00005E0053E3ネイバーMACアドレススコープフラッディングサポートTLV 0xF3スコープフラッディングサポートタイプ0x01値の長さ0x40 E-L1FSフラッディングスコープその他のTLV（オプション）...イーサネットトレーラー0xXXXXXXXXイーサネットフレームチェックシーケンス（FCS）
Here is an example of a TRILL LSP sent over a PPP link by the same source TRILL switch as the example in Appendix B.1.
付録B.1の例と同じソースTRILLスイッチによってPPPリンクを介して送信されたTRILL LSPの例を次に示します。
PPP Header 0x405D PPP TRILL Link State Protocol IS-IS Payload Common Header 0x83 Intradomain Routeing Protocol Discriminator 0x08 Header Length 0x01 IS-IS Version Number 0x06 ID Length of 6 Bytes 0x12 PDU Type (Level 1 LSP) 0x01 Version 0x00 Reserved 0x01 Maximum Area Addresses LSP Specific Fields 0xXXXX PDU Length 0x0123 Remaining Lifetime 0x3003300330030009 LSP ID (fragment 9) 0x00001234 Sequence Number 0xXXXX Checksum 0x01 Flags = Level 1 TLVs (the following order of TLVs or of sub-TLVs in a TLV is not significant) Router Capability TLV 0xF2 Router Capability Type 0x0F Length of Value 0x00 Flags Nickname Sub-TLV 0x06 Sub-TLV Type 0x05 Length of Value NICKNAME RECORD 0x33 Nickname Priority 0x1234 Tree Root Priority 0xFFDE Nickname TRILL Version Sub-TLV 0x0D Sub-TLV Type 0x05 0x00 Max Version 0x40000000 Flags = FGL Support More TLVs (optional ... PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
PPPヘッダー0x405D PPP TRILLリンク状態プロトコルIS-ISペイロード共通ヘッダー0x83ドメイン内ルーティングプロトコルディスクリミネーター0x08ヘッダー長0x01 IS-ISバージョン番号0x06 6バイトのID長0x12 PDUタイプ（レベル1 LSP）0x01バージョン0x00予約済み0x01最大エリアアドレスLSP固有のフィールド0xXXXX PDUの長さ0x0123残りのライフタイム0x3003300330030009 LSP ID（フラグメント9）0x00001234シーケンス番号0xXXXXチェックサム0x01フラグ=レベル1 TLV（TLVの次の順序またはTLVのサブTLVの順序は重要ではありません）ルータ機能TLV 0xF2ルータ機能タイプ0x0F値の長さ0x00フラグニックネームサブTLV 0x06サブTLVタイプ0x05値の長さNICKNAME RECORD 0x33ニックネーム優先度0x1234ツリールート優先度0xFFDEニックネームTRILLバージョンサブTLV 0x0DサブTLVタイプ0x05 0x00最大バージョン0x40000000フラグ= FGLより多くのTLVをサポート（オプション... PPPトレーラー0xXXXXXX PPPフレームチェックシーケンス（FCS）
Below is an IPv4 ICMP Echo [RFC792] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 to the neighbor TRILL switch on the link used in Appendix B.1.
以下は、付録B.1のHelloを付録B.1で使用されているリンクの隣接TRILLスイッチに送信したTRILLスイッチからTRILLデータパケットで送信されたIPv4 ICMPエコー[RFC792]です。
Ethernet Header Outer.MacDA, Outer.MacSA 0x00005E0053E3 Destination MAC Address 0x00005E0053DE Source MAC Address Outer VLAN Tag (optional) 0x8100 C-VLAN Ethertype [802.1Q-2014] 0x0001 Priority 0, Outer.VLAN 1 TRILL 0x22F3 TRILL Ethertype TRILL Header 0X000E Flags, Hop Count 14 0xFFDF Egress Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0x00005E005322 Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0800 IPv4 Ethertype IP Header 0x4500 Version 4, Header Length 5, ToS 0 0xXXXX Total Length 0x3579 Identification 0x0000 Flags, Fragment Offset 0x1101 TTL 17, ICMP = Protocol 1 0xXXXX Header Checksum 0xC0000207 Source IP 192.0.2.7 0xC000020D Destination IP 192.0.2.13 0x00000000 Options, Padding ICMP 0x0800 ICMP Echo 0xXXXX Checksum 0x87654321 Identifier, Sequence Number ... Echo Data Ethernet Trailer 0xXXXXXXXX Ethernet Frame Check Sequence (FCS)
イーサネットヘッダーOuter.MacDA、Outer.MacSA 0x00005E0053E3宛先MACアドレス0x00005E0053DE送信元MACアドレス外部VLANタグ（オプション）0x8100 C-VLAN Ethertype [802.1Q-2014] 0x0001優先度0、Outer.VLAN 1 TRILL 0x22F3 TRILL Ethertype TRILLヘッダー0X000Eフラグ、ホップカウント14 0xFFDF Egress Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA、Inner.MacSA 0x00005E005322 Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0、Inner.VLAN 34 Ethertype 0x0800 IPv4 Ethertype IP Header 0x4500バージョン4、ヘッダー長5、ToS 0 0xXXXX全長0x3579識別0x0000フラグ、フラグメントオフセット0x1101 TTL 17、ICMP =プロトコル1 0xXXXXヘッダーチェックサム0xC0000207ソースIP 192.0.2.7 0xC000020D宛先IP 192.0.2.13 0x00000000オプション、パディングICMP 0x0800 ICMPエコー0xXXXXチェックサム0x87654321識別子、シーケンス番号...エコーデータイーサネットトレーラー0xXXXXXXXXイーサネットフレームチェックシーケンス（FCS）
Below is an ARP Request [RFC826] sent in a TRILL Data packet from the TRILL switch that sent the Hello in Appendix B.1 over a PPP link.
以下は、付録B.1のHelloをPPPリンク経由で送信したTRILLスイッチからTRILLデータパケットで送信されたARP要求[RFC826]です。
PPP Header 0x005D PPP TRILL Network Protocol TRILL Header 0X080D Flags (M = 1), Hop Count 13 0xFFDD Distribution Tree Root Nickname 0xFFDC Ingress Nickname Inner Ethernet Header Inner.MacDA, Inner.MacSA 0xFFFFFFFFFFFF Destination MAC Address 0x00005E005344 Source MAC Address Inner VLAN Tag 0x8100 C-VLAN Ethertype 0x0022 Priority 0, Inner.VLAN 34 Ethertype 0x0806 ARP Ethertype ARP 0x0001 Hardware Address Space = Ethernet 0x0001 Protocol Address Space = IPv4 0x06 Size of Hardware Address 0x04 Size of Protocol Address 0x0001 OpCode = Request 0x00005E005344 Sender Hardware Address 0xC0000207 Sender Protocol Address 192.0.2.7 0x000000000000 Target Hardware Address 0xC000020D Target Protocol Address 192.0.2.13 PPP Trailer 0xXXXXXX PPP Frame Check Sequence (FCS)
PPPヘッダー0x005D PPP TRILLネットワークプロトコルTRILLヘッダー0X080Dフラグ（M = 1）、ホップカウント13 0xFFDD配布ツリールートニックネーム0xFFDC入力ニックネーム内部イーサネットヘッダーInner.MacDA、Inner.MacSA 0xFFFFFFFFFFFF宛先MACアドレス0x00005E005344ソースMACアドレス内部VLANタグ0x8100 C-VLAN Ethertype 0x0022 Priority 0、Inner.VLAN 34 Ethertype 0x0806 ARP Ethertype ARP 0x0001 Hardware Address Space = Ethernet 0x0001 Protocol Address Space = IPv4 0x06 Size of Hardware Address 0x04 Size of Protocol Address 0x0001 OpCode = Request 0x00005E005344 Sender Hardware Address 0xC0000207 Sender Protocolアドレス192.0.2.7 0x000000000000ターゲットハードウェアアドレス0xC000020Dターゲットプロトコルアドレス192.0.2.13 PPPトレーラー0xXXXXXX PPPフレームチェックシーケンス（FCS）
Appendix C. Changes to Previous RFCs (New)
付録C.以前のRFCの変更（新規）
This section summarizes the changes, augmentations, and excisions this document specifies for [RFC7180], which it obsoletes and replaces.
このセクションでは、このドキュメントが[RFC7180]に指定する変更、拡張、および削除について要約します。これらは廃止され、置き換えられます。
For each section header in this document ending with "(Changed)", this section summarizes the changes that are made by this document:
このドキュメントの「（変更済み）」で終わるセクションヘッダーごとに、このセクションでは、このドキュメントによって行われた変更の概要を示します。
Section 1 ("Introduction"): Numerous changes to reflect the overall changes in contents.
セクション1（「はじめに」）：内容の全体的な変更を反映するための多数の変更。
Section 1.1 ("Precedence"): Changed to add mention of [RFC7179].
セクション1.1（「優先順位」）：[RFC7179]の言及を追加するように変更。
Section 1.3 ("Terminology and Acronyms"): Numerous terms added.
セクション1.3（「用語と略語」）：多数の用語が追加されました。
Section 3 ("Distribution Trees and RPF Check"): Changed by the addition of the new material in Section 3.6. See Appendix C.1.2, Item 1.
セクション3（「配布ツリーとRPFチェック」）：セクション3.6の新しい資料の追加によって変更されました。付録C.1.2、アイテム1を参照してください。
Section 8 ("Other IS-IS Considerations"): Changed by the addition of Sections 8.1, 8.2, 8.3, and 8.4. See Appendix C.1.2 -- Items 2, 3, 4, and 5, respectively.
セクション8（「その他のIS-ISの考慮事項」）：セクション8.1、8.2、8.3、および8.4の追加により変更。付録C.1.2-項目2、3、4、および5をそれぞれ参照してください。
Section 9 ("Updates to RFC 7177 (Adjacency)": Changes and additions to [RFC7177] to support E-L1FS. See Appendix C.1.2, Item 2.
セクション9（「RFC 7177（隣接関係）の更新」：E-L1FSをサポートするための[RFC7177]への変更と追加。付録C.1.2、項目2を参照してください。
Section 12 ("IANA Considerations"): Changed by the addition of material in Section 12.2. See Appendix C.1.2, Item 7.
セクション12（「IANAの考慮事項」）：セクション12.2での資料の追加により変更。付録C.1.2、アイテム7を参照してください。
Section 13 ("Security Considerations"): Minor changes in the RFCs listed.
セクション13（「セキュリティに関する考慮事項」）：リストされているRFCのマイナー変更。
This document contains the following material not present in [RFC7180]:
このドキュメントには、[RFC7180]にはない次の資料が含まれています。
1. Support for an alternative Reverse Path Forwarding Check (RPFC), along with considerations for deciding between the original [RFC6325] RPFC and this alternative RPFC. This alternative RPFC was originally discussed on the TRILL WG mailing list in <http://www.ietf.org/mail-archive/web/trill/current/ msg01852.html> and subsequent messages (Section 3.6).
1. 元の[RFC6325] RPFCとこの代替RPFCの間の決定に関する考慮事項とともに、代替のリバースパス転送チェック（RPFC）のサポート。この代替RPFCは、<http://www.ietf.org/mail-archive/web/trill/current/ msg01852.html>のTRILL WGメーリングリストとその後のメッセージ（セクション3.6）で最初に議論されました。
2. Mandatory E-L1FS [RFC7356] support (Sections 8.1 and 9).
2. 必須のE-L1FS [RFC7356]サポート（セクション8.1および9）。
3. Recommendations concerning control packet priorities (Section 8.2).
3. 制御パケットの優先順位に関する推奨事項（セクション8.2）。
4. Implementation requirements concerning unknown IS-IS PDU types (Section 8.3).
4. 不明なIS-IS PDUタイプに関する実装要件（セクション8.3）。
5. Specification of an optional Nickname Flags APPsub-TLV and an ingress flag within that APPsub-TLV (Section 8.4).
5. オプションのニックネームフラグAPPsub-TLVとそのAPPsub-TLV内の入力フラグの指定（セクション8.4）。
6. Update to the TRILL Header to allocate a Color bit (Section 10.1), and update to the optional TRILL Header Extension flags word to allocate a 2-bit Extended Color field (Section 10.2).
6. TRILLヘッダーを更新してカラービットを割り当て（セクション10.1）、オプションのTRILLヘッダー拡張フラグワードを更新して2ビットの拡張カラーフィールドを割り当てます（セクション10.2）。
7. Some new IANA Considerations in Section 12.2, including reservation of nicknames for use as examples in documentation.
7. ドキュメンテーションの例として使用するためのニックネームの予約を含む、セクション12.2のいくつかの新しいIANAの考慮事項。
8. A new "Appointed Forwarder Status Lost Counter" section (Section 11 of this document) that loosens the mandatory update requirements specified in [RFC6325].
8. [RFC6325]で指定されている必須の更新要件を緩和する新しい「Appointed Forwarder Status Lost Counter」セクション（このドキュメントのセクション11）。
9. Informative Appendix A on the life cycle of a TRILL port.
9. TRILLポートのライフサイクルに関する有益な付録A。
10. A new Appendix B containing example TRILL PDUs.
10. TRILL PDUの例を含む新しい付録B。
11. Recommendation to use the Purge Originator Identification TLV (Section 8.6).
11. Purge Originator Identification TLV（セクション8.6）の使用を推奨。
This document omits the following material that was present in [RFC7180]:
このドキュメントでは、[RFC7180]に存在していた次の資料を省略しています。
1. All updates to [RFC6327] that occurred in [RFC7180]. These have been rolled into [RFC7177], which obsoletes [RFC6327]. However, new updates to [RFC7177] are included (see Appendix C.3).
1. [RFC7180]で発生した[RFC6327]へのすべての更新。これらは[RFC7177]にまとめられ、[RFC6327]は廃止されました。ただし、[RFC7177]の新しい更新が含まれています（付録C.3を参照）。
2. All updates to [RFC6439]. These have been rolled into [RFC6439bis], which is intended to obsolete [RFC6439].
2. [RFC6439]のすべての更新。これらは[RFC6439bis]に組み込まれ、[RFC6439]の廃止を意図しています。
This document contains many normative updates to [RFC6325], some of which were also in [RFC7180], which this document replaces. These changes include the following:
この文書には、[RFC6325]に対する多くの規範的な更新が含まれており、その一部は[RFC7180]にもあり、この文書に置き換わります。これらの変更には、次のものがあります。
1. Changing nickname allocation to ignore conflicts with RBridges that are IS-IS unreachable.
1. IS-ISに到達できないRBridgeとの競合を無視するようにニックネームの割り当てを変更します。
2. Fixing errors: [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and [Err3508].
2. エラーの修正：[Err3002]、[Err3003]、[Err3004]、[Err3052]、[Err3053]、および[Err3508]。
3. Changing the requirement to use the RPF check described in [RFC6325] for multi-destination TRILL Data packets by providing an alternative stronger RPF check.
3. [RFC6325]で説明されているRPFチェックを使用するための要件を、代替のより強力なRPFチェックを提供することにより、マルチ宛先TRILLデータパケットに変更します。
4. Adoption of the change of the CFI bit, which was required to be zero in the inner frame, to the DEI bit, which is obtained from inner frame ingress or creation.
4. 内部フレームでゼロである必要があったCFIビットの変更を、内部フレームの入力または作成から取得されるDEIビットに採用。
5. Requiring that all RBridges support E-L1FS FS-LSP flooding.
5. すべてのRBridgeがE-L1FS FS-LSPフラッディングをサポートすることを要求します。
6. Reducing the variable-length TRILL Header extensions area to one optional flags word. The Extension Length field (called "Op-Length" in [RFC6325]) is reduced to 1 bit that indicates whether the flags word is present. The rest of that Length field is now reserved.
6. 可変長のTRILLヘッダー拡張領域を1つのオプションのフラグワードに減らします。拡張長さフィールド（[RFC6325]では「Op-Length」と呼ばれる）は、フラグワードが存在するかどうかを示す1ビットに削減されます。その長さフィールドの残りは予約されています。
7. Changing the mandatory Appointed Forwarder Status Lost Counter increment provisions, as specified in Section 11.
7. セクション11で指定されているように、必須の指定フォワーダーステータスロストカウンターの増分規定を変更する。
All of the updates to [RFC7177] herein are in Section 9. Basically, this document requires that a Scope Flooding Support TLV [RFC7356] appear in all Hellos and that TRILL switches retain in their adjacency state the information received in that TLV.
ここでの[RFC7177]の更新はすべてセクション9にあります。基本的に、このドキュメントでは、スコープフラッディングサポートTLV [RFC7356]がすべてのHelloに表示され、TRILLスイッチがそのTLVで受信した情報を隣接状態に保持する必要があります。
The updates to [RFC7179] herein are in Sections 10.2 and 10.3.
ここでの[RFC7179]の更新は、セクション10.2および10.3にあります。
Acknowledgments
謝辞
The contributions of the following individuals to this document are gratefully acknowledged:
このドキュメントへの以下の個人の貢献は感謝されます：
Santosh Rajagopalan and Gayle Noble
サントシュラジャゴパランとゲイルノーブル
The contributions of the following (listed in alphabetical order) to the preceding version of this document, [RFC7180], are gratefully acknowledged:
このドキュメントの前のバージョン[RFC7180]に対する次の貢献（アルファベット順）は、感謝の意を表しております。
Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia Perlman, Varun Shah, Mike Shand, and Meral Shirazipour.
Somnath Chatterjee、Weiguo Hao、Rakesh Kumar、Yeezho Lai、Radia Peral、Varun Shah、Mike Shand、Merle Shirazipour。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technology 155 Beaver Street Milford, MA 01757 United States
Donald Eastlake 3rd Huawei Technology 155 Beaver Streetミルフォード、MA 01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
min鬼Zhang hu Aはテクノロジーno。156 be iqing RD。、Hショートポイント地区北京100095中国
Email: zhangmingui@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
らぢあ ぺｒｌまん えＭＣ ２０１０ ２５６ｔｈ あゔぇぬえ ね、 ＃２００ べっぇゔえ、 わ ９８００７ うにてｄ Ｓたてｓ
Email: radia@alum.mit.edu
Ayan Banerjee Cisco
Ayan Banerjee Cisco
Email: ayabaner@cisco.com Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States
メール：ayabaner@cisco.com Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054 United States
Email: anoop@alumni.duke.edu
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048 India
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangaloreインド560048
Email: sujay.gupta@ipinfusion.com