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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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 LANは多くの課題を持っているスパニングツリープロトコルを使用します。これらのプロトコルは理由ヘッダループ検知サポートの欠如のため、ルートの伝播中に、厳密にループを避けるためにも、一時的なものを必要としています。ルーティングは、代替経路、または（スパニングツリーの場合）であっても非重複ペアワイズパスを最大限に活用しない傾向があります。この文書では、これらの懸念に対処し、リンク層で現代的なネットワーク層のルーティングプロトコルを適用する示唆しています。この文書では、ソリューションは、既存の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.
従来のEthernetネットワーク - イーサネットリンクサブネット、インターネットで知られている - ホスト及びルータがリナンバリングを必要とし、自動構成をサポートすることなく、サブネット内再配置することができ、多くの魅力的な特徴を有しています。これらのサブネットの単純さの基本はシンプルかつエレガントなものの、かなりの制限を持つことができ、スパニングツリー、です。重畳された木の数が少ない上に、プロトコルおよび重要な追加構成の最新バージョンで、または - トラフィックが単一のツリーを構成するリンクのサブセット上を流れるため、スパニングツリーと、サブネットを横切る帯域幅が制限されています。頻繁にトポロジの変更がある場合、スパニングツリープロトコルの最も古いバージョンでは、ゆっくりと収束させることができます。
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.
Ethernetリンクサブネットへの代替は、多くの場合、ネットワークサブネットです。ネットワークサブネットトラフィックがかなり高い総容量および障害をリンクするより抵抗を提供する、スパニングツリーバックボーンに集約されるよりも最小コストの経路を横断することを可能にするリンクステートルーティングプロトコルを使用することができます。残念ながら、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」から進化しました。各レベルは、トポロジ制限を対応しています。シンとハブ接続ツイストペアツリーとして配線されなければならないのに対し、thicknetは、本質的に線形です。スイッチは、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での追加は少しのに役立ちますが、複数のスパニングツリーの使用は、追加の設定が必要になり、木の数は限られており、これらの欠陥は関係なく、それぞれの木の中に適用されます。スパニングツリープロトコルが使用されているリンクの再構成に大きな影響を持つ特定の小さなトポロジの変更に反応します。スパニングツリープロトコルのこれらの側面のそれぞれには、現在のリンク層の展開のための問題を引き起こす可能性があります。
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に示すネットワークを考えます。エンドホストとルータが示されていません。彼らは、示さ-Hのラベルが付いてブリッジに接続します。示したネットワークは、ハブ（リピータ）もしパケットストームを引き起こすサイクルを有するスパニングツリー対応ブリッジの代わりに使用したことに留意されたいです。一つの可能なスパニングツリーは、二重線で示されています。
[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であることを前提としています。 C上のホストへのホストからのトラフィックは、スパニングツリー経路A-B-H-E-C（図中「1」で置換リンク）を介してどのようになる。図2に示します。 FとG上のホストからのトラフィックは、スパニング3つのパスG-H-E-F（図では「2」に置き換えリンク）を経由して行きます。リンクH-Eは、100Mbpsでの合計の両方A..CとG..Fパスの総容量をもたらす、（交互「1 '及び」2の）両方のパスによって共有されます。
[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
GからFへのトラフィックは完全なルーティングを使用して直接移動した場合、例えば、G-Fから、両方のパスは、100Mbpsのそれぞれを有することができ、総総容量は200 Mbpsの（図3）であってもよいです。この場合は、
H-F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is more direct.
H-Fリンクは、より直接的である '（2の）が（1とG-Fトラフィックのみ-Cトラフィック'）を運びます。
[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.
がレイヤ2で利用可能な場合に有益であろう近代的なレイヤ3ルーティングプロトコルの特徴の数であるが、これは実質的に、以下のセクション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.)
上記の議論は、別の点から流れるすべてのトラフィックが単一の経路に従うことを前提としています。近代的なルーティングは、このような経路は、コストメトリックに基づいて選択させながら、スパニングツリーを使用して、一本の木の上にすべてのそのような経路を強制することによって、集約帯域幅を減少させます。しかし、現代のルーティングプロトコルへの拡張が別のエンドポイントから流れるトラフィックを許可することにより、さらに大きな総帯域幅を有効にすることは、典型的に等価コスト、複数のパスを介して送信されます。 （トラフィックは一般に、異なる遅延が発生し、別のパス上のトラフィックに対して並べ替えてもよい異なる経路を介して送信される。これにより、トラフィックが流れる間のトラフィックの並べ替えが重要でないように、流れに分割する必要があり、それらのフローは、パスに割り当てられています。）
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つは、ネットワーク再コンバージェンス[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がルートブリッジである場合にD-> Eリンクがブロックされている間は、A-> B-> C-> DとA-> F-> G-> Eパスは、二つの開放経路です。 A-> Bのリンクが失敗した場合、Eが再び流れるようにトラフィックのためのDへのポートのブロックを解除する必要があり、それにより、BPDU（ブリッジのPDU）を介して、ツリー全体の再計算が必要な場合があります。 Rは、ルートおよびRであるか、AR接続が失敗した場合、さらに悪いことに、古いものと新しいルートに関連する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マルチキャストデータの配信を最適化すると、これらの制御メッセージ[RFC4541]のためにIPマルチキャスト制御メッセージをスヌープすることが一般的です。
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 - 添加ブリッジ（すなわち、スイッチ）と、スパニングツリープロトコル（STP）[IEEE04]（以下、802.1ワットを組み込みます）。
o 802.1w - extension for rapid reconvergence of the spanning tree protocol (RTSP) [IEEE04].
O 802.1ワット - スパニングツリープロトコル（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は、 - 1つのVLANに各リンクアドレスマップVLANと優先サポートを追加[IEEE06]（以下、802.1vと802.1sのを組み込みます）。
o 802.1v - added VLANs where segments map to VLANs based on link address together with network protocol and transport port [IEEE06].
セグメントは、ネットワークプロトコルおよびトランスポートポート[IEEE06]と一緒にリンクアドレスに基づいてVLANにマッピングする追加のVLAN - 802.1v O。
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].
802.1sのO - [IEEE06]、最大65の最大まで、VLANの非重複群（複数のSTP）ごとに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.
この文書では、TRILL溶液は、上記のいずれかを（すなわち、影響しない）と干渉しないこと、すなわち、上記変異体は、イーサネットサブネット上に支持されている前提。
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.
入出力802.1ad（プロバイダ橋） - VLANタグの第二のレベルのサポートを追加し、「サービスタグ」と呼ばれ、元の802.1Qタグを「顧客タグ」と改名。また、Q-で-Qため、802.1Q VLANタグのスタッキングとして知られています。
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.
入出力802.1ahの（プロバイダバックボーンブリッジ）は、 - 元の送信元および宛先MACアドレスを格納するタグを提供することにより、MACアドレスのスタッキングのためのサポートを追加しました。また、MAC・イン・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.
TRILLの焦点である - このセクションでは、上記の拡張子は、単一のLANで独立した、ローカライズされたルーティングの問題に対処していないことに注意することは有益です。
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.
TRILL問題と可能な解決策[PE04]のスケッチは、（IEEE 802総会チュートリアルを介して）（このBoFを介して）IETFおよびIEEE 802の両方に提示されました。 IEEEは、応答して、[PE04]で提示されるものとは異なるアプローチを取って、（IEEEプロジェクトP802.1aqを）埋める最短経路と呼ばれるプロジェクトを承認しました。 P802.1aqの現在のドラフトは、二つの異なる技術を記述するために表示されます。カプセル化を使用しないものは、せいぜい100の最短経路ブリッジの小さなネットワークに適用性に制限IEEEドラフトによれば、あります。 802.1ahのを使用する、他のない1,000以上の最短パスブリッジのネットワークへの適用に限定されるものでIEEEドラフトによれば、あります。
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:
解決策は、TRILLの問題に加えて、これらの一つ以上に対処することが可能であるが、関連するIEEE 802.1文書に言及し、いくつかのケースでは、以外本書で扱われていないイーサネットサブネットを展開する他の課題があります。これらは、次のとおりです。
o increased Ethernet link subnet scale
Oの増加イーサネットリンクサブネットスケール
o increased node relocation
Oの増加ノードの再配置
o security of the Ethernet link subnet management protocol
Ethernetリンクサブネット管理プロトコルのOのセキュリティ
o flooding attacks on a Ethernet link subnet
Ethernetリンクサブネット上の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)
こうしたプロバイダブリッジ（802.1ad）、プロバイダ・バックボーン・ブリッジ（802.1ahの）、またはプロバイダー・バックボーン・ブリッジトラフィックエンジニアリング（802.1Qay）として、「プロバイダ」サービスのためのOサポート
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橋、または千個のVLAN内の10万エンドホストの単一ブリッジLAN内の約1,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）で存在します。再度、ネットワーク層自律システム（のAS）のようなネットワーク・ルーティングで使用可能な区画は、マイグレーションの影響を隠すことができます。すなわち、この研究の主な焦点が、副作用であり、かつありません。
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).
Ethernetリンクサブネット管理（スパニングツリー）とリンク/ネットワーク統合（ARP）を含む現在のリンク層制御プレーンプロトコルは、攻撃の様々な脆弱です。 TRILLのソリューションは、これらの不安に対処する必要はありません。同様の攻撃は、データ・プレーン、例えば、送信元アドレススプーフィング、単一のアドレストラフィック攻撃、トラフィックスヌーピング、およびブロードキャスト洪水に存在します。彼らがプロセス（第5節を参照）で、新たな脆弱性を導入しないことが重要であるが、TRILLのソリューションは、これらの問題のいずれかに対処する必要はありません。
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]ですでにサポートを保持することは有用であろう。いわゆる「ゼロ設定プロトコル」（また、「ゼロ設定」として知られているが、例えば、リンクローカルアドレス[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.
両方のブリッジとハブは、ゼロコンフィギュレーション・デバイスです。全くの構成を有していないハブ、ブリッジは自動的に自己構成されています。ブリッジはハブとは異なり、さらにゼロ仮定のデバイスです。ブリッジは、サイクルあるいは自己取付けに関係なく、任意のトポロジで相互接続することができます。スパニングツリープロトコルは（のSTP）は、自動的にサイクルの影響を除去し、そしてポート自動学習は、ユニキャストトラフィックの不要なブロードキャストを減少させます。
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.
自動設定は、インターネットグループ管理プロトコル（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.
インターネットでは、ループの緩和は、ホップ数に（生存時間（TTL））をデクリメントすることによって提供されます。他のネットワークでは、パケットが訪問したノードのトレース（時々「シリアライズ」または「UNION句」という）[RFC1812]を含みます。加えて、そのようなトラフィックをルーティングは流動的であり、そのようなトラフィックはおそらく安全のために廃棄されるべきであることをことを示す予想外のインターフェイス上で受信されたかどうかのように、整合性チェックがローカライズされてもよいです。機構のこれらのタイプは、ループの影響を制限するか、明示的に検出します。同様の効果を持つメカニズムは、TRILLのソリューションに含まれるべきです。
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節）に再構成し、堅牢性の下で収束に対処するためには、スパニングツリー（STP）への参加は慎重に管理しなければなりません。目標は、TRILL溶液とSTPを使用してブリッジを含むことができる全体のEthernetリンクサブネット、所望の安定性を提供することです。これは、TRILLのために使用されるプロトコルは、STPとの相互作用を弱める可能性があり、またはそれは「スタブ」外部イーサネット・リンクサブネットセグメント上の別のSTPにSTPを切断含むことができるSTPに参加TRILL溶液を、含むことができます。
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では、シングルスパニングツリーのセグメントに複数の添付ファイルを持つ単一のノードが常に取得し、それらの接続点の一つ上のトラフィックを送信します。トラフィックを作成しないように、TRILLは、複数のTRILLアタッチメントポイントとイーサネットセグメントを含むループ、マルチキャストおよびブロードキャストトラフィックを含むすべてのトラフィックを、管理しなければなりません。これは、単一の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.1を含む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.
プロバイダーのVLAN（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.
これは、（「X」は、単一のブリッジ、ハブ、またはいくつかの他のリンク層の抽象化であるかもしれない）、すなわち、「我々はXとTRILLソリューションコンポーネントまたはコンポーネントを交換することができれば、我々は右のそれを持って」、健全性チェックを提供します。 「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.
全体として - - STPに参加TRILLソリューションのコンポーネントを単一のIEEE 802.1Dブリッジと同等であった場合たとえば、それは彼らがすることを意味します。これは、TRILLのソリューションコンポーネントは、ブリッジよりも、それ以上は、そのオンボード制御で行う必要がある、STPを伝搬する必要がある必要はありません。再び、全体として - - かのように参加して、スパニングツリー内の1つのノードは、それは解決策がする場所ソリューションは、エッジでのBPDUと相互作用することを意味します。この等価性が必要とされないことに注意してください。溶液は、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のソリューションに適用することができる最適化の数があります。これらは、パフォーマンス向上のためのトレードオフとしての機能には影響を与えない方法で適用されなければなりません。このような最適化は、ブロードキャストおよびマルチキャストフレーム配信、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のソリューションは、インターネットのネットワーク層アーキテクチャに影響を与えないように意図されています。他のリンクサブネット技術を横断するとき、彼らは同じように、展開TRILLのソリューションを横断するとき、特に、インターネットと上位層ヘッダはそのまま残るはずです。これは、インターネット層は、リンクサブネットがTTLでない変化に到達したことを仮定を妨害するようにIP 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溶液もまた、全体のEthernetリンクサブネットに浸透することができ、どちらもブロードキャストおよびマルチキャストは、透過的に展開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のソリューションのエッジ形状を支配を支援するIPv6近隣探索メッセージをスヌーピング含まれています。他の層は、同様の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のソリューションは、しかし、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のソリューションは、単一のEthernetリンクサブネット内経路の効率及び濃度、マルチパスにできないこと、および経路安定性の問題に対処することを意図しています。ブリッジのように、個々のTRILLソリューションコンポーネントは、単一のTRILL溶液に単一のEthernetリンクサブネットおよび集約内の他の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のソリューションは、このようなトンネルが単一のEthernetリンクサブネットから検出できない同等の別個のサブネットをレンダリングリンク層トンネルを介して以外、ネットワーク層（例えば、ルータ）装置によって相互接続別個イーサネットリンクサブネットに及ぶように意図されていません。
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.
現在開いている質問は、単一のEthernetリンクサブネットが一つだけTRILLソリューションのコンポーネント、アーキテクチャやユーティリティの必要性のいずれかが含まれている必要があるかどうかです。インターネットのASのような複数のTRILLのソリューションは、TRILLルーティングプロトコルは、その安定性を助ける方法で分割することを可能にすることができるが、これはイーサネットで（それぞれが橋をモデル化）ノードとして、より完全に参加するTRILLのソリューションを必要とする価格で来るかもしれませんリンクサブネットSTP。各アーキテクチャソリューションは、複数のTRILLのソリューションは、単一のEthernetリンクサブネット内でサポートされており、仕組みが作られているものは何でも決定強制するために含めるべきかどうかを決定する必要があります。
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のソリューションは、リンク層のデータ・プレーン又は制御プレーンのいずれかで、セキュリティの脆弱性に対処するものではありません。これは、（例えば、TRILLが溶液または溶液エッジによって解釈される場合）TRILLソリューションは、ブロードキャストフレーム、ARP要求、またはスパニングツリープロトコルメッセージを制限するものではないことを意味します。
TRILL solutions should not introduce new vulnerabilities compared to traditional bridged subnets.
TRILLのソリューションは、従来のブリッジのサブネットに比べて、新たな脆弱性を導入してはなりません。
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のソリューションは、およびリンクネットワーク制御プレーン（ARP）（学習キャッシュをフラッディング、STP）なりすまし、洪水、スヌーピング、およびリンク制御プレーンへの攻撃など、Ethernetリンクサブネットの脆弱性、解決策を示すものではありません。 TRILLのソリューションは、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のソリューションを使用するにはいくつかの副作用があるかもしれません。
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近隣探索[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.
この文書の部分は、[TO03]予備溶液を記述文書に基づいて、および関連するネットワーク層溶液[PE04] [Pe05]にしています。ドナルドイーストレイクIIIはかなりのテキストやコメントを提供しました。追加のコメントやフィードバックは、この文書が開発されたIETF TRILL WGのメンバーによる、およびIESGによって提供されました。
This document was prepared using 2-Word-v2.0.template.dot.
この文書は2-Word-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.1ワットを組み込んだ）、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標準、「ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格：仮想ブリッジローカルエリアネットワーク」、（802.1vおよび802.1を組み込んだ）、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]マイヤーズ、A.、T.E.ン、H.チャン、「サービスモデルの再考：百万のノードへのスケーリングイーサネット」、PROC。ネットワークのホットな話題にACMサードワークショップ（HotNets-III）、2004年3月。
[Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley, Chapter 3, 1999.
[Pe99]パールマン、R.、 "相互接続：ブリッジ、ルータ、スイッチ、およびインターネットワーキングプロトコル"、アディソンウェズリー、第3章、1999。
[Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, Mar. 2004.
[PE04]パールマン、R.、 "RBridges：透明ルーティング"、PROC。インフォコム2005年、2004年3月。
[Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent Routing," (expired work in progress), Apr. 2004 - May 2005.
[Pe05]パールマン、R.、J.タッチ、A. Yegin、 "RBridges：透過的なルーティング、"（進行中の期限切れの仕事）、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]プラマー、D.、：、STD 37、RFC 826、1982年11月「イーサネットアドレス解決プロトコルやネットワーク・プロトコルを変換するには、イーサネットハードウェア上での伝送のためのイーサネットアドレスを48ビットにIPアドレス」。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、エド。、 "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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]カーン、P.編、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、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]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、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.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4286] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4286]ローゼンバーグ、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]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[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.、シンプソン、W.、およびH.ソリマン、 "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]タッチ、J.、Y.王、L.エッゲルト、G.フィン、 "仮想インターネット・アーキテクチャ"、ISIテクニカルレポートISI-TR-570ネットワークアーキテクチャ（FDNA）での今後の方向性に関するワークショップで発表され、2003年SIGCOMM 2003、2003年3月で。
Authors' Addresses
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
ジョー・タッチUSC / ISI 4676アドミラルティWayマリナデルレイ、カリフォルニア州90292から6695 U.S.A.
Phone: +1 (310) 448-9151 EMail: touch@isi.edu URL: http://www.isi.edu/touch
電話：+1（310）448-9151 Eメール：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.
ラディア・パールマンSun Microsystemsの16ネットワークサークルumpk16-161メンロパーク、CA 94025 U.S.A.
EMail: Radia.Perlman@sun.com
メールアドレス：Radia.Perlman@sun.com