[要約] RFC 7968は、TRILLプロトコルにおいてデータラベルを使用して複数宛先データのツリー選択を行う方法を提案している。その目的は、効率的なネットワークトラフィックの配信とスケーラビリティの向上を実現することである。
Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7968 D. Eastlake 3rd
Category: Standards Track W. Hao
ISSN: 2070-1721 H. Chen
Huawei Technologies
S. Chatterjee
Cisco
August 2016
Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data
多数のリンクの透過的な相互接続（TRILL）：複数の宛先データのツリー選択にデータラベルを使用する
Abstract
概要
TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN, FGL, or multicast group can be sent on any tree, for typical fast-path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.
TRILL（多数のリンクの透過的相互接続）は、配信ツリーを使用して複数の宛先フレームを配信します。フローのVLAN、ファイングレインラベル（FGL）、および/またはマルチキャストグループに関係なく、フローの入口ルーティングブリッジ（RBridge）で複数のツリーを使用できます。異なる入力RBridgeは、同じVLAN、FGL、および/またはマルチキャストグループ内のTRILLデータパケットに対して異なる分散ツリーを選択する場合があります。不要なリンク使用率を回避するには、VLAN、FGL、またはマルチキャスト宛先アドレスの1つ以上に基づいて配布ツリーをプルーニングする必要があります。 VLAN、FGL、またはマルチキャストグループを任意のツリーで送信できる場合、一般的な高速パスハードウェアでは、プルーニング情報の量にツリーの数が掛けられますが、そのようなプルーニング情報のハードウェア容量は限られています。
This document specifies an optional facility to restrict the TRILL Data packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware.
このドキュメントでは、VLAN、FGL、マルチキャストグループごとに特定の配信ツリーで送信されるTRILLデータパケットを制限するオプションの機能を指定します。これにより、プルーニング情報の総量が減り、高速パスハードウェアでより簡単に対応できるようになります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7968.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7968で入手できます。
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 ....................................................3
1.1. Background Description .....................................3
1.2. Terminology Used in This Document ..........................4
2. Motivations .....................................................5
3. Tree Selection Based on Data Labels .............................9
3.1. Overview of the Mechanism ..................................9
3.2. APPsub-TLVs Supporting Tree Selection .....................10
3.2.1. The Tree and VLANs APPsub-TLV ......................11
3.2.2. The Tree and VLANs Used APPsub-TLV .................12
3.2.3. The Tree and FGLs APPsub-TLV .......................12
3.2.4. The Tree and FGLs Used APPsub-TLV ..................13
3.2.5. The Tree and Groups APPsub-TLV .....................13
3.2.6. The Tree and Groups Used APPsub-TLV ................14
3.3. Detailed Processing .......................................14
3.4. Failure Handling ..........................................15
4. Backward Compatibility .........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
Acknowledgments ...................................................21
Authors' Addresses ................................................21
One or more distribution trees, identified by their root nicknames, are used to distribute multi-destination data in a (Transparent Interconnection of Lots of Links) (TRILL) campus [RFC6325]. The Routing Bridge (RBridge) having the highest tree root priority announces the total number of trees that should be computed for the campus. It may also specify the list of trees that RBridges need to compute using the Tree Identifiers (TREE-RT-IDs) sub-TLV [RFC7176]. Every RBridge can specify the trees it will use for multi-destination TRILL Data packets it originates in the Trees Used Identifiers (TREE-USE-IDs) sub-TLV [RFC7176], and the VLANs or Fine-Grained Labels (FGLs) [RFC7172] it is interested in are specified in Interested VLANs and/or Interested Labels sub-TLVs [RFC7176]. It is suggested that by default the ingress RBridge uses the distribution tree whose root is the closest [RFC6325]. The TREE-USE-IDs sub-TLV is used to build the RPF (Reverse Path Forwarding) check table that is used for RPF checking. Interested VLANs and Interested Labels sub-TLVs are used for distribution tree pruning, and the multi-destination forwarding table with pruning information is built based on that RPF check table. To reduce unnecessary link loads, each distribution tree should be pruned per VLAN/FGL, eliminating branches that have no potential receivers downstream as specified in [RFC6325]. Further pruning based on Layer 2 or Layer 3 multicast addresses is also possible.
ルートニックネームで識別される1つ以上の配布ツリーを使用して、（リンクの透過的な相互接続）（TRILL）キャンパスで複数の宛先データを配布します[RFC6325]。ツリールートの優先度が最も高いルーティングブリッジ（RBridge）は、キャンパスに対して計算する必要があるツリーの総数を通知します。また、ツリー識別子（TREE-RT-ID）サブTLV [RFC7176]を使用してRBridgeが計算する必要があるツリーのリストを指定することもできます。すべてのRBridgeは、Trees Used Identifiers（TREE-USE-IDs）sub-TLV [RFC7176]と、VLANまたはFine-Grained Labels（FGL）[RFC7172]で発生する複数宛先TRILLデータパケットに使用するツリーを指定できます。 ]関心のあるVLANや関心のあるラベルのサブTLVで指定されている[RFC7176]。デフォルトでは、入力RBridgeは、ルートが最も近い[RFC6325]の配布ツリーを使用することをお勧めします。 TREE-USE-IDsサブTLVは、RPFチェックに使用されるRPF（Reverse Path Forwarding）チェックテーブルを作成するために使用されます。関係のあるVLANと関係のあるラベルのサブTLVは、配布ツリーのプルーニングに使用され、プルーニング情報を含む複数宛先転送テーブルは、そのRPFチェックテーブルに基づいて構築されます。不要なリンクの負荷を減らすには、[RFC6325]で指定されているように、ダウンストリームの受信機がない可能性のあるブランチを排除して、各配信ツリーをVLAN / FGLごとに枝刈りする必要があります。レイヤ2またはレイヤ3のマルチキャストアドレスに基づいてさらにプルーニングすることも可能です。
Defaults are provided, but how many trees are calculated, where the tree roots are located, and which tree or trees are to be used by an ingress RBridge are implementation dependent. With the increasing demand to use TRILL in data center networks, there are some features we can explore for multi-destination frames in the data center use case. In order to achieve non-blocking data forwarding, a fat tree structure is often used. Figure 1 shows a typical data center network based on the fat tree structure. RB1 and RB2 are aggregation switches, and RB11 through RB14 are access switches. It is a common practice to configure the tree roots to be at the aggregation switches for efficient traffic transportation. All the ingress RBridges that are access switches will then be equally distant from all the tree roots.
デフォルトが提供されますが、計算されるツリーの数、ツリーのルートが配置される場所、および入力RBridgeによって使用される1つまたは複数のツリーは実装に依存します。データセンターネットワークでTRILLを使用する需要が高まるにつれ、データセンターのユースケースで複数の宛先フレームについて調査できるいくつかの機能があります。ノンブロッキングデータ転送を実現するために、ファットツリー構造がよく使用されます。図1は、ファットツリー構造に基づく典型的なデータセンターネットワークを示しています。 RB1とRB2は集約スイッチであり、RB11からRB14はアクセススイッチです。効率的なトラフィック輸送のために、ツリールートを集約スイッチに配置するのが一般的な方法です。アクセススイッチであるすべての入力RBridgeは、すべてのツリールートから等しく離れます。
+-----+ +-----+
| RB1 | | RB2 |
+-----+ +-----+
/ | \\ / /|\
/ | \ \ / / | \
/ | \ \ / | \-----+
/ | \/ \ | |
/ | /\/ \| |
/ /---+---/ /\ |\ |
/ / | / \ | \ |
/ / | / \ | \ |
/ / | / \ | \ |
+-----+ +-----+ +-----+ +-----+
| RB11| | RB12| | RB13| | RB14|
+-----+ +-----+ +-----+ +-----+
Figure 1: TRILL Network Based on Fat Tree Structure
図1：ファットツリー構造に基づくTRILLネットワーク
This document uses the terminology from [RFC6325] and [RFC7172], some of which is repeated below for convenience, along with some additional terms listed below:
このドキュメントでは、[RFC6325]と[RFC7172]の用語を使用しています。その一部は、以下にリストされているいくつかの追加の用語とともに、便宜上以下に繰り返されています。
Campus: The name for a network using the TRILL protocol in the same sense that a "bridged LAN" is the name for a network using bridging. In TRILL, the word "campus" has no academic implication.
キャンパス：「ブリッジLAN」がブリッジングを使用するネットワークの名前であるのと同じ意味で、TRILLプロトコルを使用するネットワークの名前。 TRILLでは、「キャンパス」という言葉は学問的な意味を持ちません。
Data Label: VLAN or FGL.
データラベル：VLANまたはFGL。
ECMP: Equal-Cost Multipath [RFC6325].
ECMP：等コストマルチパス[RFC6325]。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
Interested Labels sub-TLV: Short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176].
興味のあるラベルのサブTLV：「興味のあるラベルとスパニングツリールートのサブTLV」の略[RFC7176]。
Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176].
関心のあるVLANサブTLV：「関心のあるVLANとスパニングツリールートのサブTLV」の略[RFC7176]。
IPTV: "Television" (video) over IP.
IPTV：IP上の「テレビ」（ビデオ）。
RBridge: An alternative name for a TRILL switch.
RBridge：TRILLスイッチの別名。
RPF: Reverse Path Forwarding.
RPF：リバースパス転送。
TRILL: Transparent Interconnection of Lots of Links (or Tunneled Routing in the Link Layer).
TRILL：多数のリンクの透過的な相互接続（またはリンク層のトンネルルーティング）。
TRILL switch: A device implementing the TRILL protocol. Sometimes called an RBridge.
TRILLスイッチ：TRILLプロトコルを実装するデバイス。 RBridgeと呼ばれることもあります。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In the structure of Figure 1, if we choose to put the tree roots at RB1 and RB2, the ingress RBridge (e.g., RB11) would find more than one equal-cost closest tree root (i.e., RB1 and RB2). An ingress RBridge has two options to select the tree root for multi-destination frames: choose one and only one as the distribution tree root, or use an ECMP-like algorithm to balance the traffic among the multiple trees whose roots are at the same distance from the RBridge.
図1の構造で、ツリールートをRB1とRB2に配置することを選択した場合、入力RBridge（たとえば、RB11）は複数の等コストの最も近いツリールート（つまり、RB1とRB2）を見つけます。入力RBridgeには、マルチ宛先フレームのツリールートを選択する2つのオプションがあります。1つだけを配布ツリールートとして選択するか、ECMPのようなアルゴリズムを使用して、ルートが同じ距離にある複数のツリー間でトラフィックのバランスをとりますRBridgeから。
- For the former (one distribution tree root), a single tree used by each ingress RBridge can have the problem of uneven or inefficient link usage. For example, if RB11 chooses the tree that is rooted at RB1 as the distribution tree, the link between RB11 and RB2 will not be used for multi-destination frames ingressed by RB11.
- 前者（1つの配布ツリールート）の場合、各入力RBridgeで使用される単一のツリーには、リンクの使用が不均一または非効率であるという問題がある可能性があります。たとえば、RB11がRB1をルートとするツリーを配布ツリーとして選択した場合、RB11とRB2の間のリンクは、RB11が入力する複数の宛先のフレームには使用されません。
- For the latter (an ECMP-like algorithm), ECMP-based tree selection results in a linear increase in multicast forwarding table size with the number of trees, as explained in the next paragraph.
- 後者（ECMPに似たアルゴリズム）では、次の段落で説明するように、ECMPベースのツリー選択により、ツリーの数に応じてマルチキャスト転送テーブルのサイズが直線的に増加します。
A multicast forwarding table at an RBridge is normally used to map the key of (distribution tree nickname + VLAN) to an index to a list of ports for multicast packet replication. The key used for mapping is simply the tree nickname when the RBridge does not prune the tree.
RBridgeのマルチキャスト転送テーブルは、通常、（配布ツリーのニックネーム+ VLAN）のキーを、マルチキャストパケットレプリケーション用のポートのリストへのインデックスにマップするために使用されます。 RBridgeがツリーをプルーニングしない場合、マッピングに使用されるキーは単にツリーのニックネームです。
The key could be the distribution tree nickname augmented by the FGL and/or Layer 2 or 3 multicast address when the RBridge supports FGL and/or Layer 2 or 3 pruning information.
キーは、RBridgeがFGLやレイヤー2または3のプルーニング情報をサポートしている場合、FGLやレイヤー2または3のマルチキャストアドレスによって拡張された配信ツリーニックネームである可能性があります。
For any RBridge RBn, for each VLAN x, if RBn is in a distribution tree t used by traffic in VLAN x, there will be an entry of (t, x, port list) in the multicast forwarding table on RBn. Typically, each entry contains a distinct combination of (tree nickname, VLAN) as the lookup key. If there are n such trees and m such VLANs, the multicast forwarding table size on RBn is n*m entries. If an FGL is used [RFC7172] and/or finer pruning is used (for example, VLAN + multicast group address is used for pruning), the value of m increases. In the larger-scale data center, more trees would be necessary for purposes of better load-balancing; this results in an increased value for n. In either case, the number of table entries (i.e., n*m) will increase dramatically.
RBridge RBnの場合、各VLAN xについて、RBnがVLAN xのトラフィックによって使用される配布ツリーtにある場合、RBnのマルチキャスト転送テーブルに（t、x、ポートリスト）のエントリがあります。通常、各エントリには、ルックアップキーとして（ツリーニックネーム、VLAN）の異なる組み合わせが含まれます。そのようなツリーがn個あり、VLANがm個ある場合、RBn上のマルチキャスト転送テーブルのサイズはn * mエントリです。 FGLが使用されている場合[RFC7172]および/またはより細かいプルーニングが使用されている場合（たとえば、プルーニングにVLAN +マルチキャストグループアドレスが使用されている場合）、mの値は増加します。より大規模なデータセンターでは、負荷分散を向上させるために、より多くのツリーが必要になります。これにより、nの値が増加します。どちらの場合でも、テーブルエントリの数（つまり、n * m）は劇的に増加します。
The left-hand table in Figure 2 shows an example of the multicast forwarding table on RB11 in the Figure 1 topology, with two distribution trees in a campus using typical fast-path hardware.
図2の左側の表は、図1のトポロジにおけるRB11のマルチキャスト転送テーブルの例を示しています。キャンパス内に2つの配布ツリーがあり、一般的な高速パスハードウェアを使用しています。
Before VLAN-Based After VLAN-Based
Tree Selection Tree Selection
+--------------+-----+---------+ +--------------+-----+---------+
|tree nickname |VLAN |port list| |tree nickname |VLAN |port list|
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 1 | | | tree 1 | 1 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 2 | | | tree 1 | 2 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 1999| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 2000| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4093| | | tree 2 | 2001| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4094| | | tree 2 | 2002| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 1 | | | tree 2 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 2 | | | tree 2 | 4093| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | | | tree 2 | 4094| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | 4093| |
+--------------+-----+---------+
| tree 2 | 4094| |
+--------------+-----+---------+
Figure 2: Multicast Forwarding Table before and after Using VLAN-Based Tree Selection
図2：VLANベースのツリー選択を使用する前後のマルチキャスト転送テーブル
The number of entries is approximately 2*4K in this case. If four distribution trees are used in a TRILL campus and RBn has 4K VLANs with downstream receivers, it consumes 16K table entries. The size of fast-path TRILL multicast forwarding tables is typically limited by hardware; therefore, the table entries are a precious resource.
この場合、エントリ数は約2 * 4Kです。 4つの配布ツリーがTRILLキャンパスで使用され、RBnに4KのVLANとダウンストリームレシーバーがある場合、16Kのテーブルエントリを消費します。高速パスTRILLマルチキャスト転送テーブルのサイズは、通常、ハードウェアによって制限されます。したがって、テーブルエントリは貴重なリソースです。
In some implementations, the table is shared with Layer 3 IP multicast for a total of 16K or 8K table entries. Therefore, we want to reduce the table size consumed for TRILL distribution trees as much as possible and at the same time maintain load-balancing among the trees.
一部の実装では、テーブルはレイヤ3 IPマルチキャストと共有され、合計で16Kまたは8Kのテーブルエントリになります。したがって、TRILL配信ツリーで消費されるテーブルサイズをできるだけ小さくし、同時にツリー間の負荷分散を維持したいと考えています。
In cases where blocks of consecutive VLANs or FGLs can be assigned to a tree, the multicast forwarding table could be greatly compressed if entries could have a Data Label value and mask, with the fast-path hardware doing the longest prefix matching. But few, if any, fast-path implementations provide such logic.
連続するVLANまたはFGLのブロックをツリーに割り当てることができる場合、高速パスハードウェアが最長のプレフィックスマッチングを行うことで、エントリにデータラベル値とマスクを含めることができれば、マルチキャスト転送テーブルを大幅に圧縮できます。しかし、ファストパス実装がそのようなロジックを提供する場合は、たとえあるとしてもごくわずかです。
A straightforward way to alleviate the problem of limited table entries is not to prune the distribution tree. However, this can only be used in restricted scenarios, for the following reasons:
限られたテーブルエントリの問題を軽減する簡単な方法は、配布ツリーをプルーニングしないことです。ただし、これは次の理由により、制限されたシナリオでのみ使用できます。
- Not pruning wastes bandwidth for multi-destination packets. There is normally broadcast traffic, like ARP and unknown unicast, that can be pruned on a VLAN (or FGL) so that it is not sent down branches of a distribution tree where it is not needed. In addition, if there is a lot of Layer 3 multicast traffic, no pruning may result in a worst-case scenario where that user data is unnecessarily flooded all over the campus. The volume of flooded data could be very large if certain applications such as IPTV are supported. More precise pruning, such as pruning based on multicast groups, may be desirable in this case.
- プルーニングを行わないと、複数の宛先のパケットの帯域幅が浪費されます。通常、ARPや不明なユニキャストなどのブロードキャストトラフィックがあり、VLAN（またはFGL）でプルーニングできるため、不要な配布ツリーのブランチに送信されません。さらに、レイヤ3マルチキャストトラフィックが大量にある場合、プルーニングによって最悪のシナリオが発生し、キャンパス全体にそのユーザーデータが不必要にフラッディングされる可能性があります。 IPTVなどの特定のアプリケーションがサポートされている場合、フラッディングされるデータの量が非常に大きくなる可能性があります。この場合、マルチキャストグループに基づくプルーニングなど、より正確なプルーニングが望ましい場合があります。
- Not pruning is only useful at pure transit nodes. Edge nodes always need to maintain the multicast forwarding table with the key of (tree nickname + VLAN (or FGL)), since the edge node needs to decide whether and how to replicate the frame to local access ports. It is likely that edge nodes are relatively low-end switches with a smaller shared table size, say 4K, available.
- プルーニングは、純粋なトランジットノードでのみ役立ちます。エッジノードは、フレームをローカルアクセスポートにレプリケートするかどうかと方法を決定する必要があるため、（ツリーニックネーム+ VLAN（またはFGL））のキーを使用してマルチキャスト転送テーブルを常に維持する必要があります。エッジノードは比較的ローエンドのスイッチであり、共有テーブルのサイズが小さく、たとえば4Kである可能性があります。
- Due to security concerns, VLAN-based (or FGL-based) traffic isolation is a basic requirement in some scenarios. No pruning may increase the risk of leakage of the traffic. Misbehaving RBridges may take advantage of this leakage of traffic.
- セキュリティ上の理由から、一部のシナリオでは、VLANベース（またはFGLベース）のトラフィック分離が基本的な要件です。剪定をしないと、トラフィックの漏洩のリスクが高まる可能性があります。 RBridgeの誤動作は、このトラフィックの漏洩を利用する可能性があります。
In addition to the concern regarding multicast table size, some silicon does not currently support hashing-based tree nickname selection at the ingress RBridge but commonly uses VLAN-based tree selection. If the control plane of the ingress RBridge maps the incoming VLAN x to a tree nickname t, the data plane will always use tree t for VLAN x multi-destination frames. Such an ingress RBridge may choose multiple trees to be used for load-sharing; it can use one and only one tree for each VLAN. If we make sure that all ingress RBridges campus-wide send VLAN x multi-destination packets only use tree t, then there would be no need to store the multicast table entry with the key of (tree-other-than-t, x) on any RBridge.
マルチキャストテーブルのサイズに関する懸念に加えて、一部のシリコンは現在、入力RBridgeでのハッシュベースのツリーニックネーム選択をサポートしていませんが、一般にVLANベースのツリー選択を使用しています。入力RBridgeのコントロールプレーンが着信VLAN xをツリーニックネームtにマップする場合、データプレーンは常にVLAN xマルチ宛先フレームにツリーtを使用します。このような入力RBridgeは、負荷共有に使用される複数のツリーを選択する場合があります。 VLANごとに1つだけツリーを使用できます。キャンパス全体のすべての入力RBridges送信VLAN xマルチ宛先パケットがツリーtのみを使用することを確認すると、（tree-other-than-t、x）のキーを持つマルチキャストテーブルエントリを格納する必要がなくなります。 RBridge上で。
This document describes the TRILL control-plane support for distribution tree selection based on a VLAN, FGL, and/or multicast address to reduce the multicast forwarding table size. It is compatible with the silicon implementations mentioned in the previous paragraph.
このドキュメントでは、VLAN、FGL、またはマルチキャストアドレスに基づいて配信ツリーを選択し、マルチキャスト転送テーブルのサイズを削減するためのTRILLコントロールプレーンサポートについて説明します。これは、前の段落で述べたシリコン実装と互換性があります。
Data Label (VLAN-based or FGL-based) tree selection can be used as a distribution tree selection mechanism, especially when the multicast forwarding table size is a concern. This section specifies that mechanism and how to extend it so that tree selection can be based on multicast groups.
データラベル（VLANベースまたはFGLベース）のツリー選択は、特にマルチキャスト転送テーブルのサイズが問題になる場合に、配信ツリー選択メカニズムとして使用できます。このセクションでは、そのメカニズムと、ツリー選択がマルチキャストグループに基づくように拡張する方法を指定します。
The RBridge that has the highest priority to be a tree root announces the tree nicknames and the Data Labels allowed on each tree. Such announcements of correspondence of tree to Data Label can be based on static configuration or some predefined algorithm beyond the scope of this document. An ingress RBridge selects the tree-VLAN correspondence that it wishes to use from the list announced by the highest-priority tree root. It SHOULD NOT transmit VLAN x frames on tree y if the highest-priority tree root does not say that VLAN x is allowed on tree y.
ツリールートになることを最高の優先度とするRBridgeは、ツリーのニックネームと各ツリーで許可されているデータラベルを通知します。このようなツリーとデータラベルの対応のアナウンスは、このドキュメントの範囲を超えた静的構成または事前定義されたアルゴリズムに基づく場合があります。入力RBridgeは、最も優先度の高いツリールートによって通知されたリストから、使用するツリーとVLANの対応を選択します。最も優先順位の高いツリールートがVLAN xがツリーyで許可されていると言っていない場合、ツリーyでVLAN xフレームを送信しないでください。
If we make sure that a particular VLAN is allowed on one and only one tree, we can keep the number of multicast forwarding table entries on any RBridge fixed at 4K maximum (or up to 16M in the case of an FGL). Take Figure 1 as an example, where two trees are rooted at RB1 and RB2, respectively. The highest-priority tree root appoints tree 1 to carry VLAN 1-2000 and tree 2 to carry VLAN 2001-4094. With such an announcement by the highest-priority tree root, every RBridge that understands the announcement will not send VLAN 2001-4094 traffic on tree 1 and will not send VLAN 1-2000 traffic on tree 2. That way, no RBridge would need to store the entries for tree 1 / VLAN 2001-4094 or tree 2 / VLAN 1-2000. Figure 2 shows the multicast forwarding table on an RBridge before and after we use VLAN-based tree selection. The number of entries is reduced by a factor f, where f is the number of trees used in the campus. In this example, it is reduced from 2*4094 to 4094. This affects both transit nodes and edge nodes. The data-plane encoding does not change.
特定のVLANが1つだけのツリーで許可されていることを確認すると、RBridge上のマルチキャスト転送テーブルエントリの数を最大4K（FGLの場合は最大16M）に保つことができます。図1を例にとると、2つのツリーがそれぞれRB1とRB2をルートとします。最も優先順位の高いツリールートは、ツリー1を指定してVLAN 1-2000を伝送し、ツリー2をVLAN 2001-4094を伝送します。最優先のツリールートによるこのようなアナウンスでは、アナウンスを理解するすべてのRBridgeは、ツリー1にVLAN 2001-4094トラフィックを送信せず、ツリー2にVLAN 1-2000トラフィックを送信しません。そのため、RBridgeは、ツリー1 / VLAN 2001-4094またはツリー2 / VLAN 1-2000のエントリを保存します。図2は、VLANベースのツリー選択を使用する前後のRBridgeのマルチキャスト転送テーブルを示しています。エントリの数は、係数fによって削減されます。ここで、fは、キャンパスで使用されるツリーの数です。この例では、2 * 4094から4094に減少しています。これは、トランジットノードとエッジノードの両方に影響します。データプレーンのエンコーディングは変更されません。
Six new APPsub-TLVs that can be carried in the TRILL GENINFO TLV [RFC7357] in Extended Level 1 Flooding Scope (E-L1FS) FS-Link State Protocol Data Units (FS-LSPs) [RFC7780] are defined below. The first four can be considered analogous to finer-granularity versions of the TREE-RT-IDs sub-TLV and the TREE-USE-IDs sub-TLV [RFC7176]. Two APPsub-TLVs supporting VLAN-based tree selection are specified in Sections 3.2.1 and 3.2.2. They are used by the highest-priority tree root to announce the allowed VLANs on each tree in the campus and by an ingress RBridge to announce the tree-VLAN correspondence that it selects from the list announced by the highest-priority tree root. Two APPsub-TLVs supporting FGL-based tree selection are specified in Sections 3.2.3 and 3.2.4 for the same purpose. Sections 3.2.5 and 3.2.6 define two APPsub-TLVs to support finer granularity in selecting trees based on multicast groups rather than Data Labels.
拡張レベル1フラッディングスコープ（E-L1FS）FS-Link状態プロトコルデータユニット（FS-LSP）[RFC7780]のTRILL GENINFO TLV [RFC7357]で伝送できる6つの新しいAPPsub-TLVを以下に定義します。最初の4つは、TREE-RT-IDsサブTLVおよびTREE-USE-IDsサブTLV [RFC7176]のより細かいバージョンに類似していると考えることができます。 VLANベースのツリー選択をサポートする2つのAPPsub-TLVは、セクション3.2.1および3.2.2で指定されています。これらは、最も優先度の高いツリールートがキャンパス内の各ツリーで許可されたVLANをアナウンスするために使用し、入力RBridgeが、最も優先度の高いツリールートによってアナウンスされたリストから選択するツリーとVLANの対応をアナウンスします。 FGLベースのツリー選択をサポートする2つのAPPsub-TLVは、セクション3.2.3および3.2.4で同じ目的で指定されています。セクション3.2.5および3.2.6は、データラベルではなくマルチキャストグループに基づいてツリーを選択する際に、より細かい粒度をサポートする2つのAPPsub-TLVを定義します。
New APPsub-TLVs Description
======================= =============
Tree and VLANs announcement by the highest-priority
tree root of the VLANs allowed per tree
Tree and VLANs Used tree-VLAN correspondence that an ingress RBridge selects
ツリーとVLAN入力RBridgeが選択する使用済みツリー-VLAN対応
Tree and FGLs announcement by the highest-priority tree root of the FGLs allowed per tree
ツリーごとに許可されたFGLの最も優先度の高いツリールートによるツリーとFGLのアナウンス
Tree and FGLs Used tree-FGL correspondence that an ingress RBridge selects
ツリーとFGLの使用入口RBridgeが選択するツリーとFGLの対応
Tree and Groups announcement by the highest-priority tree root of the multicast groups allowed on each tree
各ツリーで許可されているマルチキャストグループの最も優先度の高いツリールートによるツリーとグループのアナウンス
Tree and Groups Used tree and multicast group correspondence that an ingress RBridge selects
ツリーとグループ入力RBridgeが選択する使用済みツリーとマルチキャストグループの対応
The RBridge that is the highest-priority tree root announces the VLANs allowed on each tree with the Tree and VLANs (TREE-VLANs) APPsub-TLV. Multiple instances of this APPsub-TLV may be carried. The same tree nicknames may occur in multiple Tree-VLAN RECORDs within the same APPsub-TLV or across multiple APPsub-TLVs. The APPsub-TLV format is as follows:
最も優先度の高いツリールートであるRBridgeは、ツリーとVLAN（TREE-VLAN）APPsub-TLVを使用して、各ツリーで許可されているVLANを通知します。このAPPsub-TLVの複数のインスタンスを実行できます。同じツリーニックネームは、同じAPPsub-TLV内の複数のTree-VLAN RECORDで、または複数のAPPsub-TLVで発生する可能性があります。 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 = 11 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-VLAN RECORD (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
where each Tree-VLAN RECORD is of the form:
各Tree-VLAN RECORDの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TRILL GENINFO APPsub-TLV type; set to 11 (TREE-VLANs).
o タイプ：TRILL GENINFO APPsub-TLVタイプ。 11（TREE-VLAN）に設定します。
o Length: 6*n bytes, where there are n Tree-VLAN RECORDs. Thus, the value of Length can be used to determine n. If Length is not a multiple of 6, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：6 * nバイト。n個のTree-VLAN RECORDがあります。したがって、Lengthの値を使用してnを決定できます。長さが6の倍数でない場合、APPsub-TLVは破損しているため、無視する必要があります。
o Nickname: The nickname identifying the distribution tree by its root.
o ニックネーム：配布ツリーをルートで識別するニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the allowed VLAN range on the tree, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. If End.VLAN is less than Start.VLAN, the Tree-VLAN RECORD MUST be ignored.
o Start.VLAN、End.VLAN：これらのフィールドは、ツリーで許可されたVLAN範囲のVLAN IDです。単一のVLANを指定する場合、VLANのIDは開始VLANと終了VLANの両方として表示されます。 End.VLANがStart.VLANより小さい場合、Tree-VLAN RECORDは無視する必要があります。
This APPsub-TLV has the same structure as the TREE-VLANs APPsub-TLV specified in Section 3.2.1. The differences are that its APPsub-TLV type is set to 12 (TREE-VLAN-USE) and the tree-VLAN correspondences in the Tree-VLAN RECORDs listed are those correspondences that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-VLAN correspondence that it selects from the list announced by the highest-priority tree root.
このAPPsub-TLVの構造は、セクション3.2.1で指定されたTREE-VLANのAPPsub-TLVと同じです。違いは、そのAPPsub-TLVタイプが12（TREE-VLAN-USE）に設定されていることと、リストされているTree-VLAN RECORD内のtree-VLANの対応が、元のRBridgeが複数の宛先のパケットに使用したい対応であることです。このAPPsub-TLVは、入力RBridgeによって使用され、最も優先度の高いツリールートによって通知されたリストから選択したツリーとVLANの対応を配布します。
The RBridge that is the highest-priority tree root can use the Tree and FGLs (TREE-FGLs) APPsub-TLV to announce the FGLs allowed on each tree. Multiple instances of this APPsub-TLV may be carried. The same tree nicknames may occur in the multiple Tree-FGL RECORDs within the same APPsub-TLV or across multiple APPsub-TLVs. Its format is as follows:
最も優先順位の高いツリールートであるRBridgeは、ツリーとFGL（TREE-FGL）APPsub-TLVを使用して、各ツリーで許可されているFGLを通知できます。このAPPsub-TLVの複数のインスタンスを実行できます。同じAPPsub-TLV内または複数のAPPsub-TLVにまたがる複数のTree-FGL RECORDで同じツリーニックネームが発生する場合があります。その形式は次のとおりです。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 13 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (1) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
| Tree-FGL RECORD (N) | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
where each Tree-FGL RECORD is of the form:
各Tree-FGL RECORDの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Start.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| End.FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
o Type: TRILL GENINFO APPsub-TLV type; set to 13 (TREE-FGLs).
o タイプ：TRILL GENINFO APPsub-TLVタイプ。 13（TREE-FGL）に設定します。
o Length: 8*n bytes, where there are n Tree-FGL RECORDs. Thus, the value of Length can be used to determine n. If Length is not a multiple of 8, the APPsub-TLV is corrupt and MUST be ignored.
o 長さ：8 * nバイト。n個のTree-FGL RECORDがあります。したがって、Lengthの値を使用してnを決定できます。長さが8の倍数でない場合、APPsub-TLVは破損しているため、無視する必要があります。
o Nickname: The nickname identifying the distribution tree by its root.
o ニックネーム：配布ツリーをルートで識別するニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Start.FGL, End.FGL: These fields are the FGL IDs of the allowed FGL range on the tree, inclusive. To specify a single FGL, the FGL's ID appears as both the start and end FGL. If End.FGL is less than Start.FGL, the Tree-FGL RECORD MUST be ignored.
o Start.FGL、End.FGL：これらのフィールドは、ツリーで許可されているFGL範囲のFGL IDです。単一のFGLを指定するには、FGLのIDを開始FGLと終了FGLの両方として表示します。 End.FGLがStart.FGLより小さい場合は、Tree-FGL RECORDを無視する必要があります。
This APPsub-TLV has the same structure as the TREE-FGLs APPsub-TLV specified in Section 3.2.3. The differences are that its APPsub-TLV type is set to 14 (TREE-FGL-USE) and the Tree-FGL correspondences in the Tree-FGL RECORDs listed are those that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-FGL correspondence that it selects from the list announced by the highest-priority tree root.
このAPPsub-TLVの構造は、セクション3.2.3で指定されたTREE-FGLのAPPsub-TLVと同じです。違いは、そのAPPsub-TLVタイプが14（TREE-FGL-USE）に設定されていることと、リストされているTree-FGL RECORD内のTree-FGL対応が、発信RBridgeが複数の宛先パケットに使用したい対応であることです。このAPPsub-TLVは、入力RBridgeによって使用され、最も優先度の高いツリールートによって通知されたリストから選択したツリーとFGLの対応を配布します。
Tree selection based on Data Labels is easily extended to tree selection based on Data Label + Layer 2 or 3 multicast groups. We can appoint multicast group 1 in VLAN 10 to tree 1 and appoint group 2 in VLAN 10 to tree 2 for better load-sharing.
データラベルに基づくツリー選択は、データラベル+レイヤー2または3マルチキャストグループに基づくツリー選択に簡単に拡張できます。負荷分散を改善するために、VLAN 10のマルチキャストグループ1をツリー1に、VLAN 10のグループ2をツリー2に指定できます。
The RBridge that is the highest-priority tree root can announce the multicast groups allowed on each tree for each Data Label with the Tree and Groups (TREE-GROUPs) APPsub-TLV. Multiple instances of this APPsub-TLV may be carried. The APPsub-TLV format is as follows:
最も優先度の高いツリールートであるRBridgeは、ツリーとグループ（TREE-GROUP）APPsub-TLVを使用して、各データラベルの各ツリーで許可されるマルチキャストグループをアナウンスできます。このAPPsub-TLVの複数のインスタンスを実行できます。 APPsub-TLV形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 15 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Sub-Sub-TLVs (variable)
+-+-+-+-+-+-+-+-+-+....
o Type: TRILL GENINFO APPsub-TLV type; set to 15 (TREE-GROUPs).
o タイプ：TRILL GENINFO APPsub-TLVタイプ。 15（TREE-GROUP）に設定します。
o Length: 2 + the length of the Group Sub-Sub TLVs that are included.
o 長さ：2 +含まれるグループサブサブTLVの長さ。
o Nickname: The nickname identifying the distribution tree by its root.
o ニックネーム：配布ツリーをルートで識別するニックネーム。
o Group Sub-Sub-TLVs: Zero or more of the TLV structures that are allowed as sub-TLVs of the Group Address (GADDR) TLV [RFC7176]. Each such TLV structure specifies a multicast group and either a VLAN or FGL. Although these TLV structures are considered sub-TLVs when they appear inside a GADDR TLV, they are technically sub-sub-TLVs when they appear inside a TREE-GROUPs APPsub-TLV that is in turn inside a TRILL GENINFO TLV [RFC7357].
o Group Sub-Sub-TLVs：グループアドレス（GADDR）TLV [RFC7176]のサブTLVとして許可される0個以上のTLV構造。このような各TLV構造は、マルチキャストグループとVLANまたはFGLのいずれかを指定します。これらのTLV構造は、GADDR TLV内に表示される場合はサブTLVと見なされますが、技術的には、TRILL GENINFO TLV [RFC7357]内にあるTREE-GROUP APPS-TLV内に表示される場合はサブサブTLVです。
The Tree and Groups Used (TREE-GROUPs-USE) APPsub-TLV has the same structure as the TREE-GROUPs APPsub-TLV specified in Section 3.2.5. The differences are that its APPsub-TLV type is set to 16 (TREE-GROUPs-USE) and the Tree Nickname and Group sub-sub-TLVs listed in this APPsub-TLV are those that the originating RBridge wants to use for multi-destination packets. This APPsub-TLV is used by an ingress RBridge to distribute the tree-group correspondence that it selects from the list announced by the highest-priority tree root.
使用されるツリーとグループ（TREE-GROUPs-USE）APPsub-TLVの構造は、セクション3.2.5で指定されたTREE-GROUPs APPsub-TLVと同じです。違いは、APPsub-TLVタイプが16（TREE-GROUPs-USE）に設定されており、このAPPsub-TLVにリストされているツリーニックネームとグループサブサブTLVが、元のRBridgeが複数の宛先に使用したいものであることです。パケット。このAPPsub-TLVは、最高の優先度のツリールートによって通知されたリストから選択するツリーグループ対応を配布するために、入力RBridgeによって使用されます。
The highest-priority tree root RBridge MUST include all the necessary tree-related sub-TLVs defined in [RFC7176] as usual in its E-L1FS FS-LSP and MAY include the TREE-VLANs APPsub-TLV and/or the TREE-FGLs APPsub-TLV in its E-L1FS FS-LSP [RFC7780]. In this way, it MAY indicate that each VLAN and/or FGL is only allowed on one or some other number of trees less than the number of trees being calculated in the campus in order to save table space in the fast-path forwarding hardware.
最高の優先度のツリールートRBridgeは、[RFC7176]で定義されている必要なすべてのツリー関連サブTLVを通常どおりE-L1FS FS-LSPに含めなければならず、TREE-VLAN APPSUB-TLVやTREE-FGLを含めることができます（MAY）。 E-L1FS FS-LSP [RFC7780]のAPPsub-TLV。このように、高速パス転送ハードウェアのテーブルスペースを節約するために、キャンパスで計算されているツリーの数より少ない1つまたは他のいくつかのツリーでのみ各VLANまたはFGL、あるいはその両方が許可されることを示す場合があります。
An ingress RBridge that understands the TREE-VLANs APPsub-TLV SHOULD select the tree-VLAN correspondences that it wishes to use and put them in TREE-VLAN-USE APPsub-TLVs. If there are multiple tree nicknames announced in a TREE-VLANs APPsub-TLV for VLAN x, the ingress RBridge chooses one of them if it supports this feature. For example, the ingress RBridge may choose the closest (minimum-cost) root among them. How to make such a choice is out of scope for this document. It may be desirable to have some fixed algorithm to make sure that all ingress RBridges choose the same tree for VLAN x in this case. Any single Data Label that the ingress RBridge is interested in should be related to only one tree ID in a TREE-VLAN-USE APPsub-TLV to minimize the multicast forwarding table size on other RBridges, but as long as the Data Label is related to less than all the trees being calculated, it will reduce the burden on the forwarding table size.
TREE-VLANs APPsub-TLVを理解する入力RBridgeは、使用したいツリーとVLANの対応を選択し、それらをTREE-VLAN-USE APPsub-TLVに配置する必要があります（SHOULD）。 VLAN xのTREE-VLANs APPsub-TLVでアナウンスされた複数のツリーニックネームがある場合、この機能をサポートしていれば、入力RBridgeがそのうちの1つを選択します。たとえば、イングレスRBridgeは、それらの中で最も近い（最小コスト）ルートを選択する場合があります。このような選択を行う方法は、このドキュメントの範囲外です。この場合、すべての入力RBridgeがVLAN xに対して同じツリーを選択するようにするには、いくつかの固定アルゴリズムを使用することが望ましい場合があります。入力RBridgeが対象とする単一のデータラベルは、TREE-VLAN-USE APPsub-TLV内の1つのツリーIDにのみ関連付けて、他のRBridgeのマルチキャスト転送テーブルのサイズを最小限に抑える必要がありますが、データラベルが計算されるすべてのツリーよりも少ないため、転送テーブルのサイズへの負担が軽減されます。
When an ingress RBridge encapsulates a multi-destination frame for Data Label x, it SHOULD use a tree nickname that it selected previously in a TREE-VLAN-USE or TREE-FGL-USE APPsub-TLV for Data Label x. However, that may not be possible because either (1) the RBridge may not have advertised such TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs, in which case it can use any tree that has been advertised as permitted for the Data Label by the highest-priority tree root RBridge, or (2) the tree or trees it advertised might be unavailable due to failures.
入力RBridgeがデータラベルxの複数の宛先フレームをカプセル化する場合、データラベルxのTREE-VLAN-USEまたはTREE-FGL-USE APPsub-TLVで以前に選択したツリーニックネームを使用する必要があります。ただし、（1）RBridgeがそのようなTREE-VLAN-USEまたはTREE-FGL-USE APPsub-TLVをアドバタイズしていない可能性があるため、これは不可能である可能性があります。その場合、許可されているようにアドバタイズされた任意のツリーを使用できます。最も優先度の高いツリールートRBridgeによるデータラベル、または（2）障害が原因でアドバタイズされた1つまたは複数のツリーが使用できない可能性があります。
If RBridge RBn does not perform pruning, it builds the multicast forwarding table as specified in [RFC6325].
RBridge RBnがプルーニングを実行しない場合、[RFC6325]で指定されているようにマルチキャスト転送テーブルを構築します。
If RBn prunes the distribution tree based on VLANs, RBn uses the information received in TREE-VLAN-USE APPsub-TLVs to mark the set of VLANs reachable downstream for each adjacency and for each related tree. If RBn prunes the distribution tree based on FGLs, RBn uses the information received in TRILL-FGL-USE APPsub-TLVs to mark the set of FGLs reachable downstream for each adjacency and for each related tree.
RBnがVLANに基づいて配布ツリーをプルーニングする場合、RBnはTREE-VLAN-USE APPsub-TLVで受信した情報を使用して、各隣接関係および各関連ツリーのダウンストリームに到達可能なVLANのセットをマークします。 RBnがFGLに基づいて配布ツリーをプルーニングする場合、RBnはTRILL-FGL-USE APPsub-TLVで受信した情報を使用して、各隣接関係および各関連ツリーのダウンストリームに到達可能なFGLのセットをマークします。
Logically, an ingress RBridge that does not support VLAN-based or FGL-based tree selection is equivalent to the one that supports it but uses it in such a way as to gain no advantage; for example, it announces the use of all trees for all VLANs and FGLs.
論理的には、VLANベースまたはFGLベースのツリー選択をサポートしない入力RBridgeは、それをサポートするものと同等ですが、利点がないように使用します。たとえば、すべてのVLANおよびFGLに対するすべてのツリーの使用を通知します。
This section discusses failure scenarios for a distribution tree root for the case where that tree root is not the highest-priority root and the case where it is the highest-priority root. This section also discusses some other transient error conditions.
このセクションでは、配布ツリールートの障害シナリオについて、そのツリールートが最優先ルートではない場合と、最優先ルートである場合について説明します。このセクションでは、その他の一時的なエラー条件についても説明します。
Failure of a tree root that is not the highest-priority tree root: It is the responsibility of the highest-priority tree root to inform other RBridges of any change in the allowed tree-VLAN correspondence. When the highest-priority tree root learns that the root of tree t has failed, it should reassign the VLANs allowed on tree t to other trees or to a tree replacing the failed one.
最優先のツリールートではないツリールートの障害：許可されたツリーとVLANの対応の変更を他のRBridgeに通知するのは、最高優先度のツリールートの責任です。最も優先順位の高いツリールートは、ツリーtのルートに障害が発生したことを学習すると、ツリーtで許可されているVLANを他のツリーまたは障害が発生したツリーを置き換えるツリーに再割り当てする必要があります。
Failure of the highest-priority tree root: It is suggested that the tree root of second-highest priority be pre-configured with the proper knowledge of the tree-VLAN correspondence allowed when the highest-priority tree root fails. The information announced by the RBridge that has the second-highest priority to be a tree root would be in the link state of all RBridges but would not take effect unless the RBridge noticed the failure of the highest-priority tree root. When the highest-priority tree root fails, the tree root that formerly had second-highest priority will become the highest-priority tree root of the campus. When an RBridge notices the failure of the original highest-priority tree root, it can immediately use the stored information announced by the tree root that originally had second-highest priority. It is suggested that the tree-VLAN correspondence information be pre-configured on the tree root of second-highest priority to be the same as that on the highest-priority tree root for the trees other than the highest-priority tree itself. This can minimize the change to multicast forwarding tables in the case of highest-priority tree root failure. For a large campus, it may make sense to pre-configure this information in a similar way on the third-priority, fourth-priority, or even lower-priority tree root RBridges.
最高優先度のツリールートの失敗：2番目に高い優先度のツリールートは、最高優先度のツリールートに障害が発生した場合に許可されるツリーとVLANの対応に関する適切な知識で事前構成することをお勧めします。ツリールートとして2番目に高い優先度を持つRBridgeによってアナウンスされる情報は、すべてのRBridgeのリンク状態になりますが、RBridgeが最も優先度の高いツリールートの障害に気づかない限り、有効になりません。最も優先順位の高いツリールートに障害が発生すると、以前に2番目に優先順位が高かったツリールートが、キャンパスの最も優先順位の高いツリールートになります。 RBridgeは、元の最高優先度のツリールートの障害に気づくと、元々2番目に高い優先度を持っていたツリールートによってアナウンスされた格納情報をすぐに使用できます。ツリーVLANの対応情報は、優先順位が2番目に高いツリールートで、優先順位が最も高いツリー以外のツリーの優先順位が最も高いツリールートと同じになるように事前に構成することをお勧めします。これにより、最優先のツリールート障害が発生した場合に、マルチキャスト転送テーブルへの変更を最小限に抑えることができます。大規模なキャンパスの場合、3番目の優先順位、4番目の優先順位、またはさらに低い優先順位のツリールートRBridgeで同様の方法でこの情報を事前構成することは意味があります。
In some transient conditions, or in the case of a misbehaving highest-priority tree root, an ingress RBridge may encounter the following scenarios:
一部の一時的な状態、または動作が最も優先度の高いツリールートの場合、入力RBridgeで次のシナリオが発生する可能性があります。
- No tree has been announced for which VLAN x frames are allowed.
- VLAN xフレームが許可されているツリーは発表されていません。
- An ingress RBridge is supposed to transmit VLAN x frames on tree t, but the root of tree t is no longer reachable.
- 入力RBridgeは、ツリーtでVLAN xフレームを送信することになっていますが、ツリーtのルートに到達できなくなりました。
For the second case, an ingress RBridge may choose another reachable tree root that allows VLAN x frames according to the highest-priority tree root announcement. If there is no such tree available, then it is the same as the first case above. The ingress RBridge should then be "downgraded" to a conventional RBridge with behavior as specified in [RFC6325]. A timer should be set to allow the temporary transient stage to complete before the change of the responsive tree or the downgrade takes effect. The value of the timer should be set to at least the LSP flooding time of the campus.
2番目のケースでは、入力RBridgeは、優先度の最も高いツリールートのアナウンスメントに従ってVLAN xフレームを許可する別の到達可能なツリールートを選択する場合があります。そのようなツリーがない場合、それは上記の最初のケースと同じです。入力RBridgeは、[RFC6325]で指定された動作を持つ従来のRBridgeに「ダウングレード」する必要があります。タイマーは、応答ツリーの変更またはダウングレードが有効になる前に一時的な一時的なステージが完了するように設定する必要があります。タイマーの値は、少なくともキャンパスのLSPフラッディング時間に設定する必要があります。
RBridges MUST include the TREE-USE-IDs and INT-VLAN sub-TLVs in their LSPs when required by [RFC6325] whether or not they support the new TREE-VLAN-USE or TREE-FGL-USE APPsub-TLVs specified by this document.
このドキュメントで指定されている新しいTREE-VLAN-USEまたはTREE-FGL-USE APPsub-TLVをサポートするかどうかに関係なく、RBridgeは[RFC6325]で必要な場合、LSPにTREE-USE-IDとINT-VLANサブTLVを含める必要があります。 。
RBridges that understand the new TREE-VLAN-USE APPsub-TLV sent from another RBridge RBn should use it to build the multicast forwarding table and ignore the TREE-USE-IDs and INT-VLAN sub-TLVs sent from the same RBridge. TREE-USE-IDs and INT-VLAN sub-TLVs are still useful for some purposes other than building the multicast forwarding table (e.g., building an RPF table, spanning tree root notification). If the RBridge does not receive TREE-VLAN-USE APPsub-TLVs from RBn, it uses the conventional way described in [RFC6325] to build the multicast forwarding table.
別のRBridge RBnから送信された新しいTREE-VLAN-USE APPsub-TLVを理解するRBridgeは、それを使用してマルチキャスト転送テーブルを構築し、同じRBridgeから送信されたTREE-USE-IDとINT-VLANサブTLVを無視する必要があります。 TREE-USE-IDとINT-VLANサブTLVは、マルチキャスト転送テーブルの構築（RPFテーブルの構築、スパニングツリールート通知など）以外の目的にも役立ちます。 RBridgeがRBnからTREE-VLAN-USE APPsub-TLVを受信しない場合、[RFC6325]で説明されている従来の方法を使用してマルチキャスト転送テーブルを構築します。
For example, there are two distribution trees, tree 1 and tree 2, in the campus. RB1 and RB2 are RBridges that use the new APPsub-TLVs described in this document. RB3 is an old RBridge that is compatible with [RFC6325]. Assume that RB2 is interested in VLANs 10 and 11 and RB3 is interested in VLANs 100 and 101. Hence, RB1 receives ((tree 1, VLAN 10), (tree 2, VLAN 11)) as a TREE-VLAN-USE APPsub-TLV and (tree 1, tree 2) as a TREE-USE-IDs sub-TLV from RB2 on port x. Also, RB1 receives (tree 1) as a TREE-USE-IDs sub-TLV and no TREE-VLAN-USE APPsub-TLV from RB3 on port y. RB2 and RB3 announce their interested VLANs in an INT-VLAN sub-TLV as usual. RB1 will then build the entry of (tree 1, VLAN 10, port x) and (tree 2, VLAN 11, port x) based on RB2's LSP and the mechanism specified in this document. RB1 also builds entries of (tree 1, VLAN 100, port y), (tree 1, VLAN 101, port y), (tree 2, VLAN 100, port y), and (tree 2, VLAN 101, port y) based on RB3's LSP in the conventional way.
たとえば、キャンパスには2つの配布ツリー、ツリー1とツリー2があります。 RB1およびRB2は、このドキュメントで説明されている新しいAPPsub-TLVを使用するRBridgeです。 RB3は、[RFC6325]と互換性のある古いRBridgeです。 RB2はVLAN 10と11に関心があり、RB3はVLAN 100と101に関心があると仮定します。したがって、RB1は（（ツリー1、VLAN 10）、（ツリー2、VLAN 11））をTREE-VLAN-USE APPサブポートxのRB2からのTLVおよび（ツリー1、ツリー2）TREE-USE-IDsサブTLVとして。また、RB1は（ツリー1）をTREE-USE-IDsサブTLVとして受信し、ポートyのRB3からTREE-VLAN-USE APPsub-TLVを受信しません。 RB2とRB3は、通常どおり、関心のあるVLANをINT-VLANサブTLVでアナウンスします。次に、RB1は、RB2のLSPおよびこのドキュメントで指定されているメカニズムに基づいて、（ツリー1、VLAN 10、ポートx）および（ツリー2、VLAN 11、ポートx）のエントリを構築します。 RB1は、（ツリー1、VLAN 100、ポートy）、（ツリー1、VLAN 101、ポートy）、（ツリー2、VLAN 100、ポートy）、および（ツリー2、VLAN 101、ポートy）ベースのエントリも構築します従来の方法でRB3のLSPに。
The multicast forwarding table on RB1 with a merged entry would be like the following:
マージされたエントリを持つRB1のマルチキャスト転送テーブルは、次のようになります。
+--------------+-----+---------+
|tree nickname |VLAN |port list|
+--------------+-----+---------+
| tree 1 | 10 | x |
+--------------+-----+---------+
| tree 1 | 100 | y |
+--------------+-----+---------+
| tree 1 | 101 | y |
+--------------+-----+---------+
| tree 2 | 11 | x |
+--------------+-----+---------+
| tree 2 | 100 | y |
+--------------+-----+---------+
| tree 2 | 101 | y |
+--------------+-----+---------+
As expected, that table is not as small as the one where every RBridge supports the new TREE-VLAN-USE APPsub-TLVs. In a hybrid campus, the worst case would be where the number of entries is equal to the number of entries required by the current practice that does not support VLAN-based tree selection. Such an extreme case happens when the set of interested VLANs from the new RBridges is a subset of the set of interested VLANs from the old RBridges.
予想通り、そのテーブルは、すべてのRBridgeが新しいTREE-VLAN-USE APPsub-TLVをサポートするテーブルほど小さくはありません。ハイブリッドキャンパスでの最悪のケースは、エントリ数が、VLANベースのツリー選択をサポートしていない現在のプラクティスで必要なエントリ数と等しい場合です。このような極端なケースは、新しいRBridgeからの関係するVLANのセットが、古いRBridgeからの関係するVLANのセットのサブセットである場合に発生します。
Tree selection based on the Data Label and multicast group is compatible with the current practice. Its effectiveness increases with more RBridges supporting this feature in the TRILL campus.
データラベルとマルチキャストグループに基づくツリーの選択は、現在の方法と互換性があります。 TRILLキャンパスでこの機能をサポートするRBridgeが増えると、その効果は高まります。
This document does not change the general RBridge security considerations of the TRILL base protocol. The APPsub-TLVs specified can be secured using the IS-IS authentication feature [RFC5310]. See Section 6 of [RFC6325] for general TRILL security considerations.
このドキュメントは、TRILLベースプロトコルの一般的なRBridgeセキュリティの考慮事項を変更しません。指定されたAPPsub-TLVは、IS-IS認証機能[RFC5310]を使用して保護できます。 TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]のセクション6をご覧ください。
IANA has assigned six new TRILL APPsub-TLV types from the range less than 255, as specified in Section 3, and updated the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry on <http://www.iana.org/assignments/trill-parameters/>, as shown below.
IANAは、セクション3で指定されているように、255未満の範囲から6つの新しいTRILL APPsub-TLVタイプを割り当て、<http：// wwwの「IS-IS TLV 251 Application Identifier 1でのTRILL APPsub-TLVタイプ」レジストリを更新しました以下に示すように、.iana.org / assignments / trill-parameters />。
Type Name of APPsub-TLV Reference
---- ----------------------- -------------------------
11 Tree and VLANs Section 3.2.1 of RFC 7968
12 Tree and VLANs Used Section 3.2.2 of RFC 7968
13 Tree and FGLs Section 3.2.3 of RFC 7968
14 Tree and FGLs Used Section 3.2.4 of RFC 7968
15 Tree and Groups Section 3.2.5 of RFC 7968
16 Tree and Groups Used Section 3.2.6 of RFC 7968
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[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>。
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<http://www.rfc-editor.org/info/rfc7357>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[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>。
Acknowledgments
謝辞
The authors wish to thank David M. Bond, Liangliang Ma, Naveen Nimmu, Radia Perlman, Rakesh Kumar, Robert Sparks, Daniele Ceccarelli, and Sunny Rajagopalan for their valuable comments and contributions.
著者は、David M. Bond、Liangliang Ma、Naveen Nimmu、Radia Perlman、Rakesh Kumar、Robert Sparks、Daniele Ceccarelli、Sunny Rajagopalanの貴重なコメントと貢献に感謝します。
Authors' Addresses
著者のアドレス
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56624629
Email: liyizhou@huawei.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニューNaN京210012中国
Phone: +86-25-56623144 Email: haoweiguo@huawei.com Hao Chen Huawei Technologies 101 Software Avenue Nanjing 210012 China
Ｐほね： ＋８６ー２５ー５６６２３１４４ えまいｌ： はおうぇいぐお＠ふあうぇい。こｍ はお ちぇん ふあうぇい てｃｈのぉぎえｓ １０１ そｆとぁれ あゔぇぬえ なんじんｇ ２１００１２ ちな
Email: philips.chenhao@huawei.com
Somnath Chatterjee Cisco Systems SEZ Unit, Cessna Business Park Outer Ring Road Bangalore 560087 India
Somnath Chatterjee Cisco Systems SEZ Unit、Cessna Business Park Outer Ring Road Bangalore India
Email: somnath.chatterjee01@gmail.com