[要約] RFC 5556は、TRILL（Transparent Interconnection of Lots of Links）の問題と適用性に関する文書であり、TRILLの目的はスケーラブルなイーサネットネットワークを実現することです。
Network Working Group J. Touch
Request for Comments: 5556 USC/ISI
Category: Informational R. Perlman
Sun
May 2009
Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement
多くのリンクの透明な相互接続（TRILL）：問題と適用性ステートメント
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths (in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with 802.1, including hubs, bridges, and their existing plug-and-play capabilities.
現在のIEEE 802.1 LANSは、多くの課題があるスパニングツリープロトコルを使用しています。これらのプロトコルは、ヘッダーループ検出サポートが不足しているため、ルートの伝播中に、一時的なプロトコルを厳密に回避する必要があります。ルーティングは、代替パス、または重複しないペアワイズパスを最大限に活用しない傾向があります（木のスパンの場合）。このドキュメントは、これらの懸念に対処し、リンクレイヤーで最新のネットワーク層ルーティングプロトコルを適用することを提案します。このドキュメントは、ソリューションが既存のIEEE 802.1ブリッジ型リンクのスケーラビリティを超えたスケーラビリティの問題に対処しないが、ハブ、ブリッジ、および既存のプラグアンドプレイ機能を含む802.1との後方互換性のあるソリューションは、ソリューションが互換性があることを前提としています。
Table of Contents
目次
1. Introduction ....................................................2
2. The TRILL Problem ...............................................3
2.1. Inefficient Paths ..........................................3
2.2. Multipath Forwarding .......................................5
2.3. Convergence and Safety .....................................6
2.4. Stability of IP Multicast Optimization .....................6
2.5. IEEE 802.1 Bridging Protocols ..............................7
2.6. Problems Not Addressed .....................................8
3. Desired Properties of Solutions to TRILL ........................9
3.1. No Change to Link Capabilities .............................9
3.2. Zero Configuration and Zero Assumption ....................10
3.3. Forwarding Loop Mitigation ................................10
3.4. Spanning Tree Management ..................................11
3.5. Multiple Attachments ......................................11
3.6. VLAN Issues ...............................................11
3.7. Operational Equivalence ...................................12
3.8. Optimizations .............................................12
3.9. Internet Architecture Issues ..............................13
4. Applicability ..................................................13
5. Security Considerations ........................................14
6. Acknowledgments ................................................15
7. Informative References .........................................15
Conventional Ethernet networks -- known in the Internet as Ethernet link subnets -- have a number of attractive features, allowing hosts and routers to relocate within the subnet without requiring renumbering, and supporting automatic configuration. The basis of the simplicity of these subnets is the spanning tree, which although simple and elegant, can have substantial limitations. With spanning trees, the bandwidth across the subnet is limited because traffic flows over a subset of links forming a single tree -- or, with the latest version of the protocol and significant additional configuration, over a small number of superimposed trees. The oldest version of the spanning tree protocol can converge slowly when there are frequent topology changes.
インターネットでイーサネットリンクサブネットとして知られている従来のイーサネットネットワークには、多くの魅力的な機能があり、ホストとルーターが変更を必要とせずにサブネット内で再配置できるようにし、自動構成をサポートできます。これらのサブネットのシンプルさの基礎はスパニングツリーであり、シンプルでエレガントではありますが、大きな制限があります。スパニングツリーを使用すると、サブネット全体の帯域幅は制限されています。これは、単一のツリーを形成するリンクのサブセット上にトラフィックが流れるため、または少数の重ね張りの木にわたって最新バージョンのプロトコルと重要な追加構成を備えています。スパニングツリープロトコルの最古のバージョンは、頻繁にトポロジの変更がある場合にゆっくりと収束することができます。
The alternative to an Ethernet link subnet is often a network subnet. Network subnets can use link-state routing protocols that allow traffic to traverse least-cost paths rather than being aggregated on a spanning tree backbone, providing higher aggregate capacity and more resistance to link failures. Unfortunately, IP -- the dominant network layer technology -- requires that hosts be renumbered when relocated in different network subnets, interrupting network (e.g., tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are in progress during the transition.
イーサネットリンクサブネットに代わるものは、多くの場合、ネットワークサブネットです。ネットワークサブネットは、トラフィックがスパニングツリーバックボーンに集約されるのではなく、トラフィックが最小コストのパスを通過することを可能にするリンク状態ルーティングプロトコルを使用して、より高い集計容量とより多くの抵抗をリンク障害に提供します。残念ながら、IP（支配的なネットワークレイヤーテクノロジー）では、さまざまなネットワークサブネットに移動し、ネットワーク（トンネル、IPSECなど）および輸送（例：TCP、UDP）の関連付けを中断する場合、ホストを変更する必要があります。。
It is thus useful to consider a new approach that combines the features of these two existing solutions, hopefully retaining the desirable properties of each. Such an approach would develop a new kind of bridge system that was capable of using network-style routing, while still providing Ethernet service. It allows reuse of well-understood network routing protocols to benefit the link layer.
したがって、これら2つの既存のソリューションの機能を組み合わせた新しいアプローチを検討し、それぞれの望ましい特性を保持することを願っています。このようなアプローチは、イーサネットサービスを提供しながら、ネットワークスタイルのルーティングを使用できる新しい種類のブリッジシステムを開発します。よく理解されているネットワークルーティングプロトコルを再利用して、リンクレイヤーに利益をもたらすことができます。
This document describes the challenge of such a combined approach. This problem is known as "Transparent Interconnection of Lots of Links" or "TRILL". The remainder of this document makes minimal assumptions about a solution to TRILL.
このドキュメントでは、このような組み合わせたアプローチの課題について説明しています。この問題は、「多くのリンクの透明な相互接続」または「Trill」として知られています。このドキュメントの残りの部分は、Trillの解決策に関する最小限の仮定を行います。
Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted pair with hubs to twisted pair with switches, becoming increasingly simple to wire and manage. Each level has corresponding topology restrictions; thicknet is inherently linear, whereas thinnet and hub-connected twisted pair have to be wired as a tree. Switches, added in IEEE 802.1D, allow network managers to avoid thinking in trees, where the spanning tree protocol finds a valid tree automatically; unfortunately, this additional simplicity comes with a number of associated penalties [Pe99].
イーサネットのサブネットは、「ThickNet」から「Thinnet」から「Thinnet」に進化し、ハブとツイストペアにスイッチとツイストペアに進化し、ワイヤーと管理がますます簡単になりました。各レベルには、対応するトポロジーの制限があります。Thicknetは本質的に線形ですが、ThinnEtとHub接続のツイストペアはツリーとして配線する必要があります。IEEE 802.1dに追加されたスイッチは、スパニングツリープロトコルが有効なツリーを自動的に見つける木での思考を避けることができます。残念ながら、この追加のシンプルさには、関連する多くの罰則が伴います[PE99]。
The spanning tree often results in inefficient use of the link topology; traffic is concentrated on the spanning tree path, and all traffic follows that path even when other more direct paths are available. The addition in IEEE 802.1Q of support for multiple spanning trees helps a little, but the use of multiple spanning trees requires additional configuration, the number of trees is limited, and these defects apply within each tree regardless. The spanning tree protocol reacts to certain small topology changes with large effects on the reconfiguration of links in use. Each of these aspects of the spanning tree protocol can cause problems for current link-layer deployments.
スパニングツリーは、多くの場合、リンクトポロジを非効率的に使用します。トラフィックはスパニングツリーパスに集中しており、他のより直接的なパスが利用可能な場合でも、すべてのトラフィックはそのパスに従います。IEEE 802.1Qの複数のスパンニングツリーのサポートに追加されると、複数のスパニングツリーを使用するには追加の構成が必要であり、木の数は限られており、これらの欠陥は各ツリー内に関係なく適用されます。スパニングツリープロトコルは、使用中のリンクの再構成に大きな影響を与える特定の小さなトポロジーの変化に反応します。Spanningツリープロトコルのこれらの各側面は、現在のリンク層展開に問題を引き起こす可能性があります。
The Spanning Tree Protocol (STP) helps break cycles in a set of interconnected bridges, but it also can limit the bandwidth among that set and cause traffic to take circuitous paths. For example, in a set of N nodes that are interconnected pairwise along a ring, a spanning tree will disable one physical link so that connectivity is loop free. This will cause traffic between the pair of nodes connected by that disabled link to have to go N-1 physical hops around the entire remainder of the ring rather than take the most efficient single-hop path. Using modern routing protocols with such a topology, no traffic should have to go more than N/2 hops.
スパニングツリープロトコル（STP）は、相互接続されたブリッジのセットでサイクルを破壊するのに役立ちますが、そのセット間の帯域幅を制限し、トラフィックに回路を奪うこともできます。たとえば、リングに沿って相互接続されたペアワイズであるNノードのセットでは、スパニングツリーが1つの物理リンクを無効にして、接続性がループフリーになるようにします。これにより、その無効なリンクで接続されたノードのペア間のトラフィックが、最も効率的なシングルホップパスをとるのではなく、リングの残りの全体をn-1の物理ホップに移動する必要があります。このようなトポロジを備えた最新のルーティングプロトコルを使用すると、N/2ホップを超えるトラフィックは必要ありません。
For another example, consider the network shown in Figure 1, which shows a number of bridges and their interconnecting links. End-hosts and routers are not shown; they would connect to the bridges that are shown, labeled A-H. Note that the network shown has cycles that would cause packet storms if hubs (repeaters) were used instead of spanning-tree-capable bridges. One possible spanning tree is shown by double lines.
別の例については、図1に示すネットワークと、多くのブリッジとその相互接続リンクを示すネットワークを検討してください。エンドホストとルーターは表示されません。それらは、示されている橋に接続し、A-Hとラベル付けされます。表示されているネットワークには、トリー対応ブリッジの代わりにハブ（リピーター）が使用された場合、パケットストームを引き起こすサイクルがあることに注意してください。1つの可能なスパニングツリーは、二重線で示されています。
[A]
// \ [C]
// \ / \\ [D]
// \ / \\ //
[B]=====[H]=====[E]
\ // ||
\ // ||
\ // ||
[G]--------[F]
Figure 1: Bridged subnet with spanning tree shown
図1：スパニングツリーが表示されたブリッジ付きサブネット
The spanning tree limits the capacity of the resulting subnet. Assume that the links are 100 Mbps. Figure 2 shows how traffic from hosts on A to hosts on C goes via the spanning tree path A-B-H-E-C (links replaced with '1' in the figure); traffic from hosts on G to F go via the spanning three path G-H-E-F (links replaced by '2' in the figure). The link H-E is shared by both paths (alternating '1's and '2's), resulting in an aggregate capacity for both A..C and G..F paths of a total of 100 Mbps.
スパニングツリーは、結果のサブネットの容量を制限します。リンクが100 Mbpsであると仮定します。図2は、AのホストからCのホストへのトラフィックが、スパニングツリーパスA-B-H-E-C（図の「1」に置き換えられたリンク）を介してどのように進むかを示しています。GのホストからFへのトラフィックは、3つのパスG-H-E-Fにまたがる（図の「2」に置き換えられたリンク）を介して進みます。リンクH-Eは両方のパス（ '1と' 2を交互に）共有され、合計100 mbpsのA..Cとg..fの両方のパスの総容量になります。
[A]
1 [C]
1 1
1 1
[B]1111111[H]121212[E]
2 2
2 2
2 2
[G] [F]
Figure 2: Traffic from A..C (1) and G..F (2) share a link
図2：A..C（1）およびG..F（2）からのトラフィックがリンクを共有しています
If traffic from G to F were to go directly using full routing, e.g., from G-F, both paths could have 100 Mbps each, and the total aggregate capacity could be 200 Mbps (Figure 3). In this case, the H-F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is more direct.
GからFへのトラフィックが完全なルーティングを使用して直接移動する場合（たとえば、G-Fから）、両方のパスがそれぞれ100 Mbpsを持つ可能性があり、総凝集容量は200 Mbpsになる可能性があります（図3）。この場合、H-FリンクはA-Cトラフィック（ '1's）のみを搭載し、G-Fトラフィック（' 2）がより直接的になります。
[A]
1 [C]
1 1
1 1
[B]1111111[H]111111[E]
[G]2222222[F]
[g] 2222222 [f]
Figure 3: Traffic from A..C (1) and G..F (2) with full routing
図3：フルルーティングを備えたA..C（1）およびG..F（2）からのトラフィック
There are a number of features of modern layer 3 routing protocols which would be beneficial if available at layer 2, but which cannot practically be integrated into the spanning tree system such as multipath routing discussed in Section 2.2 below. Layer 3 routing typically optimizes paths between pairs of endpoints based on a cost metric, conventionally based on bandwidth, hop count, latency, and/or policy measures.
最新のレイヤー3ルーティングプロトコルには多くの機能がありますが、レイヤー2で利用可能な場合は有益ですが、以下のセクション2.2で説明するマルチパスルーティングなど、スパニングツリーシステムに実際に統合することはできません。レイヤー3ルーティングは通常、帯域幅、ホップカウント、レイテンシ、および/またはポリシー測定に基づいて、コストメトリックに基づいてエンドポイントのペア間のパスを最適化します。
The discussion above assumes that all traffic flowing from one point to another follows a single path. Using spanning trees reduces aggregate bandwidth by forcing all such paths onto one tree, while modern routing causes such paths to be selected based on a cost metric. However, extensions to modern routing protocols enable even greater aggregate bandwidth by permitting traffic flowing from one endpoint to another to be sent over multiple, typically equal-cost, paths. (Traffic sent over different paths will generally encounter different delays and may be reordered with respect to traffic on another path. Thus, traffic must be divided into flows, such that reordering of traffic between flows is not significant, and those flows are allocated to paths.)
上記の議論は、ある時点から別のポイントに流れるすべてのトラフィックが単一のパスに従うことを前提としています。スパンニングツリーを使用すると、そのようなパスをすべて1つのツリーに強制することにより、帯域幅が減少しますが、現代のルーティングはコストメトリックに基づいてそのようなパスを選択します。ただし、最新のルーティングプロトコルへの拡張により、あるエンドポイントから別のエンドポイントに流れるトラフィックが複数の、通常等しいコストのパスで送信できるようにすることにより、さらに大きな集計帯域幅を可能にします。（異なるパスを介して送信されるトラフィックは一般に異なる遅延に遭遇し、別のパスのトラフィックに関して再注文する場合があります。したがって、トラフィックはフローに分割する必要があります。。）
Multipathing typically spreads the traffic more evenly over the available physical links. The addition of multipathing to a routed network would typically result in only a small improvement in capacity for a network with roughly equal traffic between all pairs of nodes, because in that situation traffic is already fairly well dispersed. Conversely, multipathing can produce a dramatic improvement in a routed network where the traffic between a small number of pairs of nodes dominates, because such traffic can -- under the right circumstances -- be spread over multiple paths that might otherwise be lightly loaded.
通常、マルチパスは、利用可能な物理的リンクの上にトラフィックをより均等に広げます。ルーティングされたネットワークへのマルチパスを追加すると、通常、その状況ではトラフィックがかなりよく分散されているため、ノードのすべてのペア間でほぼ等しいトラフィックを持つネットワークの容量がわずかに改善されます。逆に、マルチパスは、少数のノード間のトラフィックが支配するルーティングネットワークで劇的な改善をもたらす可能性があります。なぜなら、そのようなトラフィックは、適切な状況下では、そうでなければ軽量にロードされる可能性のある複数のパスに広がる可能性があるからです。
The spanning tree is dependent on the way a set of bridges are interconnected, i.e., the link-layer topology. Small changes in this topology can cause large changes in the spanning tree. Changes in the spanning tree can take time to propagate and converge, especially for older versions of STP.
スパニングツリーは、ブリッジのセットが相互接続されている方法、つまりリンク層トポロジーに依存しています。このトポロジの小さな変化は、スパニングツリーに大きな変化を引き起こす可能性があります。特にSTPの古いバージョンでは、スパニングツリーの変化に時間がかかる場合があります。
One possible case occurs when one of the branches connected to the root bridge fails, causing a large number of ports to block and unblock before the network reconverges [Me04]. Consider a ring with a stub as shown in Figure 4.
ルートブリッジに接続された分岐の1つが故障した場合、1つの可能なケースが発生し、ネットワークが再緩和される前に多数のポートがブロックされ解除されます[ME04]。図4に示すように、スタブのあるリングを検討してください。
[R]----[A]----[B]----[C]----[D]----[E]
| |
+--------[F]-----[G]--------+
Figure 4: Ring with poor convergence under reconfiguration
図4：再構成下での収束が不十分なリング
If A is the root bridge, then the paths A->B->C->D and A->F->G->E are the two open paths, while the D->E link is blocked. If the A->B link fails, then E must unblock its port to D for traffic to flow again, but it may require recomputation of the entire tree through BPDUs (Bridge PDUs). Even worse, if R is root and R or the A-R connection fails, BPDU updates related to the old and new root can lead to a brief count-to-infinity event, and, if RSTP (Rapid Spanning Tree Protocol) is in use, can delay convergence for a few seconds. The original IEEE 802.1 spanning tree protocol can impose 30-second delays in re-establishing data connectivity after a topology change in order to be sure a new topology has stabilized and been fully propagated.
aがルートブリッジの場合、パスa-> b-> c-> dおよびa-> f-> g-> eは2つのオープンパスであり、d-> eリンクはブロックされます。a-> bリンクが失敗した場合、Eはトラフィックが再び流れるためにポートをDに解除する必要がありますが、BPDUS（ブリッジPDU）を介してツリー全体の再計算が必要になる場合があります。さらに悪いことに、rがルートとRまたはA-R接続が失敗した場合、古いルートと新しいルートに関連するBPDUの更新は、短いカウントからインフィニティへのイベントにつながる可能性があり、RSTP（ラピッドスパニングツリープロトコル）が使用されている場合、収束を数秒間遅らせることができます。元のIEEE 802.1スパニングツリープロトコルは、新しいトポロジが安定して完全に伝播されたことを確認するために、トポロジの変更後にデータ接続の再確立に30秒の遅延を課すことができます。
The spanning tree protocol is inherently global to an entire layer 2 subnet; there is no current way to contain, partition, or otherwise factor the protocol into a number of smaller, more stable subsets that interact as groups. Contrast this with Internet routing, which includes both intradomain and interdomain variants, split to provide exactly that containment and scalability within a domain while allowing domains to interact freely independent of what happens within a domain.
スパニングツリープロトコルは、レイヤー2サブネット全体に本質的にグローバルです。グループとして相互作用する多くの小さく、より安定したサブセットにプロトコルを封じ込めたり、分割したり、その他の方法で考慮する方法はありません。これをインターネットルーティングとは対照的に、ドメイン内でドメイン内で発生することとは独立して自由に対話できるようにしながら、ドメイン内の封じ込めとスケーラビリティを正確に提供するために分割されました。
Although it is a layer violation, it is common for high-end bridges to snoop on IP multicast control messages for the purpose of optimizing the distribution of IP multicast data and of those control messages [RFC4541].
レイヤー違反ですが、IPマルチキャストデータとそれらの制御メッセージの分布を最適化する目的で、ハイエンドブリッジがIPマルチキャスト制御メッセージをスヌープすることは一般的です[RFC4541]。
When such snooping and optimization is performed by spanning-tree-based bridges, it done at each bridge based on the traffic observed on that bridge's ports. Changes in topology may reverse or otherwise change the required forwarding ports of messages for a multicast group. Bridges must relearn the correct multicast forwarding from the receipt of multicast control messages on new ports. Such control messages are sent to establish multicast distribution state and then to refresh it, sometimes at intervals of seconds. If a bridging topology change has occurred during such intervals, multicast data may be misdirected and lost.
そのようなスヌーピングと最適化がスパニングツリーベースのブリッジによって実行されると、その橋の港で観察された交通に基づいて各ブリッジで行われます。トポロジの変更は、マルチキャストグループのメッセージの転送ポートを逆転または変更する場合があります。ブリッジは、新しいポートでマルチキャスト制御メッセージの受領から正しいマルチキャスト転送を再学習する必要があります。このような制御メッセージは、マルチキャスト分布状態を確立し、時には秒間隔で更新するために送信されます。このような間隔中にブリッジングトポロジの変更が発生した場合、マルチキャストデータは誤った方向に向けられ、失われる可能性があります。
However, a solution based on link-state routing, for example, can form and maintain a global view of the multicast group membership and multicast router situation in a similar fashion to that in which it maintains a global view of the status of links. Thus, such a solution can adjust the forwarding of multicast data and control traffic immediately as it sees the LAN topology change.
ただし、たとえば、リンク状態のルーティングに基づくソリューションは、マルチキャストグループメンバーシップとマルチキャストルーターの状況のグローバルなビューを形成および維持することができ、リンクのステータスのグローバルビューを維持するものと同様の方法で維持できます。したがって、このようなソリューションは、LANトポロジーの変化が見られるため、マルチキャストデータの転送を調整し、すぐにトラフィックを制御できます。
There have been a variety of IEEE protocols beyond the initial shared-media Ethernet variant, including:
以下を含む、最初の共有メディアイーサネットバリアントを超えて、さまざまなIEEEプロトコルがありました。
o 802.1D - added bridges (i.e., switches) and a spanning tree protocol (STP) (incorporates 802.1w, below) [IEEE04].
o 802.1d -Bridges（すなわち、スイッチ）とSpanning Tree Protocol（STP）（下記802.1Wが組み込まれています）を追加しました[IEEE04]。
o 802.1w - extension for rapid reconvergence of the spanning tree protocol (RTSP) [IEEE04].
o 802.1W -Spanning Tree Protocol（RTSP）[IEEE04]の迅速な再変換のための拡張。
o 802.1Q - added VLAN and priority support, where each link address maps to one VLAN (incorporates 802.1v and 802.1s, below) [IEEE06].
o 802.1Q -VLANと優先度サポートを追加しました。各リンクは1つのVLANにマップします（以下の802.1Vおよび802.1を組み込んでいます）[IEEE06]。
o 802.1v - added VLANs where segments map to VLANs based on link address together with network protocol and transport port [IEEE06].
o 802.1V-ネットワークプロトコルとトランスポートポート[IEEE06]とともにリンクアドレスに基づいてセグメントがVLANにマッピングされるVLANを追加しました。
o 802.1s - added support for multiple spanning trees, up to a maximum of 65, one per non-overlapping group of VLANs (Multiple STP) [IEEE06].
o 802.1S-最大65個までの複数のスパニングツリーのサポートを追加し、1つはVLANの非重複グループ（複数STP）[IEEE06]に1つずつサポートを追加しました。
This document presumes the above variants are supported on the Ethernet subnet, i.e., that a TRILL solution would not interfere with (i.e., would not affect) any of the above.
このドキュメントでは、上記のバリアントがイーサネットサブネットでサポートされていると仮定しています。つまり、上記のいずれも干渉しない（つまり、影響しない）ことを推定します。
In addition, the following more recent extensions have been standardized to specify provider/carrier Ethernet services that can be effectively transparent to the previously specified customer Ethernet services. The TRILL problem as described in this document is limited to customer Ethernet services; however, there is no reason that a TRILL solution might not be easily applicable to both customer and provider Ethernet.
さらに、以下のより最近の拡張機能が標準化されており、以前に指定された顧客イーサネットサービスに対して効果的に透明性のあるプロバイダー/キャリアイーサネットサービスを指定しています。このドキュメントで説明されているTRILLの問題は、顧客イーサネットサービスに限定されています。ただし、Trillソリューションが顧客とプロバイダーの両方のイーサネットに簡単に適用できない場合は理由はありません。
o 802.1ad (Provider Bridges) - added support for a second level of VLAN tag, called a "service tag", and renamed the original 802.1Q tag a "customer tag". Also known as Q-in-Q because of the stacking of 802.1Q VLAN tags.
o 802.1AD（プロバイダーブリッジ） - 「サービスタグ」と呼ばれる第2レベルのVLANタグのサポートを追加し、元の802.1Qタグに「顧客タグ」と改名しました。802.1Q VLANタグのスタッキングのため、Q-in-Qとも呼ばれます。
o 802.1ah (Provider Backbone Bridges) - added support for stacking of MAC addresses by providing a tag to contain the original source and destination MAC addresses. Also know as MAC-in-MAC.
o 802.1AH（プロバイダーバックボーンブリッジ） - 元のソースと宛先MACアドレスを含むタグを提供することにより、Macアドレスのスタッキングのサポートを追加しました。Mac-in-macとしても知っています。
It is useful to note that no extension listed above in this section addresses the issue of independent, localized routing in a single LAN -- which is the focus of TRILL.
このセクションに上記の拡張機能は、単一のLANでの独立したローカライズされたルーティングの問題に対処していないことに注意すると便利です。これはTrillの焦点です。
The TRILL problem and a sketch of a possible solution [Pe04] were presented to both the IETF (via a BoF) and IEEE 802 (via an IEEE 802 Plenary Meeting Tutorial). The IEEE, in response, approved a project called Shortest Path Bridging (IEEE Project P802.1aq), taking a different approach than that presented in [Pe04]. The current Draft of P802.1aq appears to describe two different techniques. One, which does not use encapsulation, is, according to the IEEE Draft, limited in applicability to small networks of no more than 100 shortest path bridges. The other, which uses 802.1ah, is, according to the IEEE Draft, limited in applicability to networks of no more than 1,000 shortest path bridges.
トリルの問題と可能なソリューション[PE04]のスケッチは、IETF（BOF経由）とIEEE 802（IEEE 802全体会議チュートリアルを介して）の両方に提示されました。これに応じて、IEEEは、[PE04]で提示されたアプローチとは異なるアプローチをとって、最短パスブリッジング（IEEEプロジェクトP802.1AQ）と呼ばれるプロジェクトを承認しました。P802.1AQの現在のドラフトは、2つの異なる手法を説明しているようです。カプセル化を使用しない1つは、IEEEドラフトによると、最短のパスブリッジの100個以下の小さなネットワークへの適用性が制限されています。802.1AHを使用するもう1つは、IEEEドラフトによると、最短のパスブリッジが1,000を超えないネットワークへの適用性が制限されています。
There are other challenges to deploying Ethernet subnets that are not addressed in this document other than, in some cases, to mention relevant IEEE 802.1 documents, although it is possible for a solution to address one or more of these in addition to the TRILL problem. These include:
場合によっては、関連するIEEE 802.1ドキュメントに言及する以外に、このドキュメントでは対処されていないイーサネットサブネットを展開するには、他の課題がありますが、Trillの問題に加えてこれらの1つ以上に対処することは可能です。これらには以下が含まれます：
o increased Ethernet link subnet scale
o イーサネットリンクサブネットスケールの増加
o increased node relocation
o ノードの再配置の増加
o security of the Ethernet link subnet management protocol
o イーサネットリンクサブネット管理プロトコルのセキュリティ
o flooding attacks on a Ethernet link subnet
o イーサネットリンクサブネットへの洪水攻撃
o support for "provider" services such as Provider Bridges (802.1ad), Provider Backbone Bridges (802.1ah), or Provider Backbone Bridge Traffic Engineering (802.1Qay)
o プロバイダーブリッジ（802.1AD）、プロバイダーバックボーンブリッジ（802.1AH）、プロバイダーバックボーンブリッジトラフィックエンジニアリング（802.1QAY）などの「プロバイダー」サービスのサポート
Solutions to TRILL need not support deployment of larger scales of Ethernet link subnets than current broadcast domains can support (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges).
Trillのソリューションは、現在のブロードキャストドメインがサポートできるよりも、イーサネットリンクサブネットのより大きなスケールの展開をサポートする必要はありません（たとえば、100ブリッジの単一のブリッジ付きLANで約1,000のエンドホスト、または10,000の橋が提供する1,000 VLAN内の100,000のエンドホスト）。
Similarly, solutions to TRILL need not address link-layer node migration, which can complicate the caches in learning bridges. Similar challenges exist in the Address Resolution Protocol (ARP), where link-layer forwarding is not updated appropriately when nodes move to ports on other bridges. Again, the compartmentalization available in network routing, like that of network-layer Autonomous Systems (ASes), can help hide the effect of migration. That is a side effect, however, and not a primary focus of this work.
同様に、Trillの解決策は、学習ブリッジのキャッシュを複雑にする可能性のあるリンク層ノードの移行に対処する必要はありません。同様の課題は、ノードが他のブリッジのポートに移動するときにリンク層転送が適切に更新されない、アドレス解像度プロトコル（ARP）に存在します。繰り返しますが、ネットワーク層の自律システム（ASE）のようなネットワークルーティングで利用可能なコンパートメント化は、移行の効果を隠すのに役立ちます。しかし、それは副作用であり、この作業の主な焦点ではありません。
Current link-layer control-plane protocols, including Ethernet link subnet management (spanning tree) and link/network integration (ARP), are vulnerable to a variety of attacks. Solutions to TRILL need not address these insecurities. Similar attacks exist in the data plane, e.g., source address spoofing, single address traffic attacks, traffic snooping, and broadcast flooding. TRILL solutions need not address any of these issues, although it is critical that they do not introduce new vulnerabilities in the process (see Section 5).
イーサネットリンクサブネット管理（スパニングツリー）およびリンク/ネットワーク統合（ARP）を含む現在のリンク層コントロールプレーンプロトコルは、さまざまな攻撃に対して脆弱です。Trillの解決策は、これらの不安に対処する必要はありません。データプレーンにも同様の攻撃が存在します。たとえば、ソースアドレススプーフィング、単一の住所トラフィック攻撃、トラフィックスヌーピング、放送洪水など。Trill Solutionsはこれらの問題のいずれにも対処する必要はありませんが、プロセスに新しい脆弱性を導入しないことが重要です（セクション5を参照）。
This section describes some of the desirable or required properties of any system that would solve the TRILL problems, independent of the details of such a solution. Most of these are based on retaining useful properties of bridges, or maintaining those properties while solving the problems listed in Section 2.
このセクションでは、このようなソリューションの詳細とは無関係に、Trillの問題を解決するシステムの望ましいまたは必要なプロパティの一部について説明します。これらのほとんどは、セクション2にリストされている問題を解決しながら、橋の有用な特性を保持するか、それらの特性を維持することに基づいています。
There must be no change to the service that Ethernet subnets already provide as a result of deploying a TRILL solution. Ethernet supports unicast, broadcast, and multicast natively. Although network protocols, notably IP, can tolerate link layers that do not provide all three, it would be useful to retain the support already in place [RFC3819]. So called "zero configuration protocols" (also known as "zeroconf", e.g., as used to configure link-local addresses [RFC3927]), as well as existing bridge autoconfiguration, are also dependent on broadcast.
Trillソリューションの展開の結果として、イーサネットサブネットがすでに提供するサービスに変更を加えてはなりません。イーサネットは、ユニキャスト、ブロードキャスト、およびマルチキャストをネイティブにサポートします。ネットワークプロトコル、特にIPは、3つすべてを提供しないリンクレイヤーに耐えることができますが、すでに実施されているサポートを保持することは有用です[RFC3819]。いわゆる「Zero Configuration Protocols」（「Zeroconf」とも呼ばれます。たとえば、リンクローカルアドレス[RFC3927]の構成に使用されます）、および既存のブリッジオートコンチュレーションもブロードキャストに依存しています。
Current Ethernet ensures in-order delivery for frames of the same priority and no duplicated frames, under normal operation (excepting transients during reconfiguration). These criteria apply in varying degrees to the different types of Ethernet, e.g., basic Ethernet up through basic VLAN (802.1Q) ensures that all frames with the same priority between two link addresses have both properties, but protocol/port VLAN (802.1v) ensures this only for packets with the same protocol and port. There are subtle implications to such a requirement. Bridge autolearning already is susceptible to moving nodes between ports, because previously learned associations between the port and link address change. A TRILL solution could be similarly susceptible to such changes.
現在のイーサネットは、通常の動作中（再構成中のトランジェントを除く）、同じ優先順位と複製フレームのフレームの順序配信を保証します。これらの基準は、さまざまなタイプのイーサネットにさまざまな程度で適用されます。たとえば、基本的なVLAN（802.1Q）を介した基本的なイーサネットは、2つのリンクアドレス間の同じ優先度のあるすべてのフレームに両方のプロパティがありますが、プロトコル/ポートVLAN（802.1V）があります。これは、同じプロトコルとポートを持つパケットに対してのみ保証されます。このような要件には微妙な意味があります。ブリッジオートラーニングは、ポートとリンクアドレスの変更の間の以前に学習された関連性があるため、ポート間でノードを移動する可能性があります。Trillソリューションは、そのような変更の影響を受けやすい場合があります。
Both bridges and hubs are zero configuration devices; hubs having no configuration at all, and bridges being automatically self-configured. Bridges are further zero-assumption devices, unlike hubs. Bridges can be interconnected in arbitrary topologies, without regard for cycles or even self-attachment. Spanning tree protocols (STPs) remove the impact of cycles automatically, and port autolearning reduces unnecessary broadcast of unicast traffic.
ブリッジとハブの両方がゼロ構成デバイスです。構成がまったくなく、橋は自動的に自己構成されています。ブリッジは、ハブとは異なり、さらにゼロ吸収デバイスです。橋は、サイクルや自己攻撃に関係なく、任意のトポロジーで相互接続することができます。スパニングツリープロトコル（STPS）サイクルの影響を自動的に削除し、ポート自動学習により、ユニキャストトラフィックの不必要な放送が減少します。
A TRILL solution should strive to have a similar zero-configuration, zero-assumption operation. This includes having TRILL solution components automatically discover other TRILL solution components and organize themselves, as well as to configure that organization for proper operation (plug-and-play). It also includes zero-configuration backward compatibility with existing bridges and hubs, which may include interacting with some of the bridge protocols, such as spanning tree.
TRILLソリューションは、同様のゼロコンフィグレーション、ゼロアサンション操作を行うように努力する必要があります。これには、Trillソリューションコンポーネントが他のTrillソリューションコンポーネントを自動的に発見し、自分自身を整理すること、および適切な操作のためにその組織を構成する（プラグアンドプレイ）を構成することが含まれます。また、既存のブリッジとハブとのゼロコンフィグラーの後方互換性も含まれています。これには、スパニングツリーなどのブリッジプロトコルの対話が含まれます。
VLANs add a caveat to zero configuration; a TRILL solution should support automatic use of a default VLAN (like non-VLAN bridges), but would undoubtedly require explicit configuration for VLANs where bridges require such configuration.
VLANは、ゼロ構成に警告を追加します。TRILLソリューションは、デフォルトのVLAN（非VLANブリッジなど）の自動使用をサポートする必要がありますが、間違いなくブリッジがそのような構成を必要とするVLANの明示的な構成が必要です。
Autoconfiguration extends to optional services, such as multicast support via Internet Group Management Protocol (IGMP) snooping, broadcast support via serial copy, and support of multiple VLANs.
Autoconfigurationは、インターネットグループ管理プロトコル（IGMP）スヌーピング、シリアルコピーによるブロードキャストサポート、複数のVLANのサポートなど、マルチキャストサポートなど、オプションのサービスに拡張されます。
Using spanning trees avoids forwarding loops by construction, although transient loops can occur, e.g., via the temporarily undetected appearance of new link connectivity or the loss of a sufficient number of spanning-tree control frames. Solutions to TRILL are intended to use adapted network-layer routing protocols that may introduce transient loops during routing convergence. A TRILL solution thus needs to provide support for mitigating the effect of such routing loops.
スパンニングツリーを使用すると、構造によってループを転送することができませんが、たとえば、新しいリンク接続の一時的に検出されない外観や、十分な数のスパニングツリー制御フレームの損失を介して、一時的なループが発生する可能性があります。Trillのソリューションは、ルーティング収束中に過渡ループを導入する可能性のある適応ネットワーク層ルーティングプロトコルを使用することを目的としています。したがって、Trillソリューションは、そのようなルーティングループの効果を緩和するためのサポートを提供する必要があります。
In the Internet, loop mitigation is provided by decrementing hop counts (Time To Live (TTL)); in other networks, packets include a trace (sometimes referred to as 'serialized' or 'unioned') of visited nodes [RFC1812]. In addition, there may be localized consistency checks, such as whether traffic is received on an unexpected interface, which indicates that routing is in flux and that such traffic should probably be discarded for safety. These types of mechanisms limit the impact of loops or detect them explicitly. Mechanisms with similar effect should be included in TRILL solutions.
インターネットでは、ループ緩和は、ホップカウントの減少によって提供されます（Time to Live（TTL））。他のネットワークでは、パケットには、訪問したノード[RFC1812]のトレース（「シリアル化」または「結合」と呼ばれることもあります）が含まれます。さらに、予期しないインターフェイスでトラフィックが受信されるかどうかなど、ローカライズされた一貫性チェックがある場合があります。これらのタイプのメカニズムは、ループの影響を制限するか、それらを明示的に検出します。同様の効果のあるメカニズムは、Trill Solutionsに含める必要があります。
In order to address convergence under reconfiguration and robustness to link interruption (Section 2.2), participation in the spanning tree (STP) must be carefully managed. The goal is to provide the desired stability of the TRILL solution and of the entire Ethernet link subnet, which may include bridges using STP. This may involve a TRILL solution participating in the STP, where the protocol used for TRILL might dampen interactions with STP, or it may involve severing the STP into separate STPs on 'stub' external Ethernet link subnet segments.
再構成の下での収束に対処するには、中断（セクション2.2）をリンクするための堅牢性（STPP）への参加を慎重に管理する必要があります。目標は、TrillソリューションとSTPを使用したブリッジを含むイーサネットリンクサブネット全体の望ましい安定性を提供することです。これには、TRILLに使用されるプロトコルがSTPとの相互作用を弱める可能性があるSTPに参加するTrillソリューションが含まれる場合があります。または、「スタブ」外部イーサネットリンクサブネットセグメントでSTPを個別のSTPに切断することが含まれます。
A requirement is that a TRILL solution must not require modifications or exceptions to the existing spanning tree protocols (e.g., STP, RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree Protocol)).
要件は、TRILLソリューションでは、既存のスパニングツリープロトコル（STP、RSTP（ラピッドスパニングツリープロトコル）、MSTP（多重スランニングツリープロトコル））の変更または例外を必要としないことです。
In STP, a single node with multiple attachments to a single spanning tree segment will always get and send traffic over only one of the those attachment points. TRILL must manage all traffic, including multicast and broadcast traffic, so as not to create traffic loops involving Ethernet segments with multiple TRILL attachment points. This includes multiple attachments to a single TRILL node and attachments to multiple TRILL nodes. Support for multiple attachments can improve support for forms of mobility that induce topology changes, such as "make before break", although this is not a major goal of TRILL.
STPでは、単一のスパニングツリーセグメントに複数の添付ファイルを備えた単一のノードが常に取得し、それらの添付ファイルポイントの1つのみにトラフィックを送信します。Trillは、複数のTrillアタッチメントポイントを備えたイーサネットセグメントを含むトラフィックループを作成しないように、マルチキャストやブロードキャストトラフィックを含むすべてのトラフィックを管理する必要があります。これには、単一のトリルノードへの複数の添付ファイルと、複数のトリルノードへの添付ファイルが含まれます。複数の添付ファイルをサポートすると、「休憩前に作る」などのトポロジの変化を引き起こすモビリティの形態のサポートを改善できますが、これはTrillの主要な目標ではありません。
A TRILL solution should support multiple customer VLANs (802.1Q, which includes 802.1v and 802.1s). This may involve ignorance, just as many bridge devices do not participate in the VLAN protocols. A TRILL solution may alternately furnish direct VLAN support, e.g., by providing configurable support for VLAN-ignorant end stations equivalent to that provided by 802.1Q non-provider bridges.
TRILLソリューションは、複数の顧客VLAN（802.1Vおよび802.1Sを含む802.1Q）をサポートする必要があります。これには、多くのブリッジデバイスがVLANプロトコルに参加していないように、無知が含まれる場合があります。Trillソリューションは、たとえば、802.1Q非プロバイダーブリッジが提供するものと同等のVLAN無視エンドステーションに構成可能なサポートを提供することにより、直接VLANサポートを交互に提供する場合があります。
Provider VLANs (802.1ad) are outside of the scope of this document. A TRILL solution might or might not be easily adaptable to handling provider VLANs.
プロバイダーVLANS（802.1AD）は、このドキュメントの範囲外です。TRILLソリューションは、プロバイダーVLANの処理に簡単に適応できる場合とそうでない場合があります。
As with any extension to an existing architecture, it would be useful -- though not strictly necessary -- to be able to describe or consider a TRILL solution as equivalent to an existing link layer component. Such equivalence provides a validation model for the architecture and a way for users to predict the effect of the use of a TRILL solution on a deployed Ethernet. In this case, 'user' refers to users of the Ethernet protocol, whether at the host (data segments), bridge (ST control segments), or VLAN (VLAN control).
既存のアーキテクチャへの拡張と同様に、Trillソリューションを既存のリンクレイヤーコンポーネントに相当するものとして説明または検討することは、厳密に必要ではありませんが、有用です。このような等価性は、アーキテクチャの検証モデルを提供し、ユーザーが展開されたイーサネットでTrillソリューションを使用する効果を予測する方法を提供します。この場合、「ユーザー」とは、ホスト（データセグメント）、ブリッジ（STコントロールセグメント）、またはVLAN（VLANコントロール）であろうと、イーサネットプロトコルのユーザーを指します。
This provides a sanity check, i.e., "we got it right if we can exchange a TRILL solution component or components with an X" (where "X" might be a single bridge, a hub, or some other link layer abstraction). It does not matter whether "X" can be implemented on the same scale as the corresponding TRILL solution. It also does not matter if it can -- there may be utility to deploying the TRILL solution components incrementally, in ways that a single "X" could not be installed.
これにより、正気のチェックが提供されます。つまり、「Trillソリューションコンポーネントまたはコンポーネントをxと交換できる場合、「x」が単一のブリッジ、ハブ、または他のリンクレイヤーの抽象化）になる可能性があります）。「x」を対応するTrillソリューションと同じスケールで実装できるかどうかは関係ありません。また、できるかどうかは関係ありません。単一の「X」をインストールできない方法で、Trillソリューションコンポーネントを段階的に展開するユーティリティがある可能性があります。
For example, if a TRILL solution's components were equivalent to a single IEEE 802.1D bridge, it would mean that they would -- as a whole - participate in the STP. This need not require that TRILL solution components would propagate STP, any more than a bridge need do so in its on-board control. It would mean that the solution would interact with BPDUs at the edge, where the solution would -- again, as a whole - participate as if a single node in the spanning tree. Note that this equivalence is not required; a solution may act as if an IEEE 802.1 hub, or may not have a corresponding equivalent link layer component at all.
たとえば、Trillソリューションのコンポーネントが単一のIEEE 802.1Dブリッジと同等であった場合、全体としてSTPに参加することを意味します。これには、TrillソリューションコンポーネントがSTPを伝播する必要はありません。ブリッジが必要以上のものは、オンボード制御でそうする必要があります。それは、ソリューションがエッジのBPDUSと相互作用することを意味します。ここでは、ソリューションがスパニングツリーに単一のノードのように関与します。この同等性は必要ないことに注意してください。ソリューションは、IEEE 802.1ハブのように機能するか、対応する等価リンクレイヤーコンポーネントをまったく持っていない場合があります。
There are a number of optimizations that may be applied to TRILL solutions. These must be applied in a way that does not affect functionality as a tradeoff for increased performance. Such optimizations may address broadcast and multicast frame distribution, VLAN support, and snooping of ARP and IPv6 neighbor discovery.
Trill Solutionsに適用される可能性のある多くの最適化があります。これらは、パフォーマンスの向上のトレードオフとして機能に影響を与えない方法で適用する必要があります。このような最適化は、放送およびマルチキャストフレーム分布、VLANサポート、およびARPおよびIPv6近隣発見のスヌーピングに対処する場合があります。
In addition, there may be optimizations which make the implementation of a TRILL solution easier than roughly equivalent existing bridge devices. For example, in many bridged LANs, there are topologies such that central ("core") bridges which have both a greater volume of traffic flowing through them as well as traffic to and from a larger variety of end station than do non-core bridges. Thus means that such core bridges need to learn a large number of end station addresses and need to do lookups based on such addresses very rapidly. This might require large high speed content addressable memory making implementation of such core bridges difficult. Although a TRILL solution need not provide such optimizations, it may reduce the need for such large, high speed content addressable memories or provide other similar optimizations.
さらに、ほぼ同等の既存のブリッジデバイスよりもTrillソリューションの実装を簡単にする最適化がある場合があります。たとえば、多くのブリッジ付きLANには、中央（「コア」）ブリッジが、それらを通るトラフィックの量が多いだけでなく、非コアブリッジよりも多種多様なエンドステーションとの間の交通の両方を持つトポロジがあります。。したがって、このようなコアブリッジは、多数のエンドステーションアドレスを学習する必要があり、そのようなアドレスに基づいて非常に迅速にルックアップを行う必要があることを意味します。これには、このようなコアブリッジの実装が困難になる、大規模な高速コンテンツアドレス指定可能なメモリが必要になる場合があります。Trillソリューションはそのような最適化を提供する必要はありませんが、このような大規模で高速コンテンツアドレス指定可能なメモリの必要性を減らすか、他の同様の最適化を提供する可能性があります。
TRILL solutions are intended to have no impact on the Internet network layer architecture. In particular, the Internet and higher layer headers should remain intact when traversing a deployed TRILL solution, just as they do when traversing any other link subnet technologies. This means that the IP TTL field cannot be co-opted for forwarding loop mitigation, as it would interfere with the Internet layer assuming that the link subnet was reachable with no changes in TTL. (Internet TTLs are changed only at routers, as per RFC 1812, and even if IP TTL were considered, TRILL is expected to support non-IP payloads, and so requires a separate solution anyway [RFC1812]).
Trill Solutionsは、インターネットネットワークレイヤーアーキテクチャに影響を与えないことを目的としています。特に、他のリンクサブネットテクノロジーを横断するときと同じように、展開されたTrillソリューションを横断するときは、インターネットおよび高層ヘッダーはそのままのままです。これは、IP TTLフィールドを、リンクサブネットがTTLに変更されずに到達可能であると仮定してインターネットレイヤーに干渉するため、ループ緩和を転送するために採用できないことを意味します。（インターネットTTLは、RFC 1812に従ってルーターでのみ変更され、IP TTLが考慮されたとしても、Trillは非IPペイロードをサポートすると予想されるため、とにかく別のソリューションが必要です[RFC1812]）。
TRILL solutions should also have no impact on Internet routing or signaling, which also means that broadcast and multicast, both of which can pervade an entire Ethernet link subnet, must be able to transparently pervade a deployed TRILL solution. Changing how either of these capabilities behaves would have significant effects on a variety of protocols, including RIP (broadcast), RIPv2 (multicast), ARP (broadcast), IPv6 neighbor discovery (multicast), etc.
Trillソリューションは、インターネットルーティングやシグナリングにも影響を与えない必要があります。これは、どちらもイーサネットリンクサブネット全体に拡大できるブロードキャストとマルチキャストが、展開されたTrillソリューションに透過的に拡大できる必要があることを意味します。これらの機能のいずれかがどのように動作するかを変更すると、RIP（ブロードキャスト）、RIPV2（マルチキャスト）、ARP（ブロードキャスト）、IPv6ネイバーディスカバリー（マルチキャスト）など、さまざまなプロトコルに大きな影響があります。
Note that snooping of network-layer packets may be useful, especially for certain optimizations. These include snooping multicast control-plane packets (IGMP) to tune link multicast to match the network multicast topology, as is already done in existing smart switches [RFC3376] [RFC4286]. This also includes snooping IPv6 neighbor discovery messages to assist with governing TRILL solution edge configuration, as is the case in some smart learning bridges [RFC4861]. Other layers may similarly be snooped, notably ARP packets, for similar reasons as for IPv4 [RFC826].
特に特定の最適化には、ネットワーク層パケットのスヌーピングが役立つ場合があることに注意してください。これらには、既存のスマートスイッチ[RFC3376] [RFC4286]で既に行われているように、ネットワークマルチキャストトポロジに一致するようにマルチキャストをリンクするようにチューニングするスヌーピングマルチキャストコントロールプレーンパケット（IGMP）が含まれます。これには、いくつかのスマートラーニングブリッジ[RFC4861]の場合のように、Trill Solution Edgeの管理を支援するためのIPv6 Neightre Discoveryメッセージをスヌーピングすることも含まれます。IPv4 [RFC826]と同様の理由により、同様に他の層がスヌープ、特にARPパケットがスヌーピングされる場合があります。
As might be expected, TRILL solutions are intended to be used to solve the problems described in Section 2. However, not all such installations are appropriate environments for such solutions. This section outlines the issues in the appropriate use of these solutions.
予想されるように、Trill Solutionsはセクション2で説明されている問題を解決するために使用することを目的としています。ただし、そのようなインストールはすべて、そのようなソリューションに適した環境であるわけではありません。このセクションでは、これらのソリューションを適切に使用する問題の概要を説明します。
TRILL solutions are intended to address problems of path efficiency and concentration, inability to multipath, and path stability within a single Ethernet link subnet. Like bridges, individual TRILL solution components may find other TRILL solution components within a single Ethernet link subnet and aggregate into a single TRILL solution.
Trillソリューションは、パスの効率と集中力、マルチパスの不能、単一のイーサネットリンクサブネット内のパス安定性の問題に対処することを目的としています。ブリッジと同様に、個々のTrillソリューションコンポーネントは、単一のイーサネットリンクサブネット内の他のTrillソリューションコンポーネントを見つけることができ、単一のTrillソリューションに集約されます。
TRILL solutions are not intended to span separate Ethernet link subnets interconnected by network-layer (e.g., router) devices, except via link-layer tunnels, where such tunnels render the distinct subnet undetectably equivalent from a single Ethernet link subnet.
TRILLソリューションは、ネットワーク層（例えば、ルーター）デバイスによって相互接続された個別のイーサネットリンクサブネットにまたがることを目的としていません。このようなトンネルは、単一のイーサネットリンクサブネットとは異なるサブネットを検出不要に同等にレンダリングします。
A currently open question is whether a single Ethernet link subnet should contain components of only one TRILL solution, either of necessity of architecture or utility. Multiple TRILL solutions, like Internet ASes, may allow TRILL routing protocols to be partitioned in ways that help their stability, but this may come at the price of needing the TRILL solutions to participate more fully as nodes (each modeling a bridge) in the Ethernet link subnet STP. Each architecture solution should decide whether multiple TRILL solutions are supported within a single Ethernet link subnet, and mechanisms should be included to enforce whatever decision is made.
現在未解決の質問は、単一のイーサネットリンクサブネットに、アーキテクチャまたはユーティリティの必要性のいずれかのTrillソリューションのみのコンポーネントを含める必要があるかどうかです。インターネットASESなどの複数のTrillソリューションにより、Trillルーティングプロトコルを安定性に役立つ方法で分割できる場合がありますが、これはトリルソリューションがイーサネットのノード（各ブリッジのモデリング）としてより完全に参加する必要がある価格で提供される場合があります。リンクSubnet STP。各アーキテクチャソリューションでは、単一のイーサネットリンクサブネット内で複数のTrillソリューションがサポートされているかどうかを決定する必要があり、決定があらゆる決定を強制するためにメカニズムを含める必要があります。
TRILL solutions need not address scalability limitations in bridged subnets. Although there may be scale benefits of other aspects of solving TRILL problems, e.g., of using network-layer routing to provide stability under link changes or intermittent outages, this is not a focus of this work.
TRILLソリューションは、ブリッジ付きサブネットのスケーラビリティの制限に対処する必要はありません。Trillの問題を解決する他の側面には、ネットワーク層ルーティングを使用してリンクの変更または断続的な停止下で安定性を提供することの他の側面の規模の利点があるかもしれませんが、これはこの作業の焦点ではありません。
As also noted earlier, TRILL solutions are not intended to address security vulnerabilities in either the data plane or control plane of the link layer. This means that TRILL solutions should not limit broadcast frames, ARP requests, or spanning tree protocol messages (if such are interpreted by the TRILL solution or solution edge).
前述のように、Trill Solutionsは、リンク層のデータプレーンまたはコントロールプレーンのいずれにおいてもセキュリティの脆弱性に対処することを意図していません。これは、Trillソリューションがブロードキャストフレーム、ARPリクエスト、またはスパニングツリープロトコルメッセージを制限すべきではないことを意味します（Trillソリューションまたはソリューションエッジによって解釈される場合）。
TRILL solutions should not introduce new vulnerabilities compared to traditional bridged subnets.
Trill Solutionsは、従来のブリッジ付きサブネットと比較して、新しい脆弱性を導入すべきではありません。
TRILL solutions are not intended to be a solution to Ethernet link subnet vulnerabilities, including spoofing, flooding, snooping, and attacks on the link control plane (STP, flooding the learning cache) and link-network control plane (ARP). Although TRILL solutions are intended to provide more stable routing than STP, this stability is limited to performance, and the subsequent robustness is intended to address non-malicious events.
Trill Solutionsは、リンク制御プレーン（STP、学習キャッシュの洪水）およびリンクネットワーク制御プレーン（ARP）のスプーフィング、洪水、スヌーピング、攻撃など、イーサネットリンクサブネットの脆弱性のソリューションではありません。Trill SolutionsはSTPよりも安定したルーティングを提供することを目的としていますが、この安定性はパフォーマンスに限定されており、その後の堅牢性は非悪質なイベントに対処することを目的としています。
There may be some side-effects to the use of TRILL solutions that can provide more robust operation under certain attacks, such as those interrupting or adding link service, but TRILL solutions should not be relied upon for such capabilities.
リンクサービスを中断したり追加したりするなど、特定の攻撃の下でより堅牢な操作を提供できるTrillソリューションの使用には、いくつかの副作用があるかもしれませんが、Trill Solutionsはそのような機能に依存するべきではありません。
Finally, TRILL solutions should not interfere with other protocols intended to address these vulnerabilities, such as those to secure IPv6 neighbor discovery [RFC3971].
最後に、Trillソリューションは、IPv6 Neighbor Discovery [RFC3971]を保護するようなこれらの脆弱性に対処することを目的とした他のプロトコルと干渉すべきではありません。
Portions of this document are based on documents that describe a preliminary solution, and on a related network-layer solution [Pe04] [Pe05] [To03]. Donald Eastlake III provided substantial text and comments. Additional comments and feedback were provided by the members of the IETF TRILL WG, in which this document was developed, and by the IESG.
このドキュメントの一部は、予備的なソリューションを説明するドキュメント、および関連するネットワーク層ソリューション[PE04] [PE05] [TO03]に基づいています。Donald Eastlake IIIは、実質的なテキストとコメントを提供しました。追加のコメントとフィードバックは、このドキュメントが開発されたIETF Trill WGのメンバーとIESGによって提供されました。
This document was prepared using 2-Word-v2.0.template.dot.
このドキュメントは、2ワード-V2.0.template.dotを使用して準備されました。
[IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and metropolitan area networks: Media Access Control (MAC) Bridges", (incorporates 802.1w), Jun. 2004.
[IEEE04] IEEE 802.1Dブリッジングスタンダード、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：メディアアクセス制御（MAC）ブリッジ」、（802.1Wを組み込んでいます）、2004年6月。
[IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and metropolitan area networks: Virtual Bridged Local Area Networks", (incorporates 802.1v and 802.1s), May 2006.
[IEEE06] IEEE 802.1Q VLAN Standard、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：仮想ブリッジ付きローカルエリアネットワーク」、2006年5月。
[Me04] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service Model: Scaling Ethernet to a Million Nodes", Proc. ACM Third Workshop on Hot Topics in Networks (HotNets-III), Mar. 2004.
[Me04] Myers、A.、T.E。Ng、H。Zhang、「サービスモデルの再考：イーサネットのスケーリングを100万ノードにスケーリングする」、Proc。2004年3月、ネットワークのホットトピック（HotNets-III）に関するACMサードワークショップ。
[Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley, Chapter 3, 1999.
[PE99] Perlman、R。、「相互接続：ブリッジ、ルーター、スイッチ、およびインターネットワーキングプロトコル」、Addison Wesley、1999年章。
[Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, Mar. 2004.
[PE04] Perlman、R。、「Rbridges：透明ルーティング」、Proc。Infocom 2005、2004年3月。
[Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent Routing," (expired work in progress), Apr. 2004 - May 2005.
[PE05] Perlman、R.、J。Touch、A。Yegin、「Rbridges：Transparent Routing」（期限切れの作業）、2004年4月 - 2005年5月。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレス」、STD 37、RFC 826、1982年11月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819] Karn、P.、Ed。、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J。、およびL. Wood、「インターネットサブネットワークデザイナー向けのアドバイス」、BCP 89、RFC 3819、2004年7月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4286] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4286] Rosenberg、J。、「リソースリストを表すための拡張可能なマークアップ言語（XML）形式」、RFC 4826、2007年5月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[To03] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Presented at the Workshop on Future Directions in Network Architecture (FDNA) 2003 at Sigcomm 2003, March 2003.
[To03] Touch、J.、Y。Wang、L。Eggert、G。Finn、「仮想インターネットアーキテクチャ」、ISIテクニカルレポートISI-TR-570、ネットワークアーキテクチャ（FDNA）2003の将来の方向に関するワークショップで発表2003年3月、Sigcomm 2003で。
Authors' Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC/ISI 4676 Admiralty Way Marina Del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
URL: http://www.isi.edu/touch
Radia Perlman Sun Microsystems 16 Network Circle umpk16-161 Menlo Park, CA 94025 U.S.A.
Radia Perlman Sun Microsystems 16 Network Circle Umpk16-161 Menlo Park、CA 94025 U.S.A.
EMail: Radia.Perlman@sun.com