[要約] RFC 8243は、TRILL（Transparent Interconnection of Lots of Links）の多レベル透過的相互接続の代替手法に関する要約です。このRFCの目的は、TRILLのアーキテクチャにおける複数のレベルの透過的な相互接続の代替手法を提案することです。
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8243 EMC
Category: Informational D. Eastlake 3rd
ISSN: 2070-1721 M. Zhang
Huawei
A. Ghanwani
Dell
H. Zhai
JIT
September 2017
Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL)
多数のリンクのマルチレベルの透過的相互接続（TRILL）の代替
Abstract
概要
Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?
TRILLはマルチレベルのユニキャストルーティングをサポートするIS-ISに基づいていますが、TRILLを複数のレベルに拡張するには、IS-ISの既存の機能では対応できない課題があります。 1つの問題は、複数の宛先のパケット配信ツリーの処理にあります。その他の問題は、TRILLスイッチのニックネームにあります。このようなニックネームは、マルチレベルのTRILLネットワークにどのように割り当てられますか？ニックネームは、マルチレベルのTRILLネットワーク全体で一意である必要がありますか？または、各マルチレベル領域内で一意にすることはできますか？
This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases.
この情報ドキュメントでは、下位互換性、単純性、スケーラビリティなど、いくつかの要素に基づいて代替案を列挙し、検討しています。それはいくつかのケースで推奨を行います。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 https://www.rfc-editor.org/info/rfc8243.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8243で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. The Motivation for Multilevel ..............................4
1.2. Improvements Due to Multilevel .............................5
1.2.1. The Routing Computation Load ........................5
1.2.2. LSDB Volatility Creating Too Much Control Traffic ...5
1.2.3. LSDB Volatility Causing Too Much Time Unconverged ...6
1.2.4. The Size of the LSDB ................................6
1.2.5. Nickname Limit ......................................6
1.2.6. Multi-Destination Traffic ...........................7
1.3. Unique and Aggregated Nicknames ............................7
1.4. More on Areas ..............................................8
1.5. Terminology and Abbreviations ..............................9
2. Multilevel TRILL Issues ........................................10
2.1. Non-Zero Area Addresses ...................................11
2.2. Aggregated versus Unique Nicknames ........................12
2.2.1. More Details on Unique Nicknames ...................12
2.2.2. More Details on Aggregated Nicknames ...............13
2.3. Building Multi-Area Trees .................................18
2.4. The RPF Check for Trees ...................................18
2.5. Area Nickname Acquisition .................................19
2.6. Link State Representation of Areas ........................19
3. Area Partition .................................................20
4. Multi-Destination Scope ........................................21
4.1. Unicast to Multi-Destination Conversions ..................21
4.1.1. New Tree Encoding ..................................22
4.2. Selective Broadcast Domain Reduction ......................22
5. Coexistence with Old TRILL Switches ............................23
6. Multi-Access Links with End Stations ...........................24
7. Summary ........................................................25
8. Security Considerations ........................................26
9. IANA Considerations ............................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................27
Acknowledgements ..................................................28
Authors' Addresses ................................................29
The IETF Transparent Interconnection of Lot of Links (TRILL) protocol [RFC6325] [RFC7177] [RFC7780] provides optimal pairwise data routing without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic in networks with arbitrary topology and link technology, including multi-access links. TRILL accomplishes this by using Intermediate System to Intermediate System [IS-IS] [RFC7176]) link state routing in conjunction with a header that includes a hop count. The design supports Data Labels (VLANs and Fine-Grained Labels (FGLs) [RFC7172]) and optimization of the distribution of multi-destination data based on Data Label and multicast group. Devices that implement TRILL are called TRILL Switches or RBridges.
IETFの多くのリンクの透過的相互接続（TRILL）プロトコル[RFC6325] [RFC7177] [RFC7780]は、構成なしの最適なペアワイズデータルーティング、一時的なループの期間中も安全な転送、およびネットワーク内のユニキャストとマルチキャストの両方のトラフィックのマルチパスのサポートを提供しますマルチアクセスリンクを含む、任意のトポロジとリンクテクノロジーを使用します。 TRILLは、中間システムから中間システム[IS-IS] [RFC7176]）リンクステートルーティングを、ホップカウントを含むヘッダーと組み合わせて使用することにより、これを実現します。この設計は、データラベル（VLANおよび細粒度ラベル（FGL）[RFC7172]）と、データラベルおよびマルチキャストグループに基づく複数宛先データの分散の最適化をサポートしています。 TRILLを実装するデバイスは、TRILLスイッチまたはRBridgeと呼ばれます。
Familiarity with [IS-IS], [RFC6325], and [RFC7780] is assumed in this document.
このドキュメントでは、[IS-IS]、[RFC6325]、および[RFC7780]に精通していることを前提としています。
The primary motivation for multilevel TRILL is to improve scalability. The following issues might limit the scalability of a TRILL-based network:
マルチレベルTRILLの主な動機は、スケーラビリティを改善することです。以下の問題は、TRILLベースのネットワークのスケーラビリティを制限する可能性があります。
1. The routing computation load
1. ルーティング計算の負荷
2. The volatility of the link state database (LSDB) creating too much control traffic
2. リンク状態データベース（LSDB）の変動性により、制御トラフィックが多すぎる
3. The volatility of the LSDB causing the TRILL network to be in an unconverged state too much of the time
3. LSDBのボラティリティによりTRILLネットワークが収束しない状態になりすぎる
4. The size of the LSDB
4. LSDBのサイズ
5. The limit of the number of TRILL switches, due to the 16-bit nickname space (for further information on why this might be a problem, see Section 1.2.5)
5. 16ビットのニックネームスペースによるTRILLスイッチの数の制限（これが問題になる理由の詳細については、セクション1.2.5を参照してください）
6. The traffic due to upper-layer protocols use of broadcast and multicast
6. ブロードキャストとマルチキャストの上位層プロトコル使用によるトラフィック
7. The size of the end-node learning table (the table that remembers (egress TRILL switch, label / Media Access Control (MAC)) pairs)
7. エンドノード学習テーブルのサイズ（記憶するテーブル（出力TRILLスイッチ、ラベル/メディアアクセスコントロール（MAC））のペア）
As discussed below, extending TRILL IS-IS to be multilevel (hierarchical) can help with all of these issues except issue 7.
以下で説明するように、TRILL IS-ISをマルチレベル（階層）に拡張すると、問題7以外のすべての問題を解決できます。
IS-IS was designed to be multilevel [IS-IS]. A network can be partitioned into "areas". Routing within an area is known as "Level 1 routing". Routing between areas is known as "Level 2 routing". The Level 2 IS-IS network consists of Level 2 routers and links between the Level 2 routers. Level 2 routers may participate in one or more Level 1 areas, in addition to their role as Level 2 routers.
IS-ISはマルチレベル[IS-IS]として設計されました。ネットワークは「エリア」に分割できます。エリア内のルーティングは「レベル1ルーティング」と呼ばれます。エリア間のルーティングは「レベル2ルーティング」として知られています。レベル2 IS-ISネットワークは、レベル2ルーターとレベル2ルーター間のリンクで構成されます。レベル2ルーターは、レベル2ルーターとしての役割に加えて、1つ以上のレベル1エリアに参加できます。
Each area is connected to Level 2 through one or more "border routers", which participate both as a router inside the area, and as a router inside the Level 2 area. Care must be taken that it is clear, when transitioning multi-destination packets between a Level 2 and a Level 1 area in either direction, that exactly one border TRILL switch will transition a particular data packet between the levels; otherwise, duplication or loss of traffic can occur.
各エリアは、エリア内のルーターとして、およびレベル2エリア内のルーターとして参加する1つ以上の「境界ルーター」を介してレベル2に接続されます。レベル2とレベル1のエリア間で複数の宛先のパケットをいずれかの方向に移行する場合、1つの境界TRILLスイッチが特定のデータパケットをレベル間で移行することは明らかです。そうしないと、トラフィックの重複または損失が発生する可能性があります。
Partitioning the network into areas directly solves the first four scalability issues listed above, as described in Sections 1.2.1 through 1.2.4. Multilevel also contributes to solving issues 5 and 6, as discussed in Sections 1.2.5 and 1.2.6, respectively.
セクション1.2.1〜1.2.4で説明されているように、ネットワークをエリアに分割すると、上記の最初の4つのスケーラビリティの問題が直接解決されます。マルチレベルは、それぞれセクション1.2.5および1.2.6で説明するように、問題5および6の解決にも貢献します。
In the subsections below, N indicates the number of TRILL switches in a TRILL campus. For simplicity, it is assumed that each TRILL switch has k links to other TRILL switches. An "optimized" multilevel campus is assumed to have Level 1 areas containing sqrt(N) switches.
以下のサブセクションでは、NはTRILLキャンパス内のTRILLスイッチの数を示します。簡単にするために、各TRILLスイッチには他のTRILLスイッチへのk個のリンクがあると想定されています。 「最適化された」マルチレベルキャンパスには、sqrt（N）スイッチを含むレベル1エリアがあると想定されます。
The Dijkstra algorithm uses computational effort on the order of the number of links in a network (N*k) times the log of the number of nodes to calculate least cost routes at a router (Section 12.3.3 of [InterCon]). Thus, in a single-level TRILL campus, it is on the order of N*k*log(N). In an optimized multilevel campus, it is on the order of sqrt(N)*k*log(N). So, for example, assuming N is 3,000, the level of computational effort would be reduced by about a factor of 50.
ダイクストラアルゴリズムは、ネットワーク内のリンク数（N * k）にノード数のログを掛けた数の計算量を使用して、ルーターで最小コストのルートを計算します（[InterCon]のセクション12.3.3）。したがって、単一レベルのTRILLキャンパスでは、N * k * log（N）のオーダーになります。最適化されたマルチレベルキャンパスでは、sqrt（N）* k * log（N）のオーダーです。したがって、たとえば、Nを3,000とすると、計算量は約50分の1になります。
The rate of LSDB changes is assumed to be approximately proportional to the number of routers and links in the TRILL campus or N*(1+k) for a single-level campus. With an optimized multilevel campus, each area would have about sqrt(N) routers and proportionately fewer links reducing the rate of LSDB changes by about a factor of sqrt(N).
LSDBの変更率は、TRILLキャンパス内のルーターとリンクの数、または単一レベルのキャンパスのN *（1 + k）にほぼ比例すると想定されています。最適化されたマルチレベルキャンパスでは、各エリアに約sqrt（N）のルーターがあり、それに比例してリンクの数が少ないため、LSDBの変化率が約sqrt（N）の係数で減少します。
With the simplifying assumption that routing converges after each topology change before the next such change, the fraction of time that routing is unconverged is proportional to the product of the rate of change occurrence and the convergence time. The rate of topology changes per some arbitrary unit of time will be roughly proportional to the number of router and links (Section 1.2.2). The convergence time is approximately proportional to the computation involved at each router (Section 1.2.1). Thus, based on these simplifying assumptions, the time spent unconverged in a single-level network is proportional to (N*(1+k))*(N*k*log(N)) while that time for an optimized multilevel network would be proportional to (sqrt(N)*(1+k))*(sqrt(N)*k*log(N)). Thus, in changing to multilevel, the time spent unconverged, using these simplifying assumptions, is improved by about a factor of N.
ルーティングが各トポロジの変更後に次の変更の前に収束するという単純化した仮定により、ルーティングが収束しない時間の割合は、変化の発生率と収束時間の積に比例します。任意の時間単位ごとのトポロジ変更の割合は、ルーターとリンクの数にほぼ比例します（セクション1.2.2）。コンバージェンス時間は、各ルーターでの計算にほぼ比例します（セクション1.2.1）。したがって、これらの単純化の仮定に基づいて、単一レベルのネットワークで収束しない時間は（N *（1 + k））*（N * k * log（N））に比例しますが、最適化されたマルチレベルネットワークの時間は（sqrt（N）*（1 + k））*（sqrt（N）* k * log（N））に比例します。したがって、マルチレベルへの変更では、これらの単純化の仮定を使用して、収束しないままに費やされた時間は、約N倍改善されます。
The size of the LSDB, which consists primarily of information about routers (TRILL switches) and links, is also approximately proportional to the number of routers and links. So, as with item 2 in Section 1.2.2, it should improve by about a factor of sqrt(N) in going from single level to multilevel.
LSDBのサイズは、主にルーター（TRILLスイッチ）とリンクに関する情報で構成され、ルーターとリンクの数にほぼ比例します。したがって、セクション1.2.2の項目2と同様に、シングルレベルからマルチレベルに移行する際に、sqrt（N）の係数で改善されるはずです。
For many TRILL protocol purposes, RBridges are designated by 16-bit nicknames. While some values are reserved, this appears to provide enough nicknames to designated over 65,000 RBridges. However, this number is effectively reduced by the following two factors:
多くのTRILLプロトコルの目的で、RBridgeは16ビットのニックネームで指定されます。一部の値は予約されていますが、これは65,000を超えるRBridgeを指定するのに十分なニックネームを提供するようです。ただし、この数は次の2つの要因によって効果的に削減されます。
- Nicknames are consumed when pseudo-nicknames are used for the active-active connection of end stations. Using the techniques in [RFC7781], for example, could double the nickname consumption if there are extensive active-active edge groups connected to different sets of edge TRILL switch ports.
- ニックネームは、エンドステーションのアクティブ/アクティブ接続に疑似ニックネームが使用されるときに使用されます。たとえば、[RFC7781]の手法を使用すると、エッジTRILLスイッチポートの異なるセットに接続された大規模なアクティブ/アクティブエッジグループがある場合、ニックネームの消費が2倍になる可能性があります。
- There might be problems in multilevel campus-wide contention for single-nickname allocation of nicknames were allocated individually from a single pool for the entire campus. Thus, it seems likely that a hierarchical method would be chosen where blocks of nicknames are allocated at Level 2 to Level 1 areas and contention for a nickname by an RBridge in such a Level 1 area would be only within that area. Such hierarchical allocation leads to further effective loss of nicknames similar to the situation with IP addresses discussed in [RFC3194].
- キャンパス全体の単一のプールから個別に割り当てられたニックネームの単一ニックネームの割り当てについて、キャンパス全体のマルチレベルの競合に問題がある可能性があります。したがって、ニックネームのブロックがレベル2からレベル1のエリアに割り当てられ、そのようなレベル1のエリア内のRBridgeによるニックネームの競合がそのエリア内にのみ存在する階層的な方法が選択されるようです。このような階層的な割り当ては、[RFC3194]で説明されているIPアドレスの状況と同様に、ニックネームをさらに効果的に失うことになります。
Even without the above effective reductions in nickname space, a very large multilevel TRILL campus, say one with 200 areas each containing 500 TRILL switches, could require 100,000 or more nicknames if all nicknames in the campus must be unique, which is clearly impossible with 16-bit nicknames.
ニックネームスペースの上記の効果的な削減がなくても、非常に大きなマルチレベルTRILLキャンパス、たとえば200のエリアに500のTRILLスイッチが含まれているキャンパスでは、キャンパス内のすべてのニックネームが一意でなければならない場合、100,000以上のニックネームが必要になる可能性があります。ビットのニックネーム。
This scaling limit, namely, the 16-bit nickname space, will only be addressed with the aggregated-nickname approach. Since the aggregated-nickname approach requires some complexity in the border TRILL switches (for rewriting the nicknames in the TRILL header), the suggested design in this document allows a campus with a mixture of unique-nickname areas, and aggregated-nickname areas. Thus, a TRILL network could start using multilevel with the simpler unique nickname method and later add aggregated-nickname areas as a later stage of network growth.
このスケーリング制限、つまり、16ビットのニックネーム空間は、集約されたニックネームのアプローチでのみ対処されます。集約ニックネームアプローチでは、境界TRILLスイッチ（TRILLヘッダーのニックネームを書き換えるため）にいくらか複雑さが必要であるため、このドキュメントで提案されている設計では、一意のニックネーム領域と集約されたニックネーム領域が混在するキャンパスを許可しています。したがって、TRILLネットワークは、より単純な一意のニックネーム方式でマルチレベルの使用を開始し、ネットワークの成長の後の段階として集約ニックネーム領域を後で追加できます。
With this design, nicknames must be unique across all Level 2 and unique-nickname area TRILL switches taken together; whereas nicknames inside an aggregated-nickname area are visible only inside that area. Nicknames inside an aggregated-nickname area must still not conflict with nicknames visible in Level 2 (which includes all nicknames inside unique nickname areas), but the nicknames inside an aggregated-nickname area may be the same as nicknames used within one or more other aggregated-nickname areas.
この設計では、ニックネームはすべてのレベル2および一意のニックネーム領域のTRILLスイッチ全体で一意でなければなりません。一方、集約されたニックネーム領域内のニックネームは、その領域内でのみ表示されます。集約されたニックネーム領域内のニックネームは、レベル2に表示されるニックネーム（一意のニックネーム領域内のすべてのニックネームを含む）と競合してはなりませんが、集約されたニックネーム領域内のニックネームは、1つ以上の他の集約されたニックネーム内で使用されるニックネームと同じになる場合があります-ニックネームエリア。
With the design suggested in this document, TRILL switches within an area need not be aware of whether they are in an aggregated-nickname area or a unique nickname area. The border TRILL switches in area A1 will indicate, in their LSP inside area A1, which nicknames (or nickname ranges) are or are not available to be chosen as nicknames by area A1 TRILL switches.
このドキュメントで提案されている設計では、エリア内のTRILLスイッチは、それらが集約されたニックネームエリアにあるのか、一意のニックネームエリアにあるのかを認識する必要はありません。エリアA1の境界TRILLスイッチは、エリアA1内のLSPで、エリアA1 TRILLスイッチでニックネームとして選択できるニックネーム（またはニックネームの範囲）を選択できるかどうかを示します。
In many cases, scaling limits due to protocol use of broadcast and multicast can be addressed in a multilevel campus by introducing locally scoped multi-destination delivery, limited to an area or a single link. See further discussion of this issue in Section 4.2.
多くの場合、ブロードキャストとマルチキャストのプロトコル使用によるスケーリング制限は、エリアまたは単一リンクに制限されたローカルスコープの複数宛先配信を導入することにより、マルチレベルキャンパスで対処できます。この問題の詳細については、セクション4.2を参照してください。
We describe two alternatives for hierarchical or multilevel TRILL. One we call the "unique-nickname" alternative. The other we call the "aggregated-nickname" alternative. In the aggregated-nickname alternative, border TRILL switches replace either the ingress or egress nickname field in the TRILL header of unicast packets with an aggregated nickname representing an entire area.
階層またはマルチレベルTRILLの2つの代替方法について説明します。 「ユニークなニックネーム」の代替と呼ばれるもの。もう1つは「集約されたニックネーム」の代替と呼ばれます。集約されたニックネームの代替では、境界TRILLスイッチは、ユニキャストパケットのTRILLヘッダーの入力または出力のニックネームフィールドを、エリア全体を表す集約されたニックネームに置き換えます。
The unique-nickname alternative has the advantage that border TRILL switches are simpler and do not need to do TRILL Header nickname modification. It also simplifies testing and maintenance operations that originate in one area and terminate in a different area.
ユニークなニックネームの代替には、ボーダーのTRILLスイッチがよりシンプルで、TRILLヘッダーのニックネームの変更を行う必要がないという利点があります。また、ある領域で発生し、別の領域で終了するテストおよび保守操作を簡素化します。
The aggregated-nickname alternative has the following advantages:
集約されたニックネームの代替には、次の利点があります。
- it solves scaling issue 5 above, the 16-bit nickname limit, in a simple way,
- 上記のスケーリング問題5、つまり16ビットのニックネームの制限を簡単な方法で解決します。
- it lessens the amount of inter-area routing information that must be passed in IS-IS, and
- IS-ISで渡す必要があるエリア間ルーティング情報の量を減らします。
- it logically reduces the RPF (Reverse Path Forwarding) Check information (since only the area nickname needs to appear, rather than all the ingress TRILL switches in that area).
- RPF（Reverse Path Forwarding）チェック情報を論理的に削減します（その領域のすべての入力TRILLスイッチではなく、領域のニックネームのみを表示する必要があるため）。
In both cases, it is possible and advantageous to compute multi-destination data packet distribution trees such that the portion computed within a given area is rooted within that area.
どちらの場合も、特定のエリア内で計算された部分がそのエリア内に根付くように、マルチ宛先データパケット分散ツリーを計算することが可能であり、有利です。
For further discussion of the unique and aggregated-nickname alternatives, see Section 2.2.
一意で集約されたニックネームの代替の詳細については、セクション2.2を参照してください。
Each area is configured with an "area address", which is advertised in IS-IS messages, so as to avoid accidentally interconnecting areas. For TRILL, the only purpose of the area address would be to avoid accidentally interconnecting areas although the area address had other purposes in CLNP (ConnectionLess Network Protocol), IS-IS was originally designed for CLNP/DECnet.
各エリアは、誤ってエリアを相互接続しないように、IS-ISメッセージでアドバタイズされる「エリアアドレス」で構成されます。 TRILLの場合、エリアアドレスの唯一の目的は、エリアを誤って相互接続しないようにすることですが、エリアアドレスにはCLNP（ConnectionLess Network Protocol）で他の目的がありましたが、IS-ISはもともとCLNP / DECnet用に設計されました。
Currently, the TRILL specification says that the area address must be zero. If we change the specification so that the area address value of zero is just a default, then most IS-IS multilevel machinery works as originally designed. However, there are TRILL-specific issues, which we address in Section 2.1.
現在、TRILL仕様では、エリアアドレスはゼロでなければならないことが規定されています。エリアアドレスの値がゼロになるように仕様を変更すると、ほとんどのIS-ISマルチレベル機械は当初の設計どおりに機能します。ただし、セクション2.1で対処するTRILL固有の問題があります。
This document generally uses the abbreviations defined in [RFC6325] plus the additional abbreviation DBRB. However, for ease of reference, most abbreviations used are listed here:
このドキュメントでは通常、[RFC6325]で定義されている略語と追加の略語DBRBを使用しています。ただし、参照しやすいように、使用されているほとんどの略語を以下に示します。
CLNP: ConnectionLess Network Protocol
CLNP：ConnectionLessネットワークプロトコル
DECnet: a proprietary routing protocol that was used by Digital Equipment Corporation. "DECnet Phase 5" was the origin of IS-IS.
DECnet：Digital Equipment Corporationが使用した独自のルーティングプロトコル。 「DECnetフェーズ5」はIS-ISの起源です。
Data Label: VLAN or Fine-Grained Label [RFC7172]
データラベル：VLANまたは細粒度ラベル[RFC7172]
DBRB: Designated Border RBridge
DBRB：指定ボーダーRBridge
ESADI: End-Station Address Distribution Information
ESADI：端末のアドレス配布情報
IS-IS: Intermediate System to Intermediate System [IS-IS]
IS-IS：中間システムから中間システム[IS-IS]
LSDB: Link State DataBase
LSDB：リンク状態データベース
LSP: Link State PDU
LSP：リンク状態PDU
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
RBridge: Routing Bridge, an alternative name for a TRILL switch
RBridge：ルーティングブリッジ、TRILLスイッチの別名
RPF: Reverse Path Forwarding
RPF：リバースパス転送
TLV: Type-Length-Value
TLV：Type-Length-Value
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325] [RFC7780]
TRILL：リンク層での多数のリンクまたはトンネルルーティングの透過的な相互接続[RFC6325] [RFC7780]
TRILL switch: a device that implements the TRILL protocol [RFC6325] [RFC7780], sometimes called an RBridge
TRILLスイッチ：TRILLプロトコルを実装するデバイス[RFC6325] [RFC7780]、RBridgeとも呼ばれる
VLAN: Virtual Local Area Network
VLAN：仮想ローカルエリアネットワーク
The TRILL-specific issues introduced by multilevel include the following:
マルチレベルによって導入されるTRILL固有の問題には、次のものがあります。
a. Configuration of non-zero area addresses, encoding them in IS-IS PDUs, and possibly interworking with old TRILL switches that do not understand non-zero area addresses.
a. 非ゼロエリアアドレスの設定、IS-IS PDUでのエンコード、および非ゼロエリアアドレスを認識しない古いTRILLスイッチとのインターワーキング。
See Section 2.1.
セクション2.1を参照してください。
b. Nickname management.
b. ニックネーム管理。
See Sections 2.5 and 2.2.
セクション2.5および2.2を参照してください。
c. Advertisement of pruning information (Data Label reachability, IP multicast addresses) across areas.
c. エリア全体のプルーニング情報（データラベルの到達可能性、IPマルチキャストアドレス）のアドバタイズメント。
Distribution tree pruning information is only an optimization, as long as multi-destination packets are not prematurely pruned. For instance, border TRILL switches could advertise they can reach all possible Data Labels, and have an IP multicast router attached. This would cause all multi-destination traffic to be transmitted to border TRILL switches, and possibly pruned there, when the traffic could have been pruned earlier based on Data Label or multicast group if border TRILL switches advertised more detailed Data Label and/or multicast listener and multicast router attachment information.
配信先ツリーのプルーニング情報は、マルチ宛先パケットが時期尚早にプルーニングされない限り、最適化にすぎません。たとえば、境界TRILLスイッチは、可能なすべてのデータラベルに到達できることをアドバタイズし、IPマルチキャストルーターを接続させることができます。これにより、ボーダーTRILLスイッチがより詳細なデータラベルやマルチキャストリスナーをアドバタイズした場合、トラフィックがデータラベルまたはマルチキャストグループに基づいて以前にプルーニングされた可能性がある場合、すべてのマルチ宛先トラフィックがボーダーTRILLスイッチに送信され、そこでプルーニングされる可能性があります。マルチキャストルーター接続情報。
d. Computation of distribution trees across areas for multi-destination data.
d. 複数の宛先データのエリア全体の分布ツリーの計算。
See Section 2.3.
セクション2.3を参照してください。
e. Computation of RPF information for those distribution trees.
e. それらの配布ツリーのRPF情報の計算。
See Section 2.4.
セクション2.4を参照してください。
f. Computation of pruning information across areas.
f. エリア全体の剪定情報の計算。
See Sections 2.3 and 2.6.
セクション2.3および2.6を参照してください。
g. Compatibility, as much as practical, with existing, unmodified TRILL switches.
g. 既存の変更されていないTRILLスイッチとの互換性。
The most important form of compatibility is with existing TRILL fast-path hardware. Changes that require upgrade to the slow-path firmware/software are more tolerable. Compatibility for the relatively small number of border TRILL switches is less important than compatibility for non-border TRILL switches.
互換性の最も重要な形式は、既存のTRILL高速パスハードウェアとの互換性です。スローパスファームウェア/ソフトウェアへのアップグレードを必要とする変更は、より許容性があります。比較的少数の境界TRILLスイッチの互換性は、非境界TRILLスイッチの互換性ほど重要ではありません。
See Section 5.
セクション5を参照してください。
The current TRILL base protocol specification [RFC6325] [RFC7177] [RFC7780] says that the area address in IS-IS must be zero. The purpose of the area address is to ensure that different areas are not accidentally merged. Furthermore, zero is an invalid area address for Layer 3 IS-IS, so it was chosen as an additional safety mechanism to ensure that Layer 3 IS-IS packets would not be confused with TRILL IS-IS packets. However, TRILL uses other techniques to avoid confusion on a link, such as different multicast addresses and Ethertypes on Ethernet [RFC6325], different PPP (Point-to-Point Protocol) code points on PPP [RFC6361], and the like. Thus, using an area address in TRILL that might be used in Layer 3 IS-IS is not a problem.
現在のTRILLベースプロトコル仕様[RFC6325] [RFC7177] [RFC7780]では、IS-ISのエリアアドレスはゼロである必要があると述べています。エリアアドレスの目的は、異なるエリアが誤ってマージされないようにすることです。さらに、ゼロはレイヤー3 IS-ISの無効なエリアアドレスであるため、レイヤー3 IS-ISパケットがTRILL IS-ISパケットと混同されないようにするための追加の安全メカニズムとして選択されました。ただし、TRILLは他の手法を使用して、リンク上の混乱を回避します。たとえば、イーサネット[RFC6325]の異なるマルチキャストアドレスとEthertype、PPP [RFC6361]の異なるPPP（Point-to-Point Protocol）コードポイントなどです。したがって、レイヤ3 IS-ISで使用される可能性のあるTRILLでエリアアドレスを使用しても問題ありません。
Since current TRILL switches will reject any IS-IS messages with non-zero area addresses, the choices are as follows:
現在のTRILLスイッチは、ゼロ以外のエリアアドレスを持つIS-ISメッセージを拒否するため、次の選択肢があります。
a.1. upgrade all TRILL switches that are to interoperate in a potentially multilevel environment to understand non-zero area addresses,
a.1。潜在的にマルチレベルの環境で相互運用するすべてのTRILLスイッチをアップグレードして、ゼロ以外のエリアアドレスを理解します。
a.2. neighbors of old TRILL switches must remove the area address from IS-IS messages when talking to an old TRILL switch (which might break IS-IS security and/or cause inadvertent merging of areas),
a.2。古いTRILLスイッチのネイバーは、古いTRILLスイッチと通信するときにIS-ISメッセージからエリアアドレスを削除する必要があります（これにより、IS-ISセキュリティが壊れたり、エリアが誤ってマージされる可能性があります）。
a.3. ignore the problem of accidentally merging areas entirely, or
a.3。誤って領域を完全にマージする問題を無視する、または
a.4. keep the fixed "area address" field as 0 in TRILL, and add a new, optional TLV for "area name" to Hellos that, if present, could be compared, by new TRILL switches, to prevent accidental area merging.
a.4。 TRILLで固定の「エリアアドレス」フィールドを0に保ち、「エリア名」の新しいオプションのTLVをHellosに追加します。存在する場合は、新しいTRILLスイッチで比較して、偶発的なエリアのマージを防止できます。
In principal, different solutions could be used in different areas but it would be much simpler to adopt one of these choices uniformly. A simple solution would be a.1, with each TRILL switch using a dominant area nickname as its area address. For the unique-nickname alternative, the dominant nickname could be the lowest value nickname held by any border RBridge of the area. For the aggregated-nickname alternative, it could be the lowest nickname held by a border RBridge of the area or a nickname representing the area.
原則として、さまざまなソリューションをさまざまな分野で使用できますが、これらの選択肢の1つを均一に採用する方がはるかに簡単です。単純な解決策はa.1で、各TRILLスイッチは、支配的なエリアニックネームをエリアアドレスとして使用します。一意のニックネームの代替の場合、支配的なニックネームは、エリアの境界RBridgeが保持する最も低い値のニックネームにすることができます。集約されたニックネームの代替の場合、それは、エリアの境界RBridgeが保持する最も低いニックネーム、またはエリアを表すニックネームである可能性があります。
In the unique-nickname alternative, all nicknames across the campus must be unique. In the aggregated-nickname alternative, TRILL switch nicknames within an aggregated-nickname area are only of local significance, and the only nickname externally (outside that area) visible is the "area nickname" (or nicknames), which aggregates all the internal nicknames.
一意のニックネームの代替では、キャンパス全体のすべてのニックネームが一意である必要があります。集約されたニックネームの代替案では、集約されたニックネーム領域内のTRILLスイッチニックネームはローカルでのみ重要であり、外部（そのエリア外）に表示されるニックネームは、すべての内部ニックネームを集約する「エリアニックネーム」（またはニックネーム）のみです。 。
The unique-nickname approach simplifies border TRILL switches.
ユニークなニックネームのアプローチにより、ボーダーTRILLスイッチが簡素化されます。
The aggregated-nickname approach eliminates the potential problem of nickname exhaustion, minimizes the amount of nickname information that would need to be forwarded between areas, minimizes the size of the forwarding table, and simplifies RPF calculation and RPF information.
集約されたニックネームのアプローチは、ニックネームの枯渇の潜在的な問題を排除し、エリア間で転送する必要があるニックネーム情報の量を最小限に抑え、転送テーブルのサイズを最小限に抑え、RPF計算とRPF情報を簡素化します。
With unique cross-area nicknames, it would be intractable to have a flat nickname space with TRILL switches in different areas contending for the same nicknames. Instead, each area would need to be configured with or allocate one or more blocks of nicknames. Either some TRILL switches would need to announce that all the nicknames other than those in blocks available to the area are taken (to prevent the TRILL switches inside the area from choosing nicknames outside the area's nickname block) or a new TLV would be needed to announce the allowable or the prohibited nicknames, and all TRILL switches in the area would need to understand that new TLV.
固有のクロスエリアニックネームを使用すると、同じニックネームをめぐって競合するさまざまなエリアにTRILLスイッチが付いたフラットニックネームスペースを作成するのは困難です。代わりに、各エリアを構成するか、ニックネームの1つ以上のブロックを割り当てる必要があります。一部のTRILLスイッチは、エリアで使用可能なブロック内のニックネーム以外のすべてのニックネームが取得されることをアナウンスする必要があります（エリア内のTRILLスイッチがエリアのニックネームブロックの外のニックネームを選択しないようにするため）、または新しいTLVがアナウンスする必要があります。許容または禁止のニックネーム、およびエリア内のすべてのTRILLスイッチは、その新しいTLVを理解する必要があります。
Currently, the encoding of nickname information in TLVs is by listing of individual nicknames; this would make it painful for a border TRILL switch to announce into an area that it is holding all other nicknames to limit the nicknames available within that area. Painful means tens of thousands of individual nickname entries in the Level 1 LSDB. The information could be encoded as ranges of nicknames to make this manageable by specifying a new TLV similar to the Nickname Flags APPsub-TLV specified in [RFC7780] but providing flags for blocks of nicknames rather than single nicknames. Although this would require updating software, such a new TLV is the preferred method.
現在、TLV内のニックネーム情報のエンコードは、個々のニックネームのリストによるものです。これは、ボーダーTRILLスイッチが他のすべてのニックネームを保持しているエリアにそのエリア内で使用可能なニックネームを制限することを通知することを困難にします。痛みを伴うとは、レベル1のLSDBにある何万もの個別のニックネームエントリを意味します。この情報は、[RFC7780]で指定されているニックネームフラグAPPsub-TLVと同様の新しいTLVを指定して、ニックネームの範囲としてエンコードすることができますが、単一のニックネームではなくニックネームのブロックにフラグを提供します。これにはソフトウェアの更新が必要ですが、そのような新しいTLVは推奨される方法です。
There is also an issue with the unique-nickname approach in building distribution trees, as follows:
次のように、配布ツリーを構築する際の一意のニックネームアプローチにも問題があります。
With unique nicknames in the TRILL campus and TRILL header nicknames not rewritten by the border TRILL switches, there would have to be globally known nicknames for the trees. Suppose there are k trees. For all of the trees with nicknames located outside an area, the local trees would be rooted at a border TRILL switch or switches. Therefore, there would be either no splitting of multi-destination traffic within the area or restricted splitting of multi-destination traffic between trees rooted at a highly restricted set of TRILL switches.
TRILLキャンパス内の一意のニックネームとボーダーTRILLスイッチによって書き換えられないTRILLヘッダーニックネームを使用する場合、ツリーにはグローバルに知られているニックネームが必要です。 k本の木があるとします。ニックネームがエリアの外にあるすべてのツリーでは、ローカルツリーは、境界TRILLスイッチに根ざしています。したがって、エリア内で複数の宛先のトラフィックが分割されないか、非常に制限されたTRILLスイッチのセットをルートとするツリー間で、複数の宛先のトラフィックの分割が制限されます。
As an alternative, just the "egress nickname" field of multi-destination TRILL Data packets could be mapped at the border, leaving known unicast packets unmapped. However, this surrenders much of the unique nickname advantage of simpler border TRILL switches.
別の方法として、複数の宛先のTRILLデータパケットの「出力ニックネーム」フィールドだけを境界でマッピングし、既知のユニキャストパケットをマッピングしないようにすることもできます。ただし、これにより、よりシンプルなボーダーTRILLスイッチのユニークなニックネームの利点の多くが失われます。
Scaling to a very large campus with unique nicknames might exhaust the 16-bit TRILL nicknames space particularly if (1) additional nicknames are consumed to support active-active end-station groups at the TRILL edge using the techniques standardized in [RFC7781] and (2) use of the nickname space is less efficient due to the allocation of, for example, power-of-two size blocks of nicknames to areas in the same way that use of the IP address space is made less efficient by hierarchical allocation (see [RFC3194]). One method to avoid nickname exhaustion might be to expand nicknames to 24 bits; however, that technique would require TRILL message format and fast-path processing changes and all TRILL switches in the campus to understand larger nicknames.
一意のニックネームを持つ非常に大きなキャンパスにスケーリングすると、特に（1）[RFC7781]および（ 2）ニックネームスペースの使用は、たとえば、ニックネームの2のべき乗サイズのブロックをエリアに割り当てるため、IPアドレススペースの使用が階層的な割り当てによって非効率になるのと同じ方法で効率が低下します（参照[RFC3194]）。ニックネームの枯渇を回避する1つの方法は、ニックネームを24ビットに拡張することです。ただし、その手法では、より大きなニックネームを理解するために、TRILLメッセージ形式と高速パス処理の変更、およびキャンパス内のすべてのTRILLスイッチが必要になります。
The aggregated-nickname approach enables passing far less nickname information. It works as follows, assuming both the source and destination areas are using aggregated nicknames:
集約されたニックネームのアプローチでは、はるかに少ないニックネーム情報を渡すことができます。ソース領域と宛先領域の両方が集約されたニックネームを使用していると想定すると、次のように機能します。
There are at least two ways areas could be identified.
エリアを特定するには、少なくとも2つの方法があります。
One method would be to assign each area a 16-bit nickname. This would not be the nickname of any actual TRILL switch. Instead, it would be the nickname of the area itself. Border TRILL switches would know the area nickname for their own area(s). For an example of a more-specific multilevel proposal using unique nicknames, see [UNIQUE].
1つの方法は、各領域に16ビットのニックネームを割り当てることです。これは、実際のTRILLスイッチのニックネームにはなりません。代わりに、それはそのエリア自体のニックネームになります。ボーダーTRILLスイッチは、自分のエリアのエリアニックネームを知っています。一意のニックネームを使用したより具体的なマルチレベルの提案の例については、[UNIQUE]を参照してください。
Alternatively, areas could be identified by the set of nicknames that identify the border routers for that area. (See [SingleName] for a multilevel proposal using such a set of nicknames.)
あるいは、エリアは、そのエリアの境界ルーターを識別するニックネームのセットで識別できます。 （このようなニックネームのセットを使用したマルチレベルの提案については、[SingleName]を参照してください。）
The TRILL Header nickname fields in TRILL Data packets being transported through a multilevel TRILL campus with aggregated nicknames are as follows:
集約されたニックネームを持つマルチレベルTRILLキャンパスを介して転送されるTRILLデータパケットのTRILLヘッダーニックネームフィールドは次のとおりです。
- When both the ingress and egress TRILL switches are in the same area, there need be no change from the existing base TRILL protocol standard in the TRILL Header nickname fields.
- 入力と出力の両方のTRILLスイッチが同じエリアにある場合、TRILLヘッダーニックネームフィールドの既存の基本TRILLプロトコル標準から変更を加える必要はありません。
- When being transported between different Level 1 areas in Level 2, the ingress nickname is a nickname of the ingress TRILL switch's area, whereas the egress nickname is either a nickname of the egress TRILL switch's area or a tree nickname.
- レベル2の異なるレベル1エリア間で転送される場合、入力ニックネームは入力TRILLスイッチのエリアのニックネームですが、出力ニックネームは出力TRILLスイッチのエリアのニックネームまたはツリーニックネームです。
- When being transported from Level 1 to Level 2, the ingress nickname is the nickname of the ingress TRILL switch itself, whereas the egress nickname is either a nickname for the area of the egress TRILL switch or a tree nickname.
- レベル1からレベル2にトランスポートされる場合、入力ニックネームは入力TRILLスイッチ自体のニックネームですが、出力ニックネームは出力TRILLスイッチのエリアのニックネームまたはツリーニックネームです。
- When being transported from Level 2 to Level 1, the ingress nickname is a nickname for the ingress TRILL switch's area, whereas the egress nickname is either the nickname of the egress TRILL switch itself or a tree nickname.
- レベル2からレベル1に移送される場合、入力ニックネームは入力TRILLスイッチのエリアのニックネームですが、出力ニックネームは出力TRILLスイッチ自体のニックネームまたはツリーニックネームです。
There are two variations of the aggregated-nickname approach. The first is the Border Learning approach, which is described in Section 2.2.2.1. The second is the Swap Nickname Field approach, which is described in Section 2.2.2.2. Section 2.2.2.3 compares the advantages and disadvantages of these two variations of the aggregated-nickname approach.
総称ニックネームアプローチには2つのバリエーションがあります。 1つ目は、ボーダーラーニングアプローチです。これについては、2.2.2.1項で説明しています。 2つ目は、セクション2.2.2.2で説明されているスワップニックネームフィールドアプローチです。 2.2.2.3項では、これらの2つのバリエーションの総称ニックネームアプローチの長所と短所を比較しています。
This section provides an illustrative example and description of the border-learning variation of aggregated nicknames where a single nickname is used to identify an area.
このセクションでは、単一のニックネームを使用してエリアを識別する、集約されたニックネームの境界学習バリエーションの例と説明を提供します。
In the following picture, RB2 and RB3 are area border TRILL switches (RBridges). A source S is attached to RB1. The two areas have nicknames 15961 and 15918, respectively. RB1 has a nickname, say 27, and RB4 has a nickname, say 44 (and in fact, they could even have the same nickname, since the TRILL switch nickname will not be visible outside these aggregated-nickname areas).
次の図で、RB2とRB3はエリア境界TRILLスイッチ（RBridges）です。ソースSがRB1に接続されています。 2つのエリアのニックネームはそれぞれ15961と15918です。 RB1にはニックネーム（27など）があり、RB4にはニックネーム（44など）があります（これらの集約されたニックネーム領域の外側にはTRILLスイッチのニックネームが表示されないため、実際には同じニックネームにすることもできます）。
Area 15961 level 2 Area 15918
+-------------------+ +-----------------+ +--------------+
| | | | | |
| S--RB1---Rx--Rz----RB2---Rb---Rc--Rd---Re--RB3---Rk--RB4---D |
| 27 | | | | 44 |
| | | | | |
+-------------------+ +-----------------+ +--------------+
Let's say that S transmits a frame to destination D, which is connected to RB4, and let's say that D's location has already been learned by the relevant TRILL switches. These relevant switches have learned the following:
SがRB4に接続されている宛先Dにフレームを送信するとし、Dの位置は関連するTRILLスイッチによってすでに学習されているとします。これらの関連スイッチは、次のことを学習しています。
1. RB1 has learned that D is connected to nickname 15918 2. RB3 has learned that D is attached to nickname 44.
1. RB1は、Dがニックネーム15918 2に接続されていることを学習しました。RB3は、Dがニックネーム44に接続されていることを学習しました。
The following sequence of events will occur:
次の一連のイベントが発生します。
- S transmits an Ethernet frame with source MAC = S and destination MAC = D.
- Sは、送信元MAC = Sおよび宛先MAC = Dのイーサネットフレームを送信します。
- RB1 encapsulates with a TRILL header with ingress RBridge = 27, and egress = 15918 producing a TRILL Data packet.
- RB1は、入口RBridge = 27、出口= 15918のTRILLヘッダーでカプセル化し、TRILLデータパケットを生成します。
- RB2 has announced in the Level 1 IS-IS instance in area 15961, that it is attached to all the area nicknames, including 15918. Therefore, IS-IS routes the packet to RB2. Alternatively, if a distinguished range of nicknames is used for Level 2, Level 1 TRILL switches seeing such an egress nickname will know to route to the nearest border router, which can be indicated by the IS-IS "attached bit" [IS-IS].
- RB2は、エリア15961のレベル1 IS-ISインスタンスで、15918を含むすべてのエリアニックネームにアタッチされることを発表しました。したがって、IS-ISはパケットをRB2にルーティングします。または、ニックネームの区別された範囲がレベル2に使用されている場合、そのような出力ニックネームを確認するレベル1 TRILLスイッチは、IS-IS「接続ビット」[IS-IS ]。
- RB2, when transitioning the packet from Level 1 to Level 2, replaces the ingress TRILL switch nickname with the area nickname, so it replaces 27 with 15961. Within Level 2, the ingress RBridge field in the TRILL header will therefore be 15961, and the egress RBridge field will be 15918. Also RB2 learns that S is attached to nickname 27 in area 15961 to accommodate return traffic.
- RB2は、パケットをレベル1からレベル2に移行するときに、入力TRILLスイッチのニックネームをエリアニックネームに置き換えます。したがって、27を15961に置き換えます。レベル2内では、TRILLヘッダーの入力RBridgeフィールドは15961になり、出力RBridgeフィールドは15918になります。また、RB2は、リターントラフィックに対応するために、エリア15961のニックネーム27にSが付加されていることを学習します。
- The packet is forwarded through Level 2, to RB3, which has advertised, in Level 2, reachability to the nickname 15918.
- パケットは、レベル2を介して、ニックネーム15918への到達可能性をレベル2でアドバタイズしたRB3に転送されます。
- RB3, when forwarding into area 15918, replaces the egress nickname in the TRILL header with RB4's nickname (44). So, within the destination area, the ingress nickname will be 15961 and the egress nickname will be 44.
- RB3は、エリア15918に転送するときに、TRILLヘッダーの出力ニックネームをRB4のニックネーム（44）に置き換えます。したがって、宛先エリア内では、入力ニックネームは15961、出力ニックネームは44になります。
- RB4, when decapsulating, learns that S is attached to nickname 15961, which is the area nickname of the ingress.
- RB4は、カプセル化を解除するときに、Sがニックネーム15961に接続されていることを学習します。ニックネームは、イングレスのエリアニックネームです。
Now suppose that D's location has not been learned by RB1 and/or RB3. What will happen, as it would in TRILL today, is that RB1 will forward the packet as multi-destination, choosing a tree. As the multi-destination packet transitions into Level 2, RB2 replaces the ingress nickname with the area nickname. If RB1 does not know the location of D, the packet must be flooded, subject to possible pruning, in Level 2 and, subject to possible pruning, from Level 2 into every Level 1 area that it reaches on the Level 2 distribution tree.
ここで、Dの位置がRB1やRB3によって学習されていないとします。今日のTRILLの場合と同様に、RB1はツリーを選択して、パケットを複数の宛先として転送します。マルチ宛先パケットがレベル2に移行すると、RB2は入力ニックネームをエリアニックネームに置き換えます。 RB1がDの場所を認識していない場合、パケットは、レベル2でのプルーニングの可能性に従って、レベル2からレベル2配信ツリーで到達するすべてのレベル1エリアにフラッディングされる必要があります。
Now suppose that RB1 has learned the location of D (attached to nickname 15918), but RB3 does not know where D is. In that case, RB3 must turn the packet into a multi-destination packet within area 15918. In this case, care must be taken so that in the case in which RB3 is not the designated transitioner between Level 2 and its area for that multi-destination packet, but was on the unicast path, that border TRILL switch in that area does not forward the now multi-destination packet back into Level 2. Therefore, it would be desirable to have a marking, somehow, that indicates the scope of this packet's distribution to be "only this area" (see also Section 4).
ここで、RB1がD（ニックネーム15918に添付）の場所を学習したが、RB3はDがどこにあるかを知らないと仮定します。その場合、RB3はパケットをエリア15918内のマルチ宛先パケットに変換する必要があります。この場合、RB3がレベル2とそのマルチエリアのエリア間の指定されたトランジターではないように注意する必要があります宛先パケットですが、ユニキャストパス上にありましたが、そのエリアの境界TRILLスイッチは、現在は複数宛先のパケットをレベル2に転送しません。したがって、この範囲を示すマーキングをすることが望ましいでしょう。パケットの分布は「このエリアのみ」になる（セクション4も参照）。
In cases where there are multiple transitioners for unicast packets, the border-learning mode of operation requires that the address learning between them be shared by some protocol such as running ESADI [RFC7357] for all Data Labels of interest to avoid excessive unknown unicast flooding.
ユニキャストパケットに複数のトランジターが存在する場合、境界学習モードの操作では、関心のあるすべてのデータラベルに対してESADI [RFC7357]を実行するなど、プロトコル間のアドレス学習を共有して、未知のユニキャストフラッディングが過度に発生しないようにする必要があります。
The potential issue described at the end of Section 2.2.1 with trees in the unique-nickname alternative is eliminated with aggregated nicknames. With aggregated nicknames, each border TRILL switch that will transition multi-destination packets can have a mapping between Level 2 tree nicknames and Level 1 tree nicknames. There need not even be agreement about the total number of trees: just agreement that the border TRILL switch have some mapping and replace the egress TRILL switch nickname (the tree name) when transitioning levels.
一意のニックネームの代替のツリーでセクション2.2.1の終わりに説明されている潜在的な問題は、集約されたニックネームで解消されます。集約されたニックネームを使用すると、複数の宛先パケットを移行する各ボーダーTRILLスイッチは、レベル2ツリーニックネームとレベル1ツリーニックネームの間のマッピングを持つことができます。ツリーの総数について合意する必要はありません。境界のTRILLスイッチにマッピングがあり、レベルを移行するときに出力TRILLスイッチのニックネーム（ツリー名）を置き換えることだけを合意してください。
There is a variant possibility where two additional fields could exist in TRILL Data packets that could be called the "ingress swap nickname field" and the "egress swap nickname field". This variant is described below for completeness, but it would require fast-path hardware changes from the existing TRILL protocol. The changes in the example above would be as follows:
「入力スワップニックネームフィールド」および「出力スワップニックネームフィールド」と呼ばれる可能性がある2つの追加フィールドがTRILLデータパケットに存在する可能性のある、さまざまな可能性があります。このバリアントは完全を期すために以下で説明しますが、既存のTRILLプロトコルからの高速パスハードウェアの変更が必要になります。上記の例の変更点は次のとおりです。
- RB1 will have learned the area nickname of D and the TRILL switch nickname of RB4 to which D is attached. In encapsulating a frame to D, it puts an area nickname of D (15918) in the egress nickname field of the TRILL Header and puts a nickname of RB3 (44) in an egress swap nickname field.
- RB1は、Dのエリアニックネームと、Dが接続されているRB4のTRILLスイッチニックネームを学習します。フレームをDにカプセル化する場合、Dのエリアニックネーム（15918）をTRILLヘッダーの出力ニックネームフィールドに入れ、RB3（44）のニックネームを出力スワップニックネームフィールドに入れます。
- RB2 moves the ingress nickname to the ingress swap nickname field and inserts 15961, an area nickname for S, into the ingress nickname field.
- RB2は、入力ニックネームを入力スワップニックネームフィールドに移動し、Sのエリアニックネーム15961を入力ニックネームフィールドに挿入します。
- RB3 swaps the egress nickname and the egress swap nickname fields, which sets the egress nickname to 44.
- RB3は、出力ニックネームフィールドと出力スワップニックネームフィールドをスワップし、出力ニックネームを44に設定します。
- RB4 learns the correspondence between the source MAC/VLAN of S and the { ingress nickname, ingress swap nickname field } pair as it decapsulates and egresses the frame.
- RB4は、SのソースMAC / VLANと{入力ニックネーム、入力スワップニックネームフィールド}のペアの対応を学習します。
See [TRILL-IP] for a multilevel proposal using aggregated swap nicknames with a single nickname representing an area.
領域を表す単一のニックネームを持つ集約されたスワップニックネームを使用したマルチレベルの提案については、[TRILL-IP]を参照してください。
The border-learning variant described in Section 2.2.2.1 minimizes the change in non-border TRILL switches, but it imposes the burden on border TRILL switches of learning and doing lookups in all the end-station MAC addresses within their area(s) that are used for communication outside the area. This burden could be reduced by decreasing the area size and increasing the number of areas.
2.2.2.1節で説明する境界学習バリアントは、非境界TRILLスイッチの変更を最小限に抑えますが、境界TRILLスイッチが学習し、そのエリア内のすべての端末MACアドレスでルックアップを実行する負担を課します。エリア外の通信に使用されます。エリアのサイズを小さくし、エリアの数を増やすことで、この負担を軽減できます。
The Swap Nickname Field variant described in Section 2.2.2.2 eliminates the extra address learning burden on border TRILL switches, but it requires changes to the TRILL Data packet header and more extensive changes to non-border TRILL switches. In particular, with this alternative, non-border TRILL switches must learn to associate both a TRILL switch nickname and an area nickname with end-station MAC/label pairs (except for addresses that are local to their area).
セクション2.2.2.2で説明されているスワップニックネームフィールドバリアントは、境界TRILLスイッチの余分なアドレス学習の負担を排除しますが、TRILLデータパケットヘッダーの変更と非境界TRILLスイッチのより広範な変更が必要です。特に、この代替案では、非ボーダーTRILLスイッチは、TRILLスイッチニックネームとエリアニックネームの両方を端末MAC /ラベルペアに関連付けることを学習する必要があります（そのエリアにローカルなアドレスを除く）。
The Swap Nickname Field alternative is more scalable but less backward compatible for non-border TRILL switches. It would be possible for border and other Level 2 TRILL switches to support both border learning, for support of legacy Level 1 TRILL switches, and Swap Nickname Field, to support Level 1 TRILL switches that understood the Swap Nickname Field method based on variations in the TRILL header; however, this would be even more complex.
スワップニックネームフィールドの代替は、よりスケーラブルですが、非ボーダーTRILLスイッチの下位互換性は低くなります。境界および他のレベル2 TRILLスイッチは、従来のレベル1 TRILLスイッチをサポートするために境界学習をサポートし、スワップニックネームフィールドは、バリエーションの変化に基づいてスワップニックネームフィールドを理解するレベル1 TRILLスイッチをサポートすることができます。 TRILLヘッダー。ただし、これはさらに複雑になります。
The requirement to change the TRILL header and fast-path processing to support the Swap Nickname Field variant make it impractical for the foreseeable future.
スワップニックネームフィールドバリアントをサポートするためにTRILLヘッダーと高速パス処理を変更する必要があるため、予見可能な将来には実用的ではありません。
It is easy to build a multi-area tree by building a tree in each area separately, (including the Level 2 area), and then having only a single-border TRILL switch, say RBx, in each area, attach to the Level 2 area. RBx would forward all multi-destination packets between that area and Level 2.
レベル2エリアを含む各エリアに個別にツリーを構築し、各エリアに単一境界のTRILLスイッチ、たとえばRBxのみをレベル2に接続することで、マルチエリアツリーを構築するのは簡単です。範囲。 RBxは、そのエリアとレベル2の間のすべての複数宛先パケットを転送します。
However, people might find this unacceptable because of the desire to path split (not always sending all multi-destination traffic through the same border TRILL switch).
ただし、パス分割を希望するため、これが受け入れられない場合もあります（常に同じ宛先TRILLスイッチを介してすべての複数の宛先トラフィックを送信するわけではありません）。
This is the same issue as with multiple ingress TRILL switches injecting traffic from a pseudonode, and it can be solved with the mechanism that was adopted for that purpose: the affinity TLV [RFC7783]. For each tree in the area, at most one border RB announces itself in an affinity TLV with that tree name.
これは、疑似ノードからトラフィックを注入する複数の入力TRILLスイッチと同じ問題であり、その目的のために採用されたメカニズムであるアフィニティTLV [RFC7783]で解決できます。エリア内のツリーごとに、最大で1つの境界RBが、そのツリー名を持つアフィニティTLVで自分自身をアナウンスします。
For multi-destination data originating locally in RBx's area, computation of the RPF check is done as today. For multi-destination packets originating outside RBx's area, computation of the RPF check must be done based on which one of the border TRILL switches (say RB1, RB2, or RB3) injected the packet into the area.
RBxの領域でローカルに発生する複数の宛先データの場合、RPFチェックの計算は現在と同様に行われます。 RBxのエリア外から発信された複数の宛先のパケットの場合、RPFチェックの計算は、境界のTRILLスイッチ（RB1、RB2、またはRB3など）のいずれがパケットをエリアに注入したかに基づいて行われる必要があります。
A TRILL switch, say RB4, located inside an area, must be able to know which of RB1, RB2, or RB3 transitioned the packet into the area from Level 2 (or into Level 2 from an area).
エリア内にあるTRILLスイッチ（RB4など）は、パケットをレベル2からエリアに（またはエリアからレベル2に）遷移したRB1、RB2、またはRB3を認識できる必要があります。
This could be done using any one of a variety of mechanisms such as having the DBRB announce the transitioner assignments to all the TRILL switches in the area or using the Affinity sub-TLV mechanism given in [RFC7783] or with a New Tree Encoding mechanism discussed in Section 4.1.1.
これは、DBRBにエリア内のすべてのTRILLスイッチへの移行者の割り当てをアナウンスさせるか、[RFC7783]で説明されているアフィニティサブTLVメカニズムを使用するか、または新しいツリーエンコーディングメカニズムを使用するなど、さまざまなメカニズムのいずれかを使用して実行できます。セクション4.1.1の
In the aggregated-nickname alternative, each area must acquire a unique identifier, for example, by acquiring a unique area nickname or by using an identifier based on the area's set of border TRILL switches. It is probably simpler to allocate a block of nicknames (say, the top 4000) to either (1) represent areas and not specific TRILL switches or (2) be used by border TRILL switches if the set of such border TRILL switches represent the area.
集約ニックネームの代替案では、各エリアは、例えば、固有のエリアニックネームを取得するか、エリアの境界TRILLスイッチのセットに基づく識別子を使用して、固有の識別子を取得する必要があります。ニックネームのブロック（たとえば、上位4000）を（1）特定のTRILLスイッチではなく、エリアを表すか、（2）境界TRILLスイッチのセットがエリアを表す場合、境界TRILLスイッチで使用する方がおそらく簡単です。 。
The nicknames used for area identification need to be advertised and acquired through Level 2.
エリアの識別に使用されるニックネームは、レベル2を通じて宣伝および取得する必要があります。
Within an area, all the border TRILL switches can discover each other through the Level 1 LSDB, by using the IS-IS "attached bit" [IS-IS] or by explicitly advertising in their LSP "I am a border RBridge".
エリア内のすべての境界TRILLスイッチは、IS-IS「接続ビット」[IS-IS]を使用するか、LSPで「私は境界RBridgeです」と明示的にアドバタイズすることにより、レベル1 LSDBを介してお互いを検出できます。
Of the border TRILL switches, one will have highest priority (say RB7). RB7 can dynamically participate, in Level 2, to acquire a nickname for identifying the area. Alternatively, RB7 could give the area a pseudonode IS-IS ID, such as RB7.5, within Level 2. So an area would appear, in Level 2, as a pseudonode and the pseudonode could participate, in Level 2, to acquire a nickname for the area.
国境のTRILLスイッチのうち、1つが最も優先されます（RB7など）。 RB7は、レベル2に動的に参加して、エリアを識別するためのニックネームを取得できます。または、RB7は、レベル2内のエリアにRB7.5などの疑似ノードIS-IS IDを与えることができます。したがって、レベル2にエリアが表示され、疑似ノードおよび疑似ノードがレベル2に参加して、エリアのニックネーム。
Within Level 2, all the border TRILL switches for an area can advertise reachability to the area, which would mean connectivity to a nickname identifying the area.
レベル2内では、エリアのすべての境界TRILLスイッチがそのエリアへの到達可能性を通知できます。これは、エリアを識別するニックネームへの接続を意味します。
Within an area, say area A1, there is an election for the DBRB, say RB1. This can be done through LSPs within area A1. The border TRILL switches announce themselves, together with their DBRB priority. (Note that the election of the DBRB cannot be done based on Hello messages, because the border TRILL switches are not necessarily physical neighbors of each other. They can, however, reach each other through connectivity within the area, which is why it will work to find each other through Level 1 LSPs.)
エリアA1などのエリア内に、RB1などのDBRBの選挙があります。これは、エリアA1内のLSPを介して実行できます。国境のTRILLスイッチは、DBRBの優先順位とともに、自身をアナウンスします。 （境界のTRILLスイッチは必ずしも物理的に隣接しているわけではないため、Helloメッセージに基づいてDBRBを選択することはできません。ただし、エリア内の接続を介して相互に到達できるため、機能します。レベル1 LSPを介してお互いを検索します。）
RB1 can acquire an area nickname (in the aggregated-nickname approach), and may give the area a pseudonode IS-IS ID (just like the Designated RBridge (DRB) would give a pseudonode IS-IS ID to a link) depending on how the area nickname is handled. RB1 advertises, in area A1, an area nickname that RB1 has acquired (and what the pseudonode IS-IS ID for the area is if needed).
RB1は、エリアニックネームを取得でき（集約ニックネームアプローチ）、その方法に応じて、エリアに疑似ノードIS-IS IDを指定できます（指定RBridge（DRB）が疑似ノードIS-IS IDをリンクに付与するのと同じように）。エリアのニックネームが処理されます。 RB1は、エリアA1で、RB1が取得したエリアニックネーム（および、エリアの疑似ノードIS-IS IDが必要な場合）を通知します。
Level 1 LSPs (possibly pseudonode) initiated by RB1 for the area include any information external to area A1 that should be input into area A1 (such as nicknames of external areas, or perhaps (in the unique nickname variant) all the nicknames of external TRILL switches in the TRILL campus and pruning information such as multicast listeners and labels). All the other border TRILL switches for the area announce (in their LSP) attachment to that area.
エリアのRB1によって開始されたレベル1 LSP（おそらく疑似ノード）には、エリアA1に入力する必要のあるエリアA1の外部情報（外部エリアのニックネーム、またはおそらく（固有のニックネームバリアント内）の外部TRILLのすべてのニックネームなど）が含まれますTRILLキャンパス内のスイッチとマルチキャストリスナーやラベルなどのプルーニング情報）。エリアの他のすべての境界TRILLスイッチは、そのエリアへの接続を（LSPで）アナウンスします。
Within Level 2, RB1 generates a Level 2 LSP on behalf of the area. The same pseudonode ID could be used within Level 1 and Level 2, for the area. (There does not seem any reason why it would be useful for it to be different, but there's also no reason why it would need to be the same). Likewise, all the area A1 border TRILL switches would announce, in their Level 2 LSPs, connection to the area.
レベル2内で、RB1はエリアに代わってレベル2 LSPを生成します。エリアのレベル1とレベル2で同じ疑似ノードIDを使用できます。 （それが異なることが有益である理由はないようですが、同じである必要がある理由もありません）。同様に、すべてのエリアA1ボーダーTRILLスイッチは、レベル2 LSPでエリアへの接続を通知します。
It is possible for an area to become partitioned, so that there is still a path from one section of the area to the other, but that path is via the Level 2 area.
エリアが分割される可能性があるため、エリアの1つのセクションから別のセクションへのパスは存在しますが、そのパスはレベル2エリアを経由します。
With multilevel TRILL, an area will naturally break into two areas in this case.
マルチレベルTRILLを使用すると、この場合、エリアは自然に2つのエリアに分割されます。
Area addresses might be configured to ensure two areas are not inadvertently connected. Area addresses appear in Hellos and LSPs within the area. If two chunks, connected only via Level 2, were configured with the same area address, this would not cause any problems. (They would just operate as separate Level 1 areas.)
エリアアドレスは、2つのエリアが誤って接続されないように構成されている場合があります。エリアアドレスは、エリア内のHelloとLSPに表示されます。レベル2でのみ接続された2つのチャンクが同じエリアアドレスで構成されている場合、これは問題を引き起こしません。 （これらは、独立したレベル1エリアとして動作します。）
A more serious problem occurs if the Level 2 area is partitioned in such a way that it could be healed by using a path through a Level 1 area. TRILL will not attempt to solve this problem. Within the Level 1 area, a single-border RBridge will be the DBRB, and will be in charge of deciding which (single) RBridge will transition any particular multi-destination packets between that area and Level 2. If the Level 2 area is partitioned, this will result in multi-destination data only reaching the portion of the TRILL campus reachable through the partition attached to the TRILL switch that transitions that packet. It will not cause a loop.
レベル2の領域が、レベル1の領域を通るパスを使用して修復できるようにパーティション化されている場合、より深刻な問題が発生します。 TRILLはこの問題の解決を試みません。レベル1エリア内では、シングルボーダーRBridgeがDBRBになり、そのエリアとレベル2の間で特定の複数宛先パケットをどの（単一の）RBridgeがトランジションするかを決定します。レベル2エリアがパーティション化されている場合、これにより、マルチ宛先データは、そのパケットを遷移させるTRILLスイッチに接続されたパーティションを介して到達可能なTRILLキャンパスの部分にのみ到達します。ループは発生しません。
There are at least two reasons it would be desirable to be able to mark a multi-destination packet with a scope that indicates the packet should not exit the area, as follows:
次のように、パケットがエリアから出てはならないことを示すスコープを使用して、複数の宛先のパケットをマークできることが望ましい2つ以上の理由があります。
1. To address an issue in the border learning variant of the aggregated-nickname alternative, when a unicast packet turns into a multi-destination packet when transitioning from Level 2 to Level 1, as discussed in Section 4.1.
1. 4.1で説明したように、レベル2からレベル1に移行するときにユニキャストパケットが複数の宛先のパケットに変わるとき、集約されたニックネームの代替の境界学習バリアントの問題に対処します。
2. To constrain the broadcast domain for certain discovery, directory, or service protocols as discussed in Section 4.2.
2. セクション4.2で説明されているように、特定の検出、ディレクトリ、またはサービスプロトコルのブロードキャストドメインを制限するため。
Multi-destination packet distribution scope restriction could be done in a number of ways. For example, there could be a flag in the packet that means "for this area only". However, the technique that might require the least change to TRILL switch fast-path logic would be to indicate this in the egress nickname that designates the distribution tree being used. There could be two general tree nicknames for each tree, one being for distribution restricted to the area and the other being for multi-area trees. Or there would be a set of N (perhaps 16) special currently reserved nicknames used to specify the N highest priority trees but with the variation that if the special nickname is used for the tree, the packet is not transitioned between areas. Or one or more special trees could be built that were restricted to the local area.
複数の宛先のパケット配信スコープの制限は、いくつかの方法で実行できます。たとえば、「このエリアのみ」を意味するフラグがパケットに含まれている可能性があります。ただし、TRILLスイッチの高速パスロジックの変更を最小限に抑えることができるテクニックは、使用されている配布ツリーを指定する出力ニックネームでこれを示すことです。各ツリーには2つの一般的なツリーニックネームがあり、1つはエリアに限定して配布するためのもので、もう1つはマルチエリアツリーのためのものです。または、N個の最高優先度ツリーを指定するために使用されるN（おそらく16）の特別な現在ニックネームのセットがありますが、ツリーに特別なニックネームが使用されている場合、パケットはエリア間で移行されません。または、地域に限定された1つ以上の特別な木を構築することもできます。
In the border learning variant of the aggregated-nickname alternative, the following situation may occur:
集約されたニックネームの代替の境界学習バリアントでは、次の状況が発生する可能性があります。
- a unicast packet might be known at the Level 1 to Level 2 transition and be forwarded as a unicast packet to the least-cost border TRILL switch advertising connectivity to the destination area, but
- ユニキャストパケットは、レベル1からレベル2への遷移で認識され、宛先エリアへの接続をアドバタイズする最小コストの境界TRILLスイッチにユニキャストパケットとして転送されますが、
- upon arriving at the border TRILL switch, it turns out to have an unknown destination { MAC, Data Label } pair.
- 境界TRILLスイッチに到達すると、不明な宛先{MAC、データラベル}ペアがあることがわかります。
In this case, the packet must be converted into a multi-destination packet and flooded in the destination area. However, if the border TRILL switch doing the conversion is not the border TRILL switch designated to transition the resulting multi-destination packet, there is the danger that the designated transitioner may pick up the packet and flood it back into Level 2 from which it may be flooded into multiple areas. This danger can be avoided by restricting any multi-destination packet that results from such a conversion to the destination area as described above.
この場合、パケットは複数の宛先のパケットに変換され、宛先エリアにフラッディングされる必要があります。ただし、変換を行うボーダーTRILLスイッチが、結果の複数宛先パケットを遷移するように指定されたボーダーTRILLスイッチではない場合、指定されたトランジターがパケットを受け取り、レベル2にフラッディングして、そこからレベル2にフラッディングする危険があります。複数の地域に氾濫する。この危険は、上記のような宛先エリアへの変換から生じる複数宛先パケットを制限することによって回避できます。
Alternatively, a multi-destination packet intended only for the area could be tunneled (within the area) to the RBridge RBx, that is the appointed transitioner for that form of packet (say, based on VLAN or FGL), with instructions that RBx only transmit the packet within the area, and RBx could initiate the multi-destination packet within the area. Since RBx introduced the packet, and is the only one allowed to transition that packet to Level 2, this would accomplish scoping of the packet to within the area. Since this case only occurs in the unusual case when unicast packets need to be turned into multi-destination as described above, the suboptimality of tunneling between the border TRILL switch that receives the unicast packet and the appointed level transitioner for that packet might not be an issue.
または、エリアのみを対象とする複数の宛先のパケットを（エリア内で）RBridge RBxにトンネリングすることもできます。RBridgeRBxは、その形式のパケット（たとえば、VLANまたはFGLに基づく）に指定されたトランジターであり、RBxのみを指示します。エリア内でパケットを送信すると、RBxはエリア内で複数の宛先のパケットを開始できます。 RBxがパケットを導入したので、そのパケットをレベル2に移行できるのはRBxだけなので、これにより、エリア内へのパケットのスコープが達成されます。このケースは、上記のようにユニキャストパケットを複数の宛先に変換する必要がある異常な場合にのみ発生するため、ユニキャストパケットを受信する境界TRILLスイッチとそのパケットに指定されたレベルトランジターとの間のトンネリングの準最適性は、問題。
The current encoding, in a TRILL header of a tree, is of the nickname of the tree root. This requires all 16 bits of the egress nickname field. TRILL could instead, for example, use the bottom 6 bits to encode the tree number (allowing 64 trees), leaving 10 bits to encode information such as:
ツリーのTRILLヘッダーの現在のエンコーディングは、ツリールートのニックネームです。これには、出力ニックネームフィールドの16ビットすべてが必要です。代わりに、TRILLは、たとえば、下位6ビットを使用してツリー番号（64ツリーを許可）をエンコードし、10ビットを残して次のような情報をエンコードします。
scope: a flag indicating whether it should be single area only or an entire campus
スコープ：単一のエリアのみにするか、キャンパス全体にするかを示すフラグ
border injector: an indicator of which of the k border TRILL switches injected this packet
ボーダーインジェクター：k個のボーダーTRILLスイッチがこのパケットを挿入したことを示すインジケーター
If TRILL were to adopt this new encoding, any of the TRILL switches in an edge group could inject a multi-destination packet. This would require all TRILL switches to be changed to understand the new encoding for a tree, and it would require a TLV in the LSP to indicate which number each of the TRILL switches in an edge group would be.
TRILLがこの新しいエンコーディングを採用する場合、エッジグループ内のTRILLスイッチのいずれかが複数の宛先のパケットを挿入する可能性があります。これには、ツリーの新しいエンコーディングを理解するためにすべてのTRILLスイッチを変更する必要があり、エッジグループの各TRILLスイッチの数をLSPのTLVに示す必要があります。
While there are a number of advantages to this technique, it requires fast-path logic changes; thus, its deployment is not practical at this time. It is included here for completeness.
この手法にはいくつかの利点がありますが、高速パスのロジック変更が必要です。したがって、現時点ではその展開は実用的ではありません。完全を期すためにここに含まれています。
There are a number of service, discovery, and directory protocols that, for convenience, are accessed via multicast or broadcast frames. Examples are DHCP, the NetBIOS Service Location Protocol, and multicast DNS.
便宜上、マルチキャストフレームまたはブロードキャストフレームを介してアクセスされるサービス、ディスカバリ、およびディレクトリプロトコルがいくつかあります。例としては、DHCP、NetBIOSサービスロケーションプロトコル、およびマルチキャストDNSがあります。
Some such protocols provide means to restrict distribution to an IP subnet or equivalent to reduce size of the broadcast domain they are using, and then they provide a proxy that can be placed in that subnet to use unicast to access a service elsewhere. In cases where a proxy mechanism is not currently defined, it may be possible to create one that references a central server or cache. With multilevel TRILL, it is possible to construct very large IP subnets that could become saturated with multi-destination traffic of this type unless packets can be further restricted in their distribution. Such restricted distribution can be accomplished for some protocols, say protocol P, in a variety of ways including the following:
一部のそのようなプロトコルは、IPサブネットまたは同等のものに配布を制限して、使用しているブロードキャストドメインのサイズを削減する手段を提供し、次に、そのサブネットに配置して、ユニキャストを使用して他の場所のサービスにアクセスできるプロキシを提供します。プロキシメカニズムが現在定義されていない場合は、中央のサーバーまたはキャッシュを参照するメカニズムを作成できる場合があります。マルチレベルTRILLを使用すると、パケットの配信をさらに制限できない限り、このタイプの複数の宛先トラフィックで飽和する可能性がある非常に大きなIPサブネットを構築することが可能です。このような制限された配布は、プロトコルPなどの一部のプロトコルでは、次のようなさまざまな方法で実現できます。
- Either (1) at all ingress TRILL switches in an area, place all protocol P multi-destination packets on a distribution tree in such a way that the packets are restricted to the area or (2) at all border TRILL switches between that area and Level 2, detect protocol P multi-destination packets and do not transition them.
- （1）エリア内のすべての入力TRILLスイッチで、パケットがエリアに制限されるように、すべてのプロトコルPマルチ宛先パケットを配布ツリーに配置するか、または（2）そのエリアとレベル2、プロトコルPの複数宛先パケットを検出し、それらを移行しません。
- Then, place one, or a few for redundancy, protocol P proxies inside each area where protocol P may be in use. These proxies unicast protocol P requests or other messages to the actual campus server(s) for P. They also receive unicast responses or other messages from those servers and deliver them within the area via unicast, multicast, or broadcast as appropriate. (Such proxies would not be needed if it was acceptable for all protocol P traffic to be restricted to an area.)
- 次に、冗長性を確保するために、プロトコルPが使用されている可能性のある各エリア内にプロトコルPプロキシを1つまたはいくつか配置します。これらのプロキシは、Pの実際のキャンパスサーバーへのユニキャストプロトコルP要求またはその他のメッセージを送信します。また、これらのサーバーからユニキャスト応答またはその他のメッセージを受信し、必要に応じてユニキャスト、マルチキャスト、またはブロードキャストを介してエリア内に配信します。 （すべてのプロトコルPトラフィックがエリアに制限されることが許容される場合、そのようなプロキシは必要ありません。）
While it might seem logical to connect the campus servers to TRILL switches in Level 2, they could be placed within one or more areas so that, in some cases, those areas might not require a local proxy server.
キャンパスサーバーをレベル2のTRILLスイッチに接続することは理にかなっているように見えるかもしれませんが、1つ以上のエリア内に配置できるため、これらのエリアにローカルプロキシサーバーが不要な場合があります。
TRILL switches that are not multilevel aware may have a problem with calculating RPF check and filtering information, since they would not be aware of the assignment of border TRILL switch transitioning.
マルチレベルに対応していないTRILLスイッチは、境界のTRILLスイッチの遷移の割り当てを認識しないため、RPFチェックとフィルタリング情報の計算に問題がある可能性があります。
A possible solution, as long as any old TRILL switches exist within an area, is to have the border TRILL switches elect a single DBRB and have all inter-area traffic go through the DBRB (unicast as well as multi-destination). If that DBRB goes down, a new one will be elected, but at any one time, all inter-area traffic (unicast as well as multi-destination) would go through that one DRBR. However this eliminates load splitting at level transition.
可能な解決策は、エリア内に古いTRILLスイッチが存在する限り、境界TRILLスイッチが単一のDBRBを選択し、すべてのエリア間トラフィックがDBRBを通過するようにすることです（ユニキャストおよびマルチ宛先）。そのDBRBがダウンすると、新しいDBRBが選出されますが、すべてのエリア間トラフィック（ユニキャストとマルチ宛先）は常にその1つのDRBRを通過します。ただし、これにより、レベル遷移での負荷分割がなくなります。
Care must be taken in the case where there are multiple TRILL switches on a link with one or more end stations, keeping in mind that end stations are TRILL ignorant. In particular, it is essential that only one TRILL switch ingress/egress any given data packet from/ to an end station so that connectivity is provided to that end station without duplicating end-station data and that loops are not formed due to one TRILL switch egressing data in native form (i.e., with no TRILL header) and having that data re-ingressed by another TRILL switch on the link.
1つ以上のエンドステーションとのリンクに複数のTRILLスイッチがある場合は、エンドステーションがTRILLを認識しないことに注意してください。特に、1つのTRILLスイッチのみが特定のデータパケットをエンドステーションに出入りすることにより、エンドステーションデータを複製せずにそのエンドステーションへの接続が提供され、1つのTRILLスイッチが原因でループが形成されないことが重要です。ネイティブ形式（つまり、TRILLヘッダーなし）でデータを出力し、そのデータをリンク上の別のTRILLスイッチによって再入力させる。
With existing, single-level TRILL, this is done by electing a single DRB per link, which appoints a single Appointed Forwarder per VLAN [RFC7177] [RFC8139]. This mechanism depends on the RBridges establishing adjacency. But, suppose there are two (or more) TRILL switches on a link in different areas, say RB1 in area A1 and RB2 in area A2, as shown below; and suppose that the link also has one or more end stations attached. If RB1 and RB2 ignore each other's Hellos because they are in different areas, as they are required to do under normal IS-IS PDU processing rules, then they will not form an adjacency. If they are not adjacent, they will ignore each other for the Appointed Forwarder mechanism and will both ingress/egress end-station traffic on the link causing loops and duplication.
既存の単一レベルのTRILLでは、これは、VLANごとに単一のAppointed Forwarderを指定するリンクごとに単一のDRBを選択することによって行われます[RFC7177] [RFC8139]。このメカニズムは、隣接を確立するRBridgeに依存します。ただし、異なるエリアのリンクに2つ（またはそれ以上）のTRILLスイッチがあるとします。たとえば、次に示すように、エリアA1にRB1、エリアA2にRB2があるとします。また、リンクにも1つ以上のエンドステーションが接続されているとします。 RB1とRB2は、通常のIS-IS PDU処理ルールで実行する必要があるため、別の領域にあるために互いのHelloを無視する場合、隣接を形成しません。それらが隣接していない場合、それらはAppointed Forwarderメカニズムに関して互いに無視し、ループの重複と重複を引き起こしているリンク上のエンド/ステーションのエンドステーショントラフィックの両方になります。
The problem is not avoiding adjacency or avoiding TRILL-Data-packet transfer between RB1 and RB2; the area address mechanism of IS-IS or possibly the use of topology constraints (or the like) does that quite well. The problem stems from end stations being TRILL ignorant; therefore, care must be taken so that multiple RBridges on a link do not ingress the same frame originated by an end station and so that an RBridge does not ingress a native frame egressed by a different RBridge because the RBridge mistakes the frame for a frame originated by an end station.
問題は、隣接関係を回避したり、RB1とRB2間のTRILLデータパケット転送を回避したりすることではありません。 IS-ISのエリアアドレスメカニズム、またはトポロジー制約（など）の使用は、それを非常にうまく行います。この問題は、端末がTRILLを知らないことに起因しています。したがって、リンク上の複数のRBridgeが端末から発信された同じフレームに入らないように、またRBridgeがフレームを発信元のフレームと間違えるためにRBridgeが別のRBridgeから出されたネイティブフレームに入らないように注意する必要があります。エンドステーション。
+--------------------------------------------+
| Level 2 |
+----------+---------------------+-----------+
| Area A1 | | Area A2 |
| +---+ | | +---+ |
| |RB1| | | |RB2| |
| +-+-+ | | +-+-+ |
| | | | | |
+-----|----+ +-----|-----+
| |
--+---------+-------------+--------+-- Link
| |
+------+------+ +--+----------+
| End Station | | End Station |
+-------------+ +-------------+
A simple rule, which is preferred, is to use the TRILL switch or switches having the lowest-numbered area, comparing area numbers as unsigned integers, to handle all native traffic to/from end stations on the link. This would automatically give multilevel-ignorant legacy TRILL switches, that would be using area number zero, highest priority for handling end-station traffic, which they would try to do anyway.
推奨される簡単なルールは、TRILLスイッチを使用してエリア番号が最も小さいスイッチを使用し、エリア番号を符号なし整数として比較して、リンク上のエンドステーションとの間のすべてのネイティブトラフィックを処理することです。これにより、マルチレベルを無視したレガシーTRILLスイッチが自動的に提供され、エリア番号0が使用され、エンドステーショントラフィックの処理に最高の優先順位が与えられます。
Other methods are possible. For example, making the selection of the Appointed Forwarders and the TRILL switch in charge of that selection across all TRILL switches on the link, regardless of area. However, a special case would then have to be made for legacy TRILL switches using area number zero.
他の方法も可能です。たとえば、エリアに関係なく、リンク上のすべてのTRILLスイッチ全体で、Appointed Forwardersの選択とTRILLスイッチがその選択を担当するようにします。ただし、エリア番号0を使用するレガシーTRILLスイッチについては、特別なケースを作成する必要があります。
These techniques require multilevel-aware TRILL switches to take actions based on Hellos from RBridges in other areas, even though they will not form an adjacency with such RBridges. However, the action is quite simple in the preferred case: if a TRILL switch sees Hellos from lower-numbered areas, then they would not act as an Appointed Forwarder on the link until the Hello timer for such Hellos had expired.
これらの手法では、他のエリアのRBridgeからのHelloに基づいてアクションを実行するために、マルチレベル対応のTRILLスイッチが必要です。ただし、好ましいケースではアクションは非常に単純です。TRILLスイッチが小さい番号のエリアからのHelloを検出した場合、そのようなHelloのHelloタイマーが期限切れになるまで、リンク上のAppointed Forwarderとして機能しません。
This document describes potential scaling issues in TRILL and possible approaches to multilevel TRILL as a solution or element of a solution to most of them.
このドキュメントでは、TRILLの潜在的なスケーリングの問題と、それらのほとんどに対するソリューションまたはソリューションの要素としてのマルチレベルTRILLへの可能なアプローチについて説明します。
The alternative using aggregated-nickname areas in multilevel TRILL has significant advantages in terms of scalability over using campus-wide unique nicknames, not just in avoiding nickname exhaustion, but by allowing RPF checks to be aggregated based on an entire area.
マルチレベルTRILLで集約ニックネームエリアを使用する代替方法には、ニックネームの枯渇を回避するだけでなく、エリア全体に基づいてRPFチェックを集約できるようにすることにより、キャンパス全体の一意のニックネームを使用するよりもスケーラビリティの点で大きな利点があります。
However, the alternative of using unique nicknames is simpler and avoids the changes in border TRILL switches required to support aggregated nicknames. It is possible to support both. For example, a TRILL campus could use simpler unique nicknames until scaling begins to cause problems and then start to introduce areas with aggregated nicknames.
ただし、固有のニックネームを使用する代わりの方法はより簡単で、集約されたニックネームをサポートするために必要な境界TRILLスイッチの変更を回避します。両方をサポートすることが可能です。たとえば、TRILLキャンパスでは、スケーリングが問題を引き起こし始め、ニックネームが集約されたエリアを導入し始めるまで、よりシンプルな一意のニックネームを使用できます。
Some multilevel TRILL issues are not difficult, such as dealing with partitioned areas. Other issues are more difficult, especially dealing with old TRILL switches that are multilevel ignorant.
分割された領域の処理など、いくつかのマルチレベルTRILLの問題は難しくありません。他の問題、特にマルチレベルの無知である古いTRILLスイッチを扱うことはより困難です。
This informational document explores alternatives for the design of multilevel IS-IS in TRILL and generally does not consider security issues.
この情報文書では、TRILLでマルチレベルIS-ISを設計するための代替案を検討し、通常はセキュリティの問題を考慮していません。
If aggregated nicknames are used in two areas that have the same area address, and those areas merge, there is a possibility of a transient nickname collision that would not occur with unique nicknames. Such a collision could cause a data packet to be delivered to the wrong egress TRILL switch, but it would still not be delivered to any end station in the wrong Data Label; thus, such delivery would still conform to security policies.
集約されたニックネームが同じエリアアドレスを持つ2つのエリアで使用され、それらのエリアがマージされる場合、一意のニックネームでは発生しない一時的なニックネームの衝突の可能性があります。このような衝突により、データパケットが誤った出力TRILLスイッチに配信される可能性がありますが、それでも、誤ったデータラベルのエンドステーションには配信されません。したがって、このような配信は依然としてセキュリティポリシーに準拠します。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002年11月。
[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, <https://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、<https://www.rfc-editor.org/info/rfc6325>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<https://www.rfc-editor.org/info/rfc7177>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc7780>。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and F. Hu、 "Transparent Interconnection of Lots of Links（TRILL）：Appointed Forwarders"、RFC 8139、DOI 10.17487 / RFC8139、2017年6月、<https://www.rfc-editor.org/info/rfc8139>。
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, DOI 10.17487/RFC3194, November 2001, <https://www.rfc-editor.org/info/rfc3194>.
[RFC3194] Durand、A。およびC. Huitema、「アドレス割り当て効率のH密度比、H比の更新」、RFC 3194、DOI 10.17487 / RFC3194、2001年11月、<https：//www.rfc- editor.org/info/rfc3194>。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011, <https://www.rfc-editor.org/info/rfc6361>.
[RFC6361]カールソン、J。およびD.イーストレイク3rd、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、DOI 10.17487 / RFC6361、2011年8月、<https：//www.rfc-editor .org / info / rfc6361>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <https://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月、<https://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, <https://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月、<https://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, <https://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月、<https://www.rfc-editor.org/info/rfc7357>。
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <https://www.rfc-editor.org/info/rfc7781>.
[RFC7781] Zhai、H.、Senevirathne、T.、Perlman、R.、Zhang、M。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：アクティブ-アクティブアクセスの疑似ニックネーム」、RFC 7781、DOI 10.17487 / RFC7781、2016年2月、<https://www.rfc-editor.org/info/rfc7781>。
[RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <https://www.rfc-editor.org/info/rfc7783>.
[RFC7783] Senevirathne、T.、Pathangi、J。、およびJ. Hudson、「多数のリンクの透過的相互接続（TRILL）のための協調マルチキャストツリー（CMT）」、RFC 7783、DOI 10.17487 / RFC7783、2016年2月、<https ：//www.rfc-editor.org/info/rfc7783>。
[InterCon] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley Longman, Second Edition, Chapter 3, 1999.
[InterCon] Perlman、R。、「相互接続：ブリッジ、ルーター、スイッチ、およびインターネットワーキングプロトコル」、Addison Wesley Longman、第2版、1999年第3章。
[TRILL-IP] Bhikkaji, B., Venkataswami, B., Mahadevan, R., Sundaram, S., and N. Swamy, "Connecting Disparate Data Center/PBB/ Campus TRILL sites using BGP", Work in Progress, draft-balaji-trill-over-ip-multi-level-05, March 2012.
[TRILL-IP] Bhikkaji、B.、Venkataswami、B.、Mahadevan、R.、Sundaram、S。、およびN. Swamy、「BGPを使用した異種データセンター/ PBB /キャンパスTRILLサイトの接続」、作業中、ドラフト-balaji-trill-over-ip-multi-level-05、2012年3月。
[UNIQUE] Zhang, M., Eastlake, D., Perlman, R., Cullen, M., Zhai, H., and D. Liu, "TRILL Multilevel Using Unique Nicknames", Work in Progress, draft-ietf-trill-multilevel-unique-nickname-02, May 2017.
[UNIQUE] Zhang、M.、Eastlake、D.、Perlman、R.、Cullen、M.、Zhai、H.、D。Liu、「TRILL Multilevel Using Unique Nicknames」、Work in Progress、draft-ietf-trill -multilevel-unique-nickname-02、2017年5月。
[SingleName] Zhang, M., Eastlake, D., Perlman, R., Cullen, M., and H. Zhai, "Transparent Interconnection of Lots of Links (TRILL) Single Area Border RBridge Nickname for Multilevel", Work in Progress, draft-ietf-trill-multilevel-single-nickname-04, July 2017.
[SingleName] Zhang、M.、Eastlake、D.、Perlman、R.、Cullen、M。、およびH. Zhai、「多数のリンクの透過的な相互接続（TRILL）単一領域ボーダーRBridgeニックネーム（マルチレベル）」、進行中の作業、draft-ietf-trill-multilevel-single-nickname-04、2017年7月。
Acknowledgements
謝辞
The helpful comments and contributions of the following are hereby acknowledged:
以下の有益なコメントと貢献をここに認めます。
Alia Atlas, David Michael Bond, Dino Farinacci, Sue Hares, Gayle Noble, Alexander Vainshtein, and Stig Venaas.
Alia Atlas、David Michael Bond、Dino Farinacci、Sue Hares、Gayle Noble、Alexander Vainshtein、Stig Venaas。
Authors' Addresses
著者のアドレス
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America
Radia Perlman EMC 2010 256th Avenue NE、＃200 Bellevue、WA 98007アメリカ合衆国
Email: radia@alum.mit.edu
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
Mingui Zhang Huawei Technologies No.156 Beiqing Rd. Haidian District, Beijing 100095 China
min鬼Zhang hu A is technologies no.156 be i青RD。H dwarf dot District、Beijing 100095 China
Email: zhangmingui@huawei.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 United States of America
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054アメリカ合衆国
Email: anoop@alumni.duke.edu
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China
ニュージーランドの命令によると、インスティチュートオブテクノロジー99ホンアベニュー、江寧区NaN京、江蘇211169中国
Email: honjun.zhai@tom.com