[要約] RFC 7172は、TRILL（Transparent Interconnection of Lots of Links）プロトコルのFine-Grained Labelingに関するものです。このRFCの目的は、TRILLネットワークでのパケットの正確な経路制御と転送を実現するために、細かいラベル付けの仕組みを提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7172 M. Zhang
Updates: 6325 Huawei
Category: Standards Track P. Agarwal
ISSN: 2070-1721 Broadcom
R. Perlman
Intel Labs
D. Dutt
Cumulus Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling
多くのリンクの透過的な相互接続（TRILL）：きめの細かいラベル付け
Abstract
概要
The IETF has standardized Transparent Interconnection of Lots of Links (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.
IETFは、リンクステートルーティングとホップカウントを使用して、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークにおける最小コストの透過フレームルーティングのためのプロトコルである、リンクの透過的相互接続（TRILL）を標準化しました。 TRILLベースプロトコル標準は、最大4K IDのTRILLデータパケットのラベル付けをサポートしています。ただし、構成可能なデータの分離を提供する多数のラベルを必要とするアプリケーションもあります。このドキュメントは、これを安全に実現するためにTRILLベースプロトコルにオプションの拡張を指定することにより、RFC 6325を更新します。これらの拡張機能は、きめの細かいラベル付けと呼ばれ、主に大規模なデータセンター、つまり、4Kを超えるユーザーが互いに構成可能なデータ分離を必要とするものでの使用を目的としています。
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/rfc7172.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7172で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Contributors ...............................................5
2. Fine-Grained Labeling ...........................................5
2.1. Goals ......................................................6
2.2. Base Protocol TRILL Data Labeling ..........................7
2.3. Fine-Grained Labeling (FGL) ................................7
2.4. Reasons for VL and FGL Coexistence .........................9
3. VL versus FGL Label Differences ................................10
4. FGL Processing .................................................11
4.1. Ingress Processing ........................................11
4.1.1. Multi-Destination FGL Ingress ......................11
4.2. Transit Processing ........................................12
4.2.1. Unicast Transit Processing .........................12
4.2.2. Multi-Destination Transit Processing ...............12
4.3. Egress Processing .........................................13
4.4. Appointed Forwarders and the DRB ..........................14
4.5. Distribution Tree Construction ............................14
4.6. Address Learning ..........................................15
4.7. ESADI Extension ...........................................15
5. FGL TRILL Interaction with VL TRILL ............................15
5.1. FGL and VL Mixed Campus ...................................15
5.2. FGL and VL Mixed Links ....................................17
5.3. Summary of FGL-Safe Requirements ..........................18
6. IS-IS Extensions ...............................................19
7. Comparison with Goals ..........................................19
8. Allocation Considerations ......................................20
8.1. IEEE Allocation Considerations ............................20
8.2. IANA Considerations .......................................20
9. Security Considerations ........................................20
Appendix A. Serial Unicast ........................................22
Appendix B. Mixed Campus Characteristics ..........................23
B.1. Mixed Campus with High Cost Adjacencies ...................23
B.2. Mixed Campus with Data Blocked Adjacencies ................24
Acknowledgements ..................................................25
References ........................................................25
Normative References ...........................................25
Informative References .........................................26
The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325], which provides a solution for least-cost transparent routing in multi-hop networks with arbitrary topologies and link technologies, using [IS-IS] [RFC6165] [RFC7176] link-state routing and a hop count. TRILL switches are sometimes called RBridges (Routing Bridges).
IETFは、リンクの透過的相互接続（TRILL）プロトコル[RFC6325]を標準化しました。これは、[IS-IS] [RFC6165]を使用して、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークにおける最小コストの透過ルーティングのソリューションを提供します。 [RFC7176]リンクステートルーティングとホップカウント。 TRILLスイッチは、RBridges（ルーティングブリッジ）と呼ばれることもあります。
The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4K IDs. However, there are applications that require a larger number of labels of data for configurable isolation based on different tenants, service instances, or the like. This document updates [RFC6325] by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine-grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other.
TRILLベースプロトコル標準は、最大4K IDのTRILLデータパケットのラベル付けをサポートしています。ただし、さまざまなテナント、サービスインスタンスなどに基づいて構成可能な分離のために、より多くのデータラベルを必要とするアプリケーションがあります。このドキュメントは、これを安全に達成するためにTRILLベースプロトコルにオプションの拡張を指定することによって[RFC6325]を更新します。これらの拡張機能は、きめの細かいラベル付けと呼ばれ、主に大規模なデータセンター、つまり、4Kを超えるユーザーが互いに構成可能なデータ分離を必要とするものでの使用を目的としています。
This document describes a format for allowing a data label of 24 bits, known as a "fine-grained label", or FGL. It also describes coexistence and migration from current RBridges, known as "VL" (for "VLAN Labeled") RBridges, to TRILL switches that can support FGL ("Fine-Grained Labeled") packets. Because various VL implementations might handle FGL packets incorrectly, FGL packets cannot be introduced until either all VL RBridges are upgraded to what we will call "FGL-safe", which means that they will not "do anything bad" with FGL packets, or all FGL RBridges take special precautions on any port by which they are connected to a VL RBridge. FGL-safe requirements are summarized in Section 5.3.
このドキュメントでは、「ファイングレインラベル」またはFGLと呼ばれる24ビットのデータラベルを許可するための形式について説明します。また、「VL」（「VLANラベル付き」）RBridgeと呼ばれる現在のRBridgeからFGL（「ファイングレインラベル付き」）パケットをサポートできるTRILLスイッチへの共存と移行についても説明します。さまざまなVL実装がFGLパケットを正しく処理しない可能性があるため、すべてのVL RBridgeが「FGLセーフ」と呼ばれるものにアップグレードされるまで、FGLパケットを導入できません。 FGL RBridgeは、VL RBridgeに接続されているすべてのポートに特別な予防策を講じます。 FGLセーフの要件は、セクション5.3にまとめられています。
It is hoped that many RBridges can become FGL-safe through a software upgrade. VL RBridges and FGL-safe RBridges can coexist without any disruption to service, as long as no FGL packets are introduced.
ソフトウェアのアップグレードにより、多くのRBridgeがFGLセーフになることが期待されています。 VL RBridgeとFGLセーフRBridgeは、FGLパケットが導入されていない限り、サービスを中断することなく共存できます。
If all RBridges are upgraded to FGL-safe, FGL traffic can be successfully handled by the campus without any topology restrictions. The existence of FGL traffic is known to all FGL RBridges because some RBridge (say, RB3) that might source or sink FGL traffic will advertise interest in one or more fine-grained labels in its contribution to the link state (its LSP). If any VL RBridges remain at the point when any RBridge announces that it might source or sink FGL traffic, the adjacent FGL-safe RBridges MUST ensure that no FGL packets are forwarded to their VL RBridge neighbor(s). The details are specified in Section 5.1 below.
すべてのRBridgeがFGLセーフにアップグレードされている場合、トポロジーの制限なしにキャンパスでFGLトラフィックを正常に処理できます。 FGLトラフィックの存在は、FGLトラフィックをソースまたはシンクする可能性がある一部のRBridge（RB3など）が、リンク状態（そのLSP）への寄与において、1つ以上のきめの細かいラベルへの関心をアドバタイズするため、すべてのFGL RBridgeに知られています。 FGLトラフィックをソースまたはシンクする可能性があることをRBridgeがアナウンスした時点でVL RBridgeが残っている場合、隣接するFGLセーフRBridgeは、FGLパケットがVL RBridgeネイバーに転送されないようにする必要があります。詳細は、以下のセクション5.1で指定されています。
The terminology and acronyms of [RFC6325] are used in this document with the additions listed below.
このドキュメントでは、[RFC6325]の用語と頭字語を以下のリストに追加して使用します。
DEI - Drop Eligibility Indicator [802.1Q].
DEI-ドロップ適格インジケーター[802.1Q]。
FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label.
FGL-きめの細かいラベル付け、またはきめの細かいラベル付けまたはきめの細かいラベル。
FGL-edge - An FGL TRILL switch advertising interest in an FGL label.
FGL-edge-FGLラベルへの関心を宣伝するFGL TRILLスイッチ。
FGL link - A link where all of the attached TRILL switches are FGL.
FGLリンク-接続されているすべてのTRILLスイッチがFGLであるリンク。
FGL-safe - A TRILL switch that can safely be given an FGL data packet, as summarized in Section 5.3.
FGLセーフ-セクション5.3で要約されているように、FGLデータパケットを安全に与えることができるTRILLスイッチ。
RBridge - Alternative name for a TRILL switch.
RBridge-TRILLスイッチの別名。
TRILL switch - Alternative name for an RBridge.
TRILLスイッチ-RBridgeの別名。
VL - VLAN Labeling or VLAN Labeled or VLAN Label.
VL-VLANラベルまたはVLANラベルまたはVLANラベル。
VL link - A link where any one or more of the attached RBridges are VL.
VLリンク-接続されている1つ以上のRBridgeがVLであるリンク。
VL RBridge - A TRILL switch that supports VL but is not FGL-safe.
VL RBridge-VLをサポートするがFGLセーフではないTRILLスイッチ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Thanks for the contributions of the following:
以下の貢献に感謝します：
Tissa Senevirathne and Jon Hudson
Tissa SenevirathneとJon Hudson
The essence of Fine-Grained Labeling (FGL) is that (a) when frames are ingressed or created they may incorporate a data label from a set consisting of significantly more than 4K labels, (b) TRILL switch ports can be labeled with a set of such fine-grained data labels, and (c) an FGL TRILL Data packet cannot be egressed through a TRILL switch port unless its fine-grained label (FGL) matches one of the data labels of the port.
Fine-Grained Labeling（FGL）の本質は、（a）フレームが入力または作成されると、4Kを大幅に超えるラベルで構成されるセットからのデータラベルを組み込むことができる、（b）TRILLスイッチポートにセットでラベルを付けることができる、ということです。このようなきめの細かいデータラベル、および（c）FGL TRILLデータパケットは、そのきめの細かいラベル（FGL）がポートのデータラベルの1つと一致しない限り、TRILLスイッチポートから出力できません。
Section 2.1 lists FGL goals. Section 2.2 briefly outlines the more coarse TRILL base protocol standard [RFC6325] data labeling. Section 2.3 outlines FGL for TRILL Data packets. Section 2.4 discusses VL and FGL coexistence.
セクション2.1は、FGLの目標を示しています。 2.2節では、より粗いTRILLベースプロトコル標準[RFC6325]のデータラベル付けについて簡単に説明します。セクション2.3では、TRILLデータパケットのFGLの概要を説明します。セクション2.4では、VLとFGLの共存について説明します。
There are several goals that would be desirable for FGL TRILL. They are briefly described in the list below in approximate order by priority, with the most important first.
FGL TRILLには望ましいいくつかの目標があります。以下のリストでは、優先度の高い順におおよそ簡単に説明しています。
1. Fine-Grained
1. きめの細かい
Some networks have a large number of entities that need configurable isolation, whether those entities are independent customers, applications, or branches of a single endeavor or some combination of these or other entities. The labeling supported by [RFC6325] provides for only 2**12 - 2 valid identifiers or labels (VLANs). A substantially larger number is required.
一部のネットワークには、構成可能な分離を必要とする多数のエンティティーがあります。それらのエンティティーは、独立した顧客、アプリケーション、または単一の試みのブランチ、あるいはこれらまたは他のエンティティーのいくつかの組み合わせであるかどうかにかかわらずです。 [RFC6325]でサポートされるラベル付けは、2 ** 12-2の有効な識別子またはラベル（VLAN）のみを提供します。かなり大きな数が必要です。
2. Silicon
2. ケイ素
Fine-grained labeling (FGL) should, to the extent practical, use existing features, processing, and fields that are already supported in many fast path silicon implementations that support the TRILL base protocol.
Fine-Graining Labeling（FGL）は、実用的な範囲で、TRILベースプロトコルをサポートする多くの高速パスシリコン実装ですでにサポートされている既存の機能、処理、およびフィールドを使用する必要があります。
3. Base RBridge Interoperation
3. ベースRBridge相互運用
To support some incremental conversion scenarios, it is desirable that not all RBridges in a campus using FGL be required to be FGL aware. That is, it is desirable if RBridges not implementing the FGL features can exchange VL TRILL Data packets with FGL TRILL switches.
一部の増分変換シナリオをサポートするには、FGLを使用するキャンパス内のすべてのRBridgeがFGLを認識する必要があるとは限らないことが望ましいです。つまり、FGL機能を実装していないRBridgeがVL TRILLデータパケットをFGL TRILLスイッチと交換できることが望ましいです。
4. Alternate Priority
4. 代替優先度
Under some circumstances, it would be desirable for traffic from an attached non-TRILL network to be handled, while transiting a TRILL network, with a different priority from the priority of the original native frames. This could be accomplished by the ingress TRILL switch assigning a different priority to the FGL TRILL Data packet resulting from ingressing the native frames. The original priority should be restored on egress.
状況によっては、接続されている非TRILLネットワークからのトラフィックが、元のネイティブフレームの優先度とは異なる優先度でTRILLネットワークを通過する間に処理されることが望ましい場合があります。これは、ネイティブフレームの入力から生じるFGL TRILLデータパケットに異なる優先順位を割り当てる入力TRILLスイッチによって実現できます。元の優先度は出口で復元する必要があります。
This section provides a brief review of the [RFC6325] TRILL Data packet VL Labeling and changes the description of the TRILL Header by moving the point at which the TRILL Header ends. This change in description does not involve any change in the bits on the wire or in the behavior of VL TRILL switches.
このセクションでは、[RFC6325] TRILLデータパケットのVLラベリングについて簡単に説明し、TRILLヘッダーの終了点を移動することでTRILLヘッダーの説明を変更します。この説明の変更には、ワイヤ上のビットやVL TRILLスイッチの動作の変更は含まれません。
VL TRILL Data packets have the structure shown below:
VL TRILLデータパケットの構造は次のとおりです。
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x8100 | (2 bytes) |
| +-----------------------+ |
| | Inner.VLAN Label | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
Figure 1: TRILL Data with VL
図1：VLを使用したTRILLデータ
In the base protocol as specified in [RFC6325], the 0x8100 value is always present and is followed by the Inner.VLAN field, which includes the 12-bit VL.
[RFC6325]で指定されている基本プロトコルでは、0x8100値が常に存在し、その後に12ビットVLを含むInner.VLANフィールドが続きます。
FGL expands the variety of data labels available under the TRILL protocol to include a fine-grained label (FGL) with a 12-bit high order part and a 12-bit low order part. In this document, FGLs are denoted as "(X.Y)", where X is the high order part and Y is the low order part of the FGL.
FGLは、TRILLプロトコルで使用できるさまざまなデータラベルを拡張して、12ビットの高次部分と12ビットの低次部分を持つファイングレインラベル（FGL）を含めます。このドキュメントでは、FGLは「（X.Y）」として表されます。ここで、XはFGLの高次部分であり、Yは低次部分です。
FGL TRILL Data packets have the structure shown below.
FGL TRILLデータパケットの構造は次のとおりです。
+-------------------------------------------+
| Link Header (depends on link technology) |
| (if link is an Ethernet link, the link |
| header may include an Outer.VLAN tag) |
+-------------------------------------------+
| TRILL Header |
| +---------------------------------------+ |
| | Initial Fields and Options | |
| +---------------------------------------+ |
| | Inner.MacDA | (6 bytes) |
| +-----------------------------+ |
| | Inner.MacSA | (6 bytes) |
| +-----------------------+-----+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label High Part | (2 bytes) |
| +-----------------------+ |
| | Ethertype 0x893B | (2 bytes) |
| +-----------------------+ |
| | Inner.Label Low Part | (2 bytes) |
| +-----------------------+ |
+-------------------------------------------+
| Native Payload |
+-------------------------------------------+
| Link Trailer (depends on link technology) |
+-------------------------------------------+
Figure 2: TRILL Data with FGL
図2：FGLを使用したTRILLデータ
For FGL packets, the inner Media Access Control (MAC) address fields are followed by the FGL information using 0x893B. There MUST be two occurrences of 0x893B, as shown. Should a TRILL switch processing an FGL TRILL Data packet notice that the second occurrence is actually some other value, it MUST discard the packet. (A TRILL switch transiting a TRILL Data packet is not required to examine any fields past the initial fixed fields and options, although it may do so to support Equal-Cost Multi-Path (ECMP) or distribution tree pruning.) The two bytes following each 0x893B have, in their low order 12 bits, fine-grained label information. The upper 4 bits of those two bytes are used for a 3-bit priority field and one Drop Eligibility Indicator (DEI) bit as shown below.
FGLパケットの場合、内部メディアアクセス制御（MAC）アドレスフィールドの後に0x893Bを使用したFGL情報が続きます。図に示すように、0x893Bが2回発生している必要があります。 FGL TRILLデータパケットを処理するTRILLスイッチが、2番目のオカレンスが実際に他の値であることを通知した場合、パケットを破棄する必要があります。 （TRILLデータパケットを通過するTRILLスイッチは、初期固定フィールドとオプションを過ぎたフィールドを検査する必要はありませんが、等コストマルチパス（ECMP）または配布ツリーのプルーニングをサポートするためにそうする場合があります。）以下の2バイト各0x893Bは、下位12ビットにきめの細かいラベル情報を持っています。これらの2バイトの上位4ビットは、以下に示すように、3ビットの優先度フィールドと1つのDrop Eligibility Indicator（DEI）ビットに使用されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
|priority|DEI| label information |
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: FGL Part Data Structure
図3：FGLパーツのデータ構造
The priority field of the Inner.Label High Part is the priority used for frame transport across the TRILL campus from ingress to egress. The label bits in the Inner.Label High Part are the high order part of the FGL, and those bits in the Inner.Label Low Part are the low order part of the FGL. The priority field of the Inner.Label Low Part is remembered from the data frame as ingressed and is restored on egress.
Inner.Label High Partの優先度フィールドは、入口から出口へのTRILLキャンパス全体のフレーム転送に使用される優先度です。 Inner.Label High PartのラベルビットはFGLの高次部分であり、Inner.Label Low PartのビットはFGLの低次部分です。 Inner.Label Low Partの優先度フィールドは、データフレームから入力として記憶され、出力時に復元されます。
The appropriate FGL value for an ingressed or locally originated native frame is determined by the ingress TRILL switch port as specified in Section 4.1.
入力またはローカルで生成されたネイティブフレームの適切なFGL値は、セクション4.1で指定されているように、入力TRILLスイッチポートによって決定されます。
For several reasons, as listed below, it is desirable for FGL TRILL switches to be able to handle both FGL and VL TRILL Data packets.
以下に示すように、いくつかの理由により、FGL TRILLスイッチがFGLとVL TRILLの両方のデータパケットを処理できることが望ましいです。
o Continued support of VL packets means that, by taking the precautions specified herein, in many cases such arrangements as VL TRILL switches easily exchanging VL packets through a core of FGL TRILL switches are possible.
o VLパケットの継続的なサポートは、ここで指定された予防策を講じることにより、多くの場合、VL TRILLスイッチなどの配置がFGL TRILLスイッチのコアを介してVLパケットを簡単に交換できることを意味します。
o Due to the way TRILL works, it may be desirable to have a maintenance VLAN or FGL [RFC7174] in which all TRILL switches in the campus indicate interest. It will be simpler to use the same type of label for all TRILL switches for this purpose. That implies using VL if there might be any VL TRILL switches in the campus.
o TRILLの動作方法により、キャンパス内のすべてのTRILLスイッチが関心を示すメンテナンスVLANまたはFGL [RFC7174]を用意することが望ましい場合があります。この目的のために、すべてのTRILLスイッチに同じタイプのラベルを使用する方が簡単です。これは、キャンパス内にVL TRILLスイッチがある場合は、VLを使用することを意味します。
o If a campus is being upgraded from VL to FGL, continued support of VL allows long-term support of edges labeled as VL.
o キャンパスをVLからFGLにアップグレードする場合、VLの継続的なサポートにより、VLとラベル付けされたエッジを長期間サポートできます。
There are differences between the semantics across a TRILL campus for TRILL Data packets that are data labeled with VL and FGL.
VLおよびFGLでラベル付けされたデータであるTRILLデータパケットのTRILLキャンパス全体のセマンティクスには違いがあります。
With VL, data label IDs have the same meaning throughout the campus and are from the same label space as the C-VLAN IDs used on Ethernet links to end stations.
VLでは、データラベルIDはキャンパス全体で同じ意味を持ち、エンドステーションへのイーサネットリンクで使用されるC-VLAN IDと同じラベルスペースからのものです。
The larger FGL data label space is a different space from the VL data label space. For ports configured for FGL, the C-VLAN on an ingressed native frame is stripped and mapped to the FGL data label space with a potentially different mapping for each port. A similar FGL-to-C-VLAN mapping occurs per port on egress. Thus, for ports configured for FGL, the native frame C-VLAN on one link corresponding to an FGL can be different from the native frame C-VLAN corresponding to that same FGL on a different link elsewhere in the campus or even a different link attached to the same TRILL switch. The FGL label space is flat and does not hierarchically encode any particular number of native frame C-VLAN bits or the like. FGLs appear only inside TRILL Data packets after the inner MAC addresses.
大きいFGLデータラベルスペースは、VLデータラベルスペースとは異なります。 FGL用に構成されたポートの場合、入力されたネイティブフレームのC-VLANが削除され、ポートごとに異なるマッピングを持つ可能性のあるFGLデータラベルスペースにマッピングされます。同様のFGLからC-VLANへのマッピングは、出力のポートごとに発生します。したがって、FGL用に構成されたポートの場合、FGLに対応する1つのリンクのネイティブフレームC-VLANは、キャンパス内の別のリンクまたは接続された別のリンクの同じFGLに対応するネイティブフレームC-VLANと異なる場合があります。同じTRILLスイッチに。 FGLラベルスペースはフラットであり、特定の数のネイティブフレームC-VLANビットなどを階層的にエンコードしません。 FGLは、内部MACアドレスの後のTRILLデータパケット内にのみ表示されます。
It is the responsibility of the network manager to properly configure the TRILL switches in the campus to obtain the desired mappings. Such configuration is expected to be automatic in many cases, based on configuration databases and orchestration systems.
キャンパス内のTRILLスイッチを適切に構成して目的のマッピングを取得するのは、ネットワーク管理者の責任です。このような構成は、多くの場合、構成データベースとオーケストレーションシステムに基づいて自動化されることが期待されています。
With FGL TRILL switches, many things remain the same because an FGL can appear only as the Inner.Label inside a TRILL Data packet. As such, only TRILL-aware devices will see a fine-grained label. The Outer.VLAN that may appear on native frames and that may appear on TRILL Data packets if they are on an Ethernet link can only be a C-VLAN tag. Thus, ports of FGL TRILL switches, up through the usual VLAN and priority processing, act as they do for VL TRILL switches: TRILL switch ports provide a C-VLAN ID for an incoming frame and accept a C-VLAN ID for a frame being queued for output. Appointed Forwarders [RFC6439] on a link are still appointed for a C-VLAN. The Designated VLAN for an Ethernet link is still a C-VLAN.
FGL TRILLスイッチを使用すると、FGLはTRILLデータパケット内のInner.Labelとしてのみ表示できるため、多くの点で同じです。そのため、TRILL対応のデバイスのみが細かいラベルを表示します。ネイティブフレームに表示される可能性があり、イーサネットリンク上にある場合にTRILLデータパケットに表示される可能性があるOuter.VLANは、C-VLANタグのみにすることができます。したがって、FGL TRILLスイッチのポートは、通常のVLANおよび優先度処理まで、VL TRILLスイッチの場合と同様に機能します。TRILLスイッチポートは、着信フレームにC-VLAN IDを提供し、フレームのC-VLAN IDを受け入れます出力のためにキューに入れられました。リンク上のAppointed Forwarders [RFC6439]は引き続きC-VLANに指定されています。イーサネットリンクの指定VLANは引き続きC-VLANです。
FGL TRILL switches have capabilities that are a superset of those for VL TRILL switches. FGL TRILL switch ports can be configured for FGL or VL, with VL being the default. As with a base protocol [RFC6325] TRILL switch, an unconfigured FGL TRILL switch port reports an untagged frame it receives as being in VLAN 1.
FGL TRILLスイッチには、VL TRILLスイッチの機能のスーパーセットである機能があります。 FGL TRILLスイッチポートは、FGLまたはVL用に構成でき、VLがデフォルトです。基本プロトコル[RFC6325] TRILLスイッチと同様に、未構成のFGL TRILLスイッチポートは、VLAN 1にあるものとして受信したタグなしフレームを報告します。
This section specifies ingress, transit, egress, and other processing details for FGL TRILL switches. A transit or egress FGL TRILL switch determines that a TRILL Data packet is FGL by detecting that the Inner.MacSA is followed by 0x893B.
このセクションでは、FGL TRILLスイッチの入力、通過、出力、およびその他の処理の詳細を指定します。トランジットまたはイグレスFGL TRILLスイッチは、Inner.MacSAの後に0x893Bが続くことを検出することにより、TRILLデータパケットがFGLであると判断します。
FGL-edge TRILL switch ports are configurable to ingress native frames as FGL. Any port not so configured performs the previously specified [RFC6325] VL ingress processing on native frames resulting in a VL TRILL Data packet. (There is no change in Appointed Forwarder logic (see Section 4.4).) An FGL-safe TRILL switch may have only VL ports, in which case it is not required to support the capabilities for FGL ingress described in this section.
FGLエッジTRILLスイッチポートは、ネイティブフレームをFGLとして入力するように構成できます。このように構成されていないポートは、ネイティブフレームで以前に指定された[RFC6325] VL入力処理を実行し、VL TRILLデータパケットが生成されます。 （Appointed Forwarderロジックに変更はありません（セクション4.4を参照）。）FGLセーフTRILLスイッチはVLポートのみを持つ場合があります。その場合、このセクションで説明するFGL入力の機能をサポートする必要はありません。
FGL-edge TRILL switches support configurable per-port mapping from the C-VLAN of a native frame, as reported by the ingress port, to an FGL. FGL TRILL switches MAY support other methods to determine the FGL of an incoming native frame, such as methods based on the protocol of the native frame or based on local knowledge.
FGLエッジTRILLスイッチは、入力ポートによって報告されたネイティブフレームのC-VLANからFGLへの構成可能なポートごとのマッピングをサポートします。 FGL TRILLスイッチは、ネイティブフレームのプロトコルに基づく方法やローカルの知識に基づく方法など、着信ネイティブフレームのFGLを決定する他の方法をサポートする場合があります。
The FGL ingress process MUST copy the priority and DEI (Drop Eligibility Indicator) associated with an ingressed native frame to the upper 4 bits of the Inner.Label Low Order part. It SHOULD also associate a possibly different mapped priority and DEI with an ingressed frame, but a TRILL switch might not be able to do so because of implementation limitations. The mapped priority is placed in the Inner.Label High Part. If such mapping is not supported, then the original priority and DEI MUST be placed in the Inner.Label High Part.
FGLイングレスプロセスは、イングレスネイティブフレームに関連付けられた優先度とDEI（ドロップ適格性インジケーター）をInner.Label Low Orderパーツの上位4ビットにコピーする必要があります。また、マップされる可能性のある異なる優先度とDEIを入力フレームに関連付ける必要があります（SHOULD）。ただし、実装の制限により、TRILLスイッチは関連付けられない場合があります。マップされた優先度は、Inner.Label Highパーツに配置されます。このようなマッピングがサポートされていない場合は、元の優先度とDEIをInner.Label High Partに配置する必要があります。
If a native frame that has a broadcast, multicast, or unknown MAC destination address is FGL ingressed, it MUST be handled in one of the following two ways. The choice of which method to use can vary from frame to frame, at the choice of the ingress TRILL switch.
ブロードキャスト、マルチキャスト、または不明なMAC宛先アドレスを持つネイティブフレームがFGL入力の場合、次の2つの方法のいずれかで処理する必要があります。使用する方法の選択は、入力TRILLスイッチの選択により、フレームごとに異なります。
1. Ingress as a TRILL multi-destination data packet (TRILL Header M bit = 1) on a distribution tree rooted at a nickname held by an FGL RBridge or by the pseudonode of an FGL link. FGL TRILL Data packets MUST NOT be sent on a tree rooted at a nickname held by a VL TRILL switch or by the pseudonode of a VL link.
1. FGL RBridgeまたはFGLリンクの疑似ノードによって保持されているニックネームをルートとする配布ツリー上のTRILLマルチ宛先データパケット（TRILLヘッダーMビット= 1）としてのイングレス。 FGL TRILLデータパケットは、VL TRILLスイッチまたはVLリンクの疑似ノードによって保持されているニックネームをルートとするツリー上で送信してはなりません（MUST NOT）。
2. Serially TRILL unicast the ingressed frame to the relevant egress TRILL switches by using a known unicast TRILL Header (M bit = 0). An FGL ingress TRILL switch SHOULD unicast a multi-destination TRILL Data packet if there is only one relevant egress FGL TRILL switch. The relevant egress TRILL switches are determined by starting with those announcing interest in the frame's (X.Y) label. That set SHOULD be further filtered based on multicast listener and multicast router attachment LSP announcements if the native frame was a multicast frame.
2. 既知のユニキャストTRILLヘッダー（Mビット= 0）を使用して、入力フレームを関連する出力TRILLスイッチに逐次TRILLユニキャストします。関連する出力FGL TRILLスイッチが1つしかない場合、FGL入力TRILLスイッチは、マルチ宛先TRILLデータパケットをユニキャストする必要があります（SHOULD）。関連する出力TRILLスイッチは、フレームの（X.Y）ラベルに関心を示しているものから開始することによって決定されます。ネイティブフレームがマルチキャストフレームの場合、そのセットは、マルチキャストリスナーとマルチキャストルーターアタッチメントのLSPアナウンスメントに基づいてさらにフィルタリングする必要があります（SHOULD）。
Using a TRILL unicast header for a multi-destination frame when it has only one actual destination RBridge almost always improves traffic spreading and decreases latency as discussed in Appendix A. How to decide whether to use a distribution tree or serial unicast for a multi-destination TRILL Data packet that has more than one destination TRILL switch is beyond the scope of this document.
付録Aで説明されているように、実際の宛先RBridgeが1つしかない場合に、マルチ宛先フレームにTRILLユニキャストヘッダーを使用すると、ほとんどの場合、トラフィックの分散が改善され、遅延が減少します。複数の宛先TRILLスイッチを持つTRILLデータパケットは、このドキュメントの範囲外です。
Any FGL TRILL switch MUST be capable of TRILL Data packet transit processing. Such processing is fairly straightforward as described in Section 4.2.1 for known unicast TRILL Data packets and in Section 4.2.2 for multi-destination TRILL Data packets.
FGL TRILLスイッチは、TRILLデータパケット転送処理に対応している必要があります。このような処理は、既知のユニキャストTRILLデータパケットの場合はセクション4.2.1で、複数宛先のTRILLデータパケットの場合はセクション4.2.2で説明されているように、かなり単純です。
There is very little change in TRILL Data packet unicast transit processing. A transit TRILL switch forwards any unicast TRILL Data packet to the next hop towards the egress TRILL switch as specified in the TRILL Header. All transit TRILL switches MUST take the priority and DEI used to forward a packet from the Inner.VLAN label or the FGL Inner.Label High Part. These bits are in the same place in the packet.
TRILLデータパケットのユニキャスト転送処理にはほとんど変更がありません。通過TRILLスイッチは、TRILLヘッダーで指定されているように、すべてのユニキャストTRILLデータパケットを出力TRILLスイッチへのネクストホップに転送します。すべてのトランジットTRILLスイッチは優先度を取り、Inner.VLANラベルまたはFGL Inner.Label High Partからパケットを転送するために使用されるDEIを使用する必要があります。これらのビットはパケットの同じ場所にあります。
An FGL TRILL switch MUST properly distinguish flows if it provides ECMP for unicast FGL TRILL Data packets.
FGL TRILLスイッチは、ユニキャストFGL TRILLデータパケットにECMPを提供する場合、フローを適切に区別する必要があります。
Multi-destination TRILL Data packets are forwarded on a distribution tree selected by the ingress TRILL switch, except that an FGL ingress TRILL switch MAY TRILL unicast such a frame to all relevant egress TRILL switches, all as described in Section 4.1. The distribution trees do not distinguish between FGL and VL multi-destination packets, except in pruning behavior if they provide pruning. There is no change in the Reverse Path Forwarding Check.
複数の宛先TRILLデータパケットは、FGL入力TRILLスイッチがすべての関連する出力TRILLスイッチにそのようなフレームをユニキャストすることを除いて、入力TRILLスイッチによって選択された配信ツリーで転送されます。配布ツリーは、プルーニングを提供する場合のプルーニング動作を除いて、FGLとVLの複数宛先パケットを区別しません。リバースパス転送チェックに変更はありません。
An FGL TRILL switch (say, RB1) having an FGL multi-destination frame for label (X.Y) to forward on a distribution tree SHOULD prune that tree based on whether there are any TRILL switches on a tree branch that are advertising connectivity to label (X.Y). In addition, RB1 SHOULD prune multicast frames based on reported multicast listener and multicast router attachment in (X.Y).
ラベル（XY）のFGLマルチ宛先フレームを持つFGL TRILLスイッチ（たとえば、RB1）は、配布ツリーで転送するために、ラベルへの接続をアドバタイズしているツリーブランチにTRILLスイッチがあるかどうかに基づいて、そのツリーをプルーニングする必要があります（SHOULD）。 XY）。さらに、RB1は、（X.Y）で報告されたマルチキャストリスナーとマルチキャストルーター接続に基づいてマルチキャストフレームをプルーニングする必要があります（SHOULD）。
Pruning is an optimization. If a transit TRILL switch does less pruning than it could, there may be greater link utilization than strictly necessary but the campus will still operate correctly. A transit TRILL switch MAY prune based on an arbitrary subset of the bits in the FGL label, for example, only the High Part or only the Low Part of the label.
剪定は最適化です。トランジットTRILLスイッチが実行するプルーニングよりもプルーニングが少ない場合、厳密に必要なものよりもリンクの使用率が高くなる可能性がありますが、キャンパスは引き続き正しく動作します。トランジットTRILLスイッチは、FGLラベルのビットの任意のサブセットに基づいてプルーニングできます（たとえば、ラベルのハイパートのみまたはローパートのみ）。
Egress processing is generally the reverse of ingress progressing described in Section 4.1. An FGL-safe TRILL switch may have only VL ports, in which case it is not required to support the capabilities for FGL egress described in this section.
出力処理は、セクション4.1で説明した入力の進行の逆です。 FGLセーフTRILLスイッチはVLポートのみを備えている場合があります。その場合、このセクションで説明するFGL出力の機能をサポートする必要はありません。
An FGL-edge TRILL switch MUST be able to convert, in a configurable fashion, from the FGL in an FGL TRILL Data packet it is egressing to the C-VLAN ID for the resulting native frame with different mappings on a per-port basis. The priority and DEI of the egressed native frame are taken from the Inner.Label Low Order Part. A port MAY be configured to strip output VLAN tagging.
FGLエッジTRILLスイッチは、構成可能な方法で、出力するFGL TRILLデータパケット内のFGLから、ポートごとに異なるマッピングを持つ結果のネイティブフレームのC-VLAN IDに変換できなければなりません（MUST）。出力されたネイティブフレームの優先度とDEIは、Inner.Label低次パーツから取得されます。ポートは、出力VLANタギングを取り除くように構成できます（MAY）。
It is the responsibility of the network manager to properly configure the TRILL switches in the campus to obtain the desired mappings.
キャンパス内のTRILLスイッチを適切に構成して目的のマッピングを取得するのは、ネットワーク管理者の責任です。
FGL egress is similar to VL egress, as follows:
FGL出力は、次のようにVL出力に似ています。
1. If the Inner.MacDA is All-Egress-RBridges, special processing applies, based on the payload Ethertype (for example, End-Station Address Distribution Information (ESADI) [RFC6325] or RBridge Channel [RFC7178]), and if the payload Ethertype is unknown, the packet is discarded. If the Inner.MacDA is not All-Egress-RBridges, then either item 2 or item 3 below applies, as appropriate.
1. Inner.MacDAがAll-Egress-RBridgesの場合、ペイロードのEthertype（たとえば、End-Station Address Distribution Information（ESADI）[RFC6325]またはRBridge Channel [RFC7178]）に基づいて特別な処理が適用され、ペイロードのEthertype不明な場合、パケットは破棄されます。 Inner.MacDAがAll-Egress-RBridgesでない場合は、以下の項目2または項目3が適切に適用されます。
2. A known unicast FGL TRILL Data packet (TRILL Header M bit = 0) with a unicast Inner.MacDA is egressed to the FGL port or ports matching its FGL and Inner.MacDA. If there are no such ports, it is flooded out of all FGL ports that have its FGL, except any ports for which the TRILL switch has knowledge that the frame's Inner.MacDA cannot be present on the link out of that port.
2. ユニキャストInner.MacDAを持つ既知のユニキャストFGL TRILLデータパケット（TRILLヘッダーMビット= 0）は、FGLポートまたはそのFGLとInner.MacDAに一致するポートに出力されます。そのようなポートがない場合、そのポートからのリンク上にフレームのInner.MacDAが存在できないことをTRILLスイッチが認識しているポートを除いて、そのFGLを持つすべてのFGLポートからフラッディングされます。
3. A multi-destination FGL TRILL Data packet is decapsulated and flooded out of all ports that have its FGL, subject to multicast pruning. The same processing applies to a unicast FGL TRILL Data packet with a broadcast or multicast Inner.MacDA that might be received due to serial unicast.
3. マルチ宛先FGL TRILLデータパケットはカプセル化が解除され、マルチキャストプルーニングの対象となるFGLを持つすべてのポートからフラッディングされます。同じ処理が、ブロードキャストまたはマルチキャストのInner.MacDAを含むユニキャストFGL TRILLデータパケットに適用されます。これは、シリアルユニキャストが原因で受信される場合があります。
An FGL TRILL switch MUST NOT egress an FGL packet with label (X.Y) to any port not configured with that FGL, even if the port is configured to egress VL packets in VLAN X.
FGL TRILLスイッチは、ポートがVLAN XのVLパケットを出力するように構成されている場合でも、そのFGLが構成されていないポートにラベル（X.Y）の付いたFGLパケットを出力してはなりません（MUST NOT）。
FGL TRILL switches MUST accept multi-destination TRILL Data packets that are sent to them as TRILL unicast packets (packets with the TRILL Header M bit set to 0). They locally egress such packets, if appropriate, but MUST NOT forward them (other than egressing them as native frames on their local links).
FGL TRILLスイッチは、TRILLユニキャストパケット（TRILLヘッダーMビットが0に設定されたパケット）として送信される複数宛先のTRILLデータパケットを受け入れる必要があります。それらは、適切な場合、そのようなパケットをローカルに出力しますが、それらを転送してはなりません（ローカルリンク上のネイティブフレームとしてそれらを出力すること以外）。
There is no change in adjacency [RFC7177], DRB (Designated RBridge) election, or Appointed Forwarder logic [RFC6439] on a link, regardless of whether some or all the ports on the link are for FGL TRILL switches, with one exception: implementations SHOULD provide that their default priority for a VL RBridge port to be the DRB is less than their default priority for an FGL RBridge to be the DRB. This will assure that, in the unconfigured case, an FGL RBridge will be elected DRB when using that implementation.
リンクの一部またはすべてのポートがFGL TRILLスイッチ用であるかどうかに関係なく、リンク上の隣接[RFC7177]、DRB（指定RBridge）選択、またはAppointed Forwarderロジック[RFC6439]に変更はありませんが、1つの例外があります：実装VL RBridgeポートがDRBになるためのデフォルトの優先順位は、FGL RBridgeがDRBになるためのデフォルトの優先順位よりも低くなければなりません。これにより、未構成の場合、その実装を使用するときにFGL RBridgeが確実にDRBとして選出されます。
All distribution trees are calculated as provided for in the TRILL base protocol standard [RFC6325] as updated by [RFC7180], with the exception that the default tree root priority for a nickname held by an FGL TRILL switch or an FGL link pseudonode is 0x9000. As a result, they will be chosen in preference to VL nicknames in the absence of configuration. If distribution tree roots are configured, there MUST be at least one tree rooted at a nickname held by an FGL TRILL switch or by an FGL link pseudonode. If distribution tree roots are misconfigured so there would not be such a tree, then the highest priority FGL nickname to be a tree root is used to construct an additional tree, regardless of configuration. (VL TRILL switches will not know about this additional distribution tree but, through the use of Step (A) or (B) in Section 5.1, no VL TRILL switch should ever receive a multi-destination TRILL Data packet using this additional tree.)
FGL TRILLスイッチまたはFGLリンク疑似ノードが保持するニックネームのデフォルトのツリールート優先度が0x9000であることを除いて、すべての配布ツリーは[RFC7180]によって更新されるTRILLベースプロトコル標準[RFC6325]の規定に従って計算されます。その結果、構成がない場合は、VLニックネームよりも優先して選択されます。配布ツリーのルートが構成されている場合、FGL TRILLスイッチまたはFGLリンク疑似ノードによって保持されているニックネームをルートとするツリーが少なくとも1つ存在する必要があります。配布ツリーのルートが誤って構成されているためにそのようなツリーが存在しない場合、構成に関係なく、ツリールートとなる最も優先度の高いFGLニックネームが追加のツリーの構築に使用されます。 （VL TRILLスイッチはこの追加の配信ツリーを認識しませんが、セクション5.1のステップ（A）または（B）を使用することで、VL TRILLスイッチはこの追加のツリーを使用して複数の宛先TRILLデータパケットを受信することはありません。）
An FGL TRILL switch learns addresses from the data plane on ports configured for FGL based on the fine-grained label rather than the native frame's VLAN. Addresses learned from ingressed native frames on FGL ports are logically represented by { MAC address, FGL, port, confidence, timer }, while remote addresses learned from egressing FGL packets are logically represented by { MAC address, FGL, remote TRILL switch nickname, confidence, timer }.
FGL TRILLスイッチは、ネイティブフレームのVLANではなく、きめの細かいラベルに基づいて、FGL用に構成されたポートのデータプレーンからアドレスを学習します。 FGLポートの入力ネイティブフレームから学習したアドレスは{MACアドレス、FGL、ポート、信頼性、タイマー}で論理的に表され、出力FGLパケットから学習したリモートアドレスは{MACアドレス、FGL、リモートTRILLスイッチニックネーム、信頼性で論理的に表されます、タイマー}。
The TRILL ESADI (End-Station Address Distribution Information) protocol is specified in [RFC6325] as optionally transmitting MAC address connection information through TRILL Data packets between participating TRILL switches over the virtual link provided by the TRILL multi-destination packet distribution mechanism. In [RFC6325], the VL to which an ESADI packet applies is indicated only by the Inner.VLAN label, and no indication of that VL is allowed within the ESADI payload.
TRILL ESADI（End-Station Address Distribution Information）プロトコルは、[RFC6325]で、TRILLマルチ宛先パケット配信メカニズムによって提供される仮想リンクを介して、参加するTRILLスイッチ間でTRILLデータパケットを介してMACアドレス接続情報を送信するオプションとして指定されています。 [RFC6325]では、ESADIパケットが適用されるVLはInner.VLANラベルによってのみ示され、そのVLはESADIペイロード内で許可されていません。
ESADI is extended to support FGL by providing for the indication of the FGL to which an ESADI packet applies only in the Inner.Label of that packet, and no indication of that FGL is allowed within the ESADI payload.
ESADIは、ESADIパケットが適用されるFGLの表示をそのパケットのInner.Labelでのみ提供することによりFGLをサポートするように拡張され、そのFGLの表示はESADIペイロード内で許可されません。
This section discusses mixing FGL-safe and VL TRILL switches in a campus. It does not apply if the campus is entirely FGL-safe or if there are no FGL-edges. Section 5.1 specifies what behaviors are needed to render such mixed campuses safe. See also Appendix B for a discussion of campus characteristics when these behaviors are in use. Section 5.2 gives details of link-local mixed behavior.
このセクションでは、キャンパス内でのFGL対応スイッチとVL TRILLスイッチの混在について説明します。キャンパスが完全にFGLセーフである場合、またはFGLエッジがない場合は適用されません。セクション5.1は、そのような混合キャンパスを安全にするために必要な行動を規定しています。これらの動作が使用されている場合のキャンパス特性の説明については、付録Bも参照してください。セクション5.2は、リンクローカル混合動作の詳細を示しています。
It is best, if possible, for VL TRILL switches to be upgraded to FGL-safe before introducing FGL-edges (and therefore FGL data packets).
可能であれば、VL TRILLスイッチをFGLセーフにアップグレードしてから、FGLエッジ（およびFGLデータパケット）を導入することをお勧めします。
By definition, it is not possible for VL TRILL switches to safely handle FGL traffic, even if the VL TRILL switch is only acting in the transit capacity. If a TRILL switch can safely transit FGL TRILL Data packets, then it qualifies as FGL-safe but will still be assumed to be VL until it advertises in its LSP that it is FGL-safe.
定義上、VL TRILLスイッチが通過容量でのみ機能している場合でも、VL TRILLスイッチがFGLトラフィックを安全に処理することはできません。 TRILLスイッチがFGL TRILLデータパケットを安全に転送できる場合、FGLセーフと見なされますが、LSPでFGLセーフであることをアドバタイズするまで、VLであると見なされます。
VL frames are required to have 0x8100 at the beginning of the data label, where FGL frames have 0x893B. VL TRILL switches conformant to [RFC6325] should discard frames with this new value after the inner MAC addresses. However, if they do not discard such frames, they could be confused and egress them into the wrong VLAN (see Section 9 below) or persistently reorder them due to miscomputing flows for ECMP, or they could improperly prune their distribution if they are multi-destination so that they would fail to reach some intended destinations. Such difficulties are avoided by taking all practical steps to minimize the chance of a VL TRILL switch handling an FGL TRILL Data packet. These steps are specified below.
VLフレームにはデータラベルの先頭に0x8100が必要ですが、FGLフレームには0x893Bがあります。 [RFC6325]に準拠したVL TRILLスイッチは、内部MACアドレスの後にこの新しい値を持つフレームを破棄する必要があります。ただし、そのようなフレームを破棄しないと、混乱して間違ったVLANに出力されるか（以下のセクション9を参照）、ECMPのフローの計算ミスが原因で永続的に並べ替えられたり、複数のフレームの場合、配信が不適切にプルーニングされたりする可能性があります。目的地への到達に失敗するため。このような問題は、VL TRILLスイッチがFGL TRILLデータパケットを処理する可能性を最小限に抑えるための実用的な手順をすべて実行することで回避されます。これらの手順を以下に示します。
FGL-safe switches will report their FGL capability in LSPs. Thus, FGL-safe TRILL switches (and any management system with access to the link-state database) will be able to detect the existence of TRILL switches in the campus that do not support FGL.
FGLセーフスイッチは、LSPでのFGL機能を報告します。したがって、FGL対応のTRILLスイッチ（およびリンク状態データベースにアクセスできる管理システム）は、FGLをサポートしていないキャンパス内のTRILLスイッチの存在を検出できます。
Once a TRILL switch advertises an FGL-edge, any FGL-safe TRILL switch (RB1 in this discussion) that observes, on one of its ports, a VL RBridge on the link out of that port, MUST take Step (A) or (B) below for that port and also take Step (C) further below. ("Observes" means that it has an adjacency to the VL TRILL switch that is in any state other than Down [RFC7177] and holds an LSP fragment zero for it, showing that it is not FGL-safe.) Finally, for there to be full FGL connectivity, the campus topology must be such that all FGL TRILL switches are reachable from all other FGL TRILL switches without going through a VL TRILL switch.
TRILLスイッチがFGLエッジをアドバタイズすると、そのポートの1つで、そのポートからのリンク上のVL RBridgeを監視するFGLセーフTRILLスイッチ（この説明ではRB1）は、ステップ（A）または（ B）そのポートについては以下、さらに以下のステップ（C）を実行します。 （「観察」とは、ダウン[RFC7177]以外の状態にあるVL TRILLスイッチに隣接しており、LSPフラグメント0を保持していることを意味します。これは、FGLセーフではないことを示します。）最後に、完全なFGL接続である場合、キャンパストポロジは、すべてのFGL TRILLスイッチがVL TRILLスイッチを経由せずに他のすべてのFGL TRILLスイッチから到達可能である必要があります。
(A) If RB1 can discard any FGL TRILL Data packet that would be output through a port where it observes a VL RBridge, while allowing the output of VL TRILL Data packets through that port, then
（A）RB1が、VL RBridgeを監視するポートを通じて出力されるFGL TRILLデータパケットを破棄できる一方で、そのポートを通じてVL TRILLデータパケットの出力を許可する場合、
A1. RB1 MUST so discard all FGL TRILL Data output packets that would otherwise be output through the port, and
A1。 RB1は、そうでなければポートを通じて出力されるすべてのFGL TRILLデータ出力パケットを破棄する必要があります。
A2. For all adjacencies out of that port (even adjacencies to other FGL RBridges or a pseudonode) in the Report state [RFC7177], RB1 MUST report that adjacency cost as 2**23 greater than it would have otherwise reported, but not more than 2**24 - 2 (the highest link cost still usable in least-cost path calculations and distribution tree construction). This assures that if any path through FGL-safe TRILL switches exists, such a path will be computed.
A2。レポート状態[RFC7177]のそのポートからのすべての隣接関係（他のFGL RBridgeまたは疑似ノードへの隣接関係も含む）の場合、RB1は、隣接関係コストを、2 ** 23として報告する必要があります。 ** 24-2（最小コストのパス計算および配布ツリーの構築で引き続き使用できる最高のリンクコスト）。これにより、FGLセーフTRILLスイッチを介したパスが存在する場合、そのようなパスが計算されます。
(B) If RB1 cannot discard any FGL TRILL Data packet that would be output through a port where it observes a VL RBridge while allowing VL TRILL Data packets, then RB1 MUST, for all adjacencies out of that port (even adjacencies to other FGL-safe RBridges or a pseudonode) in the Report state [RFC7177], report the adjacency cost as 2**24 - 1. As specified in IS-IS [RFC5305], that cost will stop the adjacency from being used in least-cost path calculations, including distribution tree construction (see Section 2.1 of [RFC7180]) but will still leave it visible in the topology and usable, for example, by any traffic engineered path mechanism.
（B）VL TRILLデータパケットを許可しているときにVL RBridgeを監視するポートを通じて出力されるFGL TRILLデータパケットをRB1が破棄できない場合、RB1は、そのポートからのすべての隣接（他のFGL-レポート状態[RFC7177]の安全なRBridgesまたは疑似ノード）、隣接コストを2 ** 24-1として報告します。IS-IS[RFC5305]で指定されているように、そのコストにより、隣接は最小コストパスで使用されなくなります配布ツリーの構築を含む計算（[RFC7180]のセクション2.1を参照）
(C) The roots for all distribution trees used for FGL TRILL Data packets must be nicknames held by an FGL-safe TRILL switch or by a pseudonode representing an FGL link. As provided in Section 4.5, there will always be such a distribution tree.
（C）FGL TRILLデータパケットに使用されるすべての配布ツリーのルートは、FGLセーフTRILLスイッチまたはFGLリンクを表す疑似ノードによって保持されているニックネームである必要があります。セクション4.5で提供されているように、常にそのような配布ツリーがあります。
Using the increased adjacency cost specified in part A2 of Step (A) above, VL links will be avoided unless no other path is available for typical data center link speeds using the default link cost determination method specified in Item 1 of Section 4.2.4.4 of [RFC6325]. However, if links have low speed (such as about 100 megabits/second or less) or some non-default method is used for determining link costs, then link costs MUST be adjusted such that no adjacency between FGL-safe TRILL switches has a cost greater than 200,000.
上記のステップ（A）のパートA2で指定された増加した隣接コストを使用すると、セクション4.2.4.4の項目1で指定されたデフォルトのリンクコスト決定方法を使用して、通常のデータセンターリンク速度に利用できる他のパスがない限り、VLリンクは回避されます。 [RFC6325]。ただし、リンクが低速（約100メガビット/秒以下など）である場合、またはリンクコストの決定にデフォルト以外の方法が使用されている場合は、FGLセーフTRILLスイッチ間の隣接にコストがかからないようにリンクコストを調整する必要があります。 200,000以上。
To summarize, for a mixed TRILL campus to be safe once FGL-edges are introduced, it is essential that the steps above be followed by FGL-safe RBridges, to ensure that paths between such RBridges do not include VL RBridges, and to ensure that FGL packets are never forwarded to VL RBridges. That is, all FGL-safe switches MUST do Step (A) or (B) for any port out of which they observe a VL RBridge neighbor. Also, for full FGL connectivity, all FGL-safe TRILL switches MUST do Step (C) and be connected in a single FGL contiguous area.
要約すると、FGLエッジが導入された後の混合TRILLキャンパスが安全であるためには、上記の手順の後にFGLセーフRBridgeが続き、そのようなRBridge間のパスにVL RBridgeが含まれないようにし、それを確実にすることが不可欠です。 FGLパケットがVL RBridgeに転送されることはありません。つまり、すべてのFGLセーフスイッチは、VL RBridgeネイバーを監視するすべてのポートに対してステップ（A）または（B）を実行する必要があります。また、完全なFGL接続のために、すべてのFGLセーフTRILLスイッチはステップ（C）を実行し、単一のFGL隣接エリアに接続する必要があります。
The usual DRB election operates on a link with mixed FGL and VL ports. If an FGL TRILL switch port is a DRB, it can handle all native traffic. It MUST appoint only other FGL TRILL switch ports as Appointed Forwarder for any VLANs that are to be mapped to FGL.
通常のDRB選択は、FGLポートとVLポートが混在するリンク上で動作します。 FGL TRILLスイッチポートがDRBの場合、すべてのネイティブトラフィックを処理できます。他のFGL TRILLスイッチポートのみを、FGLにマップされるVLANのAppointed Forwarderとして指定する必要があります。
For VLANs that are not being mapped to FGL, if Step (A) is being followed (see Section 5.1), it can appoint either a VL or FGL TRILL switch for a VLAN on the link to be handled by a VL. If Step (B) is being followed, an FGL DRB MUST only appoint FGL Appointed Forwarders, so that all end stations will get service to the FGL campus. If a VL RBridge is a DRB, it will not understand that FGL TRILL switch ports are different. To the extent that Step (B) is in effect and a VL DRB handles native frames or appoints other VL TRILL switch ports on a link to handle native frames for one or more VLANs, the end stations sending and receiving those native frames may be isolated from the FGL campus. When a VL DRB happens to appoint an FGL port as Appointed Forwarder for one or more VLANs, the end stations sending and receiving native frames in those VLANs will get service to the FGL campus.
FGLにマップされていないVLANの場合、ステップ（A）に従っている場合（セクション5.1を参照）、VLによって処理されるリンク上のVLANに対して、VLまたはFGL TRILLスイッチを指定できます。ステップ（B）が実行されている場合、FGL DRBはFGL Appointed Forwarderのみを指定する必要があるため、すべての端末はFGLキャンパスにサービスを提供します。 VL RBridgeがDRBである場合、FGL TRILLスイッチポートが異なることが理解されません。手順（B）が有効であり、VL DRBがネイティブフレームを処理するか、リンク上の他のVL TRILLスイッチポートを指定して、1つ以上のVLANのネイティブフレームを処理する場合、これらのネイティブフレームを送受信するエンドステーションは分離されます。 FGLキャンパスから。 VL DRBがたまたまFGLポートを1つ以上のVLANのAppointed Forwarderとして指定すると、それらのVLANでネイティブフレームを送受信する端末はFGLキャンパスにサービスを提供します。
The list below summarizes the requirements for a TRILL switch to be FGL-safe.
以下のリストは、TRILLスイッチがFGLセーフであるための要件をまとめたものです。
1. For both unicast and multi-destination data, RB1 MUST NOT forward an FGL packet to a VL neighbor RB2. This is accomplished as specified in Section 5.1.
1. ユニキャストデータとマルチ宛先データの両方について、RB1はFGLパケットをVLネイバーRB2に転送してはなりません（MUST NOT）。これは、セクション5.1で指定されているように行われます。
2. For both unicast and multi-destination data, RB1 MUST NOT egress a packet onto a link that does not belong in that FGL.
2. ユニキャストデータとマルチ宛先データの両方について、RB1は、そのFGLに属さないリンクにパケットを出力してはなりません（MUST NOT）。
3. For unicast data, RB1 must forward the FGL packet properly to the egress nickname in the TRILL Header. This means that it MUST NOT delete the packet because of not having the expected VLAN tag, it MUST NOT insert a VLAN tag, and it MUST NOT misclassify a flow so as to persistently misorder packets, because the TRILL fields are now 4 bytes longer than in VL TRILL packets.
3. ユニキャストデータの場合、RB1はFGLパケットをTRILLヘッダーの出力ニックネームに適切に転送する必要があります。これは、予期されたVLANタグがないためにパケットを削除してはならず（MUST）、VLANタグを挿入してはならず（MUST）、フローを誤って分類してパケットを永続的に誤った順序にしてはならないことを意味します。 VL TRILLパケットで。
4. For multi-destination data, RB1 must forward the packet properly along the specified tree. This means that RB1 MUST NOT falsely prune the packet. RB1 is allowed not to prune at all, but it MUST NOT prevent an FGL packet from reaching all the links with that FGL by incorrectly refusing to forward the FGL packet along a branch in the tree.
4. 複数の宛先データの場合、RB1は指定されたツリーに沿ってパケットを適切に転送する必要があります。これは、RB1が誤ってパケットをプルーニングしてはならないことを意味します。 RB1はプルーニングを一切許可しませんが、FGLパケットがツリーのブランチに沿って転送することを誤って拒否することにより、FGLパケットがそのFGLとのすべてのリンクに到達することを防止してはなりません。
5. RB1 must advertise, in its LSP, that it is FGL-safe.
5. RB1は、LSPでFGLセーフであることを通知する必要があります。
Point 1 above, for a TRILL switch to correctly support ECMP, and point 2, for a TRILL switch to correctly prune distribution trees, require that the TRILL switch properly recognize and distinguish between the two Ethertypes that can occur immediately after the Inner.MacSA in a TRILL Data packet.
上記のポイント1、TRILLスイッチがECMPを正しくサポートするため、およびポイント2は、TRILLスイッチが配布ツリーを正しくプルーニングするために、TRILLスイッチが、Inner.MacSAの直後に発生する2つのEthertypeを適切に認識して区別する必要があります。 TRILLデータパケット。
Extensions related to TRILL's use of IS-IS are required to support FGL and must include the following:
TRILLによるIS-ISの使用に関連する拡張機能は、FGLをサポートするために必要であり、以下を含める必要があります。
1. A method for a TRILL switch to announce itself in its LSP as FGL-safe (see Section 8.2).
1. TRILLスイッチが自身のLSPでFGLセーフとしてアナウンスする方法（8.2節を参照）。
2. A sub-TLV analogous to the Interested VLANs and Spanning Tree Roots sub-TLV of the Router Capabilities TLV but indicating FGLs rather than VLs. This is called the Interested Labels and Spanning Tree Roots (INT-LABEL) sub-TLV in [RFC7176].
2. ルータ機能TLVの対象VLANおよびスパニングツリールートサブTLVに類似しているが、VLではなくFGLを示すサブTLV。これは、[RFC7176]では、興味のあるラベルとスパニングツリーのルート（INT-LABEL）サブTLVと呼ばれています。
3. Sub-TLVs analogous to the GMAC-ADDR sub-TLV of the Group Address TLV that specifies an FGL rather than a VL. These are called the GLMAC-ADDR, GLIP-ADDR, and GLIPV6-ADDR sub-TLVs in [RFC7176].
3. VLではなくFGLを指定するグループアドレスTLVのGMAC-ADDRサブTLVに類似したサブTLV。これらは、[RFC7176]ではGLMAC-ADDR、GLIP-ADDR、GLIPV6-ADDRサブTLVと呼ばれています。
Comparing TRILL FGL, as specified in this document, with the goals given in Section 2.1, we find the following:
このドキュメントで指定されているTRILL FGLとセクション2.1の目標を比較すると、次のことがわかります。
1. Fine-Grained: FGL provides 2**24 labels, vastly more than the 4094 (4K) VLAN labels supported in TRILL as specified in [RFC6325].
1. きめ細かい：FGLは2 ** 24のラベルを提供します。これは、[RFC6325]で指定されているTRILLでサポートされている4094（4K）VLANラベルをはるかに超えています。
2. Silicon: Existing TRILL fast path silicon chips can perform base TRILL Header insertion and removal to support ingress and egress. In addition, it is believed that most such silicon chips can also perform the native-frame-to-FGL mapping and the encoding of the FGL as specified herein, as well as the inverse decoding and mapping. Some existing silicon chips can perform only one of these operations on a frame in one pass through the fast path; however, other existing chips are believed to be able to perform both operations on the same frame in one pass through their fast path. It is also believed that most FGL TRILL switches will be capable of having their ports configured to discard FGL packets. Such a capability makes interoperation with VL TRILL switches practical using Step (A) as opposed to Step (B) (see Section 5.1).
2. シリコン：既存のTRILL高速パスシリコンチップは、ベースTRILLヘッダーの挿入と削除を実行して、入出力をサポートできます。さらに、そのようなほとんどのシリコンチップは、ネイティブフレームからFGLへのマッピングと、ここで指定されたFGLのエンコード、および逆デコードとマッピングも実行できると考えられています。一部の既存のシリコンチップは、高速パスの1つのパスでフレームに対してこれらの操作の1つしか実行できません。ただし、他の既存のチップは、高速パスを通過する1つのパスで同じフレームに対して両方の操作を実行できると考えられています。また、ほとんどのFGL TRILLスイッチは、FGLパケットを破棄するようにポートを構成できると考えられています。このような機能により、ステップ（B）ではなくステップ（A）を使用して、VL TRILLスイッチとの相互運用が実用的になります（セクション5.1を参照）。
3. Base RBridge Interoperation: As described in Section 3, FGL is not generally compatible with TRILL switches conformant to the base specification [RFC6325]. In particular, a VL TRILL switch cannot be an FGL TRILL switch because there is a risk that it would mishandle FGL packets. However, a contiguous set of VL TRILL switches can exchange VL frames, regardless of the presence of FGL TRILL switches in the campus. The provisions of Section 5 support reasonable interoperation and migration scenarios.
3. 基本RBridge相互運用：セクション3で説明したように、FGLは基本仕様[RFC6325]に準拠したTRILLスイッチとは一般的に互換性がありません。特に、VL TRILLスイッチをFGL TRILLスイッチにすることはできません。FGLパケットを誤って処理するリスクがあるためです。ただし、キャンパス内のFGL TRILLスイッチの存在に関係なく、VL TRILLスイッチの連続したセットはVLフレームを交換できます。セクション5の規定は、妥当な相互運用および移行シナリオをサポートします。
4. Alternate Priority: The encoding specified in Section 2.3 and the ingress/egress processing specified in Section 4 provide for a new priority and DEI in the Inner.Label High Part and a place to preserve the original user priority and DEI in the Low Part so that it can be restored on egress.
4. 代替優先度：セクション2.3で指定されたエンコーディングとセクション4で指定された入力/出力処理は、Inner.Label High Partに新しい優先度とDEIを提供し、Low Partに元のユーザー優先度とDEIを保持する場所を提供します。出力時に復元できます。
Allocations by the IEEE Registration Authority and IANA are listed below.
IEEE Registration AuthorityとIANAによる割り当てを以下に示します。
The IEEE Registration Authority has assigned Ethertype 0x893B for TRILL FGL.
IEEE Registration Authorityは、TRILL FGLにEthertype 0x893Bを割り当てています。
IANA has allocated capability flag 1 in the TRILL-VER sub-TLV capability flags [RFC7176] to indicate that a TRILL switch is FGL-safe.
IANAはTRILL-VERサブTLV機能フラグ[RFC7176]で機能フラグ1を割り当てて、TRILLスイッチがFGLセーフであることを示しています。
See [RFC6325] for general TRILL security considerations.
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
As with any communications system, end-to-end encryption and authentication should be considered for sensitive data. In this case, that would be encryption and authentication extending from a source end station and carried through the TRILL campus to a destination end station.
他の通信システムと同様に、機密データについては、エンドツーエンドの暗号化と認証を検討する必要があります。この場合、これは、送信元エンドステーションからTRILLキャンパスを経由して宛先エンドステーションに伝送される暗号化と認証です。
Confusion between a packet with VL X and a packet with FGL (X.Y) or confusion due to a malformed frame is a potential problem if an FGL TRILL switch did not properly check for the occurrence of 0x8100 or 0x893B immediately after the Inner.MacSA (see Sections 2.2 and 2.3) and handle the frame appropriately.
Inner.MacSAの直後にFGL TRILLスイッチが0x8100または0x893Bの発生を適切にチェックしなかった場合、VL Xを含むパケットとFGL（XY）を含むパケットの混乱、または不正なフレームによる混乱は、潜在的な問題です。セクション2.2および2.3）およびフレームを適切に処理します。
[RFC6325] requires that the Ethertype immediately after the Inner.MacSA be 0x8100. A VL TRILL switch that did not discard a packet with some other value there could cause problems. If it received a TRILL Data packet with FGL (X.Y) or with junk after the Inner.MacSA that included X where a VLAN ID would appear, then:
[RFC6325]では、Inner.MacSAの直後のEthertypeが0x8100である必要があります。そこに他の値を持つパケットを破棄しなかったVL TRILLスイッチは、問題を引き起こす可能性があります。 VLAN IDが表示されるXを含むInner.MacSAの後に、FGL（X.Y）またはジャンク付きのTRILLデータパケットを受信した場合、次のようになります。
1. It could egress the packet to an end station in VLAN X. If the packet was a well-formed FGL frame, the payload of such an egressed native frame would appear to begin with Ethertype 0x893B, which would likely be discarded by an end station. In any case, such an egress would almost certainly be a violation of security policy requiring the configurable separation of differently labeled data.
1.パケットがVLAN Xのエンドステーションに出力される可能性があります。パケットが整形式のFGLフレームである場合、そのような出力されたネイティブフレームのペイロードはEthertype 0x893Bで始まるように見え、エンドによって破棄される可能性があります。駅。いずれの場合でも、このような下りは、ほぼ確実に、異なるラベルのデータを構成可能に分離することを要求するセキュリティポリシーの違反になります。
2. If the packet was multi-destination and the TRILL switch pruned the distribution tree, it would incorrectly prune it on the basis of VLAN X. For an FGL packet, this would probably lead to the multi-destination data packet not being delivered to all of its intended recipients.
2. パケットが複数の宛先であり、TRILLスイッチが配布ツリーをプルーニングした場合、VLAN Xに基づいて誤ってプルーニングされます。FGLパケットの場合、これにより、複数の宛先データパケットがすべてに配信されない可能性があります。その意図された受信者。
Possible problems with an FGL TRILL switch that (a) received a TRILL Data packet with junk after the Inner.MacSA that included X where a VLAN ID would appear and (b) did not check the Ethertype immediately after the Inner.MacSA would be that it could improperly egress the packet in VLAN X, violating security policy. If the packet was multi-destination and was improperly forwarded, it should be discarded by properly implemented TRILL switches downstream in the distribution tree and never egressed, but the propagation of the packet would still waste bandwidth.
（a）VLAN IDが表示されるXを含むInner.MacSAの後にジャンクのあるTRILLデータパケットを受信し、（b）Inner.MacSAの直後にEthertypeをチェックしなかったFGL TRILLスイッチで起こりうる問題VLAN Xでパケットを不適切に出力し、セキュリティポリシーに違反する可能性があります。パケットが複数の宛先であり、不適切に転送された場合、ディストリビューションツリーのダウンストリームに適切に実装されたTRILLスイッチによって破棄され、決して出力されませんが、パケットの伝搬によって帯域幅が浪費されます。
To avoid these problems, all TRILL switches MUST check the Ethertype immediately after the Inner.MacSA and, if it is a value they do not know how to handle, either discard the frame or make no decisions based on any data after that Ethertype. In addition, care must be taken to avoid FGL packets being sent to or through VL TRILL switches that will discard them if the VL TRILL switch is properly implemented or mishandle them if it is not properly implemented. This is accomplished as specified in Section 5.1.
これらの問題を回避するには、すべてのTRILLスイッチがInner.MacSAの直後にEthertypeをチェックする必要があり、その値が処理方法がわからない場合は、フレームを破棄するか、そのEthertypeの後のデータに基づいて決定を行わないようにします。さらに、VL TRILLスイッチが適切に実装されている場合はFGLパケットが破棄され、VL TRILLスイッチが適切に実装されていない場合はFGLパケットが送信されないように注意する必要があります。これは、セクション5.1で指定されているように行われます。
This informational appendix discusses the advantages and disadvantages of using serial unicast instead of a distribution tree for multi-destination TRILL Data packets. See Sections 4.1 and 4.3. This document requires that FGL TRILL switches accept serial unicast, but there is no requirement that they be able to send serial unicast.
この情報に関する付録では、複数宛先のTRILLデータパケットに対して、配信ツリーの代わりにシリアルユニキャストを使用することの利点と欠点について説明します。セクション4.1および4.3を参照してください。このドキュメントでは、FGL TRILLスイッチがシリアルユニキャストを受け入れることが必要ですが、シリアルユニキャストを送信できる必要はありません。
Consider a large TRILL campus with hundreds of TRILL switches in which, say, 300 end stations are in some particular FGL data label.
たとえば、300のエンドステーションが特定のFGLデータラベルにある、何百ものTRILLスイッチを備えた大規模なTRILLキャンパスについて考えてみます。
At one extreme, if all 300 end stations were on links attached to a single TRILL switch, then no other TRILL switch would be advertising interest in that FGL. As a result, it is likely that because of pruning a multi-destination (say, broadcast) frame from one such end station would not be sent to any another TRILL switch, even if put on a distribution tree.
極端な例として、300のエンドステーションすべてが1つのTRILLスイッチに接続されたリンク上にある場合、他のTRILLスイッチはそのFGLへの関心を宣伝しません。その結果、1つのエンドステーションからのマルチ宛先（たとえば、ブロードキャスト）フレームのプルーニングが原因で、たとえ分散ツリーに配置されていても、別のTRILLスイッチに送信されない可能性があります。
At the other extreme, assume that the 300 end stations are attached, one each, to 300 different TRILL switches; in that case, you are almost certainly better off using a distribution tree because if you tried to serially unicast you would have to output 300 copies, probably including multiple copies through the same port, and would cause much higher link utilization.
もう1つの極端な例として、300のエンドステーションがそれぞれ300の異なるTRILLスイッチに接続されていると仮定します。その場合、ほぼ確実に配布ツリーを使用する方がよいでしょう。シリアルユニキャストを行おうとすると、おそらく同じポートを介した複数のコピーを含めて、300のコピーを出力する必要があり、リンク使用率が非常に高くなるためです。
Now assume that these 300 end stations are connected to exactly two TRILL switches, say, 200 to one and 100 to the other. Using unicast TRILL Data packets between these two TRILL switches is best because the frames will follow least-cost paths, possibly with such traffic spread over a number of least-cost paths with equal cost. On the other hand, if distribution trees were used, each frame would be constrained to the tree used for that frame and would likely follow a higher cost route and only a single path would be available per tree. Thus, this document says that unicast SHOULD be used if there are exactly two TRILL switches involved.
ここで、これらの300のエンドステーションがちょうど2つのTRILLスイッチに接続されていると仮定します。これらの2つのTRILLスイッチ間でユニキャストTRILLデータパケットを使用するのが最適です。フレームが最小コストのパスをたどるので、このようなトラフィックは、コストが等しい複数の最小コストのパスに分散する可能性があります。一方、分散ツリーが使用された場合、各フレームはそのフレームに使用されたツリーに制約され、コストの高いルートをたどる可能性が高く、ツリーごとに1つのパスしか使用できなくなります。したがって、このドキュメントでは、2つのTRILLスイッチが関係している場合はユニキャストを使用する必要がある（SHOULD）と述べています。
The decision of whether to use a distribution tree or serial unicast if the end stations are connected to more than two TRILL switches is more complex. Which would be better would depend on many factors, including network topology and application data patterns. How to make this decision in such cases is beyond the scope of this document.
端末が3つ以上のTRILLスイッチに接続されている場合に、配信ツリーまたはシリアルユニキャストのどちらを使用するかの決定は、より複雑です。どちらが良いかは、ネットワークトポロジやアプリケーションデータパターンなど、多くの要因に依存します。このような場合にこの決定を行う方法は、このドキュメントの範囲外です。
This informational appendix describes the characteristics of a TRILL campus with mixed FGL-safe and VL TRILL switches for two cases: Appendix B.1 discusses the case where all FGL adjacencies with VL are handled by Step (A) in Section 5.1, and Appendix B.2 discusses the case where all FGL adjacencies with VL are handled by Step (B) in Section 5.1.
この情報付録では、FGLセーフスイッチとVL TRILLスイッチが混在するTRILLキャンパスの特性を2つのケースについて説明します。付録B.1では、VLを含むすべてのFGL隣接がセクション5.1のステップ（A）で処理されるケースと、付録Bについて説明します。 .2では、VLを含むすべてのFGL隣接がセクション5.1のステップ（B）で処理される場合について説明します。
If the FGL TRILL switches use Step (A) in Section 5.1, then VL and FGL TRILL switches will be able to interoperate for VL traffic. Least-cost paths will avoid any FGL -> VL TRILL switch hops unless no other reasonable path is available. In conjunction with Section 4.5, there will be at least one distribution tree rooted at a nickname held by an FGL TRILL switch or the pseudonode for an FGL link. Furthermore, if the FGL TRILL switches in the campus form a single contiguous island, this distribution tree will have a fully connected sub-tree covering that island. Thus, any FGL TRILL Data packets sent on this tree will be able to reach any other FGL TRILL switch without attempting to go through any VL TRILL switches. (Such an attempt would cause the FGL packet to be discarded as specified in part A1 of Step (A).)
FGL TRILLスイッチがセクション5.1のステップ（A）を使用する場合、VLおよびFGL TRILLスイッチはVLトラフィックに対して相互運用できます。最小コストのパスは、他の適切なパスが利用可能でない限り、FGL-> VL TRILLスイッチのホップを回避します。セクション4.5に関連して、FGL TRILLスイッチまたはFGLリンクの疑似ノードが保持するニックネームをルートとする少なくとも1つの配布ツリーがあります。さらに、キャンパス内のFGL TRILLスイッチが単一の隣接するアイランドを形成している場合、この配信ツリーはそのアイランドをカバーする完全に接続されたサブツリーを持ちます。したがって、このツリーで送信されたFGL TRILLデータパケットは、VL TRILLスイッチを経由せずに、他のFGL TRILLスイッチに到達できます。 （このような試みは、ステップ（A）のパートA1で指定されているように、FGLパケットが破棄される原因になります。）
If supported, Step (A) is particularly effective in a campus with an FGL TRILL switch core and VL TRILL switches in one or more islands around that core. For example, consider the campus below. This campus has an FGL core consisting of FGL01 to FGL14 and three VL islands consisting of VL01 to VL04, VL05, and VL06 to VL14.
サポートされている場合、ステップ（A）は、FGL TRILLスイッチコアとそのコアの周りの1つ以上のアイランドにあるVL TRILLスイッチを備えたキャンパスで特に効果的です。たとえば、以下のキャンパスを考えてみましょう。このキャンパスには、FGL01からFGL14で構成されるFGLコアと、VL01からVL04、VL05、VL06からVL14で構成される3つのVLアイランドがあります。
*VL01--*VL02
| |
*VL03--*VL04 *VL05
| | |
FGL01--FGL02--FGL03--FGL04--FGL05
| | | | |
FGL06--FGL07--FGL08--FGL09--FGL10
| | | | |
FGL11--FGL12--*VL06--*VL07---FGL13
| | | |
*VL08--*VL09--*VL10---FGL14
| | | |
*VL11--*VL12--*VL13--*VL14
Assuming that the FGL TRILL switches in this campus all implement Step (A), then end stations connected through a VL port can be connected anywhere in the campus to VL or FGL TRILL switches and, if in the same VLAN, will communicate. End stations connected through an FGL port on FGL TRILL switches will communicate if their local VLANs are mapped to the same FGL.
このキャンパスのFGL TRILLスイッチがすべてステップ（A）を実装していると仮定すると、VLポートを介して接続された端末は、キャンパス内のどこにでもVLまたはFGL TRILLスイッチに接続でき、同じVLAN内であれば通信します。 FGL TRILLスイッチのFGLポートを介して接続された端末は、ローカルVLANが同じFGLにマッピングされている場合に通信します。
Due to the high cost of FGL-to-VL adjacencies used in path computations, VL TRILL switches are avoided on paths between FGL TRILL switches. For example, even if the speed and default adjacency cost of all the connections shown above were the same, traffic from FGL12 to FGL13 would follow the 5-hop path FGL12 - FGL07 - FGL08 - FGL09 - FGL10 - FGL13 rather than the 3-hop path FGL12 - VL09 - VL10 - FGL14.
パス計算で使用されるFGLからVLへの隣接のコストが高いため、VL TRILLスイッチは、FGL TRILLスイッチ間のパスで回避されます。たとえば、上記のすべての接続の速度とデフォルトの隣接コストが同じであっても、FGL12からFGL13へのトラフィックは、3ホップではなく、5ホップパスFGL12-FGL07-FGL08-FGL09-FGL10-FGL13をたどります。パスFGL12-VL09-VL10-FGL14。
If the FGL TRILL switches use Step (B) in Section 5.1, then least-cost and distribution tree TRILL Data communication between VL and FGL TRILL switches is blocked, although TRILL IS-IS communication is normal. This data blocking, although implemented only by FGL TRILL switches, has relatively symmetric effects. The following paragraphs assume that such data blocking between VL and FGL is in effect throughout the campus.
FGL TRILLスイッチがセクション5.1の手順（B）を使用する場合、TRILL IS-IS通信は正常ですが、VLとFGL TRILLスイッチ間の最小コストおよび配布ツリーTRILLデータ通信はブロックされます。このデータブロッキングは、FGL TRILLスイッチによってのみ実装されますが、比較的対称的な効果があります。次の段落では、VLとFGLの間のこのようなデータブロッキングがキャンパス全体で有効であると想定しています。
A campus of mostly FGL TRILL switches implementing Step (B) with a few isolated VL TRILL switches scattered throughout will work well in terms of connectivity for end stations attached to those FGL switches, except that they will be unable to communicate with any end stations for which a VL switch is appointed forwarder. The VL TRILL switches will be isolated and will only be able to route TRILL Data to the extent that they happen to be contiguously connected to other VL TRILL switches. Distribution trees computed by the FGL switches will not include any VL switches (see Section 2.1 of [RFC7180]).
ステップ（B）を実装するほとんどのFGL TRILLスイッチのキャンパスは、全体に散在する少数の分離したVL TRILLスイッチで、それらのFGLスイッチに接続された端末の接続性に関してはうまく機能しますが、端末と通信できない場合を除きます。 VLスイッチがフォワーダーに指定されています。 VL TRILLスイッチは分離され、他のVL TRILLスイッチに隣接して接続されている場合にのみTRILLデータをルーティングできます。 FGLスイッチによって計算された分布ツリーには、VLスイッチは含まれません（[RFC7180]のセクション2.1を参照）。
A campus of mostly VL TRILL switches with a few isolated FGL TRILL switches scattered throughout will also work reasonably well as described immediately above but with all occurrences of "FGL" and "VL" swapped.
ほとんどがVL TRILLスイッチで構成され、全体に散在するいくつかの分離されたFGL TRILLスイッチが含まれるキャンパスも、上記の説明とほぼ同じように機能しますが、「FGL」と「VL」はすべて入れ替わります。
However, a campus so badly misconfigured that it consists of a randomly intermingled mixture of VL and FGL TRILL switches using Step (B) is likely to offer very poor data service, due to many links being blocked for data.
ただし、キャンパスが非常に誤って構成されているため、ステップ（B）を使用してVLスイッチとFGL TRILLスイッチがランダムに混在している場合、多くのリンクがデータに対してブロックされているため、データサービスが非常に貧弱になる可能性があります。
Acknowledgements
謝辞
The comments and suggestions of the following, listed in alphabetic order, are gratefully acknowledged:
以下のコメントと提案は、アルファベット順に記載されており、感謝の意を表します。
Stewart Bryant, Spencer Dawkins, Adrian Farrel, Anoop Ghanwani, Sujay Gupta, Weiguo Hao, Phanidhar Koganti, Yizhou Li, Vishwas Manral, Rajeev Manur, Thomas Narten, Gayle Nobel, Erik Nordmark, Pete Resnick, Olen Stokes, Sean Turner, Ilya Varlashkin, and Xuxiaohu.
スチュワートブライアント、スペンサードーキンス、エイドリアンファレル、アヌープガンワニ、スジャイグプタ、ウェイグオハオ、ファニダールコガンティ、イージョウリー、ヴィシュワスマナール、ラジーエフマヌール、トーマスナルテン、ゲイルノーベル、エリックノードマーク、ピートレズニック、オーレンストークス、ショーンターナー、私、Xuxiaohu。
References
参考文献
Normative References
引用文献
[802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011.
[802.1Q] IEEE 802.1、「IEEE Standard for Local and Metropolitan Area Network--Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q-2011、August 2011。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "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)", 2002.
[IS-IS] ISO / IEC 10589：2002、Second Edition、 "Information technology-Telecommunications and information exchange between systems-Intermediate System to Intermediate System intra-domain routinging information exchange protocol with used with with the protocol with with with using the protocol toコネクションレスモードのネットワークサービス（ISO 8473）」、2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、May 2014。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[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, May 2014.
[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、 2014年5月。
Informative References
参考引用
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、2011年4月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A。、およびF. Hu、「Routing Bridges（RBridges）：Appointed Forwarders」、RFC 6439、2011年11月。
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, May 2014.
[RFC7174] Salam、S.、Senevirathne、T.、Aldrin、S。、およびD. Eastlake 3度、「リンクの透過的な相互接続（TRILL）運用、管理、および保守（OAM）フレームワーク」、RFC 7174、5月2014。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、May 2014 。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies Co., Ltd Huawei Building, No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Hai-Dian District Beijing 100095 P.R. China
min鬼Zhang hu A is Technologies co。、Ltd hu A is building、no.156 be i青RD。Z-park、shi-c黄-KE-J i-shi-fan-yuan、h爱-Dイアン地区北京100095中国
EMail: zhangmingui@huawei.com Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose, CA 95134 USA
メール：zhangmingui@huawei.com Puneet Agarwal Broadcom Corporation 3151 Zanker Road San Jose、CA 95134 USA
Phone: +1-949-926-5000
EMail: pagarwal@broadcom.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、カリフォルニア州95054米国
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Dinesh G. Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
Dinesh G. Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale、CA 94086 USA
EMail: ddutt.ietf@hobbesdutt.com