[要約] RFC 6325は、RBridgesの基本プロトコル仕様を定義しており、Ethernetネットワークでのルーティングブリッジの動作を改善することを目的としています。
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 6325 Intel Labs
Category: Standards Track D. Eastlake 3rd
ISSN: 2070-1721 Huawei
D. Dutt
S. Gai
Cisco Systems
A. Ghanwani
Brocade
July 2011
Routing Bridges (RBridges): Base Protocol Specification
ルーティングブリッジ（RBridges）：基本プロトコル仕様
Abstract
概要
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.
ルーティングブリッジ（RBridges）は、構成なしで最適なペアワイズ転送を提供し、一時的なループの期間中も安全に転送し、ユニキャストとマルチキャストの両方のトラフィックのマルチパスをサポートします。 IS-ISルーティングと、ホップカウントを含むヘッダーを持つトラフィックのカプセル化を使用して、これらの目標を達成します。
RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.
RBridgeは、以前のIEEE 802.1カスタマーブリッジ、IPv4およびIPv6ルーター、エンドノードと互換性があります。これらは、ブリッジと同様に現在のIPルーターからは見えず、ルーターと同様に、ブリッジスパニングツリープロトコルを終端します。
The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges.
この設計は、VLANと、VLAN IDおよびIP派生マルチキャストグループに基づく複数の宛先フレームの配信の最適化をサポートしています。また、トランジットRBridgeのユニキャスト転送テーブルのサイズを（エンドノードの数ではなく）RBridgeの数に応じて変更できるため、転送テーブルを従来のカスタマーブリッジよりも大幅に小さくできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6325.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6325で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの資料が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Algorhyme V2, by Ray Perlner ...............................7
1.2. Normative Content and Precedence ...........................7
1.3. Terminology and Notation in This Document ..................7
1.4. Categories of Layer 2 Frames ...............................8
1.5. Acronyms ...................................................9
2. RBridges .......................................................11
2.1. General Overview ..........................................11
2.2. End-Station Addresses .....................................12
2.3. RBridge Encapsulation Architecture ........................13
2.4. Forwarding Overview .......................................15
2.4.1. Known-Unicast ......................................16
2.4.2. Multi-Destination ..................................16
2.5. RBridges and VLANs ........................................17
2.5.1. Link VLAN Assumptions ..............................17
2.6. RBridges and IEEE 802.1 Bridges ...........................18
2.6.1. RBridge Ports and 802.1 Layering ...................18
2.6.2. Incremental Deployment .............................20
3. Details of the TRILL Header ....................................20
3.1. TRILL Header Format .......................................20
3.2. Version (V) ...............................................21
3.3. Reserved (R) ..............................................21
3.4. Multi-destination (M) .....................................22
3.5. Op-Length .................................................22
3.6. Hop Count .................................................22
3.7. RBridge Nicknames .........................................23
3.7.1. Egress RBridge Nickname ............................23
3.7.2. Ingress RBridge Nickname ...........................24
3.7.3. RBridge Nickname Selection .........................24
3.8. TRILL Header Options ......................................26
4. Other RBridge Design Details ...................................27
4.1. Ethernet Data Encapsulation ...............................27
4.1.1. VLAN Tag Information ...............................30
4.1.2. Inner VLAN Tag .....................................31
4.1.3. Outer VLAN Tag .....................................31
4.1.4. Frame Check Sequence (FCS) .........................32
4.2. Link State Protocol (IS-IS) ...............................32
4.2.1. IS-IS RBridge Identity .............................32
4.2.2. IS-IS Instances ....................................33
4.2.3. TRILL IS-IS Frames .................................33
4.2.4. TRILL Link Hellos, DRBs, and Appointed Forwarders ..34
4.2.4.1. P2P Hello Links ...........................35
4.2.4.2. Designated RBridge ........................35
4.2.4.3. Appointed VLAN-x Forwarder ................36
4.2.4.4. TRILL LSP Information .....................37
4.2.5. The TRILL ESADI Protocol ...........................40
4.2.5.1. TRILL ESADI Participation .................42
4.2.5.2. TRILL ESADI Information ...................42
4.2.6. SPF, Forwarding, and Ambiguous Destinations ........43
4.3. Inter-RBridge Link MTU Size ...............................43
4.3.1. Determining Campus-Wide TRILL IS-IS MTU Size .......44
4.3.2. Testing Link MTU Size ..............................44
4.4. TRILL-Hello Protocol ......................................45
4.4.1. TRILL-Hello Rationale ..............................45
4.4.2. TRILL-Hello Contents and Timing ....................46
4.4.2.1. TRILL Neighbor List .......................48
4.4.3. TRILL MTU-Probe and TRILL Hello VLAN Tagging .......49
4.4.4. Multiple Ports on the Same Link ....................50
4.4.5. VLAN Mapping within a Link .........................51
4.5. Distribution Trees ........................................52
4.5.1. Distribution Tree Calculation ......................54
4.5.2. Multi-Destination Frame Checks .....................55
4.5.3. Pruning the Distribution Tree ......................57
4.5.4. Tree Distribution Optimization .....................58
4.5.5. Forwarding Using a Distribution Tree ...............59
4.6. Frame Processing Behavior .................................60
4.6.1. Receipt of a Native Frame ..........................60
4.6.1.1. Native Unicast Case .......................60
4.6.1.2. Native Multicast and Broadcast Frames .....61
4.6.2. Receipt of a TRILL Frame ...........................62
4.6.2.1. TRILL Control Frames ......................63
4.6.2.2. TRILL ESADI Frames ........................63
4.6.2.3. TRILL Data Frames .........................63
4.6.2.4. Known Unicast TRILL Data Frames ...........63
4.6.2.5. Multi-Destination TRILL Data Frames .......64
4.6.3. Receipt of a Layer 2 Control Frame .................65
4.7. IGMP, MLD, and MRD Learning ...............................66
4.8. End-Station Address Details ...............................66
4.8.1. Learning End-Station Addresses .....................67
4.8.2. Learning Confidence Level Rationale ................68
4.8.3. Forgetting End-Station Addresses ...................69
4.8.4. Shared VLAN Learning ...............................70
4.9. RBridge Ports .............................................71
4.9.1. RBridge Port Configuration .........................71
4.9.2. RBridge Port Structure .............................73
4.9.3. BPDU Handling ......................................76
4.9.3.1. Receipt of BPDUs ..........................76
4.9.3.2. Root Bridge Changes .......................76
4.9.3.3. Transmission of BPDUs .....................77
4.9.4. Dynamic VLAN Registration ..........................77
5. RBridge Parameters .............................................77
5.1. Per RBridge ...............................................78
5.2. Per Nickname Per RBridge ..................................79
5.3. Per Port Per RBridge ......................................79
5.4. Per VLAN Per RBridge ......................................80
6. Security Considerations ........................................80
6.1. VLAN Security Considerations ..............................81
6.2. BPDU/Hello Denial-of-Service Considerations ...............82
7. Assignment Considerations ......................................82
7.1. IANA Considerations .......................................83
7.2. IEEE Registration Authority Considerations ................83
8. Normative References ...........................................83
9. Informative References .........................................85
Appendix A. Incremental Deployment Considerations .................87
A.1. Link Cost Determination ...................................87
A.2. Appointed Forwarders and Bridged LANs .....................87
A.3. Wiring Closet Topology ....................................89
A.3.1. The RBridge Solution ...............................90
A.3.2. The VLAN Solution ..................................90
A.3.3. The Spanning Tree Solution .........................90
A.3.4. Comparison of Solutions ............................91
Appendix B. Trunk and Access Port Configuration ...................92
Appendix C. Multipathing ..........................................92
Appendix D. Determination of VLAN and Priority ....................95
Appendix E. Support of IEEE 802.1Q-2005 Amendments ................95
E.1. Completed Amendments ......................................96
E.2. In-Process Amendments .....................................97
Appendix F. Acknowledgements ......................................98
Table of Figures
図表
Figure 1: Interconnected RBridges .................................14
Figure 2: An Ethernet Encapsulated TRILL Frame ....................14
Figure 3: A PPP Encapsulated TRILL Frame ..........................14
Figure 4: RBridge Port Model ......................................19
Figure 5: TRILL Header ............................................21
Figure 6: Options Area Initial Flags Octet ........................26
Figure 7: TRILL Data Encapsulation over Ethernet ..................29
Figure 8: VLAN Tag Information ....................................30
Figure 9: TRILL IS-IS Frame Format ................................34
Figure 10: TRILL ESADI Frame Format ...............................41
Figure 11: Detailed RBridge Port Model ............................74
Figure 12: Link Cost of a Bridged Link ............................87
Figure 13: Wiring Closet Topology .................................89
Figure 14: Multi-Destination Multipath ............................93
Figure 15: Known Unicast Multipath ................................94
In traditional IPv4 and IPv6 networks, each subnet has a unique prefix. Therefore, a node in multiple subnets has multiple IP addresses, typically one per interface. This also means that when an interface moves from one subnet to another, it changes its IP address. Administration of IP networks is complicated because IP routers require per-port subnet address configuration. Careful IP address management is required to avoid creating subnets that are sparsely populated, wasting addresses.
従来のIPv4およびIPv6ネットワークでは、各サブネットに一意のプレフィックスがあります。したがって、複数のサブネット内のノードには複数のIPアドレスがあり、通常はインターフェイスごとに1つです。これは、インターフェイスがあるサブネットから別のサブネットに移動すると、IPアドレスが変更されることも意味します。 IPルーターはポートごとのサブネットアドレス構成を必要とするため、IPネットワークの管理は複雑です。人口がまばらでアドレスを浪費しているサブネットを作成しないようにするには、慎重なIPアドレス管理が必要です。
IEEE 802.1 bridges avoid these problems by transparently gluing many physical links into what appears to IP to be a single LAN [802.1D]. However, 802.1 bridge forwarding using the spanning tree protocol has some disadvantages:
IEEE 802.1ブリッジは、IPから単一のLANのように見えるものに多くの物理リンクを透過的に接着することにより、これらの問題を回避します[802.1D]。ただし、スパニングツリープロトコルを使用した802.1ブリッジ転送には、いくつかの欠点があります。
o The spanning tree protocol works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links.
o スパニングツリープロトコルは、ポートをブロックし、転送リンクの数を制限することで機能するため、選択したリンクにトラフィックを集中させることによってボトルネックを作成します。
o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths.
o 転送はペア単位の最短パスではなく、スパニングツリーが冗長パスを排除した後に残っているパスです。
o The Ethernet header does not contain a hop count (or Time to Live (TTL)) field. This is dangerous when there are temporary loops such as when spanning tree messages are lost or components such as repeaters are added.
o イーサネットヘッダーには、ホップカウント（または存続時間（TTL））フィールドが含まれていません。これは、スパニングツリーメッセージが失われた場合やリピーターなどのコンポーネントが追加された場合など、一時的なループがある場合に危険です。
o VLANs can partition when the spanning tree reconfigures.
o VLANは、スパニングツリーが再構成されるときに分割できます。
This document presents the design for RBridges (Routing Bridges [RBridges]) that implement the TRILL protocol and are poetically summarized below. Rbridges combine the advantages of bridges and routers and, as specified in this document, are the application of link state routing to the VLAN-aware customer bridging problem. With the exceptions discussed in this document, RBridges can incrementally replace IEEE [802.1Q-2005] or [802.1D] customer bridges.
このドキュメントでは、TRILLプロトコルを実装するRBridges（ルーティングブリッジ[RBridges]）の設計について説明し、以下に要約します。 Rbridgeは、ブリッジとルーターの利点を組み合わせたものであり、このドキュメントで指定されているように、リンク状態ルーティングをVLAN対応のカスタマーブリッジング問題に適用しています。このドキュメントで説明されている例外を除き、RBridgesは、IEEE [802.1Q-2005]または[802.1D]カスタマーブリッジを段階的に置き換えることができます。
While RBridges can be applied to a variety of link protocols, this specification focuses on IEEE [802.3] links. Use with other link types is expected to be covered in other documents.
RBridgeはさまざまなリンクプロトコルに適用できますが、この仕様はIEEE [802.3]リンクに焦点を当てています。他のリンクタイプでの使用は、他のドキュメントでカバーされることが期待されています。
The TRILL protocol, as specified herein, is designed to be a Local Area Network protocol and not designed with the goal of scaling beyond the size of existing bridged LANs. For further discussion of the problem domain addressed by RBridges, see [RFC5556].
ここで指定されているTRILLプロトコルは、ローカルエリアネットワークプロトコルとして設計されており、既存のブリッジLANのサイズを超えてスケーリングすることを目的として設計されていません。 RBridgesで対処される問題ドメインの詳細については、[RFC5556]を参照してください。
I hope that we shall one day see A graph more lovely than a tree.
いつか木よりも素敵なグラフを見たいと思います。
A graph to boost efficiency While still configuration-free.
設定不要で効率を向上させるグラフ。
A network where RBridges can Route packets to their target LAN.
RBridgeがパケットをターゲットLANにルーティングできるネットワーク。
The paths they find, to our elation, Are least cost paths to destination!
彼らが見つけた私たちの喜びへの道は、目的地への最小コストの道です！
With packet hop counts we now see, The network need not be loop-free!
パケットホップ数が表示されるので、ネットワークがループフリーである必要はありません。
RBridges work transparently, Without a common spanning tree.
RBridgeは、共通のスパニングツリーなしで透過的に機能します。
The bulk of the normative material in this specification appears in Sections 1 through 4. In case of conflict between provisions in these four sections, the provision in the higher numbered section prevails.
この仕様の規範的な資料の大部分は、セクション1〜4に記載されています。これらの4つのセクションの規定が矛盾する場合は、番号の大きいセクションの規定が優先されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
"TRILL" is the protocol specified herein while an "RBridge" is a device that implements that protocol. The second letter in Rbridge is case insensitive. Both Rbridge and RBridge are correct.
「TRILL」はここで指定されたプロトコルですが、「RBridge」はそのプロトコルを実装するデバイスです。 Rbridgeの2番目の文字は大文字と小文字を区別しません。 RbridgeとRBridgeの両方が正しいです。
In this document, the term "link", unless otherwise qualified, means "bridged LAN", that is to say, the combination of one or more [802.3] links with zero or more bridges, hubs, repeaters, or the like. The term "simple link" or the like is used indicate a point-to-point or multi-access link with no included bridges or RBridges.
このドキュメントでは、「リンク」という用語は、特に断りのない限り、「ブリッジLAN」、つまり1つ以上の[802.3]リンクと0個以上のブリッジ、ハブ、リピーターなどの組み合わせを意味します。 「単純リンク」などの用語は、ブリッジやRBridgeを含まないポイントツーポイントリンクまたはマルチアクセスリンクを示します。
In this document, the term "port", unless otherwise qualified, includes physical, virtual [802.1AE], and pseudo [802.1X] ports. The term "physical port" or the like is used to indicate the physical point of connection between an RBridge and a link.
このドキュメントでは、特に指定のない限り、「ポート」という用語には、物理ポート、仮想[802.1AE]、および疑似[802.1X]ポートが含まれます。 「物理ポート」などの用語は、RBridgeとリンクの間の物理的な接続ポイントを示すために使用されます。
A "campus" is to RBridges as a "bridged LAN" is to bridges. An RBridge campus consists of a network of RBridges, bridges, hubs, repeaters, simple links, and the like and it is bounded by end stations and routers.
「キャンパス」はRBridgesに対するものであり、「ブリッジされたLAN」はブリッジに対するものです。 RBridgeキャンパスは、RBridge、ブリッジ、ハブ、リピーター、シンプルリンクなどのネットワークで構成され、エンドステーションとルーターによって境界が定められています。
The term "spanning tree" in this document includes both classic spanning tree and rapid spanning tree (as in the Rapid Spanning Tree Protocol).
このドキュメントの「スパニングツリー」という用語には、クラシックスパニングツリーとラピッドスパニングツリーの両方が含まれます（ラピッドスパニングツリープロトコルの場合と同様）。
This document uses hexadecimal notation for MAC addresses. Two hexadecimal digits represent each octet (that is, 8-bit byte), giving the value of the octet as an unsigned integer. A hyphen separates successive octets. This document consistently uses IETF bit ordering, although the physical order of bit transmission within an octet on an IEEE [802.3] link is from the lowest order bit to the highest order bit, the reverse of IETF ordering.
このドキュメントでは、MACアドレスに16進表記を使用しています。 2つの16進数字は各オクテット（つまり、8ビットバイト）を表し、オクテットの値を符号なし整数として提供します。ハイフンは、連続するオクテットを区切ります。 IEEE [802.3]リンク上のオクテット内のビット伝送の物理的な順序は、IETFの順序とは逆に、最低のビットから最高のビットまでですが、このドキュメントでは一貫してIETFのビット順序を使用しています。
In this document, Layer 2 frames are divided into five categories:
このドキュメントでは、レイヤ2フレームは次の5つのカテゴリに分類されています。
o Layer 2 control frames (such as Bridge PDUs (BPDUs)) o native frames (non-TRILL-encapsulated data frames) o TRILL Data frames (TRILL-encapsulated data frames) o TRILL control frames o TRILL other frames
o レイヤー2制御フレーム（Bridge PDU（BPDUなど））oネイティブフレーム（非TRILLカプセル化データフレーム）o TRILLデータフレーム（TRILLカプセル化データフレーム）o TRILL制御フレームo TRILLその他のフレーム
The way these five types of frames are distinguished is as follows:
これら5つのタイプのフレームを区別する方法は次のとおりです。
o Layer 2 control frames are those with a multicast destination address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and forward such frames, though they MAY, unless otherwise specified in this document, perform the Layer 2 function (such as MAC-level security) of the control frame. Frames with a destination address of 01-80-C2-00-00-00 (BPDU) or 01-80-C2-00-00-21 (VLAN Registration Protocol) are called "high-level control frames" in this document. All other Layer 2 control frames are called "low-level control frames".
o レイヤー2制御フレームは、マルチキャスト宛先アドレスが01-80-C2-00-00-00から01-80-C2-00-00-0Fまたは01-80-C2-00-00-に等しいものです。 21。 RBridgeは、このようなフレームをカプセル化して転送してはならない（MUST NOT）。ただし、このドキュメントで特に指定されていない限り、制御フレームのレイヤー2機能（MACレベルのセキュリティなど）を実行する場合があります。このドキュメントでは、宛先アドレスが01-80-C2-00-00-00（BPDU）または01-80-C2-00-00-21（VLAN Registration Protocol）のフレームを「高レベル制御フレーム」と呼びます。他のすべてのレイヤ2コントロールフレームは、「低レベルコントロールフレーム」と呼ばれます。
o Native frames are those that are not control frames and have an Ethertype other than "TRILL" or "L2-IS-IS" and have a destination MAC address that is not one of the 16 multicast addresses reserved for TRILL.
o ネイティブフレームとは、制御フレームではなく、「TRILL」または「L2-IS-IS」以外のEthertypeを持ち、TRILL用に予約されている16のマルチキャストアドレスの1つではない宛先MACアドレスを持つネイティブフレームです。
o TRILL Data frames have the Ethertype "TRILL". In addition, TRILL data frames, if multicast, have the multicast destination MAC address "All-RBridges".
o TRILLデータフレームにはEthertype「TRILL」があります。さらに、TRILLデータフレームは、マルチキャストの場合、マルチキャスト宛先MACアドレス「All-RBridges」を持っています。
o TRILL control frames have the Ethertype "L2-IS-IS". In addition, TRILL control frames, if multicast, have the multicast destination MAC addresses of "All-IS-IS-RBridges". (Note that ESADI frames look on the outside like TRILL data and are so handled but, when decapsulated, have the L2-IS-IS Ethertype.)
o TRILL制御フレームには、Ethertype「L2-IS-IS」があります。さらに、TRILL制御フレームは、マルチキャストの場合、「All-IS-IS-RBridges」のマルチキャスト宛先MACアドレスを持っています。 （ESADIフレームはTRILLデータのように外側を見て処理されるが、カプセル化が解除されると、L2-IS-IS Ethertypeになることに注意してください。）
o TRILL other frames are those with any of the 16 multicast destination addresses reserved for TRILL other than All-RBridges and All-IS-IS-RBridges. RBridges conformant to this specification MUST discard TRILL other frames.
o TRILLのその他のフレームは、All-RBridgesおよびAll-IS-IS-RBridges以外の、TRILL用に予約された16個のマルチキャスト宛先アドレスのいずれかを持つフレームです。この仕様に準拠するRBridgeは、TRILLの他のフレームを破棄する必要があります。
AllL1ISs - All Level 1 Intermediate Systems
AllL1ISs-すべてのレベル1中間システム
AllL2ISs - All Level 2 Intermediate Systems
AllL2ISs-すべてのレベル2中間システム
BPDU - Bridge PDU
BPDU-ブリッジPDU
CHbH - Critical Hop-by-Hop
CHbH-クリティカルホップバイホップ
CItE - Critical Ingress-to-Egress
CItE-重要な上りから下り
CSNP - Complete Sequence Number PDU
CSNP-完全なシーケンス番号PDU
DA - Destination Address
DA-宛先アドレス
DR - Designated Router
DR-指定ルーター
DRB - Designated RBridge
DRB-指定されたRBridge
EAP - Extensible Authentication Protocol
EAP-拡張認証プロトコル
ECMP - Equal Cost Multipath
ECMP-等コストマルチパス
EISS - Extended Internal Sublayer Service
EISS-拡張内部サブレイヤーサービス
ESADI - End-Station Address Distribution Information
ESADI-端末のアドレス配布情報
FCS - Frame Check Sequence
FCS-フレームチェックシーケンス
GARP - Generic Attribute Registration Protocol
GARP-汎用属性登録プロトコル
GVRP - GARP VLAN Registration Protocol
GVRP-GARP VLAN登録プロトコル
IEEE - Institute of Electrical and Electronics Engineers
IEEE-Institute of Electrical and Electronics Engineers
IGMP - Internet Group Management Protocol IP - Internet Protocol
IGMP-インターネットグループ管理プロトコルIP-インターネットプロトコル
IS-IS - Intermediate System to Intermediate System
IS-IS-中間システムから中間システム
ISS - Internal Sublayer Service
ISS-内部サブレイヤーサービス
LAN - Local Area Network
LAN-ローカルエリアネットワーク
LSP - Link State PDU
LSP-リンク状態PDU
MAC - Media Access Control
MAC-メディアアクセスコントロール
MLD - Multicast Listener Discovery
MLD-マルチキャストリスナーの発見
MRD - Multicast Router Discovery
MRD-マルチキャストルーター検出
MTU - Maximum Transmission Unit
MTU-最大転送単位
MVRP - Multiple VLAN Registration Protocol
MVRP-複数のVLAN登録プロトコル
NSAP - Network Service Access Point
NSAP-ネットワークサービスアクセスポイント
P2P - Point-to-point
P2P-ポイントツーポイント
PDU - Protocol Data Unit
PDU-プロトコルデータユニット
PPP - Point-to-Point Protocol
PPP-ポイントツーポイントプロトコル
RBridge - Routing Bridge
RBridge-ルーティングブリッジ
RPF - Reverse Path Forwarding
RPF-リバースパス転送
SA - Source Address
SA-送信元アドレス
SNMP - Simple Network Management Protocol
SNMP-シンプルなネットワーク管理プロトコル
SPF - Shortest Path First
SPF-最短経路優先
TLV - Type, Length, Value
TLV-タイプ、長さ、値
TRILL - TRansparent Interconnection of Lots of Links
TRILL-多くのリンクの透過的な相互接続
VLAN - Virtual Local Area Network
VLAN-仮想ローカルエリアネットワーク
VRP - VLAN Registration Protocol
VRP-VLAN登録プロトコル
This section provides a high-level overview of RBridges, which implement the TRILL protocol, omitting some details. Sections 3 and 4 below provide more detailed specifications.
このセクションでは、TRILLプロトコルを実装するRBridgesの概要を説明しますが、一部の詳細は省略しています。以下のセクション3および4では、より詳細な仕様を提供します。
TRILL, as described in this document and with the exceptions discussed herein, provides [802.1Q-2005] VLAN-aware customer bridging service. As described below, TRILL is layered above the ports of an RBridge.
このドキュメントで説明されているTRILLは、ここで説明されている例外を除き、[802.1Q-2005] VLAN対応の顧客ブリッジサービスを提供します。以下で説明するように、TRILLはRBridgeのポートの上に階層化されています。
The RBridges specified by this document do not supply provider [802.1ad] or provider backbone [802.1ah] bridging or the like. The extension of TRILL to provide such provider services is left for future work that will be separately documented. However, provider or provider backbone bridges may be used to interconnect parts of an RBridge campus.
このドキュメントで指定されているRBridgeは、プロバイダー[802.1ad]またはプロバイダーバックボーン[802.1ah]ブリッジなどを提供していません。そのようなプロバイダーサービスを提供するTRILLの拡張は、別途文書化される将来の作業に残されます。ただし、プロバイダーまたはプロバイダーバックボーンブリッジを使用して、RBridgeキャンパスの一部を相互接続できます。
RBridges run a link state protocol amongst themselves. This gives them enough information to compute pair-wise optimal paths for unicast, and calculate distribution trees for delivery of frames either to destinations whose location is unknown or to multicast/broadcast groups [RBridges] [RP1999].
RBridgeは、それらの間でリンク状態プロトコルを実行します。これにより、ユニキャストのペアごとの最適パスを計算し、場所が不明な宛先またはマルチキャスト/ブロードキャストグループ[RBridges] [RP1999]にフレームを配信するための配信ツリーを計算するのに十分な情報が得られます。
To mitigate temporary loop issues, RBridges forward based on a header with a hop count. RBridges also specify the next hop RBridge as the frame destination when forwarding unicast frames across a shared-media link, which avoids spawning additional copies of frames during a temporary loop. A Reverse Path Forwarding Check and other checks are performed on multi-destination frames to further control potentially looping traffic (see Section 4.5.2).
一時的なループの問題を軽減するために、RBridgeはホップカウントのあるヘッダーに基づいて転送します。 RBridgeは、共有メディアリンクを介してユニキャストフレームを転送するときに、フレームの宛先としてネクストホップRBridgeも指定します。これにより、一時的なループ中にフレームの追加コピーが生成されるのを回避できます。ループする可能性のあるトラフィックをさらに制御するために、マルチパスフレームでリバースパス転送チェックおよびその他のチェックが実行されます（セクション4.5.2を参照）。
The first RBridge that a unicast frame encounters in a campus, RB1, encapsulates the received frame with a TRILL header that specifies the last RBridge, RB2, where the frame is decapsulated. RB1 is known as the "ingress RBridge" and RB2 is known as the "egress RBridge". To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the RBridges to select 2-octet nicknames for RBridges, unique within the campus, which are an abbreviation for the IS-IS ID of the RBridge. The 2-octet nicknames are used to specify the ingress and egress RBridges in the TRILL header.
ユニキャストフレームがキャンパスで遭遇する最初のRBridge RB1は、フレームがカプセル化解除される最後のRBridge RB2を指定するTRILLヘッダーで受信フレームをカプセル化します。 RB1は「入力RBridge」と呼ばれ、RB2は「出力RBridge」と呼ばれます。 TRILLヘッダーのスペースを節約し、転送ルックアップを簡素化するために、動的なニックネーム取得プロトコルがRBridge間で実行され、キャンパス内で一意のRBridgeの2オクテットニックネームを選択します。これは、RBridgeのIS-IS IDの略語です。 2オクテットのニックネームは、TRILLヘッダーの入力および出力RBridgeを指定するために使用されます。
Multipathing of multi-destination frames through alternative distribution trees and ECMP (Equal Cost Multipath) of unicast frames are supported (see Appendix C).
代替配信ツリーによるマルチ宛先フレームのマルチパスとユニキャストフレームのECMP（等コストマルチパス）がサポートされています（付録Cを参照）。
Networks with a more mesh-like structure will benefit to a greater extent from the multipathing and optimal paths provided by TRILL than will more tree-like networks.
よりメッシュのような構造を持つネットワークは、よりツリーのようなネットワークよりも、TRILLによって提供されるマルチパスと最適パスの恩恵を受けます。
RBridges run a protocol on a link to elect a "Designated RBridge" (DRB). The TRILL-IS-IS election protocol on a link is a little different from the Layer 3 IS-IS [ISO10589] election protocol, because in TRILL it is essential that only one RBridge be elected DRB, whereas in Layer 3 IS-IS it is possible for multiple routers to be elected Designated Router (also known as Designated Intermediate System). As with an IS-IS router, the DRB may give a pseudonode name to the link, issue an LSP (Link State PDU) on behalf of the pseudonode, and issues CSNPs (Complete Sequence Number PDUs) on the link. Additionally, the DRB has some TRILL-specific duties, including specifying which VLAN will be the Designated VLAN used for communication between RBridges on that link (see Section 4.2.4.2).
RBridgeはリンク上でプロトコルを実行して、「指定RBridge」（DRB）を選択します。リンク上のTRILL-IS-IS選定プロトコルは、レイヤー3 IS-IS [ISO10589]選定プロトコルとは少し異なります。TRILLでは1つのRBridgeのみがDRBとして選定されることが重要ですが、レイヤー3 IS-ISでは複数のルーターが指定ルーター（指定中間システムとも呼ばれます）として選出される可能性があります。 IS-ISルーターと同様に、DRBはリンクに疑似ノード名を付け、疑似ノードに代わってLSP（リンク状態PDU）を発行し、リンク上でCSNP（完全シーケンス番号PDU）を発行します。さらに、DRBには、そのVLANリンク上のRBridge間の通信に使用される指定VLANとなるVLANの指定など、いくつかのTRILL固有の役割があります（セクション4.2.4.2を参照）。
The DRB either encapsulates/decapsulates all data traffic to/from the link, or, for load splitting, delegates this responsibility, for one or more VLANs, to other RBridges on the link. There must at all times be at most one RBridge on the link that encapsulates/decapsulates traffic for a particular VLAN. We will refer to the RBridge appointed to forward VLAN-x traffic on behalf of the link as the "appointed VLAN-x forwarder" (see Section 4.2.4.3). (Section 2.5 discusses VLANs further.)
DRBは、リンクとの間のすべてのデータトラフィックをカプセル化/カプセル化解除するか、負荷分散の場合、1つ以上のVLANについて、リンク上の他のRBridgeにこの責任を委任します。特定のVLANのトラフィックをカプセル化/カプセル化解除するリンクには、常に最大1つのRBridgeが存在する必要があります。リンクの代わりにVLAN-xトラフィックを転送するように指定されたRBridgeを「指定されたVLAN-xフォワーダー」と呼びます（セクション4.2.4.3を参照）。 （セクション2.5でVLANについてさらに説明します。）
Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be specified in a separate document. If IP service is available to an RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and IPv6 [RFC3419]; however, management can be used, within a campus, even for an RBridge that lacks an IP or other Layer 3 transport stack or which does not have a Layer 3 address, by transporting SNMP with Ethernet [RFC4789].
Rbridgeは、SNMPv3 [RFC3411]をサポートする必要があります（SHOULD）。 Rbridge MIBは別のドキュメントで指定されます。 IPサービスがRBridgeで利用できる場合、IPv4 [RFC3417]およびIPv6 [RFC3419]を介したUDPを介したSNMPv3をサポートする必要があります（SHOULD）。ただし、イーサネットを使用してSNMPを転送することにより、IPまたはその他のレイヤー3トランスポートスタックがないか、レイヤー3アドレスを持たないRBridgeでも、キャンパス内で管理を使用できます[RFC4789]。
An RBridge, RB1, that is the VLAN-x forwarder on any of its links MUST learn the location of VLAN-x end nodes, both on the links for which it is VLAN-x forwarder and on other links in the campus. RB1 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on links for which it is VLAN-x forwarder from the source address of frames received, as bridges do (for example, see Section 8.7 of [802.1Q-2005]), or through configuration or a Layer 2 explicit registration protocol such as IEEE 802.11 association and authentication. RB1 learns the VLAN and Layer 2 address of distant VLAN-x end nodes, and the corresponding RBridge to which they are attached, by looking at the ingress RBridge nickname in the TRILL header and the VLAN and source MAC address of the inner frame of TRILL Data frames that it decapsulates.
リンクのいずれかのVLAN-xフォワーダーであるRBridge、RB1は、VLAN-xフォワーダーであるリンクとキャンパス内の他のリンクの両方で、VLAN-xエンドノードの場所を学習する必要があります。 RB1は、ブリッジと同様に、受信したフレームの送信元アドレスから、VLAN-xフォワーダーであるリンク上のエンドノードのポート、VLAN、およびレイヤー2（MAC）アドレスを学習します（たとえば、[802.1Q- 2005]）、または構成またはレイヤ2の明示的な登録プロトコル（IEEE 802.11アソシエーションや認証など）を通じて。 RB1は、TRILLヘッダー内の入力RBridgeニックネーム、およびTRILLの内部フレームのVLANとソースMACアドレスを調べることにより、離れたVLAN-xエンドノードのVLANおよびレイヤー2アドレス、およびそれらが接続されている対応するRBridgeを学習しますカプセル化を解除するデータフレーム。
Additionally, an RBridge that is the appointed VLAN-x forwarder on one or more links MAY use the End-Station Address Distribution Information (ESADI) protocol to announce some or all of the attached VLAN-x end nodes on those links.
さらに、1つ以上のリンクで指定されたVLAN-xフォワーダーであるRBridgeは、End-Station Address Distribution Information（ESADI）プロトコルを使用して、それらのリンクに接続されたVLAN-xエンドノードの一部またはすべてをアナウンスできます（MAY）。
The ESADI protocol could be used to announce end nodes that have been explicitly enrolled. Such information might be more authoritative than that learned from data frames being decapsulated onto the link. Also, the addresses enrolled and distributed in this way can be more secure for two reasons: (1) the enrollment might be authenticated (for example, by cryptographically based EAP methods via [802.1X]), and (2) the ESADI protocol also supports cryptographic authentication of its messages [RFC5304] [RFC5310] for more secure transmission.
ESADIプロトコルは、明示的に登録されたエンドノードをアナウンスするために使用できます。このような情報は、リンク上でカプセル化解除されたデータフレームから学習した情報よりも信頼できる可能性があります。また、この方法で登録および配布されたアドレスは、次の2つの理由でより安全になります。（1）登録が認証される（たとえば、[802.1X]を介した暗号ベースのEAPメソッドによって）、（2）ESADIプロトコルもより安全な送信のために、メッセージの暗号化認証[RFC5304] [RFC5310]をサポートします。
If an end station is unplugged from one RBridge and plugged into another, then, depending on circumstances, frames addressed to that end station can be black-holed. That is, they can be sent just to the older RBridge that the end station used to be connected to until cached address information at some remote RBridge(s) times out, possibly for a number of minutes or longer. With the ESADI protocol, the link interruption from the unplugging can cause an immediate update to be sent.
端末が1つのRBridgeから外され、別のRBridgeに接続されている場合、状況によっては、その端末にアドレス指定されたフレームがブラックホールになる可能性があります。つまり、リモートRBridgeでキャッシュされたアドレス情報がタイムアウトするまで、おそらく数分以上、エンドステーションが接続されていた古いRBridgeにのみ送信できます。 ESADIプロトコルを使用すると、取り外しによるリンクの中断により、すぐに更新が送信される可能性があります。
Even if the ESADI protocol is used to announce or learn attached end nodes, RBridges MUST still learn from received native frames and decapsulated TRILL Data frames unless configured not to do so. Advertising end nodes using ESADI is optional, as is learning from these announcements.
ESADIプロトコルを使用して接続されたエンドノードを通知または学習する場合でも、RBridgeは、そうしないように構成されていない限り、受信したネイティブフレームおよびカプセル化されていないTRILLデータフレームから学習する必要があります。 ESADIを使用したエンドノードのアドバタイズはオプションであり、これらのアナウンスから学びます。
(See Section 4.8 for further end-station address details.)
（端末アドレスの詳細については、セクション4.8を参照してください。）
The Layer 2 technology used to connect Rbridges may be either IEEE [802.3] or some other link technology such as PPP [RFC1661]. This is possible since the RBridge relay function is layered on top of the Layer 2 technologies. However, this document specifies only an IEEE 802.3 encapsulation.
Rbridgeの接続に使用されるレイヤー2テクノロジーは、IEEE [802.3]またはPPP [RFC1661]などの他のリンクテクノロジーのいずれかです。これは、RBridgeリレー機能がレイヤー2テクノロジーの上に階層化されているため可能です。ただし、このドキュメントではIEEE 802.3カプセル化のみを指定しています。
Figure 1 shows two RBridges, RB1 and RB2, interconnected through an Ethernet cloud. The Ethernet cloud may include hubs, point-to-point or shared media, IEEE 802.1D bridges, or 802.1Q bridges.
図1は、イーサネットクラウドを介して相互接続された2つのRBridge、RB1とRB2を示しています。イーサネットクラウドには、ハブ、ポイントツーポイントまたは共有メディア、IEEE 802.1Dブリッジ、または802.1Qブリッジが含まれる場合があります。
------------
/ \
+-----+ / Ethernet \ +-----+
| RB1 |----< >---| RB2 |
+-----+ \ Cloud / +-----+
\ /
------------
Figure 1: Interconnected RBridges
図1：相互接続されたRBridge
Figure 2 shows the format of a TRILL data or ESADI frame traveling through the Ethernet cloud between RB1 and RB2.
図2は、RB1とRB2の間のイーサネットクラウドを通過するTRILLデータまたはESADIフレームのフォーマットを示しています。
+--------------------------------+
| Outer Ethernet Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| Ethernet FCS |
+--------------------------------+
Figure 2: An Ethernet Encapsulated TRILL Frame
図2：イーサネットカプセル化TRILLフレーム
In the case of media different from Ethernet, the header specific to that media replaces the outer Ethernet header. For example, Figure 3 shows a TRILL encapsulation over PPP.
イーサネットとは異なるメディアの場合、そのメディアに固有のヘッダーが外側のイーサネットヘッダーを置き換えます。たとえば、図3はPPP上のTRILLカプセル化を示しています。
+--------------------------------+
| PPP Header |
+--------------------------------+
| TRILL Header |
+--------------------------------+
| Inner Ethernet Header |
+--------------------------------+
| Ethernet Payload |
+--------------------------------+
| PPP FCS |
+--------------------------------+
Figure 3: A PPP Encapsulated TRILL Frame
図3：PPPカプセル化TRILLフレーム
The outer header is link-specific and, although this document specifies only [802.3] links, other links are allowed.
外部ヘッダーはリンク固有であり、このドキュメントでは[802.3]リンクのみを指定していますが、他のリンクも許可されています。
In both cases, the inner Ethernet header and the Ethernet Payload come from the original frame and are encapsulated with a TRILL header as they travel between RBridges. Use of a TRILL header offers the following benefits:
どちらの場合も、内部イーサネットヘッダーとイーサネットペイロードは元のフレームから取得され、RBridge間を移動するときにTRILLヘッダーでカプセル化されます。 TRILLヘッダーを使用すると、次の利点があります。
1. loop mitigation through use of a hop count field;
1. ホップカウントフィールドを使用したループ緩和。
2. elimination of the need for end-station VLAN and MAC address learning in transit RBridges;
2. 中継RBridgeでの端末VLANおよびMACアドレス学習の必要性の排除。
3. direction of unicast frames towards the egress RBridge (this enables unicast forwarding tables of transit RBridges to be sized with the number of RBridges rather than the total number of end nodes); and
3. 出口RBridgeへのユニキャストフレームの方向（これにより、中継RBridgeのユニキャスト転送テーブルのサイズを、エンドノードの総数ではなくRBridgeの数で指定できます）;そして
4. provision of a separate VLAN tag for forwarding traffic between RBridges, independent of the VLAN of the native frame.
4. ネイティブフレームのVLANとは関係なく、RBridge間でトラフィックを転送するための個別のVLANタグのプロビジョニング。
When forwarding unicast frames between RBridges, the outer header has the MAC destination address of the next hop Rbridge, to avoid frame duplication if the inter-RBridge link is multi-access. This also enables multipathing of unicast, since the transmitting RBridge can specify the next hop. Having the outer header specify the transmitting RBridge as the source address ensures that any bridges inside the Ethernet cloud will not get confused, as they might be if multipathing is in use and they were to see the original source or ingress RBridge in the outer header.
RBridge間でユニキャストフレームを転送する場合、RBridge間リンクがマルチアクセスの場合にフレームの重複を回避するために、外部ヘッダーにはネクストホップRbridgeのMAC宛先アドレスが含まれます。これにより、送信RBridgeがネクストホップを指定できるため、ユニキャストのマルチパスも有効になります。外部ヘッダーに送信RBridgeを送信元アドレスとして指定させると、マルチパスが使用されていて、外部ヘッダーに元の送信元または入力RBridgeが表示された場合にイーサネットクラウド内のブリッジが混乱することがなくなります。
RBridges are true routers in the sense that, in the forwarding of a frame by a transit RBridge, the outer Layer 2 header is replaced at each hop with an appropriate Layer 2 header for the next hop, and a hop count is decreased. Despite these modifications of the outer Layer 2 header and the hop count in the TRILL header, the original encapsulated frame is preserved, including the original frame's VLAN tag. See Section 4.6 for more details.
RBridgeは、中継RBridgeによるフレームの転送で、各ホップで外側のレイヤー2ヘッダーが次のホップの適切なレイヤー2ヘッダーに置き換えられ、ホップカウントが減少するという意味で、真のルーターです。外側のレイヤー2ヘッダーとTRILLヘッダーのホップカウントのこれらの変更にもかかわらず、元のフレームのVLANタグを含む元のカプセル化されたフレームは保持されます。詳細については、セクション4.6を参照してください。
From a forwarding standpoint, transit frames may be classified into two categories: known-unicast and multi-destination. Layer 2 control frames and TRILL control and TRILL other frames are not transit frames, are not forwarded by RBridges, and are not included in these categories.
転送の観点から、中継フレームは、既知のユニキャストと複数の宛先という2つのカテゴリに分類できます。レイヤー2制御フレーム、TRILL制御フレーム、およびTRILLその他のフレームはトランジットフレームではなく、RBridgeによって転送されず、これらのカテゴリには含まれません。
These frames have a unicast inner MAC destination address (Inner.MacDA) and are those for which the ingress RBridge knows the egress RBridge for the destination MAC address in the frame's VLAN.
これらのフレームには、ユニキャスト内部MAC宛先アドレス（Inner.MacDA）があり、入力RBridgeがフレームのVLAN内の宛先MACアドレスの出力RBridgeを知っているフレームです。
Such frames are forwarded Rbridge hop by Rbridge hop to their egress Rbridge.
このようなフレームは、Rbridgeホップごとに出力Rbridgeに転送されます。
These are frames that must be delivered to multiple destinations.
これらは、複数の宛先に配信する必要があるフレームです。
Multi-destination frames include the following:
マルチ宛先フレームには、次のものがあります。
1. unicast frames for which the location of the destination is unknown: the Inner.MacDA is unicast, but the ingress RBridge does not know its location in the frame's VLAN.
1. 宛先の場所が不明なユニキャストフレーム：Inner.MacDAはユニキャストですが、入力RBridgeはフレームのVLAN内のその場所を認識していません。
2. multicast frames for which the Layer 2 destination address is derived from an IP multicast address: the Inner.MacDA is multicast, from the set of Layer 2 multicast addresses derived from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses. These frames are handled somewhat differently in different subcases:
2. レイヤー2宛先アドレスがIPマルチキャストアドレスから派生したマルチキャストフレーム：Inner.MacDAは、IPv4 [RFC1112]またはIPv6 [RFC2464]マルチキャストアドレスから派生したレイヤー2マルチキャストアドレスのセットからマルチキャストされます。これらのフレームの処理は、サブケースによって多少異なります。
2.1. IGMP [RFC3376] and MLD [RFC2710] multicast group membership reports
2.1. IGMP [RFC3376]およびMLD [RFC2710]マルチキャストグループメンバーシップレポート
2.2. IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] announcement messages
2.2. IGMP [RFC3376]およびMLD [RFC2710]クエリおよびMRD [RFC4286]アナウンスメッセージ
2.3. other IP-derived Layer 2 multicast frames
2.3. その他のIP派生レイヤー2マルチキャストフレーム
3. multicast frames for which the Layer 2 destination address is not derived from an IP multicast address: the Inner.MacDA is multicast, and not from the set of Layer 2 multicast addresses derived from IPv4 or IPv6 multicast addresses.
3. レイヤー2宛先アドレスがIPマルチキャストアドレスから派生していないマルチキャストフレーム：Inner.MacDAはマルチキャストであり、IPv4またはIPv6マルチキャストアドレスから派生したレイヤー2マルチキャストアドレスのセットからではありません。
4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF-FF).
4. ブロードキャストフレーム：Inner.MacDAがブロードキャストされます（FF-FF-FF-FF-FF-FF）。
RBridges build distribution trees (see Section 4.5) and use these trees for forwarding multi-destination frames. Each distribution tree reaches all RBridges in the campus, is shared across all VLANs, and may be used for the distribution of a native frame that is in any VLAN. However, the distribution of any particular frame on a distribution tree is pruned in different ways for different cases to avoid unnecessary propagation of the frame.
RBridgeは配布ツリー（セクション4.5を参照）を構築し、これらのツリーを使用して複数の宛先フレームを転送します。各配布ツリーはキャンパス内のすべてのRBridgeに到達し、すべてのVLANで共有され、任意のVLANにあるネイティブフレームの配布に使用できます。ただし、配信ツリー上の特定のフレームの配信は、フレームの不要な伝搬を回避するために、さまざまなケースでさまざまな方法でプルーニングされます。
A VLAN is a way to partition end nodes in a campus into different Layer 2 communities [802.1Q-2005]. Use of VLANs requires configuration. By default, the port of receipt determines the VLAN of a frame sent by an end station. End stations can also explicitly insert this information in a frame.
VLANは、キャンパスのエンドノードを異なるレイヤ2コミュニティに分割する方法です[802.1Q-2005]。 VLANを使用するには、構成が必要です。デフォルトでは、受信ポートは、エンドステーションによって送信されるフレームのVLANを決定します。端末は、この情報をフレームに明示的に挿入することもできます。
IEEE [802.1Q-2005] bridges can be configured to support multiple customer VLANs over a single simple link by inserting/removing a VLAN tag in the frame. VLAN tags used by TRILL have the same format as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2, there are two places where such tags may be present in a TRILL-encapsulated frame sent over an IEEE [802.3] link: one in the outer header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner and outer VLANs are further discussed in Section 4.1.
IEEE [802.1Q-2005]ブリッジは、フレームにVLANタグを挿入/削除することにより、単一のシンプルリンクで複数のカスタマーVLANをサポートするように構成できます。 TRILLで使用されるVLANタグは、IEEE [802.1Q-2005]で定義されているVLANタグと同じ形式です。図2に示すように、IEEE [802.3]リンクを介して送信されるTRILLカプセル化フレームにそのようなタグが存在する可能性のある場所は、外部ヘッダー（Outer.VLAN）と内部ヘッダー（Inner。 VLAN）。内部VLANと外部VLANについては、セクション4.1で詳しく説明します。
RBridges enforce delivery of a native frame originating in a particular VLAN only to other links in the same VLAN; however, there are a few differences in the handling of VLANs between an RBridge campus and an 802.1 bridged LAN as described below.
RBridgeは、特定のVLANから発信されたネイティブフレームの配信を、同じVLAN内の他のリンクにのみ強制します。ただし、以下で説明するように、RBridgeキャンパスと802.1ブリッジLANの間のVLANの処理にはいくつかの違いがあります。
(See Section 4.2.4 for further discussion of TRILL IS-IS operation on a link.)
（リンクでのTRILL IS-IS操作の詳細については、セクション4.2.4を参照してください。）
Certain configurations of bridges may cause partitions of a VLAN on a link. For such configurations, a frame sent by one RBridge to a neighbor on that link might not arrive, if tagged with a VLAN that is partitioned due to bridge configuration.
ブリッジの構成によっては、リンク上でVLANのパーティションが発生する場合があります。このような構成では、1つのRBridgeからそのリンク上のネイバーに送信されたフレームは、ブリッジ構成のために分割されたVLANでタグ付けされている場合、到着しない可能性があります。
TRILL requires at least one VLAN per link that gives full connectivity to all the RBridges on that link. The default VLAN is 1, though RBridges may be configured to use a different VLAN. The DRB dictates to the other RBridges which VLAN to use.
TRILLには、リンクごとに少なくとも1つのVLANが必要であり、そのリンク上のすべてのRBridgeに完全な接続を提供します。デフォルトのVLANは1ですが、RBridgeは別のVLANを使用するように構成できます。 DRBは、使用するVLANを他のRBridgeに指示します。
Since there will be only one appointed forwarder for any VLAN, say, VLAN-x, on a link, if bridges are configured to cause VLAN-x to be partitioned on a link, some VLAN-x end nodes on that link may be orphaned (unable to communicate with the rest of the campus).
リンク上でVLAN-xなどのVLANに指定されたフォワーダーは1つしかないため、ブリッジがリンク上でVLAN-xを分割するように構成されている場合、そのリンク上の一部のVLAN-xエンドノードは孤立する可能性があります。 （キャンパスの他の部分と通信できません）。
It is possible for bridge and port configuration to cause VLAN mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). TRILL detects this by inserting a copy of the outer VLAN into TRILL-Hello messages and checking it on receipt. If detected, it takes steps to ensure that there is at most a single appointed forwarder on the link, to avoid possible frame duplication or loops (see Section 4.4.5).
ブリッジとポートの設定により、リンクでVLANマッピングが発生する可能性があります（ここで、VLAN-xフレームはVLAN-yフレームに変わります）。 TRILLは、外部VLANのコピーをTRILL-Helloメッセージに挿入し、受信時に確認することでこれを検出します。検出された場合、フレームの重複やループの可能性を回避するために、リンク上に指定されたフォワーダーが多くても1つしかないことを確認する手順が実行されます（セクション4.4.5を参照）。
TRILL behaves as conservatively as possible, avoiding loops rather than avoiding partial connectivity. As a result, lack of connectivity may result from bridge or port misconfiguration.
TRILLは可能な限り保守的に動作し、部分的な接続を回避するのではなく、ループを回避します。その結果、接続の欠如は、ブリッジまたはポートの設定ミスが原因である可能性があります。
RBridge ports are, except as described below, layered on top of IEEE [802.1Q-2005] port facilities.
RBridgeポートは、以下で説明する場合を除き、IEEE [802.1Q-2005]ポート機能の上に階層化されています。
RBridge ports make use of [802.1Q-2005] port VLAN and priority processing. In addition, they MAY implement other lower-level 802.1 protocols as well as protocols for the link in use, such as PAUSE (Annex 31B of [802.3]), port-based access control [802.1X], MAC security [802.1AE], or link aggregation [802.1AX].
RBridgeポートは、[802.1Q-2005]ポートVLANと優先処理を利用します。さらに、PAUSE（[802.3]の付録31B）、ポートベースのアクセス制御[802.1X]、MACセキュリティ[802.1AE]など、使用中のリンク用のプロトコルだけでなく、他の下位レベルの802.1プロトコルも実装できます（MAY）。 、またはリンクアグリゲーション[802.1AX]。
However, RBridges do not use spanning tree and do not block ports as spanning tree does. Figure 4 shows a high-level diagram of an RBridge with one port connected to an IEEE 802.3 link. Single lines represent the flow of control information, double lines the flow of both frames and control information.
ただし、RBridgeはスパニングツリーを使用せず、スパニングツリーのようにポートをブロックしません。図4は、1つのポートがIEEE 802.3リンクに接続されているRBridgeの概要図を示しています。単線は制御情報の流れを表し、二重線はフレームと制御情報の両方の流れを表します。
+-----------------------------------------
| RBridge
|
| Forwarding Engine, IS-IS, etc.
| Processing of native and TRILL frames
|
+----+---+--------++----------------------
| | || other ports...
+-------------+ | ||
| | ||
+------------+-------------+ | ||
| RBridge | | +----++-------+ <- EISS
| | | | |
| High-Level Control Frame | | | 802.1Q-2005 |
| Processing (BPDU, VRP) | | | Port VLAN |
| | | | & Priority |
+-----------++-------------+ | | Processing |
|| | | |
+---------++-----------------+---+-------------+ <-- ISS
| |
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
| |
+-----------++---------------------------------+
||
|| +------------+
|| | 802.3 PHY |
|+--------+ (Physical +--------- 802.3
+---------+ Interface) +--------- Link
| |
+------------+
Figure 4: RBridge Port Model
図4：RBridgeポートモデル
The upper interface to the low-level port/link control logic corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. In RBridges, high-level control frames are processed above the ISS interface.
低レベルのポート/リンク制御ロジックへの上位インターフェースは、[802.1Q-2005]の内部サブレイヤーサービス（ISS）に対応しています。 RBridgeでは、高レベルの制御フレームがISSインターフェース上で処理されます。
The upper interface to the port VLAN and priority processing corresponds to the Extended Internal Sublayer Service (EISS) in [802.1Q-2005]. In RBridges, native and TRILL frames are processed above the EISS interface and are subject to port VLAN and priority processing.
ポートVLANへの上部インターフェイスと優先処理は、[802.1Q-2005]の拡張内部サブレイヤーサービス（EISS）に対応します。 RBridgeでは、ネイティブフレームとTRILLフレームはEISSインターフェイス上で処理され、ポートVLANおよび優先度処理の対象になります。
Because RBridges are compatible with IEEE [802.1Q-2005] customer bridges, except as discussed in this document, a bridged LAN can be upgraded by incrementally replacing such bridges with RBridges. Bridges that have not yet been replaced are transparent to RBridge traffic. The physical links directly interconnected by such bridges, together with the bridges themselves, constitute bridged LANs. These bridged LANs appear to RBridges to be multi-access links.
このドキュメントで説明されている場合を除き、RBridgeはIEEE [802.1Q-2005]カスタマーブリッジと互換性があるため、このようなブリッジをRBridgeに段階的に置き換えることで、ブリッジLANをアップグレードできます。まだ交換されていないブリッジは、RBridgeトラフィックに対して透過的です。このようなブリッジによって直接相互接続されている物理リンクは、ブリッジ自体と一緒に、ブリッジLANを構成します。これらのブリッジLANは、RBridgeからはマルチアクセスリンクのように見えます。
If the bridges replaced by RBridges were default configuration bridges, then their RBridge replacements will not require configuration.
RBridgeに置き換えられたブリッジがデフォルトの構成ブリッジである場合、それらのRBridgeの交換は構成を必要としません。
Because RBridges, as described in this document, only provide customer services, they cannot replace provider bridges or provider backbone bridges, just as a customer bridge can't replace a provider bridge. However, such provider devices can be part of the bridged LAN between RBridges. Extension of TRILL to support provider services is left for future work and will be separately documented.
このドキュメントで説明されているように、RBridgeはカスタマーサービスのみを提供するため、カスタマーブリッジがプロバイダーブリッジを置き換えることができないのと同じように、プロバイダーブリッジまたはプロバイダーバックボーンブリッジを置き換えることはできません。ただし、そのようなプロバイダーデバイスは、RBridge間のブリッジLANの一部にすることができます。プロバイダーサービスをサポートするためのTRILLの拡張は将来の作業に残されており、別途文書化されます。
Of course, if the bridges replaced had any port level protocols enabled, such as port-based access control [802.1X] or MAC security [802.1AE], replacement RBridges would need the same port level protocols enabled and similarly configured. In addition, the replacement RBridges would have to support the same link type and link level protocols as the replaced bridges.
もちろん、置き換えられたブリッジでポートベースのプロトコル（802.1X）やMACセキュリティ[802.1AE]などのポートレベルのプロトコルが有効になっている場合、同じRBridgeを有効にして同様に構成する必要があります。さらに、交換したRBridgeは、交換したブリッジと同じリンクタイプとリンクレベルのプロトコルをサポートする必要があります。
An RBridge campus will work best if all IEEE [802.1D] and [802.1Q-2005] bridges are replaced with RBridges, assuming the RBridges have the same speed and capacity as the bridges. However, there may be intermediate states, where only some bridges have been replaced by RBridges, with inferior performance.
すべてのIEEE [802.1D]および[802.1Q-2005]ブリッジがRBridgeと交換されている場合、RBridgeがブリッジと同じ速度と容量を持っていると仮定すると、RBridgeキャンパスは最適に機能します。ただし、一部のブリッジのみがRBridgeに置き換えられ、パフォーマンスが低下する中間状態が存在する場合があります。
See Appendix A for further discussion of incremental deployment.
増分展開の詳細については、付録Aを参照してください。
This section specifies the TRILL header. Section 4 below provides other RBridge design details.
このセクションでは、TRILLヘッダーを指定します。以下のセクション4では、他のRBridge設計の詳細について説明します。
The TRILL header is shown in Figure 5 and is independent of the data link layer used. When that layer is IEEE [802.3], it is prefixed with the 16-bit TRILL Ethertype [RFC5342], making it 64-bit aligned. If Op-Length is a multiple of 64 bits, then 64-bit alignment is normally maintained for the content of an encapsulated frame.
TRILLヘッダーを図5に示します。これは、使用されるデータリンク層とは無関係です。その層がIEEE [802.3]の場合、16ビットのTRILL Ethertype [RFC5342]がプレフィックスとして付加され、64ビットに揃えられます。 Op-Lengthが64ビットの倍数である場合、通常、カプセル化されたフレームのコンテンツに対して64ビットのアライメントが維持されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress RBridge Nickname | Ingress RBridge Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: TRILL Header
図5：TRILLヘッダー
The header contains the following fields that are described in the sections referenced:
ヘッダーには、参照されるセクションで説明されている以下のフィールドが含まれています。
o V (Version): 2-bit unsigned integer. See Section 3.2.
o V（バージョン）：2ビット符号なし整数。セクション3.2を参照してください。
o R (Reserved): 2 bits. See Section 3.3.
o R（予約済み）：2ビット。セクション3.3を参照してください。
o M (Multi-destination): 1 bit. See Section 3.4.
o M（マルチ宛先）：1ビット。セクション3.4を参照してください。
o Op-Length (Options Length): 5-bit unsigned integer. See Section 3.5.
o Op-Length（オプションの長さ）：5ビットの符号なし整数。セクション3.5を参照してください。
o Hop Count: 6-bit unsigned integer. See Section 3.6.
o ホップ数：6ビットの符号なし整数。セクション3.6を参照してください。
o Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1.
o 出力RBridgeニックネーム：16ビットの識別子。セクション3.7.1を参照してください。
o Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2.
o Ingress RBridge Nickname：16ビットの識別子。セクション3.7.2を参照してください。
o Options: present if Op-Length is non-zero. See Section 3.8.
o オプション：Op-Lengthがゼロ以外の場合に存在します。セクション3.8を参照してください。
Version (V) is a 2-bit field. Version zero of TRILL is specified in this document. An RBridge RB1 MUST check the V field in a received TRILL-encapsulated frame. If the V field has a value not recognized by RB1, then RB1 MUST silently discard the frame. The allocation of new TRILL Version numbers requires an IETF Standards Action.
バージョン（V）は2ビットのフィールドです。このドキュメントでは、TRILLのバージョン0が指定されています。 RBridge RB1は、受信したTRILLカプセル化フレームのVフィールドをチェックする必要があります。 VフィールドにRB1で認識されない値がある場合、RB1は暗黙のうちにフレームを破棄しなければなりません（MUST）。新しいTRILLバージョン番号の割り当てには、IETF標準アクションが必要です。
The two R bits are reserved for future use in extensions to this version zero of the TRILL protocol. They MUST be set to zero when the TRILL header is added by an ingress RBridge, transparently copied but otherwise ignored by transit RBridges, and ignored by egress RBridges. The allocation of reserved TRILL header bits requires an IETF Standards Action.
2つのRビットは、TRILLプロトコルのこのバージョン0の拡張機能で将来使用するために予約されています。 TRILLヘッダーが入力RBridgeによって追加され、透過的にコピーされますが、通過RBridgeによって無視され、出力RBridgeによって無視される場合、これらはゼロに設定する必要があります。予約済みTRILLヘッダービットの割り当てには、IETF標準アクションが必要です。
The Multi-destination bit (see Section 2.4.2) indicates that the frame is to be delivered to a class of destination end stations via a distribution tree and that the egress RBridge nickname field specifies this tree. In particular:
マルチ宛先ビット（セクション2.4.2を参照）は、フレームが配信ツリーを介して宛先エンドステーションのクラスに配信され、出力RBridgeニックネームフィールドがこのツリーを指定することを示します。特に：
o M = 0 (FALSE) - The egress RBridge nickname contains a nickname of the egress Rbridge for a known unicast MAC address.
o M = 0（FALSE）-出力RBridgeニックネームには、既知のユニキャストMACアドレスの出力Rbridgeのニックネームが含まれています。
o M = 1 (TRUE) - The egress RBridge nickname field contains a nickname that specifies a distribution tree. This nickname is selected by the ingress RBridge for a TRILL Data frame or by the source RBridge for a TRILL ESADI frame.
o M = 1（TRUE）-出力RBridgeニックネームフィールドには、配布ツリーを指定するニックネームが含まれています。このニックネームは、TRILLデータフレームの入力RBridge、またはTRILL ESADIフレームのソースRBridgeによって選択されます。
There are provisions to express in the TRILL header that a frame is using an optional capability and to encode information into the header in connection with that capability.
フレームがオプションの機能を使用していることをTRILLヘッダーで表現し、その機能に関連して情報をヘッダーにエンコードするための規定があります。
The Op-Length header field gives the length of the TRILL header options in units of 4 octets, which allows up to 124 octets of options area. If Op-Length is zero, there are no options present. If options are present, they follow immediately after the Ingress Rbridge Nickname field.
Op-Lengthヘッダーフィールドは、TRILLヘッダーオプションの長さを4オクテット単位で示します。これにより、最大124オクテットのオプション領域が可能になります。 Op-Lengthがゼロの場合、オプションはありません。オプションが存在する場合、それらはIngress Rbridge Nicknameフィールドの直後に続きます。
See Section 3.8 for more information on TRILL header options.
TRILLヘッダーオプションの詳細については、セクション3.8を参照してください。
The Hop Count field is a 6-bit unsigned integer. An Rbridge drops frames received with a hop count of zero, otherwise it decrements the hop count. (This behavior is different from IPv4 and IPv6 in order to support the later addition of a traceroute-like facility that would be able to get a hop count exceeded from an egress RBridge.)
ホップカウントフィールドは、6ビットの符号なし整数です。 Rbridgeは、ホップカウントがゼロの受信フレームをドロップします。それ以外の場合は、ホップカウントをデクリメントします。 （この動作は、出力RBridgeからホップカウントを超える可能性があるtracerouteのような機能の後での追加をサポートするために、IPv4およびIPv6とは異なります。）
For known unicast frames, the ingress RBridge SHOULD set the Hop Count in excess of the number of RBridge hops it expects to the egress RBridge to allow for alternate routing later in the path.
既知のユニキャストフレームの場合、入力RBridgeは、出力RBridgeがパスの後半で代替ルーティングを可能にするために期待するRBridgeホップの数を超えるホップカウントを設定する必要があります（SHOULD）。
For multi-destination frames, the Hop Count SHOULD be set by the ingress RBridge (or source RBridge for a TRILL ESADI frame) to at least the expected number of hops to the most distant RBridge. To accomplish this, RBridge RBn calculates, for each branch from RBn of the specified distribution tree rooted at RBi, the maximum number of hops in that branch.
複数の宛先フレームの場合、ホップカウントは、入力RBridge（またはTRILL ESADIフレームのソースRBridge）によって、少なくとも最も遠いRBridgeへの予想されるホップ数に設定する必要があります（SHOULD）。これを達成するために、RBridge RBnは、RBiをルートとする指定された分散ツリーのRBnからの各ブランチについて、そのブランチの最大ホップ数を計算します。
Multi-destination frames are of particular danger because a loop involving one or more distribution tree forks could result in the rapid generation of multiple copies of the frame, even with the normal hop count mechanism. It is for this reason that multi-destination frames are subject to a stringent Reverse Path Forwarding Check and other checks as described in Section 4.5.2. As an optional additional traffic control measure, when forwarding a multi-destination frame onto a distribution tree branch, transit RBridge RBm MAY decrease the hop count by more than 1, unless decreasing the hop count by more than 1 would result in a hop count insufficient to reach all destinations in that branch of the tree rooted at RBi. Using a hop count close or equal to the minimum needed on multi-destination frames provides additional protection against problems with temporary loops when forwarding.
複数の宛先フレームは特に危険です。1つまたは複数の配信ツリーフォークを含むループは、通常のホップカウントメカニズムを使用していても、フレームの複数のコピーを迅速に生成する可能性があるためです。このため、セクション4.5.2で説明されているように、複数の宛先フレームは、厳しい逆パス転送チェックやその他のチェックの対象になります。オプションの追加のトラフィック制御手段として、マルチ宛先フレームを配布ツリーブランチに転送するとき、中継RBridge RBmは、ホップカウントを1以上減らすとホップカウントが不十分にならない限り、ホップカウントを1以上減らすことができます（MAY）。 RBiをルートとするツリーのそのブランチのすべての宛先に到達する。複数の宛先フレームで必要な最小数に近いか等しいホップカウントを使用すると、転送時の一時的なループの問題に対する追加の保護が提供されます。
Although the RBridge MAY decrease the hop count of multi-destination frames by more than 1, under the circumstances described above, the RBridge forwarding a frame MUST decrease the hop count by at least 1, and discards the frame if it cannot do so because the hop count is 0. The option to decrease the hop count by more than 1 under the circumstances described above applies only to multi-destination frames, not to known unicast frames.
RBridgeは、マルチデスティネーションフレームのホップカウントを1以上減らしてもよい（MAY）が、上記の状況では、フレームを転送するRBridgeはホップカウントを少なくとも1減らしなければならず（MUST）、それができない場合はフレームを破棄する必要があります。ホップカウントは0です。上記の状況でホップカウントを1以上減らすオプションは、複数の宛先のフレームにのみ適用され、既知のユニキャストフレームには適用されません。
Nicknames are 16-bit dynamically assigned quantities that act as abbreviations for RBridges' IS-IS IDs to achieve a more compact encoding and can be used to specify potentially different trees with the same root. This assignment allows specifying up to 2**16 RBridges; however, the value 0x0000 is reserved to indicate that a nickname is not specified, the values 0xFFC0 through 0xFFFE are reserved for future specification, and the value 0xFFFF is permanently reserved. RBridges piggyback a nickname acquisition protocol on the link state protocol (see Section 3.7.3) to acquire one or more nicknames unique within the campus.
ニックネームは16ビットの動的に割り当てられる数量で、RBridgeのIS-IS IDの省略形として機能し、よりコンパクトなエンコーディングを実現し、同じルートで潜在的に異なるツリーを指定するために使用できます。この割り当てにより、最大2 ** 16のRBridgeを指定できます。ただし、値0x0000は、ニックネームが指定されていないことを示すために予約されており、値0xFFC0から0xFFFEは将来の仕様のために予約されており、値0xFFFFは永久に予約されています。 RBridgesは、リンク状態プロトコル（セクション3.7.3を参照）でニックネーム取得プロトコルを便乗させて、キャンパス内で一意の1つ以上のニックネームを取得します。
There are two cases for the contents of the egress RBridge nickname field, depending on the M bit (see Section 3.4). The nickname is filled in by the ingress RBridge for TRILL Data frames and by the source RBridge for TRILL ESADI frames.
Mビットに応じて、出力RBridgeニックネームフィールドの内容には2つのケースがあります（セクション3.4を参照）。ニックネームは、TRILLデータフレームの場合は入力RBridge、TRILL ESADIフレームの場合はソースRBridgeによって埋められます。
o For known unicast TRILL Data frames, M == 0 and the egress RBridge nickname field specifies the egress RBridge; that is, it specifies the RBridge that needs to remove the TRILL encapsulation and forward the native frame. Once the egress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.
o 既知のユニキャストTRILLデータフレームの場合、M == 0であり、出力RBridgeニックネームフィールドは出力RBridgeを指定します。つまり、TRILLカプセル化を削除してネイティブフレームを転送する必要があるRBridgeを指定します。出力ニックネームフィールドが設定されると、後続のトランジットRBridgeによって変更されてはならない（MUST NOT）。
o For multi-destination TRILL Data frames and for TRILL ESADI frames, M == 1. The egress RBridge nickname field contains a nickname specifying the distribution tree selected to be used to forward the frame. This root nickname MUST NOT be changed by transit RBridges.
o 複数宛先TRILLデータフレームおよびTRILL ESADIフレームの場合、M ==1。出力RBridgeニックネームフィールドには、フレームの転送に使用するために選択された配布ツリーを指定するニックネームが含まれます。このルートニックネームは、トランジットRBridgesによって変更してはなりません。
The ingress RBridge nickname is set to a nickname of the ingress RBridge for TRILL Data frames and to a nickname of the source RBridge for TRILL ESADI frames. If the RBridge setting the ingress nickname has multiple nicknames, it SHOULD use the same nickname in the ingress field whenever it encapsulates a frame with any particular Inner.MacSA and Inner.VLAN value. This simplifies end node learning.
入力RBridgeニックネームは、TRILLデータフレームの場合は入力RBridgeのニックネームに、TRILL ESADIフレームの場合はソースRBridgeのニックネームに設定されます。入力ニックネームを設定するRBridgeに複数のニックネームがある場合、特定のInner.MacSAおよびInner.VLAN値を持つフレームをカプセル化するときはいつでも、入力フィールドで同じニックネームを使用する必要があります（SHOULD）。これにより、エンドノードの学習が簡素化されます。
Once the ingress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.
入力ニックネームフィールドが設定されると、後続のトランジットRBridgeによって変更されてはならない（MUST NOT）。
The nickname selection protocol is piggybacked on TRILL IS-IS as follows:
ニックネーム選択プロトコルは、次のようにTRILL IS-ISに便乗しています。
o The nickname or nicknames being used by an RBridge are carried in an IS-IS TLV (type-length-value data element) along with a priority of use value [RFC6326]. Each RBridge chooses its own nickname or nicknames.
o RBridgeによって使用されている1つまたは複数のニックネームは、使用優先度の値[RFC6326]とともにIS-IS TLV（type-length-valueデータエレメント）で運ばれます。各RBridgeは、独自のニックネームを選択します。
o Nickname values MAY be configured. An RBridge that has been configured with one or more nickname values will have priority for those nickname values over all Rbridges with non-configured nicknames.
o ニックネームの値を構成できます。 1つ以上のニックネーム値で構成されたRBridgeは、未構成のニックネームを持つすべてのRbridgeよりもそれらのニックネーム値を優先します。
o The nickname value 0x0000 and the values from 0xFFC0 through 0xFFFF are reserved and MUST NOT be selected by or configured for an RBridge. The value 0x0000 is used to indicate that a nickname is not known.
o ニックネーム値0x0000および0xFFC0から0xFFFFまでの値は予約されており、RBridgeによって選択または構成することはできません。値0x0000は、ニックネームが不明であることを示すために使用されます。
o The priority of use field reported with a nickname is an unsigned 8-bit value, where the most significant bit (0x80) indicates that the nickname value was configured. The bottom 7 bits have the default value 0x40, but MAY be configured to be some other value. Additionally, an RBridge MAY increase its priority after holding a nickname for some amount of time. However, the most significant bit of the priority MUST NOT be set unless the nickname value was configured.
o ニックネームで報告される使用優先度フィールドは、符号なし8ビット値です。最上位ビット（0x80）は、ニックネーム値が構成されたことを示します。下位7ビットのデフォルト値は0x40ですが、他の値になるように構成できます（MAY）。さらに、RBridgeは、ニックネームをしばらく保持した後、優先順位を上げることができます（MAY）。ただし、ニックネーム値が構成されていない限り、優先順位の最上位ビットを設定してはなりません（MUST NOT）。
o Once an RBridge has successfully acquired a nickname, it SHOULD attempt to reuse it in the case of a reboot.
o RBridgeがニックネームの取得に成功すると、再起動の際にそれを再利用する必要があります（SHOULD）。
o Each RBridge is responsible for ensuring that its nickname or each of its nicknames is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if there is a tie in priority, the RBridge with the numerically higher IS-IS System ID keeps the nickname, and the other RBridge MUST select a new nickname. This can require an RBridge with a configured nickname to select a replacement nickname.
o 各RBridgeは、そのニックネームまたは各ニックネームが一意であることを確認する責任があります。 RB1がニックネームxを選択し、RB1が後でRB2のLSPを受信することにより、RB2もxを選択したことを検出した場合、数値が大きいIS-IS ID（LAN ID）を持つRBridgeまたは疑似ノードがニックネームを保持しますまたは、優先順位にタイがある場合、数値的に大きいIS-ISシステムIDを持つRBridgeはニックネームを保持し、他のRBridgeは新しいニックネームを選択する必要があります。これにより、ニックネームが構成されたRBridgeで、代わりのニックネームを選択することが必要になる場合があります。
o To minimize the probability of nickname collisions, an RBridge selects a nickname randomly from the apparently available nicknames, based on its copy of the link state. This random selection can be by the RBridge hashing some of its parameters, e.g., SystemID, time and date, and other entropy sources, such as those given in [RFC4086], each time or by the RBridge using such hashing to create a seed and making any selections based on pseudo-random numbers generated from that seed [RFC4086]. The random numbers or seed and the algorithm used SHOULD make uniformly distributed selections over the available nicknames. Convergence to a nickname-collision-free campus is accelerated by selecting new nicknames only from those that appear to be available and by having the highest priority nickname involved in a nickname conflict retain its value. There is no reason for all Rbridges to use the same algorithm for selecting nicknames.
o ニックネームの衝突の可能性を最小限に抑えるために、RBridgeは、リンク状態のコピーに基づいて、明らかに使用可能なニックネームからランダムにニックネームを選択します。このランダムな選択は、RBridgeがそのパラメーターの一部、たとえばSystemID、時刻と日付、および[RFC4086]で提供されているような他のエントロピーソースを毎回ハッシュすることによって、またはRBridgeがそのようなハッシュを使用してシードとそのシードから生成された疑似乱数に基づいて選択を行います[RFC4086]。乱数またはシードと使用されるアルゴリズムは、利用可能なニックネームに対して均一に分散された選択を行う必要があります。ニックネームの衝突のないキャンパスへの収束は、利用可能なように見えるニックネームからのみ新しいニックネームを選択し、ニックネームの競合に関与する最高優先度のニックネームがその値を保持することによって加速されます。すべてのRbridgeがニックネームの選択に同じアルゴリズムを使用する理由はありません。
o If two RBridge campuses merge, then transient nickname collisions are possible. As soon as each RBridge receives the LSPs from the other RBridges, the RBridges that need to change nicknames select new nicknames that do not, to the best of their knowledge, collide with any existing nicknames. Some RBridges may need to change nicknames more than once before the situation is resolved.
o 2つのRBridgeキャンパスがマージすると、一時的なニックネームの衝突が発生する可能性があります。各RBridgeが他のRBridgeからLSPを受信するとすぐに、ニックネームを変更する必要があるRBridgeは、知る限りでは既存のニックネームと衝突しない新しいニックネームを選択します。一部のRBridgeは、状況が解決される前に、ニックネームを複数回変更する必要がある場合があります。
o To minimize the probability of a new RBridge usurping a nickname already in use, an RBridge SHOULD wait to acquire the link state database from a neighbor before it announces any nicknames that were not configured.
o 新しいRBridgeがすでに使用されているニックネームを使用する可能性を最小限に抑えるため、RBridgeは、構成されていないニックネームをアナウンスする前に、ネイバーからリンク状態データベースを取得するのを待つ必要があります（SHOULD）。
o An RBridge by default has only a single nickname but MAY be configured to request multiple nicknames. Each such nickname would specify a shortest path tree with the RBridge as root but, since the tree number is used in tiebreaking when there are multiple equal cost paths (see Section 4.5.1), the trees for the different nicknames will likely utilize different links. Because of the potential tree computation load it imposes, this capability to request multiple nicknames for an RBridge should be used sparingly. For example, it should be used at a few RBridges that, because of campus topology, are particularly good places from which to calculate multiple different shortest path distribution trees. Such trees need separate nicknames so traffic can be multipathed across them.
oデフォルトでは、RBridgeには1つのニックネームしかありませんが、複数のニックネームを要求するように構成できます（MAY）。そのような各ニックネームは、RBridgeをルートとする最短パスツリーを指定しますが、複数の等コストパスがある場合、ツリー番号はタイブレイクで使用されるため（セクション4.5.1を参照）、異なるニックネームのツリーは異なるリンクを使用する可能性があります。ツリー計算の負荷がかかる可能性があるため、RBridgeに複数のニックネームを要求するこの機能は、控えめに使用する必要があります。たとえば、キャンパストポロジのため、複数の異なる最短パス分布ツリーを計算するのに特に適したいくつかのRBridgeで使用する必要があります。そのようなツリーは、トラフィックをそれらの間でマルチパスできるように、個別のニックネームが必要です。
o If it is desired for a pseudonode to be a tree root, the DRB MAY request one or more nicknames in the pseudonode LSP.
o 疑似ノードがツリーのルートであることが望ましい場合、DRBは疑似ノードLSP内の1つ以上のニックネームを要求できます（MAY）。
Every nickname in use in a campus identifies an RBridge (or pseudonode) and every nickname designates a distribution tree rooted at the RBridge (or pseudonode) it identifies. However, only a limited number of these potential distribution trees are actually computed by all the RBridges in a campus as discussed in Section 4.5.
キャンパスで使用されているすべてのニックネームは、RBridge（または疑似ノード）を識別し、すべてのニックネームは、識別されたRBridge（または疑似ノード）をルートとする配布ツリーを指定します。ただし、セクション4.5で説明するように、キャンパス内のすべてのRBridgeによって実際に計算されるこれらの潜在的な分散ツリーの数は限られています。
All Rbridges MUST be able to skip the number of 4-octet chunks indicated by the Op-Length field (see Section 3.5) in order to find the inner frame, since RBridges must be able to find the destination MAC address and VLAN tag in the inner frame. (Transit RBridges need such information to filter VLANs, IP multicast, and the like. Egress Rbridges need to find the inner header to correctly decapsulate and handle the inner frame.)
RBridgeは宛先のMACアドレスとVLANタグを見つける必要があるため、すべてのRbridgeは、内部フレームを見つけるために、Op-Lengthフィールド（セクション3.5を参照）で示される4オクテットチャンクの数をスキップできなければなりません（MUST）。インナーフレーム。 （トランジットRBridgeは、VLAN、IPマルチキャストなどをフィルタリングするためにそのような情報を必要とします。出力Rbridgeは、内部ヘッダーを見つけて、内部フレームを正しくカプセル化解除して処理する必要があります。
To ensure backward-compatible safe operation, when Op-Length is non-zero indicating that options are present, the top two bits of the first octet of the options area are specified as follows:
下位互換性のある安全な操作を保証するために、オプション長が存在することを示すOp-Lengthがゼロ以外の場合、オプション領域の最初のオクテットの上位2ビットは次のように指定されます。
+------+------+----+----+----+----+----+----+
| CHbH | CItE | Reserved |
+------+------+----+----+----+----+----+----+
Figure 6: Options Area Initial Flags Octet
図6：オプション領域の初期フラグオクテット
If the CHbH (Critical Hop-by-Hop) bit is one, one or more critical hop-by-hop options are present. Transit RBridges that do not support all of the critical hop-by-hop options present, for example, an RBridge that supported no options, MUST drop the frame. If the CHbH bit is zero, the frame is safe, from the point of view of options processing, for a transit RBridge to forward, regardless of what options that RBridge does or does not support. A transit RBridge that supports none of the options present MUST transparently forward the options area when it forwards a frame.
CHbH（クリティカルホップバイホップ）ビットが1の場合、1つ以上のクリティカルホップバイホップオプションが存在します。存在する重要なホップバイホップオプションのすべてをサポートしていないトランジットRBridge、たとえば、オプションをサポートしていないRBridgeは、フレームをドロップする必要があります。 CHbHビットが0の場合、RBridgeがサポートするオプションまたはサポートしないオプションに関係なく、オプションの処理の観点から、トランジットRBridgeが転送するフレームは安全です。存在するオプションをサポートしない中継RBridgeは、フレームを転送するときにオプション領域を透過的に転送する必要があります。
If the CItE (Critical Ingress-to-Egress) bit is one, one or more critical ingress-to-egress options are present. If it is zero, no such options are present. If either CHbH or CItE is non-zero, egress RBridges that don't support all critical options present, for example, an RBridge that supports no options, MUST drop the frame. If both CHbH and CItE are zero, the frame is safe, from the point of view of options, for any egress RBridge to process, regardless of what options that RBridge does or does not support.
CItE（Critical Ingress-to-Egress）ビットが1の場合、1つ以上の重要な入力から出力オプションが存在します。ゼロの場合、そのようなオプションはありません。 CHbHまたはCItEのいずれかがゼロ以外の場合、存在するすべての重要なオプションをサポートしない出力RBridge、たとえば、オプションをサポートしないRBridgeは、フレームをドロップする必要があります。 CHbHとCItEの両方がゼロの場合、RBridgeがサポートするオプションまたはサポートしないオプションに関係なく、オプションの観点から見ると、出力RBridgeを処理するためにフレームは安全です。
Options, including the meaning of the bits labeled as Reserved in Figure 6, will be further specified in other documents and are expected to include provisions for hop-by-hop and ingress-to-egress options as well as critical and non-critical options.
図6で予約済みとラベルが付けられたビットの意味を含むオプションは、他のドキュメントでさらに指定され、ホップバイホップおよび入力から出力のオプション、ならびにクリティカルおよび非クリティカルオプションのプロビジョニングを含むことが期待されます。 。
Note: Most RBridge implementations are expected to be optimized for the simplest and most common cases of frame forwarding and processing. The inclusion of options may, and the inclusion of complex or lengthy options likely will, cause frame processing using a "slow path" with inferior performance to "fast path" processing. Limited slow path throughput may cause such frames to be discarded.
注：ほとんどのRBridge実装は、フレーム転送と処理の最も単純で最も一般的なケースに合わせて最適化されることが期待されています。オプションを含めると、複雑または長いオプションを含めると、「低速パス」を使用したフレーム処理が「高速パス」処理よりもパフォーマンスが低下する可能性があります。パスのスループットが遅いと、このようなフレームが破棄される可能性があります。
Section 3 above specifies the TRILL header, while this section specifies other RBridge design details.
上記のセクション3ではTRILLヘッダーを指定していますが、このセクションでは他のRBridge設計の詳細を指定しています。
TRILL data and ESADI frames in transit on Ethernet links are encapsulated with an outer Ethernet header (see Figure 2). This outer header looks, to a bridge on the path between two RBridges, like the header of a regular Ethernet frame; therefore, bridges forward the frame as they normally would. To enable RBridges to distinguish such TRILL Data frames, a new TRILL Ethertype (see Section 7.2) is used in the outer header.
イーサネットリンクで伝送中のTRILLデータとESADIフレームは、外部イーサネットヘッダーでカプセル化されます（図2を参照）。この外部ヘッダーは、通常のイーサネットフレームのヘッダーのように、2つのRBridge間のパス上のブリッジに見えます。したがって、ブリッジは通常どおりフレームを転送します。 RBridgeがそのようなTRILLデータフレームを区別できるようにするために、新しいTRILL Ethertype（セクション7.2を参照）が外部ヘッダーで使用されます。
Figure 7 details a TRILL Data frame with an outer VLAN tag traveling on an Ethernet link as shown at the top of the figure, that is, between transit RBridges RB3 and RB4. The native frame originated at end station ESa, was encapsulated by ingress RBridge RB1, and will ultimately be decapsulated by egress RBridge RB2 and delivered to destination end station ESb. The encapsulation shown has the advantage, if TRILL options are absent or the length of such options is a multiple of 64 bits, of aligning the original Ethernet frame at a 64-bit boundary.
図7は、図の上部、つまり中継RBridge RB3とRB4の間でイーサネットリンク上を移動する外部VLANタグを持つTRILLデータフレームの詳細を示しています。エンドステーションESaで発信され、入力RBridge RB1によってカプセル化されたネイティブフレームは、最終的に出力RBridge RB2によってカプセル化解除され、宛先エンドステーションESbに配信されます。示されているカプセル化には、TRILLオプションがないか、そのようなオプションの長さが64ビットの倍数である場合に、元のイーサネットフレームを64ビット境界に揃えるという利点があります。
When a TRILL Data frame is carried over an Ethernet cloud, it has three pairs of addresses: o Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA) and Outer Source MAC Address (Outer.MacSA): These addresses are used to specify the next hop RBridge and the transmitting RBridge, respectively.
TRILLデータフレームがイーサネットクラウドを介して伝送される場合、3つのアドレスペアがあります：o外部イーサネットヘッダー：外部宛先MACアドレス（Outer.MacDA）および外部ソースMACアドレス（Outer.MacSA）：これらのアドレスは、指定に使用されますネクストホップRBridgeおよび送信RBridgeです。
o TRILL Header: Egress Nickname and Ingress Nickname. These specify nicknames of the egress and ingress RBridges, respectively, unless the frame is multi-destination, in which case the Egress Nickname specifies the distribution tree on which the frame is being sent.
o TRILLヘッダー：出力ニックネームおよび入力ニックネーム。フレームが複数の宛先である場合を除き、これらはそれぞれ出力RBridgeと入力RBridgeのニックネームを指定します。その場合、出力ニックネームはフレームが送信される配信ツリーを指定します。
o Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA) and Inner Source MAC Address (Inner.MacSA): These addresses are as transmitted by the original end station, specifying, respectively, the destination and source of the inner frame.
o 内部イーサネットヘッダー：内部宛先MACアドレス（Inner.MacDA）および内部送信元MACアドレス（Inner.MacSA）：これらのアドレスは、それぞれ内部フレームの宛先および送信元を指定して、元のエンドステーションによって送信されます。
A TRILL Data frame also potentially has two VLAN tags, as discussed in Sections 4.1.2 and 4.1.3 below, that can carry two different VLAN Identifiers and specify priority.
TRILLデータフレームには、以下のセクション4.1.2および4.1.3で説明するように、2つの異なるVLAN IDを伝送して優先度を指定できる2つのVLANタグも含まれる可能性があります。
Flow:
+-----+ +-------+ +-------+ +-------+ +-------+ +----+
| ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb |
+-----+ |ingress| |transit| ^ |transit| |egress | +----+
+-------+ +-------+ | +-------+ +-------+
|
Outer Ethernet Header: |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address (RB4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address (RB3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (RB2) Nickname | Ingress (RB1) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address (ESb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address (ESa) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original Ethernet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: TRILL Data Encapsulation over Ethernet
図7：イーサネット上のTRILLデータカプセル化
A "VLAN Tag" (formerly known as a Q-tag), also known as a "C-tag" for customer tag, includes a VLAN ID and a priority field as shown in Figure 8. The "VLAN ID" may be zero, indicating that no VLAN is specified, just a priority, although such frames are called "priority tagged" rather than "VLAN tagged" [802.1Q-2005].
図8に示すように、カスタマータグの「Cタグ」とも呼ばれる「VLANタグ」（以前のQタグ）には、VLAN IDと優先度フィールドが含まれています。「VLAN ID」はゼロの場合があります、これはVLANが指定されておらず、優先度のみが指定されていることを示します。ただし、このようなフレームは「VLANタグ付き」ではなく「優先度タグ付き」と呼ばれます[802.1Q-2005]。
Use of [802.1ad] S-tags, also known as service tags, and use of stacked tags, are beyond the scope of this document.
[802.1ad] Sタグ（サービスタグとも呼ばれる）の使用、およびスタックタグの使用は、このドキュメントの範囲外です。
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Priority | C | VLAN ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 8: VLAN Tag Information
図8：VLANタグ情報
As recommended in [802.1Q-2005], Rbridges SHOULD be implemented so as to allow use of the full range of VLAN IDs from 0x001 through 0xFFE. Rbridges MAY support a smaller number of simultaneously active VLAN IDs. VLAN ID zero is the null VLAN identifier and indicates that no VLAN is specified while VLAN ID 0xFFF is reserved.
[802.1Q-2005]で推奨されているように、0x001から0xFFEまでのVLAN IDの全範囲を使用できるようにRbridgeを実装する必要があります（SHOULD）。 Rbridgeは、同時にアクティブになるVLAN IDの少数をサポートする場合があります。 VLAN ID 0はnull VLAN識別子であり、VLAN ID 0xFFFが予約されている間はVLANが指定されていないことを示します。
The VLAN ID 0xFFF MUST NOT be used. Rbridges MUST discard any frame they receive with an Outer.VLAN ID of 0xFFF. Rbridges MUST discard any frame for which they examine the Inner.VLAN ID and find it to be 0xFFF; such examination is required at all egress Rbridges that decapsulate a frame.
VLAN ID 0xFFFを使用してはなりません（MUST NOT）。 Rbridgeは、0xFFFのOuter.VLAN IDで受信したフレームを破棄する必要があります。 Rbridgeは、Inner.VLAN IDを検査して0xFFFであると判断したフレームを破棄する必要があります。このような検査は、フレームをカプセル化解除するすべての出力Rbridgeで必要です。
The "C" bit shown in Figure 8 is not used in the Inner.VLAN in TRILL. It MUST be set to zero there by ingress RBridges, transparently forwarded by transit RBridges, and is ignored by egress RBridges.
図8に示す「C」ビットは、TRILLのInner.VLANでは使用されません。これは、入口RBridgeによってゼロに設定されなければならず、中継RBridgeによって透過的に転送され、出口RBridgeによって無視されます。
As specified in [802.1Q-2005], the priority field contains an unsigned value from 0 through 7 where 1 indicates the lowest priority, 7 the highest priority, and the default priority zero is considered to be higher than priority 1 but lower than priority 2. The [802.1ad] amendment to [802.1Q-2005] permits mapping some adjacent pairs of priority levels into a single priority level with and without drop eligibility. Ongoing work in IEEE 802.1 (802.1az, Appendix E) suggests the ability to configure "priority groups" that have a certain guaranteed bandwidth. RBridges ports MAY also implement such options. RBridges are not required to implement any particular number of distinct priority levels but may treat one or more adjacent priority levels in the same fashion.
[802.1Q-2005]で指定されているように、優先度フィールドには0から7までの符号なしの値が含まれ、1は最低の優先度、7は最高の優先度を示し、デフォルトの優先度0は優先度1より高く、優先度より低いと見なされます。 2. [802.1Q-2005]の[802.1ad]修正により、優先度レベルのいくつかの隣接するペアを、ドロップの適格性の有無にかかわらず、単一の優先度レベルにマッピングできます。 IEEE 802.1（802.1az、付録E）で現在進行中の作業により、特定の保証された帯域幅を持つ「優先グループ」を構成する機能が提案されています。 RBridgesポートもそのようなオプションを実装してもよい（MAY）。 RBridgeは、特定の数の異なる優先度レベルを実装する必要はありませんが、1つ以上の隣接する優先度レベルを同じ方法で処理できます。
Frames with the same source address, destination address, VLAN, and priority that are received on the same port as each other and are transmitted on the same port MUST be transmitted in the order received unless the RBridge classifies the frames into more fine-grained flows, in which case this ordering requirement applies to each such flow. Frames in the same VLAN with the same priority and received on the same port may be sent out different ports if multipathing is in effect. (See Appendix C.)
送信元アドレス、宛先アドレス、VLAN、優先度が同じで、互いに同じポートで受信され、同じポートで送信されるフレームは、RBridgeがフレームをより細かいフローに分類しない限り、受信順に送信する必要があります。この場合、この順序付け要件は、そのような各フローに適用されます。マルチパスが有効になっている場合、同じVLAN内で同じ優先度を持ち、同じポートで受信されたフレームは、異なるポートに送信される可能性があります。 （付録Cを参照してください。）
The C-Tag Ethertype [RFC5342] is 0x8100.
C-Tag Ethertype [RFC5342]は0x8100です。
The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN tag information associated with the native frame when it was ingressed or the VLAN tag information associated with a TRILL ESADI frame when that frame was created. When a TRILL frame passes through a transit RBridge, the Inner.VLAN MUST NOT be changed except when VLAN mapping is being intentionally performed within that RBridge.
「Inner VLAN Tag Information」（Inner.VLAN）フィールドには、ネイティブフレームが入力されたときに関連付けられたVLANタグ情報、またはフレームが作成されたときにTRILL ESADIフレームに関連付けられたVLANタグ情報が含まれます。 TRILLフレームがトランジットRBridgeを通過するとき、そのRBridge内でVLANマッピングが意図的に実行されている場合を除き、Inner.VLANを変更してはなりません（MUST NOT）。
When a native frame arrives at an RBridge, the associated VLAN ID and priority are determined as specified in [802.1Q-2005] (see Appendix D and [802.1Q-2005], Section 6.7). If the RBridge is an appointed forwarder for that VLAN and the delivery of the frame requires transmission to one or more other links, this ingress RBridge forms a TRILL Data frame with the associated VLAN ID and priority placed in the Inner.VLAN information.
ネイティブフレームがRBridgeに到着すると、関連付けられたVLAN IDと優先順位が[802.1Q-2005]（付録Dと[802.1Q-2005]、セクション6.7を参照）の指定に従って決定されます。 RBridgeがそのVLANの指定されたフォワーダーであり、フレームの配信に1つ以上の他のリンクへの送信が必要な場合、この入力RBridgeは、関連付けられたVLAN IDと優先度がInner.VLAN情報に配置されたTRILLデータフレームを形成します。
The VLAN ID is required at the ingress Rbridge as one element in determining the appropriate egress Rbridge for a known unicast frame and is needed at the ingress and every transit Rbridge for multi-destination frames to correctly prune the distribution tree.
VLAN IDは、既知のユニキャストフレームの適切な出力Rbridgeを決定するための1つの要素として入力Rbridgeで必要であり、配布先ツリーの配布および適切なプルーニングのために、複数宛先フレームの入力およびすべての中継Rbridgeで必要です。
TRILL frames sent by an RBridge, except for some TRILL-Hello frames, use an Outer.VLAN ID specified by the Designated RBridge (DRB) for the link onto which they are being sent, referred to as the Designated VLAN. For TRILL data and ESADI frames, the priority in the Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN tag.
RBridgeによって送信されるTRILLフレームは、一部のTRILL-Helloフレームを除き、指定されたVLANと呼ばれる、送信先のリンクに対して指定されたRBridge（DRB）によって指定されたOuter.VLAN IDを使用します。 TRILLデータとESADIフレームの場合、Outer.VLANタグの優先度は、Inner.VLANタグの優先度に設定する必要があります（SHOULD）。
TRILL frames forwarded by a transit RBridge use the priority present in the Inner.VLAN of the frame as received. TRILL Data frames are sent with the priority associated with the corresponding native frame when received (see Appendix D). TRILL IS-IS frames SHOULD be sent with priority 7.
中継RBridgeによって転送されるTRILLフレームは、フレームのInner.VLANにある優先度を受信時に使用します。 TRILLデータフレームは、受信時に対応するネイティブフレームに関連付けられた優先度で送信されます（付録Dを参照）。 TRILL IS-ISフレームは、優先度7で送信する必要があります。
Whether an Outer.VLAN tag actually appears on the wire when a TRILL frame is sent depends on the configuration of the RBridge port through which it is sent in the same way as the appearance of a VLAN tag on a frame sent by an [802.1Q-2005] bridge depends on the configuration of the bridge port (see Section 4.9.2).
TRILLフレームが送信されたときにOuter.VLANタグが実際に回線に表示されるかどうかは、[802.1Qによって送信されたフレームにVLANタグが表示されるのと同じ方法で送信されるRBridgeポートの構成によって異なります。 -2005]ブリッジは、ブリッジポートの構成に依存します（4.9.2項を参照）。
Each Ethernet frame has a single Frame Check Sequence (FCS) that is computed to cover the entire frame, for detecting frame corruption due to bit errors on a link. Thus, when a frame is encapsulated, the original FCS is not included but is discarded. Any received frame for which the FCS check fails SHOULD be discarded (this may not be possible in the case of cut through forwarding). The FCS normally changes on encapsulation, decapsulation, and every TRILL hop due to changes in the outer destination and source addresses, the decrementing of the hop count, etc.
各イーサネットフレームには、フレーム全体をカバーするように計算された単一のフレームチェックシーケンス（FCS）があり、リンク上のビットエラーによるフレームの破損を検出します。したがって、フレームがカプセル化されると、元のFCSは含まれずに破棄されます。 FCSチェックに失敗した受信フレームは破棄する必要があります（これはカットスルー転送の場合は不可能である可能性があります）。 FCSは通常、カプセル化、カプセル化解除、およびすべてのTRILLホップで変更されます。これは、外部の宛先アドレスと送信元アドレスの変更、ホップカウントの減少などによるものです。
Although the FCS is normally calculated just before transmission, it is desirable, when practical, for an FCS to accompany a frame within an RBridge after receipt. That FCS could then be dynamically updated to account for changes to the frame during Rbridge processing and used for transmission or checked against the FCS calculated for frame transmission. This optional, more continuous use of an FCS would be helpful in detecting some internal RBridge failures such as memory errors.
FCSは通常、送信の直前に計算されますが、実際には、FCSが受信後にRBridge内のフレームに付随することが望ましいです。次に、そのFCSを動的に更新して、Rbridge処理中のフレームの変更に対応し、送信に使用したり、フレーム送信用に計算されたFCSと照合したりできます。このオプションの、FCSの継続的な使用は、メモリエラーなどの一部の内部RBridge障害の検出に役立ちます。
TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing protocol. IS-IS has the following advantages:
TRILLは、ルーティングプロトコルとしてIS-IS [ISO10589] [RFC1195]の拡張を使用します。 IS-ISには次の利点があります。
o It runs directly over Layer 2, so therefore it may be run without configuration (no IP addresses need to be assigned).
o レイヤー2で直接実行されるため、構成なしで実行できます（IPアドレスを割り当てる必要はありません）。
o It is easy to extend by defining new TLV (type-length-value) data elements and sub-elements for carrying TRILL information.
o TRILL情報を伝送するための新しいTLV（type-length-value）データ要素とサブ要素を定義することで、拡張は簡単です。
This section describes TRILL use of IS-IS, except for the TRILL-Hello protocol, which is described in Section 4.4, and the MTU-probe and MTU-ack messages that are described in Section 4.3.
このセクションでは、4.4で説明されているTRILL-Helloプロトコルと、4.3で説明されているMTUプローブおよびMTU-ackメッセージを除いて、IS-ISのTRILL使用について説明します。
Each RBridge has a unique 48-bit (6-octet) IS-IS System ID. This ID may be derived from any of the RBridge's unique MAC addresses.
各RBridgeには、一意の48ビット（6オクテット）IS-ISシステムIDがあります。このIDは、RBridgeの一意のMACアドレスのいずれかから取得できます。
A pseudonode is assigned a 7-octet ID by the DRB that created it, by taking a 6-octet ID owned by the DRB, and appending another octet. The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID unless the DRB has to create IDs for pseudonodes for more than 255 links. The only constraint for correct operation is that the 7-octet ID be unique within the campus, and that the 7th octet be nonzero. An RBridge has a 7-octet ID consisting of its 6-octet system ID concatenated with a zero octet.
疑似ノードには、DRBが所有する6オクテットIDを取得し、別のオクテットを追加することにより、それを作成したDRBによって7オクテットIDが割り当てられます。疑似ノードIDを形成するために使用される6オクテットIDは、DRBが255を超えるリンクの疑似ノードのIDを作成する必要がない限り、DRBのIDである必要があります（SHOULD）。正しく動作するための唯一の制約は、7オクテットIDがキャンパス内で一意であり、7番目のオクテットがゼロ以外であることです。 RBridgeの7オクテットIDは、6オクテットのシステムIDとゼロオクテットで連結されています。
In this document, we use the term "IS-IS ID" to refer to the 7-octet quantity that can be either the ID of an RBridge or a pseudonode.
このドキュメントでは、「IS-IS ID」という用語を使用して、RBridgeまたは疑似ノードのIDになることができる7オクテットの数量を指します。
TRILL implements a separate IS-IS instance from any used by Layer 3, that is, different from the one used by routers. Layer 3 IS-IS frames must be distinguished from TRILL IS-IS frames even when those Layer 3 IS-IS frames are transiting an RBridge campus.
TRILLは、レイヤー3で使用されるIS-ISインスタンスを個別に実装します。つまり、ルーターで使用されるものとは異なります。レイヤー3 IS-ISフレームは、それらのレイヤー3 IS-ISフレームがRBridgeキャンパスを通過する場合でも、TRILL IS-ISフレームと区別する必要があります。
Layer 3 IS-IS native frames have special multicast destination addresses specified for that purpose, such as AllL1ISs or AllL2ISs. When they are TRILL encapsulated, these multicast addresses appear as the Inner.MacDA and the Outer.MacDA will be the All-RBridges multicast address.
レイヤ3 IS-ISネイティブフレームには、AllL1ISやAllL2ISなど、その目的のために指定された特別なマルチキャスト宛先アドレスがあります。それらがTRILLカプセル化されている場合、これらのマルチキャストアドレスはInner.MacDAとして表示され、Outer.MacDAはAll-RBridgesマルチキャストアドレスになります。
Within TRILL, there is an IS-IS instance across all Rbridges in the campus as described in Section 4.2.3. This instance uses TRILL IS-IS frames that are distinguished by having a different Ethertype "L2-IS-IS". Additionally, for TRILL IS-IS frames that are multicast, there is a distinct multicast destination address of All-IS-IS-RBridges. TRILL IS-IS frames do not have a TRILL header.
TRILL内では、セクション4.2.3で説明されているように、キャンパス内のすべてのRbridgeにIS-ISインスタンスがあります。このインスタンスは、異なるEthertype「L2-IS-IS」を持つことで区別されるTRILL IS-ISフレームを使用します。さらに、マルチキャストであるTRILL IS-ISフレームの場合、All-IS-IS-RBridgesの個別のマルチキャスト宛先アドレスがあります。 TRILL IS-ISフレームにはTRILLヘッダーがありません。
ESADI is a separate protocol from the IS-IS instance implemented by all the RBridges. There is a separate ESADI instance for each VLAN, and ESADI frames are encapsulated just like TRILL Data frames. After the TRILL header, the ESADI frame has an inner Ethernet header with the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype followed by the ESADI frame.
ESADIは、すべてのRBridgeによって実装されるIS-ISインスタンスとは別のプロトコルです。 VLANごとに個別のESADIインスタンスがあり、ESADIフレームはTRILLデータフレームと同じようにカプセル化されます。 TRILLヘッダーの後に、ESADIフレームには、 "All-ESADI-RBridges"のInner.MacDAと "L2-IS-IS" Ethertypeの後にESADIフレームが続く内部イーサネットヘッダーがあります。
All Rbridges MUST participate in the TRILL IS-IS instance, which constitutes a single Level 1 IS-IS area using the fixed area address zero. TRILL IS-IS frames are never forwarded by an RBridge but are locally processed on receipt. (Such processing may cause the RBridge to send additional TRILL IS-IS frames.) A TRILL IS-IS frame on an 802.3 link is structured as shown below. All such frames are Ethertype encoded. The RBridge port out of which such a frame is sent will strip the outer VLAN tag if configured to do so.
すべてのRbridgeはTRILL IS-ISインスタンスに参加する必要があります。これは、固定エリアアドレス0を使用する単一のレベル1 IS-ISエリアを構成します。 TRILL IS-ISフレームは、RBridgeによって転送されることはありませんが、受信時にローカルで処理されます。 （このような処理により、RBridgeは追加のTRILL IS-ISフレームを送信する場合があります。）802.3リンク上のTRILL IS-ISフレームは、次のように構成されています。このようなフレームはすべてEthertypeでエンコードされています。そのようなフレームが送信されるRBridgeポートは、そうするように構成されている場合、外部VLANタグを削除します。
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-IS-IS-RBridges continued | Source RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2-IS-IS Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IS-IS Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TRILL IS-IS Frame Format
図9：TRILL IS-ISフレーム形式
The VLAN specified in the Outer.VLAN information will be the Designated VLAN for the link on which the frame is sent, except in the case of some TRILL Hellos.
一部のTRILL Helloの場合を除いて、Outer.VLAN情報で指定されたVLANは、フレームが送信されるリンクの指定VLANになります。
RBridges default to using TRILL Hellos unless, on a per-port basis, they are configured to use P2P Hellos. TRILL-Hello frames are specified in Section 4.4.
RBridgeは、ポートごとにP2P Helloを使用するように構成されていない限り、デフォルトでTRILL Helloを使用します。 TRILL-Helloフレームはセクション4.4で指定されています。
RBridges are normally configured to use P2P Hellos only when there are exactly two of them on a link. However, it can occur that RBridges are misconfigured as to which type of hello to use. This is safe but may cause lack of RBridge-to-RBridge connectivity. An RBridge port configured to use P2P Hellos ignores TRILL Hellos, and an RBridge port configured to use TRILL Hellos ignores P2P Hellos.
RBridgeは通常、リンク上に正確に2つある場合にのみP2P Helloを使用するように構成されます。ただし、使用するhelloのタイプに関してRBridgeが誤って構成されている場合があります。これは安全ですが、RBridge-to-RBridge接続の欠如を引き起こす可能性があります。 P2P Helloを使用するように構成されたRBridgeポートはTRILL Helloを無視し、TRILL Helloを使用するように構成されたRBridgeポートはP2P Helloを無視します。
If any of the RBridge ports on a link is configured to use TRILL Hellos, one of such RBridge ports using TRILL Hellos is elected DRB (Designated RBridge) for the link. This election is based on configured priority (most significant field), and source MAC address, as communicated by TRILL-Hello frames. The DRB, as described in Section 4.2.4.2, designates the VLAN to be used on the link for inter-RBridge communication by the non-P2P RBridge ports and appoints itself or other RBridges on the link as appointed forwarder (see Section 4.2.4.3) for VLANs on the link.
リンク上のRBridgeポートのいずれかがTRILL Hellosを使用するように構成されている場合、TRILL Hellosを使用するそのようなRBridgeポートの1つがリンクのDRB（指定RBridge）として選出されます。この選択は、TRILL-Helloフレームによって通信されるように、構成された優先順位（最上位フィールド）と送信元MACアドレスに基づいています。セクション4.2.4.2で説明されているように、DRBはリンク上で非P2P RBridgeポートによるRBridge通信に使用されるVLANを指定し、リンク上の自身または他のRBridgeを任命されたフォワーダーとして指定します（セクション4.2.4.3を参照） ）リンク上のVLANの場合。
RBridge ports can be configured to use IS-IS P2P Hellos. This implies that the port is a point-to-point link to another RBridge. An RBridge MUST NOT provide any end-station (native frame) service on a port configured to use P2P Hellos.
RBridgeポートは、IS-IS P2P Helloを使用するように構成できます。これは、ポートが別のRBridgeへのポイントツーポイントリンクであることを意味します。 RBridgeは、P2P Helloを使用するように構成されたポートでエンドステーション（ネイティブフレーム）サービスを提供してはなりません（MUST NOT）。
As with Layer 3 IS-IS, such P2P ports do not participate in a DRB election. They send all frames VLAN tagged as being in the Desired Designated VLAN configured for the port, although this tag may be stripped if the port is so configured. Since all traffic through the port should be TRILL frames or Layer 2 control frames, such a port cannot be an appointed forwarder. RBridge P2P ports MUST use the IS-IS three-way handshake [RFC5303] so that extended circuit IDs are associated with the link for tie breaking purposes (see Section 4.5.2).
レイヤ3 IS-ISと同様に、そのようなP2PポートはDRB選定に参加しません。ポートに設定されている必要な指定VLANにタグ付けされているすべてのフレームVLANを送信しますが、ポートがそのように設定されている場合、このタグは削除される場合があります。ポートを経由するすべてのトラフィックはTRILLフレームまたはレイヤ2制御フレームである必要があるため、そのようなポートは指定されたフォワーダーにはなれません。 RBridge P2PポートはIS-IS 3ウェイハンドシェイク[RFC5303]を使用する必要があるため、拡張回線IDはタイブレークの目的でリンクに関連付けられます（セクション4.5.2を参照）。
Even if all simple links in a network are physically point-to-point, if some of the nodes are bridges, the bridged LANs that include those bridges appear to be multi-access links to attached RBridges. This would necessitate using TRILL Hellos for proper operation in many cases.
ネットワーク内のすべての単純なリンクが物理的にポイントツーポイントである場合でも、ノードの一部がブリッジである場合、それらのブリッジを含むブリッジLANは、接続されたRBridgeへのマルチアクセスリンクのように見えます。これには、多くの場合、適切な操作のためにTRILL Helloを使用する必要があります。
While it is safe to erroneously configure ports as P2P, this may result in lack of connectivity.
誤ってポートをP2Pとして構成しても安全ですが、これにより接続が失われる可能性があります。
TRILL IS-IS elects one RBridge for each LAN link to be the Designated RBridge (DRB), that is, to have special duties. The Designated RBridge:
TRILL IS-ISは、LANリンクごとに1つのRBridgeを指定RBridge（DRB）として選択します。つまり、特別な役割を果たします。指定されたRBridge：
o Chooses, for the link, and announces in its TRILL Hellos, the Designated VLAN ID to be used for inter-RBridge communication. This VLAN is used for all TRILL-encapsulated data and ESADI frames and TRILL IS-IS frames except some TRILL-Hello frames.
o リンクについて選択し、そのTRILL Hellosで、RBridge間通信に使用する指定VLAN IDをアナウンスします。このVLANは、一部のTRILL-Helloフレームを除いて、すべてのTRILLカプセル化データとESADIフレーム、およびTRILL IS-ISフレームに使用されます。
o If the link is represented in the IS-IS topology as a pseudonode, chooses a pseudonode ID and announces that in its TRILL Hellos and issues an LSP on behalf of the pseudonode.
o リンクがIS-ISトポロジで疑似ノードとして表されている場合、疑似ノードIDを選択し、それをTRILL Hellosで通知し、疑似ノードに代わってLSPを発行します。
o Issues CSNPs.
o CSNPを発行します。
o For each VLAN-x appearing on the link, chooses an RBridge on the link to be the appointed VLAN-x forwarder (the DRB MAY choose itself to be the appointed VLAN-x forwarder for all or some of the VLANs).
o リンクに表示される各VLAN-xについて、指定されたVLAN-xフォワーダーとしてリンク上のRBridgeを選択します（DRBは、すべてまたは一部のVLANの指定されたVLAN-xフォワーダーとして自分自身を選択できます）。
o Before appointing a VLAN-x forwarder (including appointing itself), wait at least its Holding Time (to ensure it is the DRB).
o VLAN-xフォワーダーを指定する前に（それ自体を指定することを含む）、少なくともその保持時間を待機します（DRBであることを確認するため）。
o If configured to send TRILL-Hello frames, continues to send them on all its enabled VLANs that have been configured in the Announcing VLANs set of the DRB, which defaults to all enabled VLANs.
o TRILL-Helloフレームを送信するように構成されている場合、DRBのアナウンスVLANセットで構成されているすべての有効なVLANでフレームを送信し続けます。デフォルトでは、すべての有効なVLANに設定されます。
The appointed VLAN-x forwarder for a link is responsible for the following points. In connection with the loop avoidance points, when an appointed forwarder for a port is "inhibited", it drops any native frames it receives and does not transmit but instead drops any native frames it decapsulates, in the VLAN for which it is appointed.
リンクに指定されたVLAN-xフォワーダーは、次の点を担当します。ループ回避ポイントに関連して、ポートに指定されたフォワーダーが「禁止」されている場合、ポートが指定されているVLANで、受信して送信しないネイティブフレームをドロップしますが、カプセル化解除したネイティブフレームをドロップします。
o Loop avoidance:
o ループ回避：
- Inhibiting itself for a time, configurable per port from zero to 30 seconds, which defaults to 30 seconds, after it sees a root bridge change on the link (see Section 4.9.3.2).
- リンクをルートブリッジで変更した後、ポートごとに0から30秒（デフォルトは30秒）まで構成可能です（4.9.3.2を参照）。
- Inhibiting itself for VLAN-x, if it has received a Hello in which the sender asserts that it is appointed forwarder and that is either + received on VLAN-x (has VLAN-x as its Outer.VLAN) or + was originally sent on VLAN-x as indicated inside the body of the Hello.
- VLAN-xに対して自分自身を禁止します。Helloを受信し、送信者がそれがフォワーダーとして任命され、+ VLAN-xで受信した（VLAN-xがOuter.VLANである）か、または+が最初に送信されたと表明した場合Helloの本体内に示されているVLAN-x。
- Optionally, not decapsulating a frame from ingress RBridge RBm unless it has RBm's LSP, and the root bridge on the link it is about to forward onto is not listed in RBm's list of root bridges for VLAN-x. This is known as the "decapsulation check" or "root bridge collision check".
- オプションで、RBmのLSPがない限り、フレームを入力RBridge RBmからカプセル化解除せず、転送しようとしているリンク上のルートブリッジは、VLAN-xのRBmのルートブリッジのリストに表示されません。これは、「カプセル化解除チェック」または「ルートブリッジ衝突チェック」と呼ばれます。
o Unless inhibited (see above), receiving VLAN-x native traffic from the link and forwarding it as appropriate.
o 禁止されていない限り（上記を参照）、VLAN-xネイティブトラフィックをリンクから受信し、必要に応じて転送します。
o Receiving VLAN-x traffic for the link and, unless inhibited, transmitting it in native form after decapsulating it as appropriate.
o リンクのVLAN-xトラフィックを受信し、禁止されていない限り、適切にカプセル化を解除した後、ネイティブ形式で送信します。
o Learning the MAC address of local VLAN-x nodes by looking at the source address of VLAN-x frames from the link.
o リンクからのVLAN-xフレームの送信元アドレスを調べることにより、ローカルVLAN-xノードのMACアドレスを学習します。
o Optionally learning the port of local VLAN-x nodes based on any sort of Layer 2 registration protocols, such as IEEE 802.11 association and authentication.
o オプションで、IEEE 802.11の関連付けや認証など、あらゆる種類のレイヤー2登録プロトコルに基づいてローカルVLAN-xノードのポートを学習します。
o Keeping track of the { egress RBridge, VLAN, MAC address } of distant VLAN-x end nodes, learned by looking at the fields { ingress RBridge, Inner.VLAN ID, Inner.MacSA } from VLAN-x frames being received for decapsulation onto the link.
o カプセル化解除のために受信されたVLAN-xフレームからのフィールド{ingress RBridge、Inner.VLAN ID、Inner.MacSA}を調べて、遠く離れたVLAN-xエンドノードの{出力RBridge、VLAN、MACアドレス}を追跡するリンク。
o Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames to learn the presence of local multicast listeners and multicast routers.
o オプションで、ネイティブIGMP [RFC3376]、MLD [RFC2710]、およびMRD [RFC4286]フレームを観察して、ローカルマルチキャストリスナーとマルチキャストルーターの存在を確認します。
o Optionally listening to TRILL ESADI messages for VLAN-x to learn { egress RBridge, VLAN-x, MAC address } triplets and the confidence level of such explicitly advertised end nodes.
o オプションで、VLAN-xのTRILL ESADIメッセージをリッスンして{出力RBridge、VLAN-x、MACアドレス}トリプレットと、明示的にアドバタイズされたエンドノードの信頼レベルを学習します。
o Optionally advertising VLAN-x end nodes, on links for which it is appointed VLAN-x forwarder, in ESADI messages.
o オプションで、ESADIメッセージでVLAN-xフォワーダーとして指定されているリンク上のVLAN-xエンドノードをアドバタイズします。
o Sending TRILL-Hello frames on VLAN-x unless the Announcing VLANs set for the port has been configured to disable them.
o ポートに設定されたアナウンスVLANが無効に設定されていない限り、VLAN-xでTRILL-Helloフレームを送信します。
o Listening to BPDUs on the common spanning tree to learn the root bridge, if any, for that link and to report in its LSP the complete set of root bridges seen on any of its links for which it is appointed forwarder for VLAN-x.
o 共通スパニングツリーのBPDUをリッスンして、そのリンクのルートブリッジがあればそれを学習し、そのLSPで、VLAN-xのフォワーダーとして指定されているリンクで見られるルートブリッジの完全なセットを報告します。
When an appointed forwarder observes that the DRB on a link has changed, it no longer considers itself appointed for that link until appointed by the new DRB.
任命されたフォワーダーは、リンク上のDRBが変更されたことを観察すると、新しいDRBによって任命されるまで、そのリンクに自分が任命されたとは見なしません。
The information items in the TRILL IS-IS LSP that are mentioned elsewhere in this document are listed below. Unless an item is stated in the list below to be optional, it MUST be included. Other items MAY be included unless their inclusion is prohibited elsewhere in this document. The actual encoding of this information and the IS-IS Type or sub-Type values for any new IS-IS TLV or sub-TLV data elements are specified in separate documents [RFC6165] [RFC6326].
このドキュメントの他の場所で言及されているTRILL IS-IS LSPの情報項目を以下に示します。以下のリストでアイテムがオプションであると述べられていない限り、それは含まれなければなりません。他の項目は、このドキュメントの他の場所での包含が禁止されていない限り、含まれる場合があります。この情報の実際のエンコーディングと、新しいIS-IS TLVまたはサブTLVデータ要素のIS-ISタイプまたはサブタイプの値は、個別のドキュメント[RFC6165] [RFC6326]で指定されています。
1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of RBridge RBn, and the cost of the link to each of those neighbors. RBridges MUST use the Extended IS Reachability TLV (#22, also known as "wide metric" [RFC5305]) and MUST NOT use the IS Reachability TLV (#2, also known as "narrow metric"). To facilitate efficient operation without configuration and consistent with [802.1D], RBridges SHOULD, by default, set the cost of a link to the integer part of twenty trillion (20,000,000,000,000) divided by the RBridge port's bit rate but not more than 2**24-2 (16,777,214); for example, the cost for a link accessed by a 1Gbps port would default to 20,000. (Note that 2**24-1 has a special meaning in IS-IS and would exclude the link from SPF routes.) However, the link cost MAY, by default, be decreased for aggregated links and/or increased to not more than 2**24-2 if the link appears to be a bridged LAN. The tested MTU for the link (see Section 4.3) MAY be included via a sub-TLV.
1. RBridge RBnのネイバー（疑似ノードとRBridge）のIS-IS ID、およびそれらのネイバーのそれぞれへのリンクのコスト。 RBridgeは、拡張IS到達可能性TLV（＃22、「ワイドメトリック」[RFC5305]とも呼ばれる）を使用する必要があり、IS到達可能性TLV（＃2、「ナローメトリック」とも呼ばれる）を使用してはなりません（MUST NOT）。構成せずに[802.1D]と一貫した効率的な運用を容易にするために、RBridgesはデフォルトで、リンクのコストを20兆（20,000,000,000,000）の整数部をRBridgeポートのビットレートで割った2以下の整数部分に設定する必要があります。 24-2（16,777,214）;たとえば、1Gbpsポートによってアクセスされるリンクのコストは、デフォルトで20,000になります。 （2 ** 24-1はIS-ISで特別な意味を持ち、リンクをSPFルートから除外することに注意してください。）ただし、リンクコストは、デフォルトで、集約リンクに対して減少するか、増加して最大値にならない場合があります。リンクがブリッジLANのように見える場合は2 ** 24-2。リンクのテスト済みMTU（セクション4.3を参照）は、サブTLVを介して含めることができます（MAY）。
2. The following information in connection with the nickname or each of the nicknames of RBridge RBn:
2. RBridge RBnのニックネームまたは各ニックネームに関連する以下の情報：
2.1. The nickname value (2 octets).
2.1. ニックネームの値（2オクテット）。
2.2. The unsigned 8-bit priority for RBn to have that nickname (see Section 3.7.3).
2.2. RBnがそのニックネームを持つための符号なし8ビット優先順位（セクション3.7.3を参照）。
2.3. The 16-bit unsigned priority of that nickname to becoming a distribution tree root.
2.3. 配布ツリーのルートになるためのそのニックネームの16ビット符号なし優先順位。
3. The maximum TRILL Header Version supported by RBridge RBn.
3. RBridge RBnでサポートされる最大TRILLヘッダーバージョン。
4. The following information, in addition to the per-nickname tree root priority, in connection with distribution tree determination and announcement. (See Section 4.5 for further details on how this information is used.)
4. 配布ツリーの決定とアナウンスに関連する、ニックネームごとのツリールートの優先順位に加えて、次の情報。 （この情報の使用方法の詳細については、4.5節を参照してください。）
4.1. An unsigned 16-bit number that is the number of trees all RBridges in the campus calculate if RBn has the highest priority tree root.
4.1. キャンパス内のすべてのRBridgeがRBnに最高の優先度のツリールートがあるかどうかを計算するツリーの数である符号なし16ビット数。
4.2. A second unsigned 16-bit number that is the number of trees RBn would like to use.
4.2. RBnが使用するツリーの数である2番目の符号なし16ビット数。
4.3. A third unsigned 16-bit number that is the maximum number of distribution trees that RBn is able to calculate.
4.3. RBnが計算できる分散ツリーの最大数である3番目の符号なし16ビット数。
4.4. A first list of nicknames that are intended distribution trees for all RBridges in the campus to calculate.
4.4. キャンパス内のすべてのRBridgeが計算する配布ツリーを意図したニックネームの最初のリスト。
4.5. A second list of nicknames that are distribution trees RBn would like to use when ingressing multi-destination frames.
4.5. 複数の宛先フレームに入るときにRBnが使用する分散ツリーであるニックネームの2番目のリスト。
5. The list of VLAN IDs of VLANs directly connected to RBn for links on which RBn is the appointed forwarder for that VLAN. (Note: An RBridge may advertise that it is connected to additional VLANs in order to receive additional frames to support certain VLAN-based features beyond the scope of this specification as mentioned in Section 4.8.4 and in a separate document concerning VLAN mapping inside RBridges.) RBridges may associate advertised connectivity to different groups of VLANs with specific nicknames they hold. In addition, the LSP contains the following information on a per-VLAN basis:
5. RBnがそのVLANの指定されたフォワーダーであるリンクのRBnに直接接続されているVLANのVLAN IDのリスト。 （注：RBridgeは、セクション4.8.4およびRBridges内のVLANマッピングに関する別のドキュメントで説明されているように、この仕様の範囲を超える特定のVLANベースの機能をサポートする追加のフレームを受信するために、追加のVLANに接続されていることを通知する場合があります。）RBridgeは、アドバタイズされた接続を、VLANの異なるグループに、それらが保持する特定のニックネームに関連付ける場合があります。さらに、LSPには、VLANごとの次の情報が含まれています。
5.1. Per-VLAN Multicast Router attached flags: This is two bits of information that indicate whether there is an IPv4 and/or IPv6 multicast router attached to the Rbridge on that VLAN. An RBridge that does not do IP multicast control snooping MUST set both of these bits (see Section 4.5.4). This information is used because IGMP [RFC3376] and MLD [RFC2710] Membership Reports MUST be transmitted to all links with IP multicast routers, and SHOULD NOT be transmitted to links without such routers. Also, all frames for IP-derived multicast addresses MUST be transmitted to all links with IP multicast routers (within a VLAN), in addition to links from which an IP node has explicitly asked to join the group the frame is for, except for some IP multicast addresses that MUST be treated as broadcast.
5.1. VLANごとのマルチキャストルーター接続フラグ：これは、そのVLAN上のRbridgeに接続されたIPv4またはIPv6マルチキャストルーターがあるかどうかを示す2ビットの情報です。 IPマルチキャスト制御スヌーピングを行わないRBridgeは、これらのビットの両方を設定する必要があります（セクション4.5.4を参照）。 IGMP [RFC3376]およびMLD [RFC2710]メンバーシップレポートはIPマルチキャストルーターとのすべてのリンクに送信する必要があり、そのようなルーターのないリンクには送信してはならないため（SHOULD NOT）、この情報が使用されます。また、一部の場合を除いて、IPノードがフレームのグループへの参加を明示的に要求したリンクに加えて、（VLAN内の）IPマルチキャストルーターとのすべてのリンクにIP派生マルチキャストアドレスのすべてのフレームを送信する必要がありますブロードキャストとして扱う必要があるIPマルチキャストアドレス。
5.2. Per-VLAN mandatory announcement of the set of IDs of Root bridges for any of RBn's links on which RBn is appointed forwarder for that VLAN. Where MSTP (Multiple Spanning Tree Protocol) is running on a link, this is the root bridge of the CIST (Common and Internal Spanning Tree). This is to quickly detect cases where two Layer 2 clouds accidentally get merged, and where there might otherwise temporarily be two DRBs for the same VLAN on the same link. (See Section 4.2.4.3.)
5.2. RBnがそのVLANのフォワーダーとして指定されているRBnリンクのいずれかについて、ルートブリッジのIDセットのVLANごとの必須アナウンス。 MSTP（Multiple Spanning Tree Protocol）がリンク上で実行されている場合、これはCIST（共通および内部スパニングツリー）のルートブリッジです。これは、2つのレイヤ2クラウドが誤って結合された場合や、同じリンク上の同じVLANに一時的に2つのDRBが存在する可能性がある場合をすばやく検出するためです。 （4.2.4.3項を参照してください。）
5.3. Optionally, per-VLAN Layer 2 multicast addresses derived from IPv4 IGMP and IPv6 MLD notification messages received from attached end nodes on that VLAN, indicating the location of listeners for these multicast addresses (see Section 4.5.5).
5.3. 必要に応じて、VLAN上の接続されたエンドノードから受信したIPv4 IGMPおよびIPv6 MLD通知メッセージから派生したVLANごとのレイヤー2マルチキャストアドレス。これらのマルチキャストアドレスのリスナーの場所を示します（セクション4.5.5を参照）。
5.4. Per-VLAN ESADI protocol participation flag, priority, and holding time. If this flag is one, it indicates that the RBridge wishes to receive such TRILL ESADI frames (see Section 4.2.5.1).
5.4. VLANごとのESADIプロトコル参加フラグ、優先度、および保持時間。このフラグが1の場合、RBridgeがそのようなTRILL ESADIフレームを受信したいことを示します（セクション4.2.5.1を参照）。
5.5. Per-VLAN appointed forwarder status lost counter (see Section 4.8.3).
5.5. VLANごとに指定されたフォワーダステータスロストカウンタ（セクション4.8.3を参照）。
6. Optionally, the largest TRILL IS-IS frame that the RBridge can handle using the originatingLSPBufferSize TLV #14 (see Section 4.3).
6. 必要に応じて、RBridgeがoriginatingLSPBufferSize TLV＃14を使用して処理できる最大のTRILL IS-ISフレーム（セクション4.3を参照）。
7. Optionally, a list of VLAN groups where address learning is shared across that VLAN group (see Section 4.8.4). Each VLAN group is a list of VLAN IDs, where the first VLAN ID listed in a group, if present, is the "primary" and the others are "secondary". This is to detect misconfiguration of features outside the scope of this document. RBridges that do not support features such as "shared VLAN learning" ignore this field.
7. オプションで、アドレス学習がそのVLANグループ全体で共有されるVLANグループのリスト（セクション4.8.4を参照）。各VLANグループはVLAN IDのリストであり、グループにリストされている最初のVLAN IDが存在する場合は「プライマリ」であり、その他は「セカンダリ」です。これは、このドキュメントの範囲外の機能の設定ミスを検出するためです。 「共有VLAN学習」などの機能をサポートしないRBridgeは、このフィールドを無視します。
8. Optionally, the Authentication TLV #10 (see Section 6).
8. オプションで、認証TLV＃10（セクション6を参照）。
RBridges that are the appointed VLAN-x forwarder for a link MAY participate in the TRILL ESADI protocol for that VLAN. But all transit RBridges MUST properly forward TRILL ESADI frames as if they were multicast TRILL Data frames. TRILL ESADI frames are structured like IS-IS frames but are always TRILL encapsulated on the wire as if they were TRILL Data frames.
リンクに指定されたVLAN-xフォワーダーであるRBridgeは、そのVLANのTRILL ESADIプロトコルに参加する場合があります。ただし、すべての中継RBridgeは、TRILL ESADIフレームをマルチキャストTRILLデータフレームであるかのように適切に転送する必要があります。 TRILL ESADIフレームはIS-ISフレームのように構造化されていますが、常にTRILLデータフレームであるかのように、ワイヤー上でカプセル化されます。
Because of this forwarding, it appears to the ESADI protocol at an RBridge that it is directly connected by a shared virtual link to all other RBridges in the campus running ESADI for that VLAN. RBridges that do not implement the ESADI protocol or are not appointed forwarder for that VLAN do not decapsulate or locally process any TRILL ESADI frames they receive for that VLAN. In other words, these frames are transparently tunneled through transit RBridges. Such transit RBridges treat them exactly as multicast TRILL Data frames and no special processing is invoked due to such forwarding.
この転送のため、RBridgeのESADIプロトコルからは、共有仮想リンクによって、そのVLANのESADIを実行しているキャンパス内の他のすべてのRBridgeに直接接続されているように見えます。 ESADIプロトコルを実装していない、またはそのVLANのフォワーダーに指定されていないRBridgeは、そのVLANで受信したTRILL ESADIフレームをカプセル化解除したり、ローカルで処理したりしません。つまり、これらのフレームは通過RBridgeを介して透過的にトンネリングされます。そのようなトランジットRBridgeは、それらをマルチキャストTRILLデータフレームとして正確に扱い、そのような転送のために特別な処理は呼び出されません。
TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown below. The outer VLAN tag will not be present if it was stripped by the port out of which the frame was sent.
IEEE 802.3リンクで送信されるTRILL ESADIフレームは、次のように構成されます。外側のVLANタグは、フレームの送信元のポートによって削除された場合は存在しません。
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address | Sending RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL | V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-ESADI-RBridges continued | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Inner.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TRILL ESADI Frame Format
図10：TRILL ESADIフレーム形式
The Next Hop Destination Address or Outer.MacDA is the All-RBridges multicast address. The VLAN specified in the Outer.VLAN information will always be the Designated VLAN for the link on which the frame is sent. The V and R fields will be zero while the M field will be one. The VLAN specified in the Inner.VLAN information will be the VLAN to which the ESADI frame applies. The Origin RBridge MAC Address or Inner.MacSA MUST be a globally unique MAC address owned by the RBridge originating the ESADI frame, for example, any of its port MAC addresses, and each RBridge MUST use the same Inner.MacSA for all of the ESADI frames that RBridge originates.
Next Hop Destination AddressまたはOuter.MacDAは、All-RBridgesマルチキャストアドレスです。 Outer.VLAN情報で指定されたVLANは、常にフレームが送信されるリンクの指定VLANになります。 VフィールドとRフィールドはゼロになり、Mフィールドは1になります。 Inner.VLAN情報で指定されたVLANは、ESADIフレームが適用されるVLANになります。オリジンRBridge MACアドレスまたはInner.MacSAは、ESADIフレームを発信するRBridgeが所有するグローバルに一意のMACアドレス（たとえば、任意のポートMACアドレス）である必要があり、各RBridgeはすべてのESADIに対して同じInner.MacSAを使用する必要がありますRBridgeが発生するフレーム。
An RBridge does not send any Hellos because of participation in the ESADI protocol. The information available in the TRILL IS-IS link state database is sufficient to determine the ESADI DRB on the virtual link for the ESADI protocol for each VLAN. In particular, the link state database information for each RBridge includes the VLANs, if any, for which that RBridge is participating in the ESADI protocol, its priority for being selected as DRB for the ESADI protocol for each of those VLANs, its holding time, and its IS-IS system ID for breaking ties in priority.
ESADIプロトコルに参加しているため、RBridgeはHellosを送信しません。 TRILL IS-ISリンク状態データベースで利用可能な情報は、各VLANのESADIプロトコルの仮想リンク上のESADI DRBを決定するのに十分です。特に、各RBridgeのリンク状態データベース情報には、そのRBridgeがESADIプロトコルに参加しているVLANが含まれている場合、それらのVLANのESADIプロトコルのDRBとして選択されるための優先順位、その保持時間、優先順位を下げるためのIS-ISシステムID。
An RBridge need not perform any routing calculation because of participation in the ESADI protocol. Since all RBridges participating in ESADI for a particular VLAN appear to be connected to the same single virtual link, there are no routing decisions to be made. A participating RBridge merely transmits the ESADI frames it originates on this virtual link.
ESADIプロトコルに参加しているため、RBridgeはルーティング計算を実行する必要はありません。特定のVLANのESADIに参加しているすべてのRBridgeは、同じ単一の仮想リンクに接続されているように見えるため、ルーティングを決定する必要はありません。参加しているRBridgeは、この仮想リンクで発生したESADIフレームを送信するだけです。
The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual link. For robustness, a participating RBridge that determines that some other RBridge should be ESADI DRB on such a virtual link but has not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB holding time MAY also send a TRILL-ESADI-CSNP on the virtual link. A participating RBridge that determines that no other RBridges are participating in the ESADI protocol for a particular VLAN SHOULD NOT send ESADI information or TRILL-ESADI-CSNPs on the virtual link for that VLAN.
ESADI DRBはESADI仮想リンクでTRILL-ESADI-CSNPフレームを送信します。堅牢性のために、他の一部のRBridgeがそのような仮想リンク上のESADI DRBである必要があるが、少なくともESADI DRB保持時間内にTRILL-ESADI-CSNPを受信または送信していないと判断する参加RBridgeも、TRILL-ESADI-CSNPを送信できます。仮想リンク上。他のRBridgeが特定のVLANのESADIプロトコルに参加していないことを決定する参加RBridgeは、そのVLANの仮想リンクでESADI情報またはTRILL-ESADI-CSNPを送信してはいけません。
The information distributed with the ESADI protocol is the list of local end-station MAC addresses known to the originating RBridge and, for each such address, a one-octet unsigned "confidence" rating in the range 0-254 (see Section 4.8).
ESADIプロトコルで配布される情報は、発信元のRBridgeが認識しているローカル端末MACアドレスのリストであり、そのような各アドレスに対して、1オクテットの符号なし「信頼度」の範囲が0〜254です（セクション4.8を参照）。
It is intended to optionally provide for VLAN ID translation within RBridges, as specified in [VLAN-MAPPING]. This includes translating TRILL ESADI frames. If TRILL ESADI frames could contain VLAN IDs in arbitrary internal locations, such translation would be impractical. Thus, TRILL ESADI frames MUST NOT contain the VLAN ID of the VLAN to which they apply in the body of the frame after the Inner.VLAN tag.
[VLAN-MAPPING]で指定されているように、RBridge内でオプションでVLAN ID変換を提供することを目的としています。これには、TRILL ESADIフレームの変換が含まれます。 TRILL ESADIフレームが任意の内部ロケーションにVLAN IDを含む可能性がある場合、そのような変換は実用的ではありません。したがって、TRILL ESADIフレームには、フレームの本文でInner.VLANタグの後に適用するVLANのVLAN IDを含めてはなりません（MUST NOT）。
This section describes the logical result desired. Alternative implementation methods may be used as long as they produce the same forwarding behavior.
このセクションでは、望ましい論理結果について説明します。同じ転送動作を生成する限り、代替の実装方法を使用できます。
When building a forwarding table, an RBridge RB1 calculates shortest paths from itself as described in Appendix C.1 of [RFC1195]. Nicknames are added into the shortest path calculation as a final step, just as with an end node. If multiple RBridges, say, RBa and RBb, claim the same nickname, this is a transitory condition and one of RBa or RBb will defer and choose a new nickname. However, RB1 simply adds that nickname as if it were attached to both RBa and RBb, and uses its standard shortest path calculation to choose the next hop.
[RFC1195]の付録C.1で説明されているように、転送テーブルを作成するとき、RBridge RB1は自身からの最短パスを計算します。ニックネームは、エンドノードと同様に、最終ステップとして最短パス計算に追加されます。複数のRBridge、たとえばRBaとRBbが同じニックネームを要求する場合、これは一時的な状態であり、RBaまたはRBbのいずれかが保留され、新しいニックネームが選択されます。ただし、RB1は単にそのニックネームをRBaとRBbの両方に接続されているかのように追加し、標準の最短パス計算を使用して次のホップを選択します。
An ingress RBridge RB2 maps a native frame's known unicast destination MAC address and VLAN into an egress RBridge nickname. If RB2 learns addresses only from the observation of received and decapsulated frames, then such MAC addresses cannot be duplicated within a VLAN in RB2 tables because more recent learned information, if of a higher or equal confidence, overwrites previous information and, if of a lower confidence, is ignored. However, duplicates of the same MAC within a VLAN can appear in ESADI data and between ESADI data and addresses learned from the observation of received and decapsulated frames, entered by manual configuration, or learned through Layer 2 registration protocols. If duplicate MAC addresses occur within a VLAN, RB2 sends frames to the MAC with the highest confidence. If confidences are also tied between the duplicates, for consistency it is suggested that RB2 direct all such frames (or all such frames in the same ECMP flow) toward the same egress RBridge; however, the use of other policies will not cause a network problem since transit RBridges do not examine the Inner.MacDA for known unicast frames.
入力RBridge RB2は、ネイティブフレームの既知のユニキャスト宛先MACアドレスとVLANを出力RBridgeニックネームにマッピングします。 RB2が受信およびカプセル化解除されたフレームの観測からのみアドレスを学習する場合、そのようなMACアドレスはRB2テーブル内のVLAN内で複製できません。これは、信頼度が高いか等しい場合、より新しい学習情報が以前の情報を上書きし、低い場合は上書きするためです。信頼、無視されます。ただし、VLAN内の同じMACの重複は、ESADIデータ内、およびESADIデータと、受信およびカプセル化解除されたフレームの観察から学習されたアドレス、手動構成によって入力されたアドレス、またはレイヤ2登録プロトコルを通じて学習されたアドレスの間に現れる可能性があります。重複したMACアドレスがVLAN内で発生した場合、RB2は最も高い信頼度でMACにフレームを送信します。重複の間にも信頼性が関連付けられている場合、一貫性を保つために、RB2はそのようなすべてのフレーム（または同じECMPフロー内のすべてのそのようなフレーム）を同じ出口RBridgeに向けることをお勧めします。ただし、トランジットRBridgeは既知のユニキャストフレームについてInner.MacDAを検査しないため、他のポリシーを使用してもネットワークの問題は発生しません。
There are two reasons why it is important to know what size of frame each inter-RBridge link in the campus can support:
キャンパス内の各RBridgeリンクがサポートできるフレームのサイズを知ることが重要である理由は2つあります。
1. RBridge RB1 must know the size of link state information messages it can generate that will be guaranteed to be forwardable across all inter-RBridge links in the campus.
1. RBridge RB1は、キャンパス内のすべてのRBridge間リンクで転送可能であることが保証される、生成できるリンク状態情報メッセージのサイズを知っている必要があります。
2. If traffic engineering tools know which links support larger than minimally acceptable data packet sizes, paths can be computed that can support large data packets.
2. トラフィックエンジニアリングツールが、最小許容サイズを超えるデータパケットサイズをサポートするリンクを知っている場合は、大きなデータパケットをサポートできるパスを計算できます。
In a stable campus, there must ultimately be agreement among all RBridges on the value of "Sz", the minimum acceptable inter-RBridge link size for the campus, for the proper operation of TRILL IS-IS. All RBridges MUST format their link state information messages to be in chunks of size no larger than what they believe Sz to be. Also, every RBridge RB1 SHOULD test each of its RBridge adjacencies, say, to RB2, to ensure that the RB1-RB2 link can forward packets of at least size Sz.
安定したキャンパスでは、TRILL IS-ISを適切に運用するために、最終的にすべてのRBridge間で、キャンパスのRBridge間リンクの最小許容サイズである「Sz」の値について合意する必要があります。すべてのRBridgeは、リンク状態情報メッセージを、Szであると信じるサイズ以下のサイズのチャンクにフォーマットする必要があります。また、すべてのRBridge RB1は、RBridgeの隣接関係のそれぞれを、たとえばRB2に対してテストして、RB1-RB2リンクが少なくともサイズSzのパケットを転送できることを確認する必要があります（SHOULD）。
Sz has no direct effect on end stations and is not directly related to any end-station-to-end-station "path MTU". Methods of using Sz or any link MTU information gathered by TRILL IS-IS in the traffic engineering of routes or the determination of any path MTU is beyond the scope of this document. Native frames that, after TRILL encapsulation, exceed the MTU of a link on which they are sent will generally be discarded.
Szはエンドステーションに直接影響を与えることはなく、エンドステーションからエンドステーションへの「パスMTU」には直接関係しません。ルートのトラフィックエンジニアリングでTRILL IS-ISによって収集されたSzまたはリンクMTU情報を使用する方法、またはパスMTUの決定は、このドキュメントの範囲外です。 TRILLカプセル化の後に、それらが送信されるリンクのMTUを超えるネイティブフレームは、通常破棄されます。
Sz is determined by having each RBridge (optionally) advertise, in its LSP, its assumption of the value of the campus-wide Sz. This LSP element is known in IS-IS as the originatingLSPBufferSize, TLV #14. The default and minimum value for Sz, and the implicitly advertised value of Sz if the TLV is absent, is 1470 octets. This length (which is also the maximum size of a TRILL-Hello) was chosen to make it extremely unlikely that a TRILL control frame, even with reasonable additional headers, tags, and/or encapsulation, would encounter MTU problems on an inter-RBridge link.
Szは、各RBridgeに（オプションで）キャンパス全体のSzの値の仮定をLSPで通知させることによって決定されます。このLSP要素は、IS-ISではoriginatingLSPBufferSize、TLV＃14として知られています。 Szのデフォルト値と最小値、およびTLVが存在しない場合に暗黙的にアドバタイズされるSzの値は、1470オクテットです。この長さ（これはTRILL-Helloの最大サイズでもあります）は、妥当な追加のヘッダー、タグ、および/またはカプセル化があっても、TRILL制御フレームがRBridge間でMTUの問題に遭遇する可能性を極めて低くするために選択されましたリンク。
The campus-wide value of Sz is the smallest value of Sz advertised by any RBridge.
キャンパス全体のSzの値は、RBridgeによってアドバタイズされるSzの最小値です。
There are two new TRILL IS-IS message types for use between pairs of RBridge neighbors to test the bidirectional packet size capacity of their connection. These messages are:
接続の双方向パケットサイズ容量をテストするために、RBridgeネイバーのペア間で使用する2つの新しいTRILL IS-ISメッセージタイプがあります。これらのメッセージは次のとおりです。
-- MTU-probe
-- MTU-ack
Both the MTU-probe and the MTU-ack are padded to the size being tested.
MTUプローブとMTU-ackの両方が、テストされるサイズに埋め込まれます。
Sending of MTU-probes is optional; however, an RBridge RB2 that receives an MTU-probe from RB1 MUST respond with an MTU-ack padded to the same size as the MTU-probe. The MTU-probe MAY be multicast to All-RBridges, or unicast to a specific RBridge. The MTU-ack is normally unicast to the source of the MTU-probe to which it responds but MAY be multicast to All-RBridges.
MTUプローブの送信はオプションです。ただし、RB1からMTUプローブを受信するRBridge RB2は、MTUプローブと同じサイズにパディングされたMTU-ackで応答する必要があります。 MTUプローブは、All-RBridgeにマルチキャストすることも、特定のRBridgeにユニキャストすることもできます（MAY）。 MTU-ackは通常、MTUプローブが応答するMTUプローブのソースにユニキャストされますが、All-RBridgeにマルチキャストされる場合があります。
If RB1 fails to receive an MTU-ack to a probe of size X from RB2 after k tries (where k is a configurable parameter whose default is 3), then RB1 assumes the RB1-RB2 link cannot support size X. If X is not greater than Sz, then RB1 sets the "failed minimum MTU test" flag for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 advertises the largest tested X for each adjacency in the TRILL Hellos RB1 sends on that link, and RB1 MAY advertise X as an attribute of the link to RB2 in RB1's LSP.
k回試行した後、RB1がRB2からサイズXのプローブへのMTU-ackの受信に失敗した場合（kはデフォルトが3の設定可能なパラメーターです）、RB1はRB1-RB2リンクがサイズXをサポートできないと想定します。 Szより大きい場合、RB1はRB1のHelloでRB2の「失敗した最小MTUテスト」フラグを設定します。サイズXが成功し、X> Szの場合、RB1は、そのリンクでRB1が送信するTRILL Hellosの隣接ごとにテストされた最大のXをアドバタイズし、RB1は、RB1のLSPのRB2へのリンクの属性としてXをアドバタイズできます。
The TRILL-Hello protocol is a little different from the Layer 3 IS-IS LAN Hello protocol and uses a new type of IS-IS message known as a TRILL-Hello.
TRILL-Helloプロトコルは、レイヤ3 IS-IS LAN Helloプロトコルとは少し異なり、TRILL-Helloと呼ばれる新しいタイプのIS-ISメッセージを使用します。
The reason for defining this new type of link in TRILL is that in Layer 3 IS-IS, the LAN Hello protocol may elect multiple Designated Routers (DRs) since, when choosing a DR, routers ignore other routers with whom they do not have 2-way connectivity. Also, Layer 3 IS-IS LAN Hellos are padded, to avoid forming adjacencies between neighbors that can't speak the maximum-sized packet to each other. This means, in Layer 3 IS-IS, that neighbors that have connectivity to each other, but with an MTU on that connection less than what they perceive as maximum sized packets, will not see each other's Hellos. The result is that routers might form cliques, resulting in the link turning into multiple pseudonodes.
TRILLでこの新しいタイプのリンクを定義する理由は、レイヤー3 IS-ISでは、LAN Helloプロトコルが複数の指定ルーター（DR）を選択する可能性があるためです。DRを選択すると、ルーターは、DRを選択していない他のルーターを無視するためです。ウェイ接続。また、レイヤ3 IS-IS LAN Helloは、最大サイズのパケットを互いに話すことができないネイバー間の隣接関係を形成しないように、パディングされます。つまり、レイヤー3 IS-ISでは、相互に接続しているが、その接続のMTUが最大サイズのパケットとして認識しているものよりも小さいネイバーは、お互いのHelloを認識しません。その結果、ルーターがクリークを形成し、リンクが複数の疑似ノードになる可能性があります。
This behavior is fine for Layer 3, but not for Layer 2, where loops may form if there are multiple DRBs. Therefore, the TRILL-Hello protocol is a little different from Layer 3 IS-IS's LAN Hello protocol.
この動作はレイヤー3では問題ありませんが、複数のDRBがある場合にループが形成される可能性があるレイヤー2では問題ありません。したがって、TRILL-Helloプロトコルは、レイヤ3 IS-ISのLAN Helloプロトコルとは少し異なります。
One other issue with TRILL-Hellos is to ensure that subsets of the information can appear in any single message, and be processable, in the spirit of IS-IS LSPs and CSNPs. TRILL-Hello frames, even though they are not padded, can become very large. An example where this might be the case is when some sort of backbone technology interconnects hundreds of TRILL sites over what would appear to TRILL to be a giant Ethernet, where the RBridges connected to that cloud will perceive that backbone to be a single link with hundreds of neighbors.
TRILL-Hellosのもう1つの問題は、IS-IS LSPおよびCSNPの精神で、情報のサブセットを単一のメッセージに表示し、処理できるようにすることです。 TRILL-Helloフレームは、パディングされていなくても、非常に大きくなる可能性があります。これが当てはまる例は、ある種のバックボーンテクノロジーが、TRILLから巨大なイーサネットであると思われるものを介して何百ものTRILLサイトを相互接続する場合です。そのクラウドに接続されたRBridgeは、そのバックボーンが数百の単一のリンクであると認識します。隣人の。
In TRILL (unlike in Layer 3 IS-IS), the DRB is selected based solely on priority and MAC address. In other words, if RB2 receives a TRILL-Hello from RB1 with higher (priority, MAC), RB2 defers to RB1 as DRB, regardless of whether RB1 lists RB2 in RB1's TRILL-Hello.
TRILLでは（レイヤー3 IS-ISとは異なり）、DRBは優先度とMACアドレスのみに基づいて選択されます。言い換えると、RB2がより高い（優先度、MAC）を持つRB1からTRILL-Helloを受信した場合、RB1がRB1のTRILL-HelloにRB2をリストするかどうかに関係なく、RB2はRB1にDRBに従います。
Although the neighbor list in a TRILL-Hello does not influence the DRB election, it does determine what is announced in LSPs. RB1 only reports links to RBridges with which it has two-way connectivity. If RB1 is the DRB on a link, and for whatever reason (MTU mismatch, or one-way connectivity) RB1 and RB2 do not have two-way connectivity, then RB2 does not report a link to RB1 (or the pseudonode), and RB1 (or RB1 on behalf of the pseudonode) does not report a link to RB2.
TRILL-HelloのネイバーリストはDRBの選択に影響しませんが、LSPでアナウンスされる内容を決定します。 RB1は、双方向接続を持つRBridgeへのリンクのみを報告します。 RB1がリンク上のDRBであり、何らかの理由（MTUの不一致、または一方向接続）の場合、RB1とRB2には双方向接続がないため、RB2はRB1（または疑似ノード）へのリンクを報告しません。 RB1（または疑似ノードの代わりにRB1）は、RB2へのリンクを報告しません。
The TRILL-Hello has a new IS-IS message type. It starts with the same fixed header as an IS-IS LAN Hello, which includes the 7-bit priority for the issuing RBridge to be DRB on that link. TRILL-Hellos are sent with the same timing as IS-IS LAN Hellos.
TRILL-Helloに新しいIS-ISメッセージタイプがあります。 IS-IS LAN Helloと同じ固定ヘッダーで始まります。これには、そのリンクで発行するRBridgeがDRBになるための7ビットの優先順位が含まれます。 TRILL-Helloは、IS-IS LAN Helloと同じタイミングで送信されます。
TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA, but excluding any Outer.VLAN or other tags, MUST NOT exceed 1470 octets in length and SHOULD NOT be padded. The following information MUST appear in every TRILL-Hello. References to "TLV" may actually be a "sub-TLV" as specified in separate documents [RFC6165] [RFC6326].
Outer.MacDAとOuter.MacSAを含み、Outer.VLANまたはその他のタグを除外したTRILL-Helloメッセージは、長さが1470オクテットを超えてはならず、パディングしないでください。次の情報は、すべてのTRILL-Helloに表示する必要があります。 「TLV」への参照は、実際には別のドキュメント[RFC6165] [RFC6326]で指定されている「サブTLV」である場合があります。
1. The VLAN ID of the Designated VLAN for the link.
1. リンクの指定VLANのVLAN ID。
2. A copy of the Outer.VLAN ID with which the Hello was tagged on sending.
2. Helloが送信時にタグ付けされたOuter.VLAN IDのコピー。
3. A 16-bit port ID assigned by the sending RBridge to the port the TRILL-Hello is sent on such that no two ports of that RBridge have the same port ID.
3. 送信RBridgeによってTRILL-Helloポートに割り当てられた16ビットのポートIDは、そのRBridgeの2つのポートが同じポートIDを持たないように送信されます。
4. A nickname of the sending RBridge.
4. 送信RBridgeのニックネーム。
5. Two flags as follows:
5. 次の2つのフラグ：
5.a. A flag that, if set, indicates that the sender has detected VLAN mapping on the link, within the past 2 of its Holding Times.
5.a.フラグが設定されている場合、送信者がリンク上のVLANマッピングを保持時間の過去2以内に検出したことを示します。
5.b. A flag that, if set, indicates that the sender believes it is appointed forwarder for the VLAN and port on which the TRILL-Hello was sent.
5.b.設定されている場合、送信者がTRILL-Helloが送信されたVLANおよびポートのフォワーダーに任命されていると送信者が信じていることを示すフラグ。
The following information MAY appear:
次の情報が表示される場合があります。
1. The set of VLANs for which end-station service is enabled on the port.
1. 端末でエンドステーションサービスが有効になっているVLANのセット。
2. Several flags as follows:
2. 次のようないくつかのフラグ：
2.a. A flag that, if set, indicates that the sender's port was configured as an access port.
2.a.設定されている場合、送信者のポートがアクセスポートとして構成されたことを示すフラグ。
2.b. A flag that, if set, indicates that the sender's port was configured as a trunk port.
2.b.設定されている場合、送信者のポートがトランクポートとして構成されたことを示すフラグ。
2.c. A bypass pseudonode flag, as described below in this section.
2.c.このセクションで後述する、疑似ノードのバイパスフラグ。
3. If the sender is the DRB, the Rbridges (excluding itself) that it appoints as forwarders for that link and the VLANs for which it appoints them. As described below, this TLV is designed so that not all the appointment information need be included in each Hello. Its absence means that appointed forwarders should continue as previously assigned.
3. 送信者がDRBの場合、そのリンクのフォワーダーとして指定するRbridge（それ自体を除く）と、それらが指定するVLAN。以下に説明するように、このTLVは、各Helloにすべての予定情報を含める必要がないように設計されています。その不在は、任命されたフォワーダーが以前に割り当てられたように継続する必要があることを意味します。
4. The TRILL neighbor list. This is a new TLV, not the same as the IS-IS Neighbor TLV, in order to accommodate fragmentation and reporting MTU on the link (see Section 4.4.2.1).
4. TRILLネイバーリスト。これは、リンク上のフラグメンテーションとレポートMTUに対応するために、IS-ISネイバーTLVとは異なる新しいTLVです（4.4.2.1項を参照）。
The Appointed Forwarders TLV specifies a range of VLANs and, within that range, specifies which Rbridge, if any, other than the DRB, is appointed forwarder for the VLANs in that range [RFC6326]. Appointing an RBridge as forwarder on a port for a VLAN that is not enabled on that port has no effect.
Appointed Forwarders TLVは、VLANの範囲を指定し、その範囲内で、DRB以外の場合は、そのRVLANがその範囲のVLANのフォワーダーとして指定されていることを指定します[RFC6326]。そのポートで有効になっていないVLANのポートで、RBridgeをフォワーダーとして指定しても効果はありません。
It is anticipated that many links between RBridges will be point-to-point, in which case using a pseudonode merely adds to the complexity. If the DRB specifies the bypass pseudonode bit in its TRILL-Hellos, the RBridges on the link just report their adjacencies as point-to-point. This has no effect on how LSPs are flooded on a link. It only affects what LSPs are generated.
RBridge間の多くのリンクがポイントツーポイントになることが予想されます。その場合、疑似ノードを使用すると、複雑さが増すだけです。 DRBがTRILL-Helloでバイパス疑似ノードビットを指定している場合、リンク上のRBridgeは、隣接関係をポイントツーポイントとして報告するだけです。これは、LSPがリンクでフラッディングされる方法には影響しません。生成されるLSPにのみ影響します。
For example, if RB1 and RB2 are the only RBridges on the link and RB1 is the DRB, then if RB1 creates a pseudonode that is used, there are 3 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say they are connected to RB1.25. Whereas if DRB RB1 sets the bypass pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and RB2 each reporting connectivity to each other.
たとえば、RB1とRB2がリンク上の唯一のRBridgeであり、RB1がDRBである場合、RB1が使用される疑似ノードを作成する場合、3つのLSPがあります。たとえば、RB1.25（疑似ノード）、RB1、およびRB2。RB1.25はRB1とRB2への接続を報告し、RB1とRB2はそれぞれRB1.25に接続されているとだけ言います。一方、DRB RB1がHellosにバイパス疑似ノードビットを設定する場合、LSPは2つしかありません。RB1とRB2はそれぞれ、相互への接続を報告しています。
A DRB SHOULD set the bypass pseudonode bit for its links unless, for a particular link, it has seen at least two simultaneous adjacencies on the link at some point since it last rebooted.
DRBは、特定のリンクについて、最後に再起動してからある時点でリンク上に少なくとも2つの同時隣接が見られない限り、リンクのバイパス疑似ノードビットを設定する必要があります（SHOULD）。
The new TRILL Neighbor TLV includes the following information for each neighbor it lists:
新しいTRILLネイバーTLVには、リストされているネイバーごとに次の情報が含まれています。
1. The neighbor's MAC address.
1. ネイバーのMACアドレス。
2. MTU size to this neighbor as a 2-octet unsigned integer in units of 4-octet chunks. The value zero indicates that the MTU is untested.
2. 4オクテットのチャンクを単位とする2オクテットの符号なし整数としてこのネイバーへのMTUサイズ。値0は、MTUがテストされていないことを示します。
3. A flag for "failed minimum MTU test".
3. 「失敗した最小MTUテスト」のフラグ。
To allow partial reporting of neighbors, the neighbor IDs MUST be sorted by ID. If a set of neighbors { X1, X2, X3, ... Xn } is reported in RB1's Hello, then X1 < X2 < X3, ... < Xn. If RBridge RB2's ID is between X1 and Xn, and does not appear in RB1's Hello, then RB2 knows that RB1 has not heard RB2's Hello.
ネイバーの部分的なレポートを許可するには、ネイバーIDをIDでソートする必要があります。一連のネイバー{X1、X2、X3、... Xn}がRB1のHelloで報告される場合、X1 <X2 <X3、... <Xnです。 RBridge RB2のIDがX1とXnの間にあり、RB1のHelloに表示されない場合、RB2は、RB1がRB2のHelloを聞いていないことを認識しています。
Additionally there are two overall TRILL Neighbor List TLV flags: "the smallest ID I reported in this Hello is the smallest ID of any neighbor", and "the largest ID I reported in this Hello is the largest ID of any neighbor". If all the neighbors fit in RB1's TRILL-Hello, both flags will be set.
さらに、2つの全体的なTRILLネイバーリストTLVフラグがあります。「このHelloで報告した最小IDは、任意のネイバーの最小IDです」と、「このHelloで報告した最大IDは、任意のネイバーの最大IDです」。すべてのネイバーがRB1のTRILL-Helloに適合する場合、両方のフラグが設定されます。
If RB1 reports { X1, ... Xn } in its Hello, with the "smallest" flag set, and RB2's ID is smaller than X1, then RB2 knows that RB1 has not heard RB2's Hello. Similarly, if RB2's ID is larger than Xn and the "largest" flag is set, then RB2 knows that RB1 has not heard RB2's Hello.
RB1が「最小」のフラグが設定されたHelloで{X1、... Xn}を報告し、RB2のIDがX1より小さい場合、RB2は、RB1がRB2のHelloを聞いていないことを認識しています。同様に、RB2のIDがXnより大きく、「最大」のフラグが設定されている場合、RB2は、RB1がRB2のHelloを聞いたことがないことを認識しています。
To ensure that any RBridge RB2 can definitively determine whether RB1 can hear RB2, RB1's neighbor list MUST eventually cover every possible range of IDs, that is, within a period that depends on RB1's policy and not necessarily within any specific period such as the holding time. In other words, if X1 is the smallest ID reported in one of RB1's neighbor lists, and the "smallest" flag is not set, then X1 MUST also appear as the largest ID reported in a different TRILL-Hello neighbor list. Or, fragments may overlap, as long as there is no gap, such that some range, say, between Xi and Xj, never appears in any fragment.
すべてのRBridge RB2がRB1がRB2を聞くことができるかどうかを確実に判断できるようにするために、RB1のネイバーリストは最終的にすべての可能なIDの範囲をカバーする必要があります。 。つまり、X1がRB1のネイバーリストのいずれかで報告された最小のIDであり、「最小」フラグが設定されていない場合、X1は別のTRILL-Helloネイバーリストで報告された最大のIDとしても出現する必要があります。あるいは、ギャップがない限り、フラグメントが重複する可能性があります。たとえば、XiとXjの間の一部の範囲は、どのフラグメントにも表示されません。
The MTU-probe mechanism is designed to determine the MTU for transmissions between RBridges. MTU-probes and probe acknowledgements are only sent on the Designated VLAN.
MTUプローブメカニズムは、RBridge間の送信のMTUを決定するように設計されています。 MTUプローブとプローブ確認は、指定VLANでのみ送信されます。
An RBridge RBn maintains for each port the same VLAN information as a customer IEEE [802.1Q-2005] bridge, including the set of VLANs enabled for output through that port (see Section 4.9.2). In addition, RBn maintains the following TRILL-specific VLAN parameters per port:
RBridge RBnは、ポートを介した出力が有効になっているVLANのセットを含む、各ポートのカスタマーIEEE [802.1Q-2005]ブリッジと同じVLAN情報を維持します（セクション4.9.2を参照）。さらに、RBnはポートごとに以下のTRILL固有のVLANパラメーターを維持します。
a) Desired Designated VLAN: the VLAN that RBn, if it is the DRB, will specify in its TRILL-Hellos as the VLAN to be used by all RBridges on the link to communicate all TRILL frames, except some TRILL-Hellos. This MUST be a VLAN enabled on RBn's port. It defaults to the numerically lowest enabled VLAN ID, which is VLAN 1 for a default configuration RBridge.
a) 望ましい指定VLAN：RBn（DRBの場合）が、そのTRILL-Helloで、一部のTRILL-Helloを除くすべてのTRILLフレームを通信するためにリンク上のすべてのRBridgeによって使用されるVLANとして指定するVLAN。これは、RBnのポートで有効になっているVLANでなければなりません。デフォルトでは、数値的に最小の有効なVLAN IDになります。これは、デフォルト構成のRBridgeのVLAN 1です。
b) Designated VLAN: the VLAN being used on the link for all TRILL frames except some TRILL Hellos. This is RBn's Desired Designated VLAN if RBn believes it is the DRB or the Designated VLAN in the DRB's Hellos if RBn is not the DRB.
b) 指定VLAN：一部のTRILL Helloを除くすべてのTRILLフレームのリンクで使用されているVLAN。これは、RBnがDRBであると考える場合のRBnの望ましい指定VLANです。RBnがDRBでない場合は、DRBのHello内の指定VLANです。
c) Announcing VLANs set. This defaults to the enabled VLANs set on the port but may be configured to be a subset of the enabled VLANs.
c) VLANセットが発表されました。これは、デフォルトでポートに設定されている有効なVLANですが、有効なVLANのサブセットになるように構成できます。
d) Forwarding VLANs set: the set of VLANs for which an RBridge port is appointed VLAN forwarder on the port. This MUST contain only enabled VLANs for the port, possibly all enabled VLANs.
d) Forwarding VLANs set：RBridgeポートがポートのVLANフォワーダーとして指定されているVLANのセット。これには、ポートで有効になっているVLANのみが含まれている必要があります。
On each of its ports that is not configured to use P2P Hellos, an RBridge sends TRILL-Hellos Outer.VLAN tagged with each VLAN in a set of VLANs. This set depends on the RBridge's DRB status and the above VLAN parameters. RBridges send TRILL Hellos Outer.VLAN tagged with the Designated VLAN, unless that VLAN is not enabled on the port. In addition, the DRB sends TRILL Hellos Outer.VLAN tagged with each enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send TRILL-Hellos Outer.VLAN tagged with all enabled VLANs that are in the intersection of their Forwarding VLANs set and their Announcing VLANs set. More symbolically, TRILL-Hello frames, when sent, are sent as follows:
P2P Helloを使用するように構成されていない各ポートで、RBridgeは、一連のVLAN内の各VLANでタグ付けされたTRILL-Hellos Outer.VLANを送信します。このセットは、RBridgeのDRBステータスと上記のVLANパラメーターに依存します。 RBridgeは、指定されたVLANでタグ付けされたTRILL Hellos Outer.VLANを送信します（そのVLANがポートで有効になっていない場合を除く）。さらに、DRBは、そのアナウンスVLANセット内の有効な各VLANでタグ付けされたTRILL Hellos Outer.VLANを送信します。すべての非DRB RBridgeは、転送VLANセットとアナウンスVLANセットの交差点にあるすべての有効なVLANでタグ付けされたTRILL-Hellos Outer.VLANを送信します。より象徴的には、TRILL-Helloフレームが送信されると、次のように送信されます。
If sender is DRB intersection ( Enabled VLANs, union ( Designated VLAN, Announcing VLANs ) )
送信者がDRB交差の場合（有効なVLAN、ユニオン（指定VLAN、VLANのアナウンス））
If sender is not DRB intersection ( Enabled VLANs, union ( Designated VLAN, intersection ( Forwarding VLANs, Announcing VLANs ) ) )
送信者がDRB交差ではない場合（有効なVLAN、ユニオン（指定VLAN、交差（VLANの転送、VLANのアナウンス））））
Configuring the Announcing VLANs set to be null minimizes the number of TRILL-Hellos. In that case, TRILL-Hellos are only tagged with the Designated VLAN. Great care should be taken in configuring an RBridge to not send TRILL Hellos on any VLAN where that RBridge is appointed forwarder as, under some circumstances, failure to send such Hellos can lead to loops.
nullに設定されたアナウンスVLANを構成すると、TRILL-Helloの数が最小限になります。その場合、TRILL-Helloには指定VLANのみがタグ付けされます。状況によっては、このようなHelloの送信に失敗するとループが発生する可能性があるため、RBridgeがフォワーダーとして指定されているVLANでTRILL Helloを送信しないようにRBridgeを構成する場合は、細心の注意を払う必要があります。
The number of TRILL-Hellos is maximized, within this specification, by configuring the Announcing VLANs set to be the set of all enabled VLAN IDs, which is the default. In that case, the DRB will send TRILL-Hello frames tagged with all its Enabled VLAN tags; in addition, any non-DRB RBridge RBn will send TRILL-Hello frames tagged with the Designated VLAN, if enabled, and tagged with all VLANs for which RBn is an appointed forwarder. (It is possible to send even more TRILL-Hellos. In particular, non-DRB RBridges could send TRILL-Hellos on enabled VLANs for which they are not an appointed forwarder and which are not the Designated VLAN. This would cause no harm other than a further communications and processing burden.)
TRILL-Helloの数は、この仕様の範囲内で、デフォルトの有効なすべてのVLAN IDのセットになるようにアナウンスVLANセットを構成することにより最大化されます。その場合、DRBはすべての有効なVLANタグでタグ付けされたTRILL-Helloフレームを送信します。さらに、DRB以外のRBridge RBnはすべて、指定VLANでタグ付けされたTRILL-Helloフレームを送信します（有効な場合）。RBnが指定されたフォワーダーであるすべてのVLANでタグ付けされます。 （さらに多くのTRILL-Helloを送信することが可能です。特に、DRB以外のRBridgeは、指定されたフォワーダーではなく、指定VLANではない有効なVLANでTRILL-Helloを送信できます。これにより、他に害が生じることはありません。さらなる通信と処理の負担。）
When an RBridge port comes up, until it has heard a TRILL-Hello from a higher priority RBridge, it considers itself to be DRB on that port and sends TRILL-Hellos on that basis. Similarly, even if it has at some time recognized some other RBridge on the link as DRB, if it receives no TRILL-Hellos on that port from an RBridge with higher priority as DRB for a long enough time, as specified by IS-IS, it will revert to believing itself DRB.
RBridgeポートが起動すると、優先順位の高いRBridgeからTRILL-Helloを受信するまで、ポート自体がDRBであると見なし、それに基づいてTRILL-Helloを送信します。同様に、ある時点でリンク上の他のRBridgeをDRBとして認識した場合でも、IS-ISで指定されているように、DRBとして優先度の高いRBridgeからそのポートでTRILL-Helloを十分長い時間受信しない場合、それは自分自身をDRBと信じることに戻ります。
It is possible for an RBridge RB1 to have multiple ports to the same link. It is important for RB1 to recognize which of its ports are on the same link, so, for instance, if RB1 is appointed forwarder for VLAN A, RB1 knows that only one of its ports acts as appointed forwarder for VLAN A on that link.
RBridge RB1が同じリンクに複数のポートを持つことが可能です。 RB1がそのポートのどれが同じリンク上にあるかを認識することは重要です。たとえば、RB1がVLAN Aのフォワーダーに任命されている場合、RB1はそのリンクのVLAN Aの任命されたフォワーダーとしてポートの1つだけが機能することを知っています。
RB1 detects this condition based on receiving TRILL-Hello messages with the same IS-IS pseudonode ID on multiple ports. RB1 might have one set of ports, say, { p1, p2, p3 } on one link, and another set of ports { p4, p5 } on a second link, and yet other ports, say, p6, p7, p8, that are each on distinct links. Let us call a set of ports on the same link a "port group".
RB1は、複数のポートで同じIS-IS疑似ノードIDを持つTRILL-Helloメッセージを受信することに基づいてこの状態を検出します。 RB1には、1つのリンクに1セットのポート、たとえば{p1、p2、p3}と2番目のリンクに別のセットのポート{p4、p5}があり、さらに他のポート、たとえばp6、p7、p8があるとします。それぞれ別個のリンクにあります。同じリンク上の一連のポートを「ポートグループ」と呼びます。
If RB1 detects that a set of ports, say, { p1, p2, p3 }, is a port group on a link, then RB1 MUST ensure that it does not cause loops when it encapsulates and decapsulates traffic from/to that link. If RB1 is appointed forwarder for VLAN A on that Ethernet link, RB1 MUST encapsulate/decapsulate VLAN A on only one of the ports. However, if RB1 is appointed forwarder for more than one VLAN, RB1 MAY choose to load split among its ports, using one port for some set of VLANs, and another port for a disjoint set of VLANs.
RB1が{p1、p2、p3}などの一連のポートがリンク上のポートグループであることを検出した場合、RB1は、そのリンクとの間のトラフィックをカプセル化およびカプセル化解除するときにループが発生しないことを確認する必要があります。 RB1がそのイーサネットリンク上のVLAN Aのフォワーダーに指定されている場合、RB1はポートの1つだけでVLAN Aをカプセル化/カプセル化解除する必要があります。ただし、RB1が複数のVLANのフォワーダーに指定されている場合、RB1は、いくつかのVLANセットに1つのポートを使用し、独立したVLANセットに別のポートを使用して、ポート間でロードスプリットを選択できます。
If RB1 detects VLAN mapping occurring (see Section 4.4.5), then RB1 MUST NOT load split as appointed forwarder, and instead MUST act as appointed VLAN forwarder on that link on only one of its ports in the port group.
RB1がVLANマッピングの発生を検出した場合（セクション4.4.5を参照）、RB1は、指定されたフォワーダーとしてロードスプリットを行わず、代わりに、ポートグループ内のそのポートの1つのみでそのリンク上の指定されたVLANフォワーダーとして機能する必要があります。
When forwarding TRILL-encapsulated multi-destination frames to/from a link on which RB1 has a port group, RB1 MAY choose to load split among its ports, provided that it does not duplicate frames, and provided that it keeps frames for the same flow on the same port. If RB1's neighbor on that link, RB2, accepts multi-destination frames on that tree on that link from RB1, RB2 MUST accept the frame from any of RB2's adjacencies to RB1 on that link.
RB1にポートグループがあるリンクとの間でTRILLカプセル化された複数の宛先フレームを転送する場合、フレームを複製せず、同じフローのフレームを保持するという条件で、RB1はポート間でロードスプリットを選択できます。同じポート上。そのリンク上のRB1のネイバーであるRB2が、そのリンク上のそのツリー上のマルチ宛先フレームをRB1から受け入れる場合、RB2は、そのリンク上のRB2の隣接のいずれかからのフレームをRB1に受け入れる必要があります。
If an RBridge has more than one port connected to a link and those ports have the same MAC address, they can be distinguished by the port ID contained in TRILL-Hellos.
RBridgeにリンクに接続された複数のポートがあり、それらのポートが同じMACアドレスを持っている場合、それらはTRILL-Helloに含まれているポートIDで区別できます。
IEEE [802.1Q-2005] does not provide for bridges changing the C-tag VLAN ID for a tagged frame they receive, that is, mapping VLANs. Nevertheless, some bridge products provide this capability and, in any case, bridged LANs can be configured to display this behavior. For example, a bridge port can be configured to strip VLAN tags on output and send the resulting untagged frames onto a link leading to another bridge's port configured to tag these frames with a different VLAN. Although each port's configuration is legal under [802.1Q-2005], in the aggregate they perform manipulations not permitted on a single customer [802.1Q-2005] bridge. Since RBridge ports have the same VLAN capabilities as customer [802.1Q-2005] bridges, this can occur even in the absence of bridges. (VLAN mapping is referred to in IEEE 802.1 as "VLAN ID translation".)
IEEE [802.1Q-2005]では、ブリッジが受信するタグ付きフレームのCタグVLAN IDを変更する、つまりVLANをマッピングするブリッジは提供されていません。それでも、一部のブリッジ製品はこの機能を備えており、いずれの場合でも、この動作を表示するようにブリッジLANを構成できます。たとえば、ブリッジポートは、出力でVLANタグを取り除き、結果のタグなしフレームを、別のVLANでこれらのフレームにタグを付けるように構成された別のブリッジのポートにつながるリンクに送信するように構成できます。各ポートの設定は[802.1Q-2005]の下では合法ですが、全体として、単一のカスタマー[802.1Q-2005]ブリッジで許可されていない操作を実行します。 RBridgeポートはカスタマー[802.1Q-2005]ブリッジと同じVLAN機能を備えているため、ブリッジがない場合でもこれが発生する可能性があります。 （VLANマッピングは、IEEE 802.1では「VLAN ID変換」と呼ばれています。）
RBridges include the Outer.VLAN ID inside every TRILL-Hello message. When a TRILL-Hello is received, RBridges compare this saved copy with the Outer.VLAN ID information associated with the received frame. If these differ and the VLAN ID inside the Hello is X and the Outer.VLAN is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID Y.
RBridgeには、すべてのTRILL-Helloメッセージ内にOuter.VLAN IDが含まれています。 TRILL-Helloを受信すると、RBridgeはこの保存されたコピーを、受信したフレームに関連付けられたOuter.VLAN ID情報と比較します。これらが異なり、Hello内のVLAN IDがXでOuter.VLANがYの場合、VLAN ID XがVLAN ID Yにマッピングされていると見なすことができます。
When non-DRB RB2 detects VLAN mapping, based on receiving a TRILL-Hello where the VLAN tag in the body of the Hello differs from the one in the outer header, it sets a flag in all of its TRILL-Hellos for a period of two of its Holding Times since the last time RB2 detected VLAN mapping. When DRB RB1 is informed of VLAN mapping, either because of receiving a TRILL-Hello that has been VLAN-mapped, or because of seeing the "VLAN mapping detected" flag in a neighbor's TRILL-Hello on the link, RB1 re-assigns VLAN forwarders to ensure there is only a single forwarder on the link for all VLANs.
非DRB RB2がVLANマッピングを検出すると、Helloの本文のVLANタグが外部ヘッダーのVLANタグと異なるTRILL-Helloの受信に基づいて、すべてのTRILL-Helloにフラグを設定します。 RB2が最後にVLANマッピングを検出してからの2つの保持時間。 VLANマッピングされたTRILL-Helloを受信したため、またはリンク上のネイバーのTRILL-Helloに「VLANマッピング検出」フラグが表示されたために、DRB RB1がVLANマッピングを通知されると、RB1はVLANを再割り当てしますすべてのVLANのリンクに単一のフォワーダーのみが存在することを確認するためのフォワーダー。
RBridges use distribution trees to forward multi-destination frames (see Section 2.4.2). Distribution trees are bidirectional. Although a single tree is logically sufficient for the entire campus, the computation of additional distribution trees is warranted for the following reasons: it enables multipathing of multi-destination frames and enables the choice of a tree root closer to or, in the limit, identical with the ingress RBridge. Such a closer tree root improves the efficiency of the delivery of multi-destination frames that are being delivered to a subset of the links in the campus and reduces out-of-order delivery when a unicast address transitions between unknown and known. If applications are in use where occasional out-of-order unicast frames due to such transitions are a problem, the RBridge campus should be engineered to make sure they are of extremely low probability, such as by using the ESADI protocol, configuring addresses to eliminate unknown destination unicast frames, or using keep alive frames.
RBridgeは、配信ツリーを使用して複数の宛先フレームを転送します（セクション2.4.2を参照）。配信ツリーは双方向です。キャンパス全体では論理的には1つのツリーで十分ですが、次の理由により、追加の配信ツリーの計算が必要になります。これにより、複数の宛先フレームのマルチパスが可能になり、ツリールートをより近く、または制限内で同一に選択できるようになります。入力RBridgeを使用します。このようなより近いツリールートにより、キャンパス内のリンクのサブセットに配信されている複数の宛先フレームの配信効率が向上し、ユニキャストアドレスが不明と既知の間で移行するときの順不同配信が減少します。このような遷移が原因で時々発生するユニキャストフレームが問題となるアプリケーションを使用している場合は、RBridgeキャンパスを設計して、ESADIプロトコルを使用してアドレスを削除するなど、非常に低い確率になるようにしてアドレスを構成する必要があります。不明な宛先ユニキャストフレーム、またはキープアライブフレームの使用。
An additional level of flexibility is the ability of an RBridge to acquire multiple nicknames, and therefore have multiple trees rooted at the same RBridge. Since the tree number is used as a tiebreaker for equal cost paths, the different trees, even if rooted at the same RBridge, will likely utilize different equal cost paths.
追加のレベルの柔軟性は、RBridgeが複数のニックネームを取得する機能であり、したがって、同じRBridgeをルートとする複数のツリーを持っています。ツリー番号は等コストパスのタイブレーカーとして使用されるため、同じRBridgeでルート設定されていても、異なるツリーは異なる等コストパスを利用する可能性があります。
How an ingress RBridge chooses the distribution tree or trees that it uses for multi-destination frames is beyond the scope of this document. However, for the reasons stated above, in the absence of other factors, a good choice is the tree whose root is least cost from the ingress RBridge and that is the default for an ingress RBridge that uses a single tree to distribute multi-destination frames.
入力RBridgeが複数の宛先フレームに使用する1つまたは複数の配布ツリーを選択する方法は、このドキュメントの範囲を超えています。ただし、上記の理由により、他の要因がない場合、適切な選択は、ルートが入力RBridgeからのコストが最小で、単一のツリーを使用して複数の宛先フレームを配布する入力RBridgeのデフォルトであるツリーです。 。
RBridges will precompute all the trees that might be used, and keep
state for Reverse Path Forwarding Check filters (see Section 4.5.2).
Also, since the tree number is used as a tiebreaker, it is important
for all RBridges to know:
o how many trees to compute
o which trees to compute
o what the tree number for each tree is
o which trees each ingress RBridge might choose (for building
Reverse Path Forwarding Check filters)
Each RBridge advertises in its LSP a "tree root" priority for its nickname or for each of its nicknames if it has been configured to have more than one. This is a 16-bit unsigned integer that defaults, for an unconfigured RBridge, to 0x8000. Tree roots are ordered with highest numerical priority being highest priority, then with system ID of the RBridge (numerically higher = higher priority) as tiebreaker, and if that is equal, by the numerically higher nickname value, as an unsigned integer, having priority.
各RBridgeは、そのニックネーム、または複数のRBridgeが構成されている場合は各ニックネームの「ツリールート」優先順位をLSPで通知します。これは、未構成のRBridgeの場合、デフォルトで0x8000になる16ビットの符号なし整数です。ツリーのルートは、最も高い数値の優先順位が最も高い優先順位で、次にRBridgeのシステムID（数値がより高い=より高い優先順位）がタイブレーカーとして順序付けられます。
Each RBridge advertises in its LSP the maximum number of distribution trees that it can compute and the number of trees that it wants all RBridges in the campus to compute. The number of trees, k, that are computed for the campus is the number wanted by the RBridge RB1, which has the nickname with the highest "tree root" priority, but no more than the number of trees supported by the RBridge in the campus that supports the fewest trees. If RB1 does not specify the specific distribution tree roots as described below, then the k highest priority trees are the trees that will be computed by all RBridges. Note that some of these k highest priority trees might be rooted at the same RBridge, if that RBridge has multiple nicknames.
各RBridgeは、LSPで、計算できる分散ツリーの最大数と、キャンパス内のすべてのRBridgeに計算させたいツリーの数を通知します。キャンパスに対して計算されるツリーの数kは、最高の「ツリールート」優先度を持つニックネームを持つRBridge RB1で必要な数ですが、キャンパス内のRBridgeでサポートされるツリーの数以下です最も少ないツリーをサポートします。以下で説明するように、RB1が特定の配布ツリーのルートを指定しない場合、k個の最高優先度ツリーは、すべてのRBridgeによって計算されるツリーです。 RBridgeに複数のニックネームがある場合、これらのk個の最も優先度の高いツリーのいくつかは、同じRBridgeをルートとする可能性があることに注意してください。
If an RBridge specifies the number of trees it can compute, or the number of trees it wants computed for the campus, as 0, it is treated as specifying them as 1. Thus, k defaults to 1.
RBridgeが計算できるツリーの数、またはキャンパスに対して計算したいツリーの数を0として指定した場合、それらは1として指定されたものとして扱われます。したがって、kのデフォルトは1です。
In addition, the RBridge RB1 having the highest root priority nickname might explicitly advertise a set of s trees by providing a list of s nicknames. In that case, the first k of those s trees will be computed. If s is less than k, or if any of the s nicknames associated with the trees RB1 is advertising does not exist within the LSP database, then the RBridges still compute k trees, but the remaining trees they select are the highest priority trees, such that k trees are computed.
さらに、最高のルート優先度ニックネームを持つRBridge RB1は、sニックネームのリストを提供することにより、sツリーのセットを明示的にアドバタイズする場合があります。その場合、それらのsツリーの最初のkが計算されます。 sがkより小さい場合、またはRB1がアドバタイズしているツリーに関連付けられているsニックネームのいずれかがLSPデータベース内に存在しない場合でも、RBridgeはk個のツリーを計算しますが、それらが選択する残りのツリーは最も優先度の高いツリーです。 k個のツリーが計算されること。
There are two exceptions to the above, which can cause fewer distribution trees to be computed, as follows:
上記には2つの例外があり、次のように計算される分布ツリーが少なくなる可能性があります。
o A nickname whose tree root priority is zero is not selected as a tree root based on priority, although it may be selected by being listed by the RBridge holding the highest priority tree root nickname. The one exception to this is that if all nicknames have priority zero, then the highest priority among them as determined by the tiebreakers is used as a tree root so that there is always guaranteed to be at least one distribution tree.
oツリールートの優先度がゼロであるニックネームは、優先度に基づいてツリールートとして選択されませんが、最高の優先度のツリールートニックネームを保持するRBridgeによってリストされることによって選択される場合があります。これの1つの例外は、すべてのニックネームの優先度がゼロの場合、タイブレーカーによって決定されたニックネームの中で最も高い優先度がツリールートとして使用されるため、常に少なくとも1つの配布ツリーがあることが保証されます。
o As a transient condition, two or more identical nicknames can appear in the list of roots for trees to be computed. In such a case, it is useless to compute a tree for the nickname(s) that are about to be lost by the RBridges holding them. So a distribution tree is only computed for the instance of the nickname where the priority to hold that nickname value is highest, reducing the total number of trees computed. (It would also be of little use to go further down the priority ordered list of possible tree root nicknames to maintain the number of trees as the additional tree roots found this way would only be valid for a very brief nickname transition period.)
o 一時的な条件として、2つ以上の同一のニックネームが、計算されるツリーのルートのリストに表示されることがあります。このような場合、それらを保持しているRBridgeによって失われようとしているニックネームのツリーを計算しても意味がありません。したがって、分散ツリーは、ニックネームの値を保持する優先度が最も高いニックネームのインスタンスに対してのみ計算され、計算されるツリーの総数が減ります。 （また、この方法で見つかった追加のツリールートは非常に短いニックネームの移行期間のみ有効であるため、ツリーの数を維持するために、可能なツリールートニックネームの優先順位順リストをさらに下るのはほとんど役に立ちません。）
The k trees calculated for a campus are ordered and numbered from 1 to k. In addition to advertising the number k, RB1 might explicitly advertise a set of s trees by providing a list of s nicknames as described above.
キャンパスに対して計算されたk本のツリーは、1からkまでの順序で番号が付けられています。番号kをアドバタイズすることに加えて、RB1は、上記のようにsニックネームのリストを提供することにより、sツリーのセットを明示的にアドバタイズする場合があります。
- If s == k, then the trees are numbered in the order that RB1 advertises them.
- s == kの場合、ツリーには、RB1がアドバタイズする順序で番号が付けられます。
- If s == 0, then the trees are numbered in order of decreasing priority. For example, if RB1 advertises only that k=2, then the highest priority tree is number 1 and the 2nd highest priority tree is number 2.
- s == 0の場合、ツリーには優先度の高い順に番号が付けられます。たとえば、RB1がそのk = 2のみをアドバタイズする場合、最も優先度の高いツリーは番号1で、2番目に高い優先度ツリーは番号2です。
- If s < k, then those advertised by RB1 are numbered from 1 in the order advertised. Then the remainder are chosen by priority order from among the remaining possible trees with the numbering continuing. For example, if RB1 advertises k=4, advertises { Tx, Ty } as the nicknames of the root of the trees, and the campus-wide priority ordering of trees in decreasing order is Ty > Ta > Tc > Tb > Tx, the numbering will be as follows: Tx is 1 and Ty is 2 since that is the order they are advertised in by RB1. Then Ta is 3 and Tc is 4 because they are the highest priority trees that have not already been numbered.
- s <kの場合、RB1によってアドバタイズされたものには、アドバタイズされた順序で1から番号が付けられます。次に、残りの可能なツリーの中から優先順位によって残りが選択され、番号が続きます。たとえば、RB1がk = 4をアドバタイズする場合、{Tx、Ty}をツリーのルートのニックネームとしてアドバタイズし、キャンパス全体でのツリーの優先順位の降順は、Ty> Ta> Tc> Tb> Txです。番号は次のようになります。Txは1で、Tyは2です。これは、RB1によってアドバタイズされる順序だからです。次に、Taは3で、Tcは4です。これらは、まだ番号付けされていない、最も優先度の高いツリーだからです。
RBridges do not use spanning tree to calculate distribution trees. Instead, distribution trees are calculated based on the link state information, selecting a particular RBridge nickname as the root. Each RBridge RBn independently calculates a tree rooted at RBi by performing the SPF (Shortest Path First) calculation with RBi as the root without requiring any additional exchange of information.
RBridgeは、スパニングツリーを使用して分布ツリーを計算しません。代わりに、配布ツリーはリンク状態情報に基づいて計算され、特定のRBridgeニックネームをルートとして選択します。各RBridge RBnは、追加の情報交換を必要とせずにRBiをルートとしてSPF（Shortest Path First）計算を実行することにより、RBiをルートとするツリーを個別に計算します。
It is important, when building a distribution tree, that all RBridges choose the same links for that tree. Therefore, when there are equal cost paths for a particular tree, all RBridges need to use the same tiebreakers. It is also desirable to allow splitting of traffic on as many links as possible. For this reason, a simple tiebreaker such as "always choose the parent with lower ID" would not be desirable. Instead, TRILL uses the tree number as a parameter in the tiebreaking algorithm.
配布ツリーを構築する場合、すべてのRBridgeがそのツリーに同じリンクを選択することが重要です。したがって、特定のツリーに等しいコストのパスがある場合、すべてのRBridgeは同じタイブレーカーを使用する必要があります。できるだけ多くのリンクでトラフィックを分割できるようにすることも望ましいです。このため、「常にIDが低い親を選択する」などの単純なタイブレーカーは望ましくありません。代わりに、TRILLはタイブレークアルゴリズムのパラメーターとしてツリー番号を使用します。
When building the tree number j, remember all possible equal cost parents for node N. After calculating the entire "tree" (actually, directed graph), for each node N, if N has "p" parents, then order the parents in ascending order according to the 7-octet IS-IS ID considered as an unsigned integer, and number them starting at zero. For tree j, choose N's parent as choice j mod p.
ツリー番号jを構築するときは、ノードNのすべての可能な等価コストの親を覚えておいてください。「ツリー」全体（実際には有向グラフ）を計算した後、各ノードNについて、Nに「p」の親がある場合、親を昇順に並べます。符号なし整数と見なされる7オクテットIS-IS IDに従って順序付けし、ゼロから始まる番号を付けます。ツリーjの場合、選択肢j mod pとしてNの親を選択します。
Note that there might be multiple equal cost links between N and potential parent P that have no pseudonodes, because they are either point-to-point links or pseudonode-suppressed links. Such links will be treated as a single link for the purpose of tree building, because they all have the same parent P, whose IS-IS ID is "P.0".
Nと潜在的な親Pの間に、擬似ノードを持たない複数の等コストリンクが存在する可能性があることに注意してください。これらのリンクは、ポイントツーポイントリンクまたは擬似ノード抑制リンクのいずれかです。そのようなリンクはすべて、ツリー構築の目的で単一のリンクとして扱われます。これは、IS-IS IDが「P.0」である親Pがすべて同じであるためです。
In other words, the set of potential parents for N, for the tree rooted at R, consists of those that give equally minimal cost paths from N to R and that have distinct IS-IS IDs, based on what is reported in LSPs.
つまり、RをルートとするツリーのNの潜在的な親のセットは、LSPで報告された内容に基づいて、NからRへのコストパスが等しく最小であり、異なるIS-IS IDを持つ親で構成されます。
When a multi-destination TRILL-encapsulated frame is received by an RBridge, there are four checks performed, each of which may cause the frame to be discarded:
複数の宛先のTRILLカプセル化フレームがRBridgeによって受信されると、4つのチェックが実行されます。それぞれのチェックにより、フレームが破棄される可能性があります。
1. Tree Adjacency Check: Each RBridge RBn keeps a set of adjacencies ( { port, neighbor } pairs ) for each distribution tree it is calculating. One of these adjacencies is toward the tree root RBi, and the others are toward the leaves. Once the adjacencies are chosen, it is irrelevant which ones are towards the root RBi and which are away from RBi. RBridges MUST drop a multi-destination frame that arrives at a port from an RBridge that is not an adjacency for the tree on which the frame is being distributed. Let's suppose that RBn has calculated that adjacencies a, c, and f are in the RBi tree. A multi-destination frame for the distribution tree RBi is received only from one of the adjacencies a, c, or f (otherwise it is discarded) and forwarded to the other two adjacencies. Should RBn have multiple ports on a link, a multi-destination frame it sends on one of these ports will be received by the others but will be discarded as an RBridge is not adjacent to itself.
1.ツリー隣接チェック：各RBridge RBnは、計算している各配信ツリーの隣接（{ポート、ネイバー}ペア）のセットを保持します。これらの隣接関係の1つはツリーのルートRBiに向かっており、他の隣接関係は葉に向かっています。隣接関係が選択されると、どれがルートRBiに向かっているか、RBiから離れているかは関係ありません。 RBridgesは、フレームが配布されているツリーの隣接ではないRBridgeからポートに到着する複数の宛先フレームをドロップしなければなりません（MUST）。隣接関係a、c、およびfがRBiツリーにあるとRBnが計算したと仮定します。配布ツリーRBiのマルチ宛先フレームは、隣接a、c、またはfの1つからのみ受信され（そうでない場合は破棄されます）、他の2つの隣接に転送されます。 RBnがリンク上に複数のポートを持っている場合、これらのポートの1つで送信する複数の宛先のフレームは他のポートによって受信されますが、RBridgeはそれ自体に隣接していないため破棄されます。
2. RPF Check: Another technique used by RBridges for avoiding temporary multicast loops during topology changes is the Reverse Path Forwarding Check. It involves checking that a multi-destination frame, based on the tree and the ingress RBridge, arrives from the expected link. RBridges MUST drop multi-destination frames that fail the RPF check.
2. RPFチェック：トポロジの変更中に一時的なマルチキャストループを回避するためにRBridgeが使用するもう1つの手法は、リバースパス転送チェックです。これには、ツリーと入力RBridgeに基づいて、マルチ宛先フレームが予期されたリンクから到着することの確認が含まれます。 RBridgeは、RPFチェックに失敗したマルチ宛先フレームをドロップする必要があります。
To limit the amount of state necessary to perform the RPF check, each RBridge RB2 MUST announce which trees RB2 may choose when RB2 ingresses a multi-destination packet. When any RBridge, say, RB3, is computing the tree from nickname X, RB3 computes, for each RBridge RB2 that might act as ingress for tree X, the link on which RB3 should receive a packet from ingress RB2 on tree X, and note for that link that RB2 is a legal ingress RBridge for tree X.
RPFチェックを実行するために必要な状態の量を制限するために、各RBridge RB2は、RB2がマルチ宛先パケットに入るときにRB2がどのツリーを選択できるかを通知しなければなりません（MUST）。ニックネームXからRBridgeなどのRBridgeがツリーを計算しているとき、RB3はツリーXの入口として機能するRBridge RB2ごとに、RB3がツリーXの入口RB2からパケットを受信するリンクを計算します。そのリンクの場合、RB2はツリーXの合法的な入口RBridgeです。
The information to determine which trees RB2 might choose is included in RB2's LSP. Similarly to how the highest priority RBridge RB1 specifies the k trees that will be computed by all RBridges, RB2 specifies a number j, which is the total number of different trees RB2 might specify, and the specific trees RB2 might specify are a combination of specified trees and trees selected from highest priority trees. If RB2 specifies any trees that are not in the k trees as specified by RB1, they are ignored.
RB2が選択するツリーを決定するための情報は、RB2のLSPに含まれています。最高の優先度のRBridge RB1がすべてのRBridgeによって計算されるk個のツリーを指定する方法と同様に、RB2は、RB2が指定する異なるツリーの総数であるjを指定し、RB2が指定する特定のツリーは、指定された組み合わせです。木および優先度の最も高い木から選択された木。 RB2が、RB1で指定されたkツリーにないツリーを指定した場合、それらは無視されます。
The j potential ingress trees for RB2 are the ones with nicknames that RB2 has explicitly specified in "specified ingress tree nicknames" (and that are included in the k campus-wide trees selected by highest priority RBridge RB1), with the remainder (up to the maximum of {j,k}) being the highest priority of the k campus-wide trees.
RB2のj個の潜在的な進入ツリーは、RB2が「指定された進入ツリーニックネーム」で明示的に指定したニックネームを持つツリーであり（最も優先度の高いRBridge RB1によって選択されたkキャンパス全体のツリーに含まれます）、残りは（最大最大の{j、k}）は、kキャンパス全体のツリーの最高の優先順位です。
The default value for j is 1. The value 0 for j is special and means that RB2 can pick any of the k trees being computed for the campus.
jのデフォルト値は1です。jの値0は特別であり、RB2がキャンパスに対して計算されているk個のツリーのいずれかを選択できることを意味します。
3. Parallel Links Check: If the tree-building and tiebreaking for a particular multi-destination frame distribution tree selects a non-pseudonode link between RB1 and RB2, that "RB1-RB2 link" might actually consist of multiple links. These parallel links would be visible to RB1 and RB2, but not to the rest of the campus (because the links are not represented by pseudonodes). If this bundle of parallel links is included in a tree, it is important for RB1 and RB2 to decide which link to use, but is irrelevant to other RBridges, and therefore, the tiebreaking algorithm need not be visible to any RBridges other than RB1 and RB2. In this case, RB1-RB2 adjacencies are ordered as follows, with the one "most preferred" adjacency being the one on which RB1 and RB2 transmit to and receive multi-destination frames from each other.
3.パラレルリンクチェック：特定の複数宛先フレーム分散ツリーのツリー構築とタイブレイクがRB1とRB2の間の非疑似ノードリンクを選択する場合、その「RB1-RB2リンク」は実際には複数のリンクで構成されている可能性があります。これらの並列リンクは、RB1およびRB2からは見えますが、キャンパスの他の部分からは見えません（リンクが疑似ノードで表されていないため）。この並列リンクのバンドルがツリーに含まれている場合、RB1とRB2が使用するリンクを決定することが重要ですが、他のRBridgeとは無関係であるため、タイブレーキングアルゴリズムはRB1とRBridge以外のRBridgeから見える必要はありません。 RB2。この場合、RB1-RB2隣接関係は次のように順序付けられます。1つの「最も好ましい」隣接関係は、RB1とRB2が相互にマルチ宛先フレームとの間で送受信する隣接関係です。
a) Most preferred are those established by P2P Hellos. Tiebreaking among those is based on preferring the one with the numerically highest Extended Circuit ID as associated with the adjacency by the RBridge with the highest System ID.
a) 最も好ましいのは、P2P Helloによって確立されたものです。それらの間のタイブレイクは、最大のシステムIDを持つRBridgeによる隣接関係に関連付けられている数値的に最大の拡張回線IDを持つものを優先することに基づいています。
b) Next considered are those established through TRILL-Hello frames, with suppressed pseudonodes. Note that the pseudonode is suppressed in LSPs, but still appears in the TRILL-Hello, and therefore is available for this tiebreaking. Among these links, the one with the numerically largest pseudonode ID is preferred.
b) 次に考慮されるのは、疑似ノードが抑制された、TRILL-Helloフレームを通じて確立されたものです。疑似ノードはLSPで抑制されますが、それでもTRILL-Helloに表示されるため、このタイブレイクに使用できることに注意してください。これらのリンクの中で、数値的に最大の疑似ノードIDを持つリンクが推奨されます。
4. Port Group Check: If an RBridge has multiple ports attached to the same link, a multi-destination frame it is receiving will arrive on all of them. All but one received copy of such a frame MUST be discarded to avoid duplication. All such frames that are part of the same flow must be accepted on the same port to avoid re-ordering.
4. ポートグループチェック：RBridgeに同じリンクに接続された複数のポートがある場合、受信している複数の宛先フレームはすべてのポートに到着します。重複を避けるために、このようなフレームの受信したコピーを1つを除いてすべて破棄する必要があります。同じフローの一部であるそのようなフレームはすべて、並べ替えを回避するために同じポートで受け入れられる必要があります。
When a topology change occurs (including apparent changes during start up), an RBridge MUST adjust its input distribution tree filters no later than it adjusts its output forwarding.
トポロジーの変更が発生した場合（起動時の明らかな変更を含む）、RBridgeは、その出力転送を調整する前に、入力分散ツリーフィルターを調整する必要があります。
Each distribution tree SHOULD be pruned per VLAN, eliminating branches that have no potential receivers downstream. Multi-destination TRILL Data frames SHOULD only be forwarded on branches that are not pruned.
各配布ツリーはVLANごとにプルーニングする必要があります（SHOULD）。下流に潜在的なレシーバーがないブランチを排除します。複数宛先のTRILLデータフレームは、枝刈りされていないブランチでのみ転送する必要があります（SHOULD）。
Further pruning SHOULD be done in two cases: (1) IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] messages, where these are to be delivered only to links with IP multicast routers; and (2) other multicast frames derived from an IP multicast address that should be delivered only to links that have registered listeners, plus links that have IP multicast routers, except for IP multicast addresses that must be broadcast. Each of these cases is scoped per VLAN.
（1）IGMP [RFC3376]、MLD [RFC2710]、およびMRD [RFC4286]メッセージ。これらはIPマルチキャストルーターとのリンクにのみ配信されます。 （2）ブロードキャストが必要なIPマルチキャストアドレスを除いて、リスナーが登録されているリンクとIPマルチキャストルーターがあるリンクにのみ配信される必要があるIPマルチキャストアドレスから派生した他のマルチキャストフレーム。これらの各ケースは、VLANごとにスコープされます。
Let's assume that RBridge RBn knows that adjacencies (a, c, and f) are in the nickname1 distribution tree. RBn marks pruning information for each of the adjacencies in the nickname1-tree. For each adjacency and for each tree, RBn marks: o the set of VLANs reachable downstream,
RBridge RBnが、隣接（a、c、およびf）がnickname1分散ツリーにあることを知っていると想定します。 RBnは、nickname1-tree内の各隣接のプルーニング情報をマークします。各隣接および各ツリーで、RBnは以下をマークします。oダウンストリームに到達可能なVLANのセット、
o for each one of those VLANs, flags indicating whether there are IPv4 or IPv6 multicast routers downstream, and
o これらのVLANのそれぞれについて、IPv4またはIPv6マルチキャストルーターがダウンストリームにあるかどうかを示すフラグ、および
o the set of Layer 2 multicast addresses derived from IP multicast groups for which there are receivers downstream.
o ダウンストリームにレシーバーが存在するIPマルチキャストグループから派生した一連のレイヤー2マルチキャストアドレス
RBridges MUST determine the VLAN associated with all native frames they ingress and properly enforce VLAN rules on the emission of native frames at egress RBridge ports according to how those ports are configured and designated as appointed forwarders. RBridges SHOULD also prune the distribution tree of multi-destination frames according to VLAN. But, since they are not required to do such pruning, they may receive TRILL data or ESADI frames that should have been VLAN pruned earlier in the tree distribution. They silently discard such frames. A campus may contain some Rbridges that prune distribution trees on VLAN and some that do not.
RBridgesは、入力するすべてのネイティブフレームに関連付けられたVLANを決定し、指定されたフォワーダーとしてポートがどのように構成および指定されているかに応じて、出力RBridgeポートでのネイティブフレームの送信にVLANルールを適切に適用する必要があります。 RBridgesはまた、VLANに従って複数宛先フレームの配布ツリーをプルーニングする必要があります（SHOULD）。ただし、そのようなプルーニングを実行する必要がないため、ツリー配布の早い段階でVLANプルーニングされているはずのTRILLデータまたはESADIフレームを受信する可能性があります。それらはそのようなフレームを静かに廃棄します。キャンパスには、VLAN上の配布ツリーをプルーニングするRbridgeとプルーニングしないRbridgeが含まれている場合があります。
The situation is more complex for multicast. RBridges SHOULD analyze IP-derived native multicast frames, and learn and announce listeners and IP multicast routers for such frames as discussed in Section 4.7 below. And they SHOULD prune the distribution of IP-derived multicast frames based on such learning and announcements. But, they are not required to prune based on IP multicast listener and router attachment state. And, unlike VLANs, where VLAN attachment state of ports MUST be maintained and honored, RBridges are not required to maintain IP multicast listener and router attachment state.
マルチキャストの場合、状況はより複雑になります。 RBridgesは、以下のセクション4.7で説明するように、IP派生のネイティブマルチキャストフレームを分析し、そのようなフレームのリスナーとIPマルチキャストルーターを学習およびアナウンスする必要があります（SHOULD）。そして、それらはそのような学習とアナウンスに基づいてIP派生のマルチキャストフレームの配布を剪定するべきです（SHOULD）。ただし、IPマルチキャストリスナーとルーター接続状態に基づいてプルーニングする必要はありません。また、VLANとは異なり、ポートのVLANアタッチメント状態を維持および尊重する必要があるため、RBridgeは、IPマルチキャストリスナーおよびルーターアタッチメント状態を維持する必要はありません。
An RBridge that does not examine native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frames that it ingresses MUST advertise that it has IPv4 and IPv6 IP multicast routers attached for all the VLANs for which it is an appointed forwarder. It need not advertise any IP-derived multicast listeners. This will cause all IP-derived multicast traffic to be sent to this RBridge for those VLANs. It then egresses that traffic onto the links for which it is appointed forwarder where the VLAN of the traffic matches the VLAN for which it is appointed forwarder on that link. (This may cause the suppression of certain IGMP membership report messages from end stations, but that is not significant because any multicast traffic that such reports would be requesting will be sent to such end stations under these circumstances.) A campus may contain a mixture of Rbridges with different levels of IP-derived multicast optimization. An RBridge may receive IP-derived multicast frames that should have been pruned earlier in the tree distribution. It silently discards such frames.
ネイティブIGMP [RFC3376]、MLD [RFC2710]、またはMRD [RFC4286]フレームを検査しないRBridgeは、指定されたフォワーダーであるすべてのVLANにIPv4およびIPv6 IPマルチキャストルーターが接続されていることを通知する必要があります。 IP派生のマルチキャストリスナーをアドバタイズする必要はありません。これにより、すべてのIP派生マルチキャストトラフィックが、それらのVLANのこのRBridgeに送信されます。次に、そのトラフィックを、フォワーダーとして指定されているリンクに出力します。トラフィックのVLANは、そのリンクでフォワーダーとして指定されているVLANと一致します。 （これにより、エンドステーションからの特定のIGMPメンバーシップレポートメッセージが抑制される可能性がありますが、そのようなレポートが要求するマルチキャストトラフィックは、これらの状況下でそのようなエンドステーションに送信されるため、重要ではありません。）キャンパスには、さまざまなレベルのIP派生マルチキャスト最適化を備えたRbridge。 RBridgeは、ツリー配信の早い段階でプルーニングされているはずのIP派生マルチキャストフレームを受信する場合があります。このようなフレームは静かに破棄されます。
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541].
「インターネットグループ管理プロトコル（IGMP）とマルチキャストリスナ探索（MLD）スヌーピングスイッチに関する考慮事項」[RFC4541]も参照してください。
With full optimization, forwarding a multi-destination data frame is done as follows. References to adjacencies below do not include the adjacency on which a frame was received.
完全な最適化では、複数の宛先データフレームの転送は次のように行われます。以下の隣接への言及には、フレームが受信された隣接は含まれていません。
o The RBridge RBn receives a multi-destination TRILL Data frame with inner VLAN-x and a TRILL header indicating that the selected tree is the nickname1 tree;
o RBridge RBnは、内部VLAN-xと、選択されたツリーがnickname1ツリーであることを示すTRILLヘッダーを含む複数の宛先TRILLデータフレームを受信します。
o if the source from which the frame was received is not one of the adjacencies in the nickname1 tree for the specified ingress RBridge, the frame is dropped (see Section 4.5.1);
o フレームの送信元である送信元が、指定された入力RBridgeのnickname1ツリー内の隣接のいずれでもない場合、フレームはドロップされます（セクション4.5.1を参照）。
o else, if the frame is an IGMP or MLD announcement message or an MRD query message, then the encapsulated frame is forwarded onto adjacencies in the nickname1 tree that indicate there are downstream VLAN-x IPv4 or IPv6 multicast routers as appropriate;
o それ以外の場合、フレームがIGMPまたはMLDアナウンスメッセージまたはMRDクエリメッセージである場合、カプセル化されたフレームは、必要に応じてダウンストリームVLAN-x IPv4またはIPv6マルチキャストルーターがあることを示すnickname1ツリーの隣接に転送されます。
o else, if the frame is for a Layer 2 multicast address derived from an IP multicast group, but its IP address is not the range of IP multicast addresses that must be treated as broadcast, the frame is forwarded onto adjacencies in the nickname1 tree that indicate there are downstream VLAN-x IP multicast routers of the corresponding type (IPv4 or IPv6), as well as adjacencies that indicate there are downstream VLAN-x receivers for that group address;
o それ以外の場合、フレームがIPマルチキャストグループから派生したレイヤ2マルチキャストアドレス用であるが、そのIPアドレスがブロードキャストとして処理する必要があるIPマルチキャストアドレスの範囲ではない場合、フレームは、ニックネーム1ツリー内の隣接に転送されます。対応するタイプ（IPv4またはIPv6）のダウンストリームVLAN-x IPマルチキャストルーターと、そのグループアドレスのダウンストリームVLAN-xレシーバーがあることを示す隣接関係があります。
o else (the inner frame is for a Layer 2 multicast address not derived from an IP multicast group or an unknown destination or broadcast or an IP multicast address that is required to be treated as broadcast), the frame is forwarded onto an adjacency if and only if that adjacency is in the nickname1 tree, and marked as reaching VLAN-x links.
o それ以外の場合（内部フレームは、IPマルチキャストグループ、不明な宛先、ブロードキャスト、またはブロードキャストとして処理する必要があるIPマルチキャストアドレスから派生していないレイヤー2マルチキャストアドレス用）、次の場合に限り、隣接に転送されます。その隣接関係がnickname1ツリーにあり、VLAN-xリンクに到達するようにマークされている場合。
For each link for which RBn is appointed forwarder, RBn additionally checks to see if it should decapsulate the frame and send it to the link in native form, or process the frame locally.
RBnがフォワーダーとして指定されているリンクごとに、RBnはさらに、フレームをカプセル化解除してネイティブ形式でリンクに送信するか、ローカルでフレームを処理する必要があるかどうかを確認します。
TRILL ESADI frames will be delivered only to RBridges that are appointed forwarders for their VLAN. Such frames will be multicast throughout the campus, like other non-IP-derived multicast data frames, on the distribution tree chosen by the RBridge that created the TRILL ESADI frame, and pruned according to the Inner.VLAN ID. Thus, all the RBridges that are appointed forwarders for a link in that VLAN receive them.
TRILL ESADIフレームは、VLANのフォワーダーに指定されているRBridgeにのみ配信されます。そのようなフレームは、TRILL ESADIフレームを作成したRBridgeによって選択された配布ツリー上で、他の非IP派生マルチキャストデータフレームと同様に、キャンパス全体にマルチキャストされ、Inner.VLAN IDに従ってプルーニングされます。したがって、そのVLAN内のリンクのフォワーダーに指定されているすべてのRBridgeは、それらを受信します。
This section describes RBridge behavior for all varieties of received frames, including how they are forwarded when appropriate. Section 4.6.1 covers native frames, Section 4.6.2 covers TRILL frames, and Section 4.6.3 covers Layer 2 control frames. Processing may be organized or sequenced in a different way than described here as long as the result is the same. See Section 1.4 for frame type definitions.
このセクションでは、すべての種類の受信フレームのRBridgeの動作について説明します。セクション4.6.1はネイティブフレームをカバーし、セクション4.6.2はTRILLフレームをカバーし、セクション4.6.3はレイヤー2コントロールフレームをカバーします。処理は、結果が同じである限り、ここで説明した方法とは異なる方法で編成または順序付けできます。フレームタイプの定義については、セクション1.4を参照してください。
Corrupt frames, for example, frames that are not a multiple of 8 bits, are too short or long for the link protocol/hardware in use, or have a bad FCS are discarded on receipt by an RBridge port as they are discarded on receipt at an IEEE 802.1 bridge port.
破損したフレーム（8ビットの倍数ではないフレームなど）は、使用中のリンクプロトコル/ハードウェアに対して短すぎるか長すぎるか、または不正なFCSがあるため、受信時にRBridgeポートで破棄されるため、RBridgeポートで破棄されます。 IEEE 802.1ブリッジポート。
Source address information ( { VLAN, Outer.MacSA, port } ) is learned by default from any frame with a unicast source address (see Section 4.8).
送信元アドレス情報（{VLAN、Outer.MacSA、port}）は、ユニキャスト送信元アドレスを持つフレームからデフォルトで学習されます（セクション4.8を参照）。
If the port is configured as disabled or if end-station service is disabled on the port by configuring it as a trunk port or configuring it to use P2P Hellos, the frame is discarded.
ポートが無効として構成されている場合、またはポートがトランクポートとして構成されているか、P2P Helloを使用するように構成されているためにポートで端末サービスが無効になっている場合、フレームは破棄されます。
The ingress Rbridge RB1 determines the VLAN ID for a native frame according to the same rules as IEEE [802.1Q-2005] bridges do (see Appendix D and Section 4.9.2). Once the VLAN is determined, if RB1 is not the appointed forwarder for that VLAN on the port where the frame was received or is inhibited, the frame is discarded. If it is appointed forwarder for that VLAN and is not inhibited (see Section 4.2.4.3), then the native frame is forwarded according to Section 4.6.1.1 if it is unicast and according to Section 4.6.1.2 if it is multicast or broadcast.
入力Rbridge RB1は、IEEE [802.1Q-2005]ブリッジと同じルールに従って、ネイティブフレームのVLAN IDを決定します（付録Dおよびセクション4.9.2を参照）。 VLANが決定されると、RB1が、フレームを受信したポートまたは禁止されたポート上のそのVLANの指定されたフォワーダーではない場合、フレームは破棄されます。そのVLANのフォワーダーに指定されており、禁止されていない場合（セクション4.2.4.3を参照）、ネイティブフレームは、ユニキャストの場合はセクション4.6.1.1に従って、マルチキャストまたはブロードキャストの場合はセクション4.6.1.2に従って転送されます。
If the destination MAC address of the native frame is a unicast address, the following steps are performed.
ネイティブフレームの宛先MACアドレスがユニキャストアドレスの場合、次の手順が実行されます。
The Layer 2 destination address and VLAN are looked up in the ingress RBridge's database of MAC addresses and VLANs to find the egress RBridge RBm or the local egress port or to discover that the destination is the receiving RBridge or is unknown. One of the following four cases will apply:
レイヤー2の宛先アドレスとVLANは、MACアドレスとVLANの入力RBridgeのデータベースで検索され、出力RBridge RBmまたはローカル出力ポートを見つけるか、宛先が受信RBridgeであるか不明であることがわかります。次の4つのケースのいずれかが適用されます。
1. If the destination is the receiving RBridge, the frame is locally processed.
1. 宛先が受信RBridgeの場合、フレームはローカルで処理されます。
2. If the destination is known to be on the same link from which the native frame was received but is not the receiving RBridge, the RBridge silently discards the frame, since the destination should already have received it.
2. 宛先がネイティブフレームの受信元と同じリンク上にあることがわかっているが、受信RBridgeではない場合、宛先はすでに受信しているはずなので、RBridgeはフレームをサイレントに破棄します。
3. If the destination is known to be on a different local link for which RBm is the appointed forwarder, then RB1 converts the native frame to a TRILL Data frame with an Outer.MacDA of the next hop RBridge towards RBm, a TRILL header with M = 0, an ingress nickname for RB1, and the egress nickname for RBm. If ingress RB1 has multiple nicknames, it SHOULD use the same nickname in the ingress nickname field whenever it encapsulates a native frame from any particular source MAC address and VLAN. This simplifies end node learning. If RBm is RB1, processing then proceeds as in Section 4.6.2.4; otherwise, the Outer.MacSA is set to the MAC address of the RB1 port on the path to the next hop RBridge towards RBm and the frame is queued for transmission out of that port.
3. 宛先が、RBmが指定されたフォワーダーである別のローカルリンク上にあることがわかっている場合、RB1はネイティブフレームを、RBmへのネクストホップRBridgeのOuter.MacDAを持つTRILLデータフレームに変換します。 0、RB1の入力ニックネーム、RBmの出力ニックネーム。入力RB1に複数のニックネームがある場合、特定の送信元MACアドレスおよびVLANからのネイティブフレームをカプセル化するときは常に、入力ニックネームフィールドで同じニックネームを使用する必要があります（SHOULD）。これにより、エンドノードの学習が簡素化されます。 RBmがRB1の場合、処理はセクション4.6.2.4のように進みます。それ以外の場合、Outer.MacSAは、RBmへのネクストホップRBridgeへのパス上のRB1ポートのMACアドレスに設定され、フレームはそのポートからの送信のためにキューに入れられます。
4. If a unicast destination MAC is unknown in the frame's VLAN, RB1 handles the frame as described in Section 4.6.1.2 for a broadcast frame except that the Inner.MacDA is the original native frame's unicast destination address.
4. フレームのVLANでユニキャスト宛先MACが不明の場合、RB1は、Inner.MacDAが元のネイティブフレームのユニキャスト宛先アドレスであることを除いて、ブロードキャストフレームのセクション4.6.1.2で説明されているようにフレームを処理します。
If the RBridge has multiple ports attached to the same link, all but one received copy of a native multicast or broadcast frame is discarded to avoid duplication. All such frames that are part of the same flow must be accepted on the same port to avoid re-ordering.
RBridgeに同じリンクに接続された複数のポートがある場合、重複を避けるために、ネイティブマルチキャストまたはブロードキャストフレームの1つを除いてすべてのコピーが破棄されます。同じフローの一部であるそのようなフレームはすべて、並べ替えを回避するために同じポートで受け入れられる必要があります。
If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD [RFC4286] frame, then RB1 SHOULD analyze it, learn any group membership or IP multicast router presence indicated, and announce that information for the appropriate VLAN in its LSP (see Section 4.7).
フレームがネイティブIGMP [RFC3376]、MLD [RFC2710]、またはMRD [RFC4286]フレームである場合、RB1はそれを分析し、グループメンバーシップまたは示されたIPマルチキャストルーターの存在を学習し、その中の適切なVLANの情報を通知する必要があります（SHOULD）。 LSP（セクション4.7を参照）。
For all multi-destination native frames, RB1 forwards the frame in native form to its links where it is appointed forwarder for the frame's VLAN, subject to further pruning and inhibition. In addition, it converts the native frame to a TRILL Data frame with the All-RBridges multicast address as Outer.MacDA, a TRILL header with the multi-destination bit M = 1, the ingress nickname for RB1, and the egress nickname for the distribution tree it decides to use. It then forwards the frame on the pruned distribution tree (see Section 4.5) setting the Outer.MacSA of each copy sent to the MAC address of the RB1 port on which it is sent.
すべてのマルチデスティネーションネイティブフレームの場合、RB1はフレームをネイティブ形式でそのリンクに転送します。リンクはフレームのVLANのフォワーダーに指定され、さらにプルーニングと抑制が行われます。さらに、ネイティブフレームを、All-RBridgesマルチキャストアドレスがOuter.MacDA、マルチ宛先ビットM = 1のTRILLヘッダー、RB1の入力ニックネーム、およびRB1の出力ニックネームを持つTRILLデータフレームに変換します。使用することを決定する配布ツリー。次に、プルーニングされた配布ツリー（セクション4.5を参照）でフレームを転送し、送信される各コピーのOuter.MacSAを、それが送信されるRB1ポートのMACアドレスに設定します。
The default is for RB1 to write into the egress nickname field the nickname for a distribution tree, from the set of distribution trees RB1 has announced it might use, whose root is least cost from RB1. RB1 MAY choose different distribution trees for different frames if RB1 has been configured to path-split multicast. In that case, RB1 MUST select a tree by specifying a nickname that is a distribution tree root (see Section 4.5). Also, RB1 MUST select a nickname that RB1 has announced (in RB1's own LSP) to be one of those that RB1 might use. The strategy RB1 uses to select distribution trees in multipathing multi-destination frames is beyond the scope of this document.
デフォルトでは、RB1は、出力ツリーのニックネームフィールドに、RB1が使用する可能性があると発表した一連の配布ツリーから、配布ツリーのニックネームを出力します。そのルートはRB1からのコストが最小です。 RB1がパススプリットマルチキャストに設定されている場合、RB1は異なるフレームに対して異なる配信ツリーを選択できます。その場合、RB1は、配布ツリーのルートであるニックネームを指定してツリーを選択する必要があります（セクション4.5を参照）。また、RB1は、RB1が使用する可能性があるニックネームの1つになるように、RB1が（RB1自身のLSPで）アナウンスしたニックネームを選択する必要があります。 RB1がマルチパスのマルチ宛先フレームで配信ツリーを選択するために使用する戦略は、このドキュメントの範囲を超えています。
A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a multicast Outer.MacDA allocated to TRILL (see Section 7.2). The following tests are performed sequentially, and the first that matches controls the handling of the frame:
TRILLフレームには、TRILLまたはL2-IS-IS Ethertypeがあるか、マルチキャストOuter.MacDAがTRILLに割り当てられています（セクション7.2を参照）。次のテストが順番に実行され、最初に一致したテストがフレームの処理を制御します。
1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is L2-IS-IS, the frame is handled as described in Section 4.6.2.1.
1. Outer.MacDAがAll-IS-IS-RBridgesで、EthertypeがL2-IS-ISの場合、フレームはセクション4.6.2.1の説明に従って処理されます。
2. If the Outer.MacDA is a multicast address allocated to TRILL other than All-RBridges, the frame is discarded.
2. Outer.MacDAがAll-RBridges以外のTRILLに割り当てられたマルチキャストアドレスである場合、フレームは破棄されます。
3. If the Outer.MacDA is a unicast address other than the receiving Rbridge port MAC address, the frame is discarded. (Such discarded frames are most likely addressed to another RBridge on a multi-access link and that other Rbridge will handle them.)
3. Outer.MacDAが受信RbridgeポートMACアドレス以外のユニキャストアドレスである場合、フレームは破棄されます。 （このような破棄されたフレームは、マルチアクセスリンク上の別のRBridgeにアドレス指定されている可能性が高く、他のRbridgeがそれらを処理します。）
4. If the Ethertype is not TRILL, the frame is discarded.
4. EthertypeがTRILLでない場合、フレームは破棄されます。
5. If the Version field in the TRILL header is greater than 0, the frame is discarded.
5. TRILLヘッダーのVersionフィールドが0より大きい場合、フレームは破棄されます。
6. If the hop count is 0, the frame is discarded.
6. ホップカウントが0の場合、フレームは破棄されます。
7. If the Outer.MacDA is multicast and the M bit is zero or if the Outer.MacDA is unicast and M bit is one, the frame is discarded.
7. Outer.MacDAがマルチキャストでMビットがゼロの場合、またはOuter.MacDAがユニキャストでMビットが1の場合、フレームは破棄されます。
8. By default, an RBridge MUST NOT forward TRILL-encapsulated frames from a neighbor with which it does not have a TRILL IS-IS adjacency. RBridges MAY be configured per port to accept these frames for forwarding in cases where it is known that a non-peering device (such as an end station) is configured to originate TRILL-encapsulated frames that can be safely forwarded.
8. デフォルトでは、RBridgeは、TRILL IS-IS隣接を持たないネイバーからのTRILLカプセル化フレームを転送してはなりません（MUST NOT）。安全に転送できるTRILLカプセル化フレームを発信するように非ピアリングデバイス（エンドステーションなど）が構成されていることがわかっている場合は、RBridgeをポートごとに構成して、これらのフレームを転送用に受け入れることができます。
9. The Inner.MacDA is then tested. If it is the All-ESADI-RBridges multicast address and RBn implements the ESADI protocol, processing proceeds as in Section 4.6.2.2 below. If it is any other address or RBn does not implement ESADI, processing proceeds as in Section 4.6.2.3.
9. 次に、Inner.MacDAがテストされます。 All-ESADI-RBridgesマルチキャストアドレスであり、RBnがESADIプロトコルを実装している場合、処理はセクション4.6.2.2のように進行します。それが他のアドレスであるか、RBnがESADIを実装していない場合、処理はセクション4.6.2.3のように進行します。
The frame is processed by the TRILL IS-IS instance on RBn and is not forwarded.
フレームは、RBn上のTRILL IS-ISインスタンスによって処理され、転送されません。
If M == 0, the frame is silently discarded.
M == 0の場合、フレームは通知なく破棄されます。
The egress nickname designates the distribution tree. The frame is forwarded as described in Section 4.6.2.5. In addition, if the forwarding Rbridge is an appointed forwarder for a link in the specified VLAN and implements the TRILL ESADI protocol and ESADI is enabled at the forwarding Rbridge for that VLAN, the inner frame is decapsulated and provided to that local ESADI protocol.
出力ニックネームは配布ツリーを指定します。フレームは、セクション4.6.2.5で説明されているように転送されます。さらに、転送Rbridgeが指定されたVLAN内のリンクに指定されたフォワーダーであり、TRILL ESADIプロトコルを実装し、ESADIがそのVLANの転送Rbridgeで有効になっている場合、内部フレームはカプセル化解除され、そのローカルESADIプロトコルに提供されます。
The M flag is then checked. If it is zero, processing continues as described in Section 4.6.2.4, if it is one, processing continues as described in Section 4.6.2.5.
次にMフラグがチェックされます。ゼロの場合、セクション4.6.2.4の説明に従って処理が続行され、1の場合、セクション4.6.2.5の説明に従って処理が続行されます。
The egress nickname in the TRILL header is examined, and if it is unknown or reserved, the frame is discarded.
TRILLヘッダーの出力ニックネームが検査され、不明または予約されている場合、フレームは破棄されます。
If RBn is a transit RBridge, the hop count is decremented by one and the frame is forwarded to the next hop RBridge towards the egress RBridge. (The provision permitting RBridges to decrease the hop count by more than one under some circumstances (see Section 3.6) applies only to multi-destination frames, not to the known unicast frames considered in this subsection.) The Inner.VLAN is not examined by a transit RBridge when it forwards a known unicast TRILL Data frame. For the forwarded frame, the Outer.MacSA is the MAC address of the transmitting port, the Outer.MacDA is the unicast address of the next hop RBridge, and the VLAN is the Designated VLAN on the link onto which the frame is being transmitted.
RBnがトランジットRBridgeの場合、ホップカウントは1だけ減り、フレームは出力RBridgeに向かう次のホップRBridgeに転送されます。 （状況によっては、RBridgesがホップカウントを2つ以上減らすことを許可する規定（セクション3.6を参照）は、マルチサブスティネーションフレームにのみ適用され、このサブセクションで検討されている既知のユニキャストフレームには適用されません。）Inner.VLANは、既知のユニキャストTRILLデータフレームを転送するときの中継RBridge。転送されたフレームの場合、Outer.MacSAは送信ポートのMACアドレス、Outer.MacDAはネクストホップRBridgeのユニキャストアドレス、VLANはフレームが送信されるリンク上の指定VLANです。
If RBn is not a transit RBridge, that is, if the egress RBridge indicated is the RBridge performing the processing, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. Then the frame being forwarded is decapsulated to native form, and the following checks are performed:
RBnがトランジットRBridgeではない場合、つまり、示されている出力RBridgeが処理を実行するRBridgeである場合、デフォルトでは、ニックネームが不明であるか、予約済み、またはInner.MacSAはユニキャストではありません。次に、転送されるフレームがカプセル化解除されてネイティブ形式になり、次のチェックが実行されます。
o The Inner.MacDA is checked. If it is not unicast, the frame is discarded.
o Inner.MacDAがチェックされます。ユニキャストでない場合、フレームは破棄されます。
o If the Inner.MacDA corresponds to the RBridge doing the processing, the frame is locally delivered.
o Inner.MacDAが処理を行うRBridgeに対応している場合、フレームはローカルに配信されます。
o The Inner.VLAN ID is checked. If it is 0x0 or 0xFFF, the frame is discarded.
o Inner.VLAN IDがチェックされます。 0x0または0xFFFの場合、フレームは破棄されます。
o The Inner.MacDA and Inner.VLAN ID are looked up in RBn's local address cache and the frame is then either sent onto the link containing the destination, if the RBridge is appointed forwarder for that link for the frame's VLAN and is not inhibited (or discarded if it is inhibited), or processed as in one of the following two paragraphs.
o Inner.MacDAとInner.VLAN IDはRBnのローカルアドレスキャッシュで検索され、RBridgeがフレームのVLANのリンクのフォワーダーに指定されており、禁止されていない場合（または、禁止されている場合は破棄）、または次の2つの段落のいずれかとして処理されます。
A known unicast TRILL Data frame can arrive at the egress Rbridge only to find that the combination of Inner.MacDA and Inner.VLAN is not actually known by that RBridge. One way this can happen is that the address information may have timed out in the egress RBridge MAC address cache. In this case, the egress RBridge sends the native frame out on all links that are in the frame's VLAN for which the RBridge is appointed forwarder and has not been inhibited, except that it MAY refrain from sending the frame on links where it knows there cannot be an end station with the destination MAC address, for example, the link port is configured as a trunk (see Section 4.9.1).
既知のユニキャストTRILLデータフレームは、Ingress.MacDAとInner.VLANの組み合わせがそのRBridgeによって実際には認識されていないことを検出するためにのみ、出力Rbridgeに到達できます。これが発生する可能性のある1つの方法は、アドレス情報が出力RBridge MACアドレスキャッシュでタイムアウトした可能性があることです。この場合、出力RBridgeは、RBridgeがフォワーダーとして指定され、禁止されていないフレームのVLANにあるすべてのリンクでネイティブフレームを送信します。ただし、リンクできないことがわかっているリンクでフレームを送信しない場合があります。宛先MACアドレスを持つエンドステーションであること。たとえば、リンクポートはトランクとして設定されている（4.9.1を参照）。
If, due to manual configuration or learning from Layer 2 registration, the destination MAC and VLAN appear in RBn's local address cache for two or more links for which RBn is an uninhibited appointed forwarder for the frame's VLAN, RBn sends the native frame on all such links.
手動構成またはレイヤー2登録からの学習により、宛先MACおよびVLANが、RBnがフレームのVLANの抑制されていない指定されたフォワーダーである2つ以上のリンクのRBnのローカルアドレスキャッシュに表示される場合、RBnはそのようなすべてのネイティブフレームを送信しますリンク。
The egress and ingress nicknames in the TRILL header are examined and, if either is unknown or reserved, the frame is discarded.
TRILLヘッダーの出力ニックネームと入力ニックネームが検査され、不明または予約されている場合、フレームは破棄されます。
The Outer.MacSA is checked and the frame discarded if it is not a tree adjacency for the tree indicated by the egress RBridge nickname on the port where the frame was received. The Reverse Path Forwarding Check is performed on the ingress and egress nicknames and the frame discarded if it fails. If there are multiple TRILL-Hello pseudonode suppressed parallel links to the previous hop RBridge, the frame is discarded if it has been received on the wrong one. If the RBridge has multiple ports connected to the link, the frame is discarded unless it was received on the right one. For more information on the checks in this paragraph, see Section 4.5.2.
Outer.MacSAがチェックされ、フレームが受信されたポートの出力RBridgeニックネームによって示されたツリーのツリー隣接でない場合、フレームは破棄されます。リバースパス転送チェックは、入力と出力のニックネームで実行され、失敗した場合はフレームが破棄されます。前のホップのRBridgeへのTRILL-Hello疑似ノード抑制並列リンクが複数ある場合、フレームが間違ったもので受信された場合、フレームは破棄されます。 RBridgeにリンクに接続された複数のポートがある場合、フレームは、正しいポートで受信されない限り廃棄されます。この段落のチェックの詳細については、4.5.2項を参照してください。
If the Inner.VLAN ID of the frame is 0x0 or 0xFFF, the frame is discarded.
フレームのInner.VLAN IDが0x0または0xFFFの場合、フレームは破棄されます。
If the RBridge is an appointed forwarder for the Inner.VLAN ID of the frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. A copy of the frame is then decapsulated, sent in native form on those links in its VLAN for which the RBridge is appointed forwarder subject to additional pruning and inhibition as described in Section 4.2.4.3, and/or locally processed as appropriate.
RBridgeがフレームのInner.VLAN IDの指定されたフォワーダーである場合、デフォルトで、ニックネームが不明または予約されていないか、Inner.MacSAでない限り、Inner.MacSAおよびInner.VLAN IDは、入力ニックネームに関連付けられていると学習されます。ユニキャストではありません。次に、フレームのコピーがカプセル化解除され、ネイティブフォームで、セクション4.2.4.3で説明されているように、追加のプルーニングと禁止の対象となるRBridgeがフォワーダーとして指定されているVLANに送信され、必要に応じてローカルで処理されます。
The hop count is decreased (possibly by more than one; see Section 3.6), and the frame is forwarded down the tree specified by the egress RBridge nickname pruned as described in Section 4.5.
ホップカウントが減少し（おそらく1つ以上、セクション3.6を参照）、フレームはセクション4.5で説明されているようにプルーニングされた出力RBridgeニックネームによって指定されたツリーに転送されます。
For the forwarded frame, the Outer.MacSA is set to that of the port on which the frame is being transmitted, the Outer.MacDA is the All-RBridges multicast address, and the VLAN is the Designated VLAN of the link on which the frame is being transmitted.
転送されたフレームの場合、Outer.MacSAはフレームが送信されているポートのポートに設定され、Outer.MacDAはAll-RBridgesマルチキャストアドレスであり、VLANはフレームが接続されているリンクの指定VLANです。送信されています。
Low-level control frames received by an RBridge are handled within the port where they are received as described in Section 4.9.
RBridgeによって受信された低レベルの制御フレームは、セクション4.9で説明されているように、それらが受信されたポート内で処理されます。
There are two types of high-level control frames, distinguished by their destination address, which are handled as described in the sections referenced below.
高レベル制御フレームには2つのタイプがあり、宛先アドレスによって区別されます。これらは、以下で参照されるセクションで説明されているように処理されます。
Name Section Destination Address
名前セクション宛先アドレス
BPDU 4.9.3 01-80-C2-00-00-00 VRP 4.9.4 01-80-C2-00-00-21
BPDU 4.9.3 01-80-C2-00-00-00 VRP 4.9.4 01-80-C2-00-00-21
Ingress RBridges SHOULD learn, based on native IGMP [RFC3376], MLD [RFC2710], and MRD [RFC4286] frames they receive in VLANs for which they are an uninhibited appointed forwarder, which IP-derived multicast messages should be forwarded onto which links. Such frames are also, in general, encapsulated as TRILL Data frames and distributed as described below and in Section 4.5.
Ingress RBridgesは、ネイティブIGMP [RFC3376]、MLD [RFC2710]、およびMRD [RFC4286]フレームに基づいて学習する必要があります。これらのフレームは、抑制されていない指定フォワーダーであり、IP派生マルチキャストメッセージはどのリンクに転送される必要があります。このようなフレームは、一般に、TRILLデータフレームとしてカプセル化され、以下およびセクション4.5で説明するように配布されます。
An IGMP or MLD membership report received in native form from a link indicates a multicast group listener for that group on that link. An IGMP or MLD query or an MRD advertisement received in native form from a link indicates the presence of an IP multicast router on that link.
リンクからネイティブ形式で受信されたIGMPまたはMLDメンバーシップレポートは、そのリンク上のそのグループのマルチキャストグループリスナーを示します。リンクからネイティブ形式で受信されたIGMPまたはMLDクエリまたはMRDアドバタイズは、そのリンク上にIPマルチキャストルーターが存在することを示します。
IP multicast group membership reports have to be sent throughout the campus and delivered to all IP multicast routers, distinguishing IPv4 and IPv6. All IP-derived multicast traffic must also be sent to all IP multicast routers for the same version of IP.
IPマルチキャストグループメンバーシップレポートはキャンパス全体に送信され、IPv4とIPv6を区別してすべてのIPマルチキャストルーターに配信される必要があります。すべてのIP派生マルチキャストトラフィックは、同じバージョンのIPのすべてのIPマルチキャストルーターにも送信する必要があります。
IP multicast data SHOULD only be sent on links where there is either an IP multicast router for that IP type (IPv4 or IPv6) or an IP multicast group listener for that IP-derived multicast MAC address, unless the IP multicast address is in the range required to be treated as broadcast.
IPマルチキャストデータは、IPマルチキャストアドレスが範囲内にない限り、そのIPタイプ（IPv4またはIPv6）のIPマルチキャストルーターまたはそのIP派生マルチキャストMACアドレスのIPマルチキャストグループリスナーのいずれかがあるリンクでのみ送信する必要があります（SHOULD）。放送として扱う必要があります。
RBridges do not need to announce themselves as listeners to the IPv4 All-Snoopers multicast group (the group used for MRD reports [RFC4286]), because the IPv4 multicast address for that group is in the range where all frames sent to that IP multicast address must be broadcast (see [RFC4541], Section 2.1.2). However, RBridges that are performing IPv6-derived multicast optimization MUST announce themselves as listeners to the IPv6 All-Snoopers multicast group.
RBridgeは、IPv4 All-Snoopersマルチキャストグループ（MRDレポートに使用されるグループ[RFC4286]）へのリスナーとして自身をアナウンスする必要はありません。そのグループのIPv4マルチキャストアドレスは、すべてのフレームがそのIPマルチキャストアドレスに送信される範囲にあるためです。ブロードキャストする必要があります（[RFC4541]、セクション2.1.2を参照）。ただし、IPv6派生のマルチキャスト最適化を実行しているRBridgeは、IPv6 All-Snoopersマルチキャストグループへのリスナーとして自身を通知する必要があります。
See also "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" [RFC4541].
「インターネットグループ管理プロトコル（IGMP）とマルチキャストリスナ探索（MLD）スヌーピングスイッチに関する考慮事項」[RFC4541]も参照してください。
RBridges have to learn the MAC addresses and VLANs of their locally attached end stations for link/VLAN pairs for which they are the appointed forwarder. Learning this enables them to do the following:
RBridgeは、ローカルに接続されたエンドステーションのMACアドレスとVLANを学習する必要があります。これらのエンドステーションは、指定されたフォワーダーであるリンク/ VLANペアに対応します。これを学ぶことで、彼らは次のことができるようになります：
o Forward the native form of incoming known unicast TRILL Data frames onto the correct link.
o 着信する既知のユニキャストTRILLデータフレームのネイティブ形式を正しいリンクに転送します。
o Decide, for an incoming native unicast frame from a link, where the RBridge is the appointed forwarder for the frame's VLAN, whether the frame is
o リンクからの着信ネイティブユニキャストフレームの場合、RBridgeがフレームのVLANの指定されたフォワーダーであるかどうか、フレームが
- known to have been destined for another end station on the same link, so the RBridge need do nothing, or
- 同じリンク上の別の端末を宛先とすることがわかっているため、RBridgeは何もする必要がない、または
- has to be converted to a TRILL Data frame and forwarded.
- TRILLデータフレームに変換して転送する必要があります。
RBridges need to learn the MAC addresses, VLANs, and remote RBridges of remotely attached end stations for VLANs for which they and the remote RBridge are an appointed forwarder, so they can efficiently direct native frames they receive that are unicast to those addresses and VLANs.
RBridgeは、リモートアタッチされたエンドステーションのMACアドレス、VLAN、およびリモートRBridgeを学習する必要があります。これらのエンドステーションとリモートRBridgeは、指定されたフォワーダーであり、受信するネイティブフレームを効率的に転送して、それらのアドレスとVLANにユニキャストします。
There are five independent ways an RBridge can learn end-station addresses as follows:
RBridgeが次のようにエンドステーションアドレスを学習する方法は5つあります。
1. From the observation of VLAN-x frames received on ports where it is appointed VLAN-x forwarder, learning the { source MAC, VLAN, port } triplet of received frames.
1. VLAN-xフォワーダーとして指定されているポートで受信されたVLAN-xフレームの観察から、受信フレームの{送信元MAC、VLAN、ポート}トリプレットを学習します。
2. The { source MAC, VLAN, ingress RBridge nickname } triplet of any native frames that it decapsulates.
2. カプセル化を解除するネイティブフレームの{ソースMAC、VLAN、入力RBridgeニックネーム}トリプレット。
3. By Layer 2 registration protocols learning the { source MAC, VLAN, port } of end stations registering at a local port.
3. レイヤ2登録プロトコルによって、ローカルポートに登録している端末の{ソースMAC、VLAN、ポート}を学習します。
4. By running the TRILL ESADI protocol for one or more VLANs and thereby receiving remote address information and/or transmitting local address information.
4. 1つまたは複数のVLANに対してTRILL ESADIプロトコルを実行することにより、リモートアドレス情報を受信したり、ローカルアドレス情報を送信したりします。
5. By management configuration.
5. 管理構成によって。
RBridges MUST implement capabilities 1 and 2 above. RBridges use these capabilities unless configured, for one or more particular VLANs and/or ports, not to learn from either received frames or from decapsulating native frames to be transmitted or both.
RBridgesは、上記の機能1および2を実装する必要があります。 RBridgeは、1つ以上の特定のVLANまたはポート、あるいはその両方に対して構成されていない限り、これらの機能を使用して、受信フレームまたは送信されるネイティブフレームのカプセル化解除、あるいはその両方から学習しません。
RBridges MAY implement capabilities 3 and 4 above. If capability 4 is implemented, the ESADI protocol is run only when the RBridge is configured to do so on a per-VLAN basis.
RBridgesは、上記の機能3と4を実装してもよい（MAY）。機能4が実装されている場合、RBridgeがVLANごとに実行するように構成されている場合にのみ、ESADIプロトコルが実行されます。
RBridges SHOULD implement capability 5.
RBridgesは機能を実装する必要があります（SHOULD）5。
Entries in the table of learned MAC and VLAN addresses and associated information also have a one-octet unsigned confidence level associated with each entry whose rationale is given below. Such information learned from the observation of data has a confidence of 0x20 unless configured to have a different confidence. This confidence level can be configured on a per-RBridge basis separately for information learned from local native frames and that learned from remotely originated encapsulated frames. Such information received via the TRILL ESADI protocol is accompanied by a confidence level in the range 0 to 254. Such information configured by management defaults to a confidence level of 255 but may be configured to have another value.
学習されたMACアドレスとVLANアドレスのテーブルのエントリと関連情報も、その理論的根拠が以下に示されている各エントリに関連付けられた1オクテットの符号なし信頼レベルです。データの観察から得られたそのような情報は、異なる信頼度を持つように構成されていない限り、0x20の信頼度を持っています。この信頼レベルは、ローカルネイティブフレームから学習した情報と、リモートで生成されたカプセル化フレームから学習した情報について、RBridgeごとに個別に構成できます。 TRILL ESADIプロトコルを介して受信されるこのような情報には、0〜254の範囲の信頼レベルが付随します。管理者がデフォルトで構成するこのような情報は、255の信頼レベルですが、別の値を持つように構成することもできます。
The table of learned MAC addresses includes (1) { confidence, VLAN, MAC address, local port } for addresses learned from local native frames and local registration protocols, (2) { confidence, VLAN, MAC address, egress RBridge nickname } for addresses learned from remote encapsulated frames and ESADI link state databases, and (3) additional information to implement timeout of learned addresses, statically configured addresses, and the like.
学習されたMACアドレスのテーブルには、（1）{信頼性、VLAN、MACアドレス、ローカルポート}が含まれます。リモートのカプセル化されたフレームとESADIリンク状態データベースから学習し、（3）学習したアドレス、静的に構成されたアドレスなどのタイムアウトを実装するための追加情報。
When a new address and related information learned from observing data frames are to be entered into the local database, there are three possibilities:
データフレームの監視から学習した新しいアドレスと関連情報をローカルデータベースに入力する場合、3つの可能性があります。
A. If this is a new { address, VLAN } pair, the information is entered accompanied by the confidence level.
A.これが新しい{アドレス、VLAN}のペアである場合、情報は信頼レベルを伴って入力されます。
B. If there is already an entry for this { address, VLAN } pair with the same accompanying delivery information, the confidence level in the local database is set to the maximum of its existing confidence level and the confidence level with which it is being learned. In addition, if the information is being learned with the same or a higher confidence level than its existing confidence level, timer information is reset.
B.この{アドレス、VLAN}ペアのエントリに同じ付随する配信情報がすでに存在する場合、ローカルデータベースの信頼レベルは、既存の信頼レベルと学習される信頼レベルの最大値に設定されます。 。さらに、情報が既存の信頼レベルと同じかそれよりも高い信頼レベルで学習されている場合、タイマー情報がリセットされます。
C. If there is already an entry for this { address, VLAN } pair with different information, the learned information replaces the older information only if it is being learned with higher or equal confidence than that in the database entry. If it replaces older information, timer information is also reset.
C.すでにこの{アドレス、VLAN}ペアに異なる情報のエントリがある場合、データベースエントリよりも高いまたは同等の信頼度で学習されている場合にのみ、学習された情報が古い情報を置き換えます。古い情報を置き換えると、タイマー情報もリセットされます。
The confidence level mechanism allows an RBridge campus manager to cause certain address learning sources to prevail over others. In a default configuration, without the optional ESADI protocol, addresses are only learned from observing local native frames and the decapsulation of received TRILL Data frames. Both of these sources default to confidence level 0x20 so, since learning at an equal or high confidence overrides previous learning, the learning in such a default case mimics default 802.1 bridge learning.
信頼レベルのメカニズムにより、RBridgeキャンパスマネージャは、特定のアドレス学習ソースを他のソースよりも優先させることができます。デフォルトの構成では、オプションのESADIプロトコルがない場合、アドレスはローカルのネイティブフレームと受信したTRILLデータフレームのカプセル化を監視することからのみ学習されます。これらのソースはどちらもデフォルトで信頼レベル0x20に設定されているため、同等または高い信頼度での学習は以前の学習をオーバーライドするため、このようなデフォルトの場合の学習はデフォルトの802.1ブリッジ学習を模倣します。
While RBridge campus management policies are beyond the scope of this document, here are some example types of policies that can be implemented with the confidence mechanism and the rationale for each:
RBridgeキャンパス管理ポリシーはこのドキュメントの範囲外ですが、信頼メカニズムとそれぞれの根拠で実装できるポリシーのタイプの例をいくつか次に示します。
o Locally received native frames might be considered more reliable than decapsulated frames received from remote parts of the campus. To stop MAC addresses learned from such local frames from being usurped by remotely received forged frames, the confidence in locally learned addresses could be increased or that in addresses learned from remotely sourced decapsulated frames decreased.
o ローカルで受信したネイティブフレームは、キャンパスのリモート部分から受信したカプセル化解除されたフレームよりも信頼性が高いと考えられています。このようなローカルフレームから学習したMACアドレスが、リモートで受信した偽造フレームによって奪われるのを防ぐには、ローカルで学習したアドレスの信頼性を高めるか、リモートでソースされたカプセル化解除フレームから学習したアドレスの信頼性を下げます。
o MAC address information learned through a cryptographically authenticated Layer 2 registration protocol, such as 802.1X with a cryptographically based EAP method, might be considered more reliable than information learned through the mere observation of data frames. When such authenticated learned address information is transmitted via the ESADI protocol, the use of authentication in the TRILL ESADI LSP frames could make tampering with it in transit very difficult. As a result, it might be reasonable to announce such authenticated information via the ESADI protocol with a high confidence, so it would override any alternative learning from data observation.
o 暗号化ベースのEAP方式の802.1Xなど、暗号化認証されたレイヤー2登録プロトコルを通じて学習したMACアドレス情報は、データフレームの単なる観察を通じて学習した情報よりも信頼性が高いと考えられます。このような認証済みの学習済みアドレス情報がESADIプロトコルを介して送信される場合、TRILL ESADI LSPフレームで認証を使用すると、送信中にその改ざんが非常に困難になる可能性があります。その結果、ESADIプロトコルを介してそのような認証された情報を高い信頼度で発表することが合理的である可能性があるため、データ観察からの代替学習を無効にします。
Manually configured address information is generally considered static and so defaults to a confidence of 0xFF while no other source of such information can be configured to a confidence any higher than 0xFE. However, for other cases, such as where the manual configuration is just a starting point that the Rbridge campus manager wishes to be dynamically overridable, the confidence of such manually configured information may be configured to a lower value.
手動で構成されたアドレス情報は一般に静的と見なされるため、デフォルトで0xFFの信頼性が設定されますが、そのような情報の他のソースを0xFEより高い信頼性に構成することはできません。ただし、手動構成がRbridgeキャンパスマネージャーが動的に上書き可能であることを望む開始点にすぎない場合など、他のケースでは、そのような手動構成情報の信頼度は低い値に構成されます。
While RBridges need to learn end-station addresses as described above, it is equally important that they be able to forget such information. Otherwise, frames for end stations that have moved to a different part of the campus could be indefinitely black-holed by RBridges with stale information as to the link to which the end station is attached.
RBridgeは上記のようにエンドステーションのアドレスを学習する必要がありますが、そのような情報を忘れることができることも同様に重要です。そうしないと、キャンパスの別の部分に移動したエンドステーションのフレームが、エンドステーションが接続されているリンクに関する古い情報を含むRBridgeによって無期限にブラックホール化される可能性があります。
For end-station address information locally learned from frames received, the time out from the last time a native frame was received or decapsulated with the information conforms to the recommendations of [802.1D]. It is referred to as the "Ageing Time" and is configurable per RBridge with a range of from 10 seconds to 1,000,000 seconds and a default value of 300 seconds.
受信フレームからローカルに学習された端末アドレス情報の場合、ネイティブフレームが最後に受信されたか、情報でカプセル化が解除されたときからのタイムアウトは、[802.1D]の推奨事項に準拠しています。これは「エージングタイム」と呼ばれ、RBridgeごとに設定可能で、範囲は10秒から1,000,000秒、デフォルト値は300秒です。
The situation is different for end-station address information acquired via the TRILL ESADI protocol. It is up to the originating RBridge to decide when to remove such information from its ESADI LSPs (or up to ESADI protocol timeouts if the originating RBridge becomes inaccessible).
TRILL ESADIプロトコルを介して取得した端末アドレス情報の場合は、状況が異なります。そのような情報をESADI LSPからいつ削除するかを決定するのは、元のRBridgeです（または、元のRBridgeにアクセスできなくなった場合は、ESADIプロトコルタイムアウトまで）。
When an RBridge ceases to be appointed forwarder for VLAN-x on a port, it forgets all end-station address information learned from the observation of VLAN-x native frames received on that port. It also increments a per-VLAN counter of the number of times it lost appointed forwarder status on one of its ports for that VLAN.
RBridgeがポート上のVLAN-xのフォワーダーとして指定されなくなると、そのポートで受信されたVLAN-xネイティブフレームの観測から得られたすべてのエンドステーションアドレス情報を失います。また、そのVLANのポートの1つで指定されたフォワーダーステータスを失った回数のVLANごとのカウンターをインクリメントします。
When, for all of its ports, RBridge RBn is no longer appointed forwarder for VLAN-x, it forgets all end-station address information learned from decapsulating VLAN-x native frames. Also, if RBn is participating in the TRILL ESADI protocol for VLAN-x, it ceases to so participate after sending a final LSP nulling out the end-station address information for the VLAN that it had been originating. In addition, all other RBridges that are VLAN-x forwarder on at least one of their ports notice that the link state data for RBn has changed to show that it no longer has a link on VLAN-x. In response, they forget all end-station address information they have learned from decapsulating VLAN-x frames that show RBn as the ingress RBridge.
すべてのポートについて、RBridge RBnがVLAN-xのフォワーダーに指定されなくなった場合、VLAN-xネイティブフレームのカプセル化解除から学習したすべてのエンドステーションアドレス情報を忘れます。また、RBnがVLAN-xのTRILL ESADIプロトコルに参加している場合は、元のVLANの端末アドレス情報をヌルにする最終LSPを送信した後、RBnは参加しなくなります。さらに、少なくとも1つのポートでVLAN-xフォワーダーである他のすべてのRBridgeは、RBnのリンク状態データが変更され、VLAN-xにリンクがなくなったことを示すことに気付きます。それに応じて、RBnを入力RBridgeとして示すVLAN-xフレームのカプセル化を解除して得たすべてのエンドステーションアドレス情報を忘れます。
When the appointed forwarder lost counter for RBridge RBn for VLAN-x is observed to increase via the TRILL IS-IS link state database but RBn continues to be an appointed forwarder for VLAN-x on at least one of its ports, every other RBridge that is an appointed forwarder for VLAN-x modifies the aging of all the addresses it has learned by decapsulating native frames in VLAN-x from ingress RBridge RBn as follows: the time remaining for each entry is adjusted to be no larger than a per-RBridge configuration parameter called (to correspond to [802.1D]) "Forward Delay". This parameter is in the range of 4 to 30 seconds with a default value of 15 seconds.
VLAN-xのRBridgeの指定されたフォワーダーロストカウンターがTRILL IS-ISリンクステートデータベースを介して増加することが観察されたが、RBnがそのポートの少なくとも1つでVLAN-xの指定されたフォワーダーであり続け、他のすべてのRBridgeがVLAN-xの指定されたフォワーダーです。VLAN-xのネイティブフレームを入力RBridge RBnからカプセル化解除することにより、学習したすべてのアドレスのエージングを次のように変更します。各エントリの残り時間は、RBridgeごとに長くならないように調整されます（[802.1D]に対応する） "Forward Delay"と呼ばれる設定パラメータ。このパラメーターの範囲は4〜30秒で、デフォルト値は15秒です。
RBridges can map VLAN IDs into a smaller number of identifiers for purposes of address learning, as [802.1Q-2005] bridges can. Then, when a lookup is done in learned address information, this identifier is used for matching in place of the VLAN ID. If the ID of the VLAN on which the address was learned is not retained, then there are the following consequences: o The RBridge no longer has the information needed to participate in the TRILL ESADI protocol for the VLANs whose ID is not being retained.
RBridgeは、[802.1Q-2005]ブリッジができるように、アドレス学習のためにVLAN IDを少数の識別子にマッピングできます。次に、学習されたアドレス情報で検索が行われると、VLAN IDの代わりにこの識別子が照合に使用されます。アドレスが学習されたVLANのIDが保持されない場合、次の結果が生じます。o RBridgeは、IDが保持されていないVLANのTRILL ESADIプロトコルに参加するために必要な情報を失いました。
o In cases where Section 4.8.3 above requires the discarding of learned address information based on a particular VLAN, when the VLAN ID is not available for entries under a shared VLAN identifier, instead the time remaining for each entry under that shared VLAN identifier is adjusted to be no longer than the RBridge's "Forward Delay".
o 上記のセクション4.8.3で特定のVLANに基づいて学習したアドレス情報を破棄する必要がある場合、共有VLAN識別子の下のエントリでVLAN IDを使用できないときは、その共有VLAN識別子の下の各エントリの残り時間が調整されます。 RBridgeの「Forward Delay」を超えないようにしてください。
Although outside the scope of this specification, there are some Layer 2 features in which a set of VLANs has shared learning, where one of the VLANs is the "primary" and the other VLANs in the group are "secondaries". An example of this is where traffic from different communities is separated using VLAN tags, and yet some resource (such as an IP router or DHCP server) is to be shared by all the communities. A method of implementing this feature is to give a VLAN tag, say, Z, to a link containing the shared resource, and have the other VLANs, say, A, C, and D, be part of the group { primary = Z, secondaries = A, C, D }. An RBridge, aware of this grouping, attached to one of the secondary VLANs in the group also claims to be attached to the primary VLAN. So an RBridge attached to A would claim to also be attached to Z. An RBridge attached to the primary would claim to be attached to all the VLANs in the group.
この仕様の範囲外ですが、VLANのセットが学習を共有するいくつかのレイヤ2機能があります。ここで、VLANの1つは「プライマリ」であり、グループ内の他のVLANは「セカンダリ」です。この例では、さまざまなコミュニティからのトラフィックがVLANタグを使用して分離され、さらに一部のリソース（IPルーターやDHCPサーバーなど）がすべてのコミュニティで共有されます。この機能を実装する方法は、共有リソースを含むリンクにVLANタグ（Zなど）を割り当て、他のVLAN（A、C、Dなど）をグループ{primary = Z、セカンダリ= A、C、D}。このグループ化を認識し、グループ内のセカンダリVLANの1つに接続されているRBridgeも、プライマリVLANに接続されていると主張します。したがって、Aに接続されているRBridgeはZにも接続されていると主張します。プライマリに接続されているRBridgeは、グループ内のすべてのVLANに接続されていると主張します。
This document does not specify how VLAN groups might be used. Only RBridges that participate in a VLAN group will be configured to know about the VLAN group. However, to detect misconfiguration, an RBridge configured to know about a VLAN group SHOULD report the VLAN group in its LSP.
このドキュメントでは、VLANグループの使用方法については説明していません。 VLANグループに参加するRBridgeのみが、VLANグループを認識するように構成されます。ただし、構成ミスを検出するために、VLANグループを認識するように構成されたRBridgeは、LSPでVLANグループを報告する必要があります（SHOULD）。
Section 4.9.1 below describes the several RBridge port configuration bits, Section 4.9.2 gives a logical port structure in terms of frame processing, and Sections 4.9.3 and 4.9.4 describe the handling of high-level control frames.
以下のセクション4.9.1は、いくつかのRBridgeポート構成ビットについて説明し、セクション4.9.2はフレーム処理の観点から論理ポート構造を示し、セクション4.9.3および4.9.4は高レベルの制御フレームの処理について説明します。
There are four per-port configuration bits as follows:
次のように、ポートごとの構成ビットが4つあります。
o Disable port bit. When this bit is set, all frames received or to be transmitted are discarded, with the possible exception of some Layer 2 control frames (see Section 1.4) that may be generated and transmitted or received and processed within the port. By default, ports are enabled.
o ポートビットを無効にします。このビットが設定されると、ポート内で生成および送信または受信および処理される一部のレイヤ2制御フレーム（セクション1.4を参照）を除いて、受信または送信されるすべてのフレームが破棄されます。デフォルトでは、ポートは有効になっています。
o End-station service disable (trunk port) bit. When this bit is set, all native frames received on the port and all native frames that would have been sent on the port are discarded. (See Appendix B.) (Note that, for this document, "native frames" does not include Layer 2 control frames.) By default, ports are not restricted to being trunk ports.
o 端末のサービス無効化（トランクポート）ビット。このビットが設定されている場合、ポートで受信されたすべてのネイティブフレーム、およびポートで送信されたすべてのネイティブフレームは破棄されます。 （付録Bを参照してください。）（このドキュメントでは、「ネイティブフレーム」にはレイヤ2コントロールフレームが含まれていないことに注意してください。）デフォルトでは、ポートはトランクポートに限定されていません。
If a port with end-station service disabled reports, in a TRILL-Hello frame it sends out that port, which VLANs it provides end-station support for, it reports that there are none.
端末サービスが無効になっているポートがTRILL-Helloフレームでレポートする場合、そのポートを送信し、どのVLANが端末サポートを提供するかを報告します。
o TRILL traffic disable (access port) bit. If this bit is set, the goal is to avoid sending any TRILL frames, except TRILL-Hello frames, on the port since it is intended only for native end-station traffic. By default, ports are not restricted to being access ports. This bit is reported in TRILL-Hello frames. If RB1 is the DRB and has this bit set in its TRILL-Hello, the DRB still appoints VLAN forwarders. However, usually no pseudonode is reported, and none of the inter-RBridge links associated with that link are reported in LSPs.
o TRILLトラフィック無効化（アクセスポート）ビット。このビットが設定されている場合、ネイティブのエンドステーショントラフィック専用であるため、ポートでTRILL-Helloフレーム以外のTRILLフレームを送信しないようにすることが目標です。デフォルトでは、ポートはアクセスポートに限定されません。このビットはTRILL-Helloフレームで報告されます。 RB1がDRBであり、このビットがTRILL-Helloに設定されている場合でも、DRBはVLANフォワーダーを指定します。ただし、通常は疑似ノードは報告されず、そのリンクに関連付けられているRBridge間リンクはLSPで報告されません。
If the DRB RB1 does not have this bit set, but neighbor RB2 on the link does have the bit set, then RB1 does not appoint RB2 as appointed forwarder for any VLAN, and none of the RBridges (including the pseudonode) report RB2 as a neighbor in LSPs.
DRB RB1にこのビットが設定されていないが、リンク上のネイバーRB2にビットが設定されている場合、RB1はRB2をVLANの指定されたフォワーダーとして指定せず、どのRBridges（疑似ノードを含む）もRB2をLSPのネイバー。
In some cases even though the DRB has the "access port" flag set, the DRB MAY choose to create a pseudonode for the access port. In this case, the other RBridges report connectivity to the pseudonode in their LSP, but the DRB sets the "overload" flag in the pseudonode LSP.
DRBに「アクセスポート」フラグが設定されている場合でも、DRBはアクセスポートの疑似ノードを作成することを選択できます（MAY）。この場合、他のRBridgeはLSPの疑似ノードへの接続を報告しますが、DRBは疑似ノードLSPに「過負荷」フラグを設定します。
o Use P2P Hellos bit. If this bit is set, Hellos sent on this port are IS-IS P2P Hellos. By default TRILL-Hellos are used. See Section 4.2.4.1 for more information on P2P links.
o P2P Hellosビットを使用します。このビットが設定されている場合、このポートで送信されるHelloはIS-IS P2P Helloです。デフォルトではTRILL-Helloが使用されます。 P2Pリンクの詳細については、セクション4.2.4.1を参照してください。
The dominance relationship of these four configuration bits is as follows, where configuration bits to the left dominate those to the right. That is to say, when any pair of bits is asserted, inconsistencies in behavior they mandate are resolved in favor of behavior mandated by the bit to the left of the other bit in this list.
これらの4つの構成ビットの優位関係は次のとおりです。ここで、左側の構成ビットが右側の構成ビットを支配しています。つまり、ビットのペアがアサートされると、このリストで他のビットの左側にあるビットによって義務付けられた動作を優先して、それらが要求する動作の不整合が解決されます。
Disable > P2P > Access > Trunk
An RBridge port can be modeled as having a lower-level structure similar to that of an [802.1Q-2005] bridge port as shown in Figure 11. In this figure, the double lines represent the general flow of the frames and information while single lines represent information flow only. The dashed lines in connection with VRP (GVRP/MVRP) are to show that VRP support is optional. An actual RBridge port implementation may be structured in any way that provides the correct behavior.
RBridgeポートは、図11に示すように、[802.1Q-2005]ブリッジポートと同様の下位レベルの構造を持つものとしてモデル化できます。この図では、二重線はフレームと情報の一般的なフローを表しています。線は情報の流れのみを表します。 VRP（GVRP / MVRP）に関連する破線は、VRPサポートがオプションであることを示しています。実際のRBridgeポート実装は、正しい動作を提供する方法で構造化できます。
+----------------------------------------------
| RBridge
|
| Interport Forwarding, IS-IS. Management, ...
|
+----++----------------------+-------------++--
|| | ||
TRILL || Data | ||
|| +--+---------+ ||
+-------------++-----+ | TRILL | ||
| Encapsulation | +------+ IS-IS Hello| ||
| Decapsulation | | | Processing | ||
| Processing | | +-----++-----+ ||
+--------------------+ | || ||
| RBridge Appointed +------+ || ||
+---+ Forwarder and | || ||
| | Inhibition Logic +==============\\ || //====++
| +---------+--------+-+ Native \\ ++ //
| | | Frames \++/
| | | ||
+----+-----+ +- - + - - + | ||
| RBridge | | RBridge | | || All TRILL and
| BPDU | | VRP | | || Native Frames
|Processing| |Processing| | ||
+-----++---+ + - - -+- -+ | +--------++--+ <- EISS
|| | | | 802.1Q |
|| | | | Port VLAN |
|| | | |and Priority|
|| | | | Processing |
+---++------------++------+------------+------------+ <-- ISS
| 802.1/802.3 Low-Level Control Frame |
| Processing, Port/Link Control Logic |
+------------++-------------------------------------+
||
|| +------------+
|| | 802.3 PHY |
++========+ (Physical +======== 802.3
| Interface) | Link
+------------+
Figure 11: Detailed RBridge Port Model
図11：詳細なRBridgeポートモデル
Low-level control frames are handled in the lower-level port/link control logic in the same way as in an [802.1Q-2005] bridge port. This can optionally include a variety of 802.1 or link specific protocols such as PAUSE (Annex 31B of [802.3]), link layer discovery [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or port-based access control [802.1X]. While handled at a low level,
低レベルの制御フレームは、[802.1Q-2005]ブリッジポートと同じ方法で、低レベルのポート/リンク制御ロジックで処理されます。これには、PAUSE（[802.3]のAnnex 31B）、リンク層検出[802.1AB]、リンクアグリゲーション[802.1AX]、MACセキュリティ[802.1AE]、ポートベースなど、さまざまな802.1またはリンク固有のプロトコルをオプションで含めることができますアクセス制御[802.1X]。低レベルで処理されている間、
these frames may affect higher-level processing. For example, a Layer 2 registration protocol may affect the confidence in learned addresses. The upper interface to this lower-level port control logic corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005].
これらのフレームは、高レベルの処理に影響を与える可能性があります。たとえば、レイヤ2登録プロトコルは、学習したアドレスの信頼性に影響を与える可能性があります。この下位レベルのポート制御ロジックへの上位インターフェースは、[802.1Q-2005]の内部サブレイヤーサービス（ISS）に対応しています。
High-level control frames (BPDUs and, if supported, VRP frames) are not VLAN tagged. Although they extend through the ISS interface, they are not subject to port VLAN processing. Behavior on receipt of a VLAN tagged BPDU or VLAN tagged VRP frame is unspecified. If a VRP is not implemented, then all VRP frames are discarded. Handling of BPDUs is described in Section 4.9.3. Handling of VRP frames is described in Section 4.9.4.
高レベルの制御フレーム（BPDU、およびサポートされている場合はVRPフレーム）には、VLANタグが付けられていません。これらはISSインターフェイスを介して拡張されますが、ポートVLAN処理の対象ではありません。 VLANタグ付きBPDUまたはVLANタグ付きVRPフレームの受信時の動作は指定されていません。 VRPが実装されていない場合、すべてのVRPフレームが破棄されます。 BPDUの処理については、4.9.3節で説明します。 VRPフレームの処理については、セクション4.9.4で説明します。
Frames other than Layer 2 control frames, that is, all TRILL and native frames, are subject to port VLAN and priority processing that is the same as for an [802.1Q-2005] bridge. The upper interface to the port VLAN and priority processing corresponds to the Extended Internal Sublayer Service (EISS) in [802.1Q-2005].
レイヤ2制御フレーム以外のフレーム、つまりすべてのTRILLおよびネイティブフレームは、ポートVLANおよび[802.1Q-2005]ブリッジと同じ優先処理の対象です。ポートVLANへの上部インターフェイスと優先処理は、[802.1Q-2005]の拡張内部サブレイヤーサービス（EISS）に対応します。
In this model, RBridge port processing below the EISS layer is identical to an [802.1Q-2005] bridge except for (1) the handling of high-level control frames and (2) that the discard of frames that have exceeded the Maximum Transit Delay is not mandatory but MAY be done.
このモデルでは、EISSレイヤーの下のRBridgeポート処理は、（1）高レベル制御フレームの処理、および（2）最大伝送を超えたフレームの破棄を除いて、[802.1Q-2005]ブリッジと同じです。遅延は必須ではありませんが、行われる場合があります。
As described in more detail elsewhere in this document, incoming native frames are only accepted if the RBridge is an uninhibited appointed forwarder for the frame's VLAN, after which they are normally encapsulated and forwarded; outgoing native frames are usually obtained by decapsulation and are only output if the RBridge is an uninhibited appointed forwarder for the frame's VLAN.
このドキュメントの他の場所で詳細に説明されているように、着信ネイティブフレームは、RBridgeがフレームのVLANの抑制されていない指定フォワーダーである場合にのみ受け入れられ、その後通常はカプセル化されて転送されます。発信ネイティブフレームは通常、カプセル化解除によって取得され、RBridgeがフレームのVLANの抑制されていない指定フォワーダーである場合にのみ出力されます。
TRILL-Hellos, MTU-probes, and MTU-acks are handled per port and, like all TRILL IS-IS frames, are never forwarded. They can affect the appointed forwarder and inhibition logic as well as the RBridge's LSP.
TRILL-Hello、MTUプローブ、およびMTU-ackはポートごとに処理され、すべてのTRILL IS-ISフレームと同様に転送されることはありません。これらは、指定されたフォワーダーと禁止ロジック、およびRBridgeのLSPに影響を与える可能性があります。
Except TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control as well as TRILL data and ESADI frames are passed up to higher-level RBridge processing on receipt and passed down for transmission on creation or forwarding. Note that these frames are never blocked due to the appointed forwarder and inhibition logic, which affects only native frames, but there are additional filters on some of them such as the Reverse Path Forwarding Check.
TRILL-Hello、MTUプローブ、およびMTU-ackを除いて、すべてのTRILL制御とTRILLデータおよびESADIフレームは、受信時に上位レベルのRBridge処理に渡され、作成または転送時に送信のために渡されます。これらのフレームは、指定されたフォワーダーと禁止ロジックのためにブロックされることはなく、ネイティブフレームのみに影響しますが、リバースパス転送チェックなどの一部のフレームには追加のフィルターがあります。
If RBridge campus topology were static, RBridges would simply be end stations from a bridging perspective, terminating but not otherwise interacting with spanning tree. However, there are reasons for RBridges to listen to and sometimes to transmit BPDUs as described below. Even when RBridges listen to and transmit BPDUs, this is a local RBridge port activity. The ports of a particular RBridge never interact so as to make the RBridge as a whole a spanning tree node.
RBridgeキャンパストポロジが静的である場合、RBridgeはブリッジングの観点からは単にエンドステーションであり、スパニングツリーで終端しますが、他の方法では相互作用しません。ただし、以下に説明するように、RBridgeがBPDUをリッスンし、場合によっては送信する理由があります。 RBridgeがBPDUをリッスンして送信する場合でも、これはローカルのRBridgeポートアクティビティです。特定のRBridgeのポートが相互作用して、RBridge全体をスパニングツリーノードにすることはありません。
Rbridges MUST listen to spanning tree configuration BPDUs received on a port and keep track of the root bridge, if any, on that link. If MSTP is running on the link, this is the CIST root. This information is reported per VLAN by the RBridge in its LSP and may be used as described in Section 4.2.4.3. In addition, the receipt of spanning tree configuration BPDUs is used as an indication that a link is a bridged LAN, which can affect the RBridge transmission of BPDUs.
Rbridgeは、ポートで受信したスパニングツリー構成BPDUをリッスンし、そのリンク上にルートブリッジがある場合は、それを追跡する必要があります。 MSTPがリンク上で実行されている場合、これはCISTルートです。この情報は、LSPのRBridgeによってVLANごとに報告され、セクション4.2.4.3で説明されているように使用できます。さらに、スパニングツリー構成BPDUの受信は、リンクがブリッジLANであることを示すものとして使用されます。これは、BPDUのRBridge送信に影響を与える可能性があります。
An RBridge MUST NOT encapsulate or forward any BPDU frame it receives.
RBridgeは、受信したBPDUフレームをカプセル化または転送してはなりません（MUST NOT）。
RBridges discard any topology change BPDUs they receive, but note Section 4.9.3.3.
RBridgeは、受信したトポロジ変更BPDUを破棄しますが、セクション4.9.3.3に注意してください。
A change in the root bridge seen in the spanning tree BPDUs received at an RBridge port may indicate a change in bridged LAN topology, including the possibility of the merger of two bridged LANs or the like, without any physical indication at the port. During topology transients, bridges may go into pre-forwarding states that block TRILL-Hello frames. For these reasons, when an RBridge sees a root bridge change on a port for which it is appointed forwarder for one or more VLANs, it is inhibited for a period of time between zero and 30 seconds. (An inhibited appointed forwarder discards all native frames received from or that it would otherwise have sent to the link.) This time period is configurable per port and defaults to 30 seconds.
RBridgeポートで受信されたスパニングツリーBPDUに表示されるルートブリッジの変化は、ポートでの物理的な表示なしに、2つのブリッジLANの結合などの可能性を含む、ブリッジLANトポロジの変化を示している可能性があります。トポロジーの過渡状態の間、ブリッジはTRILL-Helloフレームをブロックする転送前の状態になる場合があります。これらの理由により、RBridgeは、1つ以上のVLANのフォワーダーとして指定されているポートでルートブリッジの変更を検出すると、0〜30秒の間禁止されます。 （禁止された任命フォワーダーは、リンクから受信した、またはリンクに送信したはずのすべてのネイティブフレームを破棄します。）この期間はポートごとに構成可能で、デフォルトは30秒です。
For example, consider two bridged LANs carrying multiple VLANs, each with various RBridge appointed forwarders. Should they become merged, due to a cable being plugged in or the like, those RBridges attached to the original bridged LAN with the lower priority root will see a root bridge change while those attached to the other original bridged LAN will not. Thus, all appointed forwarders in the lower priority set will be inhibited for a time period while things are sorted out by BPDUs within the merged bridged LAN and TRILL-Hello frames between the RBridges involved.
たとえば、複数のVLANを伝送する2つのブリッジLANについて考えてみましょう。それぞれがさまざまなRBridgeでフォワーダーを指定しています。ケーブルが差し込まれているなどの理由でそれらがマージされた場合、優先順位の低いルートで元のブリッジLANに接続されているRBridgeにはルートブリッジの変更が表示されますが、他の元のブリッジLANに接続されているRBridgeには表示されません。したがって、マージされたブリッジLAN内のBPDUと関係するRBridge間のTRILL-Helloフレームによって物事が分類されている間、優先度の低いセットで指定されたすべてのフォワーダーが一定期間禁止されます。
When an RBridge ceases to be appointed forwarder for one or more VLANs out a particular port, it SHOULD, as long as it continues to receive spanning tree BPDUs on that port, send topology change BPDUs until it sees the topology change acknowledged in a spanning tree configuration BPDU.
特定のポートから1つ以上のVLANのRBridgeがフォワーダーとして指定されなくなると、そのポートでスパニングツリーBPDUを受信し続ける限り、トポロジ変更がスパニングツリーで確認されるまでトポロジ変更BPDUを送信する必要があります（SHOULD）。構成BPDU。
RBridges MAY support a capability for sending spanning tree BPDUs for the purpose of attempting to force a bridged LAN to partition as discussed in Appendix A.3.3.
RBridgesは、付録A.3.3で説明されているように、ブリッジングされたLANを強制的に分割しようとする目的で、スパニングツリーBPDUを送信する機能をサポートする場合があります。
Dynamic VLAN registration provides a means for bridges (and less commonly end stations) to request that VLANs be enabled or disabled on ports leading to the requestor. This is done by VLAN registration protocol (VRP) frames: GVRP or MVRP. RBridges MAY implement GVRP and/or MVRP as described below.
動的VLAN登録は、ブリッジ（および一般的にエンドステーションではない）が、リクエスタにつながるポートでVLANを有効または無効にすることを要求する手段を提供します。これは、VLAN Registration Protocol（VRP）フレーム（GVRPまたはMVRP）によって行われます。 RBridgesは、以下に説明するようにGVRPやMVRPを実装してもよい（MAY）。
VRP frames are never encapsulated as TRILL frames between RBridges or forwarded in native form by an RBridge. If an RBridge does not implement a VRP, it discards any VRP frames received and sends none.
VRPフレームは、RBridge間のTRILLフレームとしてカプセル化されたり、RBridgeによってネイティブ形式で転送されたりすることはありません。 RBridgeがVRPを実装していない場合、RBridgeは受信したVRPフレームを破棄して何も送信しません。
RBridge ports may have dynamically enabled VLANs. If an RBridge supports a VRP, the actual enablement of dynamic VLANs is determined by GVRP/MVRP frames received at the port as it would be for an [802.1Q-2005] / [802.1ak] bridge.
RBridgeポートには、動的に有効化されたVLANがある場合があります。 RBridgeがVRPをサポートする場合、動的VLANの実際の有効化は、[802.1Q-2005] / [802.1ak]ブリッジの場合と同様に、ポートで受信されるGVRP / MVRPフレームによって決定されます。
An RBridge that supports a VRP sends GVRP/MVRP frames as an [802.1Q-2005] / [802.1ak] bridge would send on each port that is not configured as an RBridge trunk port or P2P port. For this purpose, it sends VRP frames to request traffic in the VLANs for which it is appointed forwarder and in the Designated VLAN, unless the Designated VLAN is disabled on the port, and to not request traffic in any other VLAN.
VRPをサポートするRBridgeは、GVRP / MVRPフレームを[802.1Q-2005] / [802.1ak]ブリッジがRBridgeトランクポートまたはP2Pポートとして構成されていない各ポートで送信するように送信します。この目的のために、ポートで指定VLANが無効になっていない限り、フォワーダーとして指定されたVLANと指定VLANでトラフィックを要求し、他のVLANでトラフィックを要求しないように、VRPフレームを送信します。
This section lists parameters for RBridges. It is expected that the TRILL MIB will include many of the items listed in this section plus additional Rbridge status and data including traffic and error counts.
このセクションでは、RBridgeのパラメーターをリストします。 TRILL MIBには、このセクションにリストされている項目の多くに加えて、追加のRbridgeステータスと、トラフィックやエラーの数を含むデータが含まれることが予想されます。
The default value and range are given for parameters added by TRILL. Where a parameter is defined as a 16-bit unsigned integer and an explicit maximum is not given, that maximum is 2**16-1. For parameters imported from [802.1Q-2005], [802.1D], or IS-IS [ISO10589] [RFC1195], see those standards for default and range if not given here.
TRILLによって追加されたパラメータには、デフォルト値と範囲が指定されています。パラメータが16ビットの符号なし整数として定義され、明示的な最大値が指定されていない場合、その最大値は2 ** 16-1です。 [802.1Q-2005]、[802.1D]、またはIS-IS [ISO10589] [RFC1195]からインポートされたパラメーターについては、ここに記載されていない場合は、デフォルトと範囲の標準を参照してください。
The following parameters occur per RBridge:
以下のパラメーターは、RBridgeごとに発生します。
o Number of nicknames, which defaults to 1 and may be configured in the range of 1 to 256.
o ニックネームの数。デフォルトは1で、1から256の範囲で構成できます。
o The desired number of distribution trees to be calculated by every RBridge in the campus and a desired number of distribution trees for the advertising RBridge to use, both of which are unsigned 16-bit integers that default to 1 (see Section 4.5).
o キャンパス内のすべてのRBridgeによって計算される必要な配布ツリーの数と、アドバタイジングRBridgeが使用する必要な配布ツリーの数。どちらもデフォルトで1になる符号なし16ビット整数です（セクション4.5を参照）。
o The maximum number of distribution trees the RBridge can compute. This is a 16-bit unsigned integer that is implementation and environment dependent and not subject to management configuration.
o RBridgeが計算できる分布ツリーの最大数。これは、実装と環境に依存する16ビットの符号なし整数であり、管理構成の対象ではありません。
o Two lists of nicknames, one designating the distribution trees to be computed and one designating distribution trees to be used as discussed in Section 4.5. By default, these lists are empty.
o ニックネームの2つのリスト。1つは計算する分布ツリーを指定し、もう1つはセクション4.5で説明するように使用する分布ツリーを指定します。デフォルトでは、これらのリストは空です。
o The parameters Ageing Timer and Forward Delay with the default and range specified in [802.1Q-2005].
o [802.1Q-2005]で指定されたデフォルトと範囲のパラメータエージングタイマーと転送遅延。
o Two unsigned octets that are, respectively, the confidence in { MAC, VLAN, local port } triples learned from locally received native frames and the confidence in { MAC, VLAN, remote RBridge } triples learned from decapsulating frames. These each default to 0x20 and may each be configured to values from 0x00 to 0xFE.
o ローカルで受信したネイティブフレームから学習した{MAC、VLAN、ローカルポート}トリプルの信頼度と、カプセル化解除フレームから学習した{MAC、VLAN、リモートRBridge}トリプルの信頼度である2つの符号なしオクテット。これらのデフォルトはそれぞれ0x20であり、それぞれ0x00から0xFEまでの値に設定できます。
o The desired minimum acceptable inter-RBridge link MTU for the campus, that is, originatingLSPBufferSize. This is a 16-bit unsigned integer number of octets that defaults to 1470 bytes, which is the minimum valid value. Any lower value being advertised by an RBridge is ignored.
o キャンパスの望ましい最小許容RBridgeリンクMTU、つまりoriginatingLSPBufferSize。これは、デフォルトのオクテットの16ビット符号なし整数で、有効な最小値である1470バイトにデフォルト設定されています。 RBridgeによってアドバタイズされるそれより小さい値は無視されます。
o The number of failed MTU-probes before the RBridge concludes that a particular MTU is not supported, which defaults to 3 and may be configured between 1 and 255.
o RBridgeが特定のMTUがサポートされていないと判断するまでの、失敗したMTUプローブの数。デフォルトは3で、1〜255の範囲で設定できます。
Static end-station address information and confidence in such end station information statically configured can also be configured with a default confidence of 0xFF and range of 0x00 to 0xFF. By default, there is no such static address information. The quantity of such information that can be configured is implementation dependent.
静的なエンドステーションアドレス情報と静的に構成されたこのようなエンドステーション情報の信頼性は、デフォルトの信頼性0xFFと0x00〜0xFFの範囲で構成することもできます。デフォルトでは、そのような静的アドレス情報はありません。構成できるそのような情報の量は実装に依存します。
The following is configuration information per nickname at each RBridge:
以下は、各RBridgeのニックネームごとの構成情報です。
o Priority to hold the nickname, which defaults to 0x40 if no specific value has been configured or 0xC0 if it is configured (see Section 3.7.3).
o ニックネームを保持する優先度。特定の値が構成されていない場合はデフォルトで0x40、構成されている場合は0xC0（セクション3.7.3を参照）。
o Nickname priority to be selected as a distribution tree root, a 16-bit unsigned integer that defaults to 0x8000.
o 配布ツリーのルートとして選択されるニックネームの優先順位。デフォルトは0x8000である16ビットの符号なし整数。
o Nickname value, an unsigned 16-bit quantity that defaults to the configured value if configured, else to the last value held if the RBridge coming up after a reboot and that value is remembered, else to a random value; however, in all cases the reserved values 0x0000 and 0xFFC0 through 0xFFFF are excluded (see Section 3.7.3).
o ニックネーム値。構成されている場合は構成された値にデフォルトで設定される符号なし16ビット数量。それ以外の場合は、再起動後にRBridgeが起動してその値が記憶される場合は最後に保持された値、それ以外の場合はランダムな値。ただし、すべての場合に予約済みの値0x0000および0xFFC0〜0xFFFFは除外されます（セクション3.7.3を参照）。
An RBridge has the following per-port configuration parameters:
RBridgeには、次のポートごとの構成パラメーターがあります。
o The same parameters as an [802.1Q-2005] port in terms of C-VLAN IDs. In addition, there is an Announcing VLANs set that defaults to the enabled VLANs on the port (see Section 4.4.3) and ranges from the null set to the set of all legal VLAN IDs.
o C-VLAN IDに関しては、[802.1Q-2005]ポートと同じパラメーター。さらに、デフォルトでポートで有効なVLANに設定されているアナウンスVLANセットがあり（セクション4.4.3を参照）、ヌルセットからすべての正当なVLAN IDのセットまでの範囲です。
o The same parameters as an [802.1Q-2005] port in terms of frame priority code point mapping (see [802.1Q-2005]).
o フレームプライオリティコードポイントマッピングの点で[802.1Q-2005]ポートと同じパラメーター（[802.1Q-2005]を参照）。
o The inhibition time for the port when it observed a change in the root bridge of an attached bridged LAN. This is in units of seconds, defaults to 30, and can be configured to any value from 0 to 30.
o 接続されたブリッジLANのルートブリッジの変化を観察したときのポートの抑制時間。これは秒単位であり、デフォルトは30で、0〜30の任意の値に設定できます。
o The Desired Designated VLAN that the RBridge will advertise in its TRILL Hellos if it is the DRB for the link via that port. This defaults to the lowest VLAN ID enabled on the port and may be configured to any valid VLAN ID that is enabled on the port (0x001 through 0xFFE).
o RBridgeがそのポートを介したリンクのDRBである場合に、RBridgeがTRILL Hellosで通知する必要のある指定VLAN。これは、デフォルトでポートで有効になっている最小のVLAN IDであり、ポートで有効になっている任意の有効なVLAN ID（0x001〜0xFFE）に構成できます。
o Four per-port configuration bits: disable port (default 0 == enabled), disable end-station service (trunk, default 0 == enabled), access port (default 0 == not restricted to being an access port), and use P2P Hellos (default 0 == use TRILL Hellos). (See Section 4.9.1.)
o ポートごとの4つの構成ビット：ポートの無効化（デフォルト0 ==有効）、エンドステーションサービスの無効化（トランク、デフォルト0 ==有効）、アクセスポート（デフォルト0 ==アクセスポートに限定されない）、および使用P2P Hellos（デフォルト0 == TRILL Hellosを使用）。 （4.9.1項を参照してください。）
o One bit per port such that, if the bit is set, it disables learning { MAC address, VLAN, port } triples from locally received native frames on the port. Default value is 0 == learning enabled.
o ポートごとに1ビット。ビットが設定されている場合、ポートでローカルに受信したネイティブフレームからの{MACアドレス、VLAN、ポート}トリプルの学習を無効にします。デフォルト値は0 ==学習可能です。
o The priority of the RBridge to be DRB and its Holding Time via that port with defaults and range as specified in IS-IS [ISO10589] [RFC1195].
o IS-IS [ISO10589] [RFC1195]で指定されているデフォルトと範囲を使用して、RBridgeの優先順位をDRBにし、そのポートを介してその保持時間を保持します。
o A bit that, when set, enables the receipt of TRILL-encapsulated frames from an Outer.MacSA with which the RBridges does not have an IS-IS adjacency. Default value is 0 == disabled.
o 設定すると、RBridgesにIS-IS隣接関係がない、Outer.MacSAからのTRILLカプセル化フレームの受信を可能にするビット。デフォルト値は0 ==無効です。
o Configuration for the optional send-BPDUs solution to the wiring closet topology problem as described in Appendix A.3.3. Default Bridge Address is the System ID of the RBridge with the lowest System ID. If RB1 and RB2 are part of a wiring closet topology, both need to be configured to know about this, and know the ID that should be used in the spanning tree protocol on the specified port.
o 付録A.3.3で説明されている、ワイヤリングクローゼットトポロジの問題に対するオプションのsend-BPDUソリューションの構成。デフォルトブリッジアドレスは、最小のシステムIDを持つRBridgeのシステムIDです。 RB1とRB2がワイヤリングクローゼットトポロジの一部である場合は、両方についてこれを認識し、指定されたポートのスパニングツリープロトコルで使用する必要があるIDを認識するように構成する必要があります。
An RBridge has the following per-VLAN configuration parameters:
RBridgeには、VLANごとの次の構成パラメーターがあります。
o Per-VLAN ESADI protocol participation flag, 7-bit priority, and Holding Time. Default participation flag is 0 == not participating. Default and range of priority and Holding Time as specified in IS-IS [ISO10589] [RFC1195].
o VLANごとのESADIプロトコル参加フラグ、7ビットの優先度、および保持時間。デフォルトの参加フラグは0 ==参加していません。 IS-IS [ISO10589] [RFC1195]で指定されている、優先度と保持時間のデフォルトと範囲。
o One bit per VLAN that, if set, disables learning { MAC address, VLAN, remote RBridge } triples from frames decapsulated in the VLAN. Defaults to 0 == learning enabled.
o VLANごとに1ビット。設定されている場合、VLANでカプセル化解除されたフレームからのトリプル{MACアドレス、VLAN、リモートRBridge}の学習を無効にします。デフォルトは0です==学習を有効にします。
Layer 2 bridging is not inherently secure. It is, for example, subject to spoofing of source addresses and bridging control messages. A goal for TRILL is that RBridges do not add new issues beyond those existing in current bridging technology.
レイヤ2ブリッジングは本質的に安全ではありません。たとえば、送信元アドレスのなりすましや制御メッセージのブリッジングの対象になります。 TRILLの目標は、RBridgesが現在のブリッジングテクノロジーに存在する問題以外に新しい問題を追加しないことです。
Countermeasures are available such as to configure the TRILL IS-IS and ESADI protocols to use IS-IS security [RFC5304] [RFC5310] and ignore unauthenticated TRILL control and ESADI frames received. RBridges using IS-IS security will need configuration.
IS-ISセキュリティ[RFC5304] [RFC5310]を使用するようにTRILL IS-ISおよびESADIプロトコルを構成し、受信した認証されていないTRILLコントロールとESADIフレームを無視するなどの対策が利用できます。 IS-ISセキュリティを使用するRBridgeには構成が必要です。
IEEE 802.1 port admission and link security mechanisms, such as [802.1X] and [802.1AE], can also be used. These are best thought of as being implemented below TRILL (see Section 4.9.2) and are outside the scope of TRILL (just as they are generally out of scope for bridging standards [802.1D] and 802.1Q); however, TRILL can make use of secure registration through the confidence level communicated in the optional TRILL ESADI protocol (see Section 4.8).
[802.1X]や[802.1AE]などのIEEE 802.1ポートアドミッションおよびリンクセキュリティメカニズムも使用できます。これらはTRILL（セクション4.9.2を参照）の下に実装されていると考えられ、TRILLの範囲外です（これらは一般にブリッジング標準[802.1D]と802.1Qの範囲外です）。ただし、TRILLは、オプションのTRILL ESADIプロトコル（セクション4.8を参照）で伝達される信頼レベルを介して安全な登録を利用できます。
TRILL encapsulates native frames inside the RBridge campus while they are in transit between ingress RBridge and egress RBridge(s) as described in Sections 2.3 and 4.1. Thus, TRILL ignorant devices with firewall features that cannot be detected by RBridges as end stations will generally not be able to inspect the content of such frames for security checking purposes. This may render them ineffective. Layer 3 routers and hosts appear to RBridges to be end stations, and native frames will be decapsulated before being sent to such devices. Thus, they will not see the TRILL Ethertype. Firewall devices that do not appear to an RBridge to be an end station, for example, bridges with co-located firewalls, should be modified to understand TRILL encapsulation.
セクション2.3と4.1で説明されているように、TRILLは、RBridgeキャンパス内のネイティブフレームを、それらが入口RBridgeと出口RBridgeの間で伝送されている間にカプセル化します。したがって、エンドステーションはセキュリティチェックの目的でそのようなフレームの内容を検査できないため、RBridgesで検出できないファイアウォール機能を備えたTRILL無知のデバイス。これはそれらを無効にするかもしれません。レイヤー3ルーターとホストはRBridgeからはエンドステーションのように見え、ネイティブフレームはそのようなデバイスに送信される前にカプセル化解除されます。したがって、彼らはTRILL Ethertypeを見ることはありません。 RBridgeからエンドステーションに見えないファイアウォールデバイス（たとえば、ファイアウォールが同じ場所にあるブリッジ）は、TRILLカプセル化を理解するように変更する必要があります。
RBridges do not prevent nodes from impersonating other nodes, for instance, by issuing bogus ARP/ND replies. However, RBridges do not interfere with any schemes that would secure neighbor discovery.
RBridgesは、偽のARP / ND応答を発行するなどして、ノードが他のノードになりすますことを防ぎません。ただし、RBridgeは、ネイバー探索を保護するスキームに干渉しません。
TRILL supports VLANs. These provide logical separation of traffic, but care should be taken in using VLANs for security purposes. To have reasonable assurance of such separation, all the RBridges and links (including bridged LANs) in a campus must be secured and configured so as to prohibit end stations from using dynamic VLAN registration frames or otherwise gaining access to any VLAN carrying traffic for which they are not authorized to read and/or inject.
TRILLはVLANをサポートしています。これらはトラフィックの論理的な分離を提供しますが、セキュリティの目的でVLANを使用する場合は注意が必要です。このような分離を合理的に保証するには、キャンパス内のすべてのRBridgeとリンク（ブリッジLANを含む）を保護し、エンドステーションが動的VLAN登録フレームを使用したり、トラフィックを運ぶVLANへのアクセスを取得したりできないように構成する必要があります。読み取りや注入は許可されていません。
Furthermore, if VLANs were used to keep some information off links where it might be observed in a bridged LAN, this will no longer work, in general, when bridges are replaced with RBridges; with encapsulation and a different outer VLAN tag, the data will travel the least cost transit path regardless of VLAN. Appropriate counter measures are to use end-to-end encryption or an appropriate TRILL security option should one be specified.
さらに、VLANを使用して、ブリッジされたLANで観測される可能性のあるリンクから情報を離しておくと、一般に、ブリッジがRBridgeに置き換えられたときに機能しなくなります。カプセル化と異なる外部VLANタグを使用すると、データはVLANに関係なく、最小コストのトランジットパスを移動します。適切な対策として、エンドツーエンドの暗号化を使用するか、適切なTRILLセキュリティオプションを指定する必要があります。
The TRILL protocol requires that an appointed forwarder at an RBridge port be temporarily inhibited if it sees a TRILL-Hello from another RBridge claiming to be the appointed forwarder for the same VLAN or sees a root bridge change out that port. Thus, it would seem that forged BPDUs showing repeated root bridge changes and forged TRILL-Hello frames with the Appointed Forwarder flag set could represent a significant denial-of-service attack. However, the situation is not as bad as it seems.
TRILLプロトコルでは、同じVLANの指定されたフォワーダーであると主張する別のRBridgeからのTRILL-Helloを確認した場合、またはルートブリッジがそのポートを変更した場合、RBridgeポートで指定されたフォワーダーを一時的に禁止する必要があります。したがって、ルートブリッジの変更が繰り返されたことを示す偽造BPDUと、Appointed Forwarderフラグが設定された偽造TRILL-Helloフレームは、重大なサービス拒否攻撃を表す可能性があります。しかし、状況は思ったほど悪くはありません。
The best defense against forged TRILL-Hello frames or other IS-IS messages is the use of IS-IS security [RFC5304] [RFC5310]. Rogue end stations would not normally have access to the required IS-IS keying material needed to forge authenticatible messages.
偽造されたTRILL-Helloフレームやその他のIS-ISメッセージに対する最善の防御策は、IS-ISセキュリティ[RFC5304] [RFC5310]を使用することです。不正なエンドステーションは、通常、認証可能なメッセージを偽造するために必要なIS-ISキー情報にアクセスできません。
Authentication similar to IS-IS security is usually unavailable for BPDUs. However, it is also the case that in typical modern wired LANs, all the links are point-to-point. If you have an all-RBridged point-to-point campus, then the worst that an end-station can do by forging BPDUs or TRILL-Hello frames is to deny itself service. This could be either through falsely inhibiting the forwarding of native frames by the RBridge to which it is connected or by falsely activating the optional decapsulation check (see Section 4.2.4.3).
IS-ISセキュリティと同様の認証は、通常、BPDUでは使用できません。ただし、一般的な最新の有線LANでは、すべてのリンクがポイントツーポイントである場合もあります。すべてRBridgedのポイントツーポイントキャンパスがある場合、エンドステーションがBPDUまたはTRILL-Helloフレームを偽造することによってできる最悪の事態は、サービス自体を拒否することです。これは、接続されているRBridgeによるネイティブフレームの転送を誤って禁止するか、オプションのカプセル開放チェックを誤ってアクティブにすることで発生する可能性があります（セクション4.2.4.3を参照）。
However, when an RBridge campus contains bridged LANs, those bridged LANs appear to any connected RBridges to be multi-access links. The forging of BPDUs by an end-station attached to such a bridged LAN could affect service to other end-stations attached to the same bridged LAN. Note that bridges never forward BPDUs but process them, although this processing may result in the issuance of further BPDUs. Thus, for an end-station to forge BPDUs to cause continuing changes in the root bridge as seen by an RBridge through intervening bridges would typically require it to cause root bridge thrashing throughout the bridged LAN that would be disruptive even in the absence of RBridges.
ただし、RBridgeキャンパスにブリッジLANが含まれている場合、それらのブリッジLANは、接続されているRBridgeからはマルチアクセスリンクのように見えます。このようなブリッジLANに接続されたエンドステーションによるBPDUの偽造は、同じブリッジLANに接続された他のエンドステーションへのサービスに影響を与える可能性があります。ブリッジがBPDUを転送することはなく、それらを処理することに注意してください。ただし、この処理により、さらにBPDUが発行される場合があります。したがって、エンドステーションがBPDUを偽造して、ルートブリッジに継続的な変更を引き起こし、介在するブリッジを介してRBridgeによって確認されると、通常は、ブリッジされたLAN全体でルートブリッジのスラッシングを引き起こし、RBridgeがない場合でも破壊的である必要があります。
Some bridges can be configured to not send BPDUs and/or to ignore BPDUs on particular ports, and RBridges can be configured not to inhibit appointed forwarding on a port due to root bridge changes; however, such configuration should be used with caution as it can be unsafe.
一部のブリッジは、BPDUを送信しないように、または特定のポートでBPDUを無視するように構成できます。また、RBridgeは、ルートブリッジの変更によりポートで指定された転送を禁止しないように構成できます。ただし、このような構成は安全ではない可能性があるため、注意して使用する必要があります。
This section discuses IANA and IEEE 802 assignment considerations. See [RFC5226].
このセクションでは、IANAおよびIEEE 802の割り当てに関する考慮事項を取り上げます。 [RFC5226]を参照してください。
A new IANA registry has been created for TRILL Parameters with two subregistries as below.
以下の2つのサブレジストリを持つTRILLパラメータ用の新しいIANAレジストリが作成されました。
The initial contents of the TRILL Nicknames subregistry are as follows:
TRILL Nicknamesサブレジストリの初期の内容は次のとおりです。
0x0000 Reserved to indicate no nickname specified 0x0001-0xFFBF Dynamically allocated by the RBridges within each RBridge campus 0xFFC0-0xFFFE Available for allocation by RFC Required (single value) or IETF Review (single or multiple values) 0xFFFF Permanently reserved
0x0000ニックネームが指定されていないことを示すために予約済み
The initial contents of the TRILL Multicast Address subregistry are as follows:
TRILL Multicast Addressサブレジストリの初期の内容は次のとおりです。
01-80-C2-00-00-40 Assigned as All-RBridges 01-80-C2-00-00-41 Assigned as All-IS-IS-RBridges 01-80-C2-00-00-42 Assigned as All-ESADI-RBridges 01-80-C2-00-00-43 to 01-80-C2-00-00-4F Available for allocation by IETF Review
01-80-C2-00-00-40 All-RBridgesとして割り当て01-80-C2-00-00-41 All-IS-IS-RBridgesとして割り当て01-80-C2-00-00-42 Allとして割り当て-ESADI-RBridges 01-80-C2-00-00-43〜01-80-C2-00-00-4F IETFレビューによる割り当てに使用可能
The Ethertype 0x22F3 is assigned by the IEEE Registration Authority to the TRILL Protocol.
Ethertype 0x22F3は、IEEE Registration AuthorityによってTRILLプロトコルに割り当てられています。
The Ethertype 0x22F4 is assigned by the IEEE Registration Authority for L2-IS-IS.
Ethertype 0x22F4は、IEEE Registration Authority for L2-IS-ISによって割り当てられます。
The block of 16 multicast MAC addresses from <01-80-C2-00-00-40> to <01-80-C2-00-00-4F> is assigned by the IEEE Registration Authority for IETF TRILL protocol use.
<01-80-C2-00-00-40>から<01-80-C2-00-00-4F>までの16個のマルチキャストMACアドレスのブロックは、IETF TRILLプロトコルで使用するためにIEEE登録局によって割り当てられます。
[802.1ak] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks / Multiple Registration Protocol", IEEE Standard 802.1ak-2007, 22 June 2007.
[802.1ak]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準/仮想ブリッジローカルエリアネットワーク/複数登録プロトコル」、IEEE標準802.1ak-2007、2007年6月22日。
[802.1D] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004.
[802.1D]「IEEE Standard for Local and Metropolitan Area Networks / Media Access Control（MAC）Bridges」、802.1D-2004、2004年6月9日。
[802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.1Q-2005]「IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks」、802.1Q-2005、2006年5月19日。
[802.3] "IEEE Standard for Information technology / Telecommunications and information exchange between systems / Local and metropolitan area networks / Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", 802.3-2008, 26 December 2008.
[802.3]「IEEE情報技術に関する標準/システム間のテレコミュニケーションおよび情報交換/ローカルおよびメトロポリタンエリアネットワーク/特定の要件パート3：衝突検知（CSMA / CD）アクセス方式を使用したキャリアセンスマルチアクセスと物理層の仕様」、802.3- 2008年12月26日。
[ISO10589] ISO/IEC, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002.
[ISO10589] ISO / IEC、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システムから中間システムへのルーティング情報交換プロトコル」、ISO / IEC 10589：2002。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[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月。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、Ed。、「Transport Mappings for the Simple Network Management Protocol（SNMP）」、STD 62、RFC 3417、2002年12月。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002.
[RFC3419] Daniele、M。およびJ. Schoenwaelder、「トランスポートアドレスのテキスト表記法」、RFC 3419、2002年12月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]ハーバーマンB.およびJ.マーティン、「マルチキャストルータディスカバリ」、RFC 4286、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 2008.
[RFC5303] Katz、D.、Saluja、R。、およびD. Eastlake 3番目、「IS-ISポイントツーポイント隣接のための3ウェイハンドシェイク」、RFC 5303、2008年10月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、2011年4月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326] Eastlake、D.、Banerjee、A.、Dutt、D.、Perlman、R。、およびA. Ghanwani、「リンクの透過的な相互接続（TRILL）IS-ISの使用」、RFC 6326、2011年7月。
[802.1AB] "IEEE Standard for Local and Metropolitan Networks / Station and Media Access Control Connectivity Discovery", 802.1AB-2009, 17 September 2009.
[802.1AB]「ローカルおよびメトロポリタンネットワークのIEEE標準/ステーションおよびメディアアクセスコントロールの接続性の発見」、802.1AB-2009、2009年9月17日。
[802.1ad] "IEEE Standard for and metropolitan area networks / Virtual Bridged Local Area Networks / Provider Bridges", 802.1ad-2005, 26 May 2005.
[802.1ad]「IEEE Standard for and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Provider Bridges」、802.1ad-2005、2005年5月26日。
[802.1ah] "IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Provider Backbone Bridges", 802.1ah-2008, 1 January 2008.
[802.1ah]「IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Provider Backbone Bridges」、802.1ah-2008、2008年1月1日。
[802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access Control (MAC) Relay, 802.1aj Draft 4.2, 24 September 2009.
[802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access Control（MAC）Relay、802.1aj Draft 4.2、24 September 2009。
[802.1AE] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Security", 802.1AE-2006, 18 August 2006.
[802.1AE]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準/メディアアクセスコントロール（MAC）セキュリティ」、802.1AE-2006、2006年8月18日。
[802.1AX] "IEEE Standard for Local and metropolitan area networks / Link Aggregation", 802.1AX-2008, 1 January 2008.
[802.1AX]「IEEE Standard for Local and Metropolitan Area Networks / Link Aggregation」、802.1AX-2008、2008年1月1日。
[802.1X] "IEEE Standard for Local and metropolitan area networks / Port Based Network Access Control", 802.1X-REV Draft 2.9, 3 September 2008.
[802.1X]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準/ポートベースのネットワークアクセスコントロール」、802.1X-REVドラフト2.9、2008年9月3日。
[RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, March 2004.
[RBridges] Perlman、R。、「RBridges：Transparent Routing」、Proc。 Infocom 2005、2004年3月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、Ed。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「An Architecture for Describing Simple Network Management Protocol（SNMP）Management Frameworks」、STD 62、RFC 3411、2002年12月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005。
[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月。
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006.
[RFC4789] Schoenwaelder、J。およびT. Jeffree、「Simple Network Management Protocol（SNMP）over IEEE 802 Networks」、RFC 4789、2006年11月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RFC5342] Eastlake 3rd, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008.
[RFC5342] Eastlake 3rd、D。、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルの使用」、BCP 141、RFC 5342、2008年9月。
[RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement", RFC 5556, May 2009.
[RFC5556]タッチ、J。およびR.パールマン、「多数のリンクの透過的な相互接続（TRILL）：問題と適用性に関する声明」、RFC 5556、2009年5月。
[RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols, 2nd Edition", Addison Wesley Longman, Chapter 3, 1999.
[RP1999] Perlman、R。、「相互接続：ブリッジ、ルーター、スイッチ、およびインターネットワーキングプロトコル、第2版」、Addison Wesley Longman、第3章、1999年。
[VLAN-MAPPING] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., and D. Eastlake 3rd, "RBridges: Campus VLAN and Priority Regions", Work in Progress, April 2011.
[VLANマッピング] Perlman、R.、Dutt、D.、Banerjee、A.、Rijhsinghani、A。、およびD. Eastlake 3rd、「RBridges：Campus VLAN and Priority Regions」、Work in Progress、2011年4月。
Some aspects of partial RBridge deployment are described below for link cost determination (Appendix A.1) and possible congestion due to appointed forwarder bottlenecks (Appendix A.2). A particular example of a problem related to the TRILL use of a single appointed forwarder per link per VLAN (the "wiring closet topology") is explored in detail in Appendix A.3.
リンクコストの決定（付録A.1）および指定されたフォワーダーのボトルネックによる可能性のある輻輳（付録A.2）について、部分的なRBridge展開のいくつかの側面を以下に説明します。 VLANごとのリンクごとに指定された単一のフォワーダーのTRILL使用に関連する問題の特定の例（「ワイヤリングクローゼットトポロジ」）については、付録A.3で詳しく説明しています。
With an RBridged campus having no bridges or repeaters on the links between RBridges, the RBridges can accurately determine the number of physical hops involved in a path and the line speed of each hop, assuming this is reported by their port logic. With intervening devices, this is no longer possible. For example, as shown in Figure 12, the two bridges B1 and B2 can completely hide a slow link so that both Rbridges RB1 and RB2 incorrectly believe the link is faster.
RBridge間のリンクにブリッジやリピーターがないRBridgedキャンパスでは、RBridgeは、パスに含まれる物理ホップの数と各ホップの回線速度を正確に決定できます。これは、ポートロジックによって報告されると想定しています。介在するデバイスでは、これは不可能です。たとえば、図12に示すように、2つのブリッジB1とB2は低速リンクを完全に隠すことができるため、Rbridge RB1とRB2の両方がリンクが高速であると誤って認識します。
+-----+ +----+ +----+ +-----+
| | Fast | | Slow | | Fast | |
| RB1 +--------+ B1 +--------+ B2 +--------+ RB2 |
| | Link | | Link | | Link | |
+-----+ +----+ +----+ +-----+
Figure 12: Link Cost of a Bridged Link
図12：ブリッジリンクのリンクコスト
Even in the case of a single intervening bridge, two RBridges may know they are connected but each sees the link as a different speed from how it is seen by the other.
1つの介在ブリッジの場合でも、2つのRBridgeはそれらが接続されていることを認識している可能性がありますが、それぞれがリンクを他のリンクとは異なる速度として認識しています。
However, this problem is not unique to RBridges. Bridges can encounter similar situations due to links hidden by repeaters, and routers can encounter similar situations due to links hidden by bridges, repeaters, or Rbridges.
ただし、この問題はRBridgesに固有のものではありません。ブリッジはリピーターによって隠されたリンクが原因で同様の状況に遭遇する可能性があり、ルーターはブリッジ、リピーター、またはRbridgeによって隠されたリンクが原因で同様の状況に遭遇する可能性があります。
With partial RBridge deployment, the RBridges may partition a bridged LAN into a relatively small number of relatively large remnant bridged LANs, or possibly not partition it at all so a single bridged LAN remains. Such configuration can result in the following problem:
RBridgeが部分的に配備されている場合、RBridgeは、ブリッジされたLANを比較的少数の比較的大きな残りのブリッジされたLANに分割するか、まったく分割しないため、単一のブリッジされたLANが残る可能性があります。このような構成では、次の問題が発生する可能性があります。
The requirement that native frames enter and leave a link via the link's appointed forwarder for the VLAN of the frame can cause congestion or suboptimal routing. (Similar problems can occur within a bridged LAN due to the spanning tree algorithm.) The extent to which such a problem will occur is highly dependent on the network topology. For example, if a bridged LAN had a star-like structure with core bridges that connected only to other bridges and peripheral bridges that connected to end stations and are connected to core bridges, the replacement of all of the core bridges by RBridges without replacing the peripheral bridges would generally improve performance without inducing appointed forwarder congestion.
ネイティブフレームがリンクに指定されたフレームのVLANのフォワーダーを介してリンクに出入りするという要件は、輻輳または準最適ルーティングを引き起こす可能性があります。 （スパニングツリーアルゴリズムにより、同様の問題がブリッジLAN内で発生する可能性があります。）このような問題が発生する程度は、ネットワークトポロジに大きく依存します。たとえば、ブリッジングされたLANが、他のブリッジにのみ接続されたコアブリッジと、エンドステーションに接続されてコアブリッジに接続されたペリフェラルブリッジを備えた星のような構造であった場合、すべてのコアブリッジをRBridgeで置き換え、周辺ブリッジは通常、指定されたフォワーダーの輻輳を引き起こすことなく、パフォーマンスを向上させます。
Solutions to this problem are discussed below and a particular example explored in Appendix A.3.
この問題の解決策については以下で説明し、特定の例については付録A.3で説明します。
Inserting RBridges so that all the bridged portions of the LAN stay connected to each other and have multiple RBridge connections is generally the least efficient arrangement.
LANのすべてのブリッジ部分が互いに接続されたままになるようにRBridgeを挿入し、複数のRBridge接続を持つことは、一般的に最も効率の悪い配置です。
There are four techniques that may help if the problem above occurs and that can, to some extent, be used in combination:
上記の問題が発生した場合に役立ち、ある程度組み合わせて使用できる4つの手法があります。
1. Replace more IEEE 802.1 customer bridges with RBridges so as to minimize the size of the remnant bridged LANs between RBridges. This requires no configuration of the RBridges unless the bridges they replace required configuration.
1. RBridge間の残りのブリッジLANのサイズを最小限に抑えるために、IEEE 802.1カスタマーブリッジをRBridgeに置き換えます。これは、必要な構成を置き換えるブリッジを除いて、RBridgeの構成を必要としません。
2. Re-arrange network topology to minimize the problem. If the bridges and RBridges involved are configured, this may require changes in their configuration.
2. 問題を最小限に抑えるために、ネットワークトポロジを再配置します。関連するブリッジとRBridgeが構成されている場合は、構成の変更が必要になる場合があります。
3. Configure the RBridges and bridges so that end stations on a remnant bridged LAN are separated into different VLANs that have different appointed forwarders. If the end stations were already assigned to different VLANs, this is straightforward (see Section 4.2.4.2). If the end stations were on the same VLAN and have to be split into different VLANs, this technique may lead to connectivity problems between end stations.
3. RBridgeとブリッジを構成して、残りのブリッジLAN上のエンドステーションが、異なるフォワーダーが指定された異なるVLANに分離されるようにします。端末がすでに異なるVLANに割り当てられている場合、これは簡単です（セクション4.2.4.2を参照）。エンドステーションが同じVLAN上にあり、異なるVLANに分割する必要がある場合、この手法はエンドステーション間の接続の問題を引き起こす可能性があります。
4. Configure the RBridges such that their ports that are connected to the bridged LAN send spanning tree configuration BPDUs (see Section A.3.3) in such a way as to force the partition of the bridged LAN. (Note: A spanning tree is never formed through an RBridge but always terminates at RBridge ports.) To use this technique, the RBridges must support this optional feature, and would need to be configured to use it, but the bridges involved would rarely have to be configured. This technique makes the bridged LAN unavailable for TRILL through traffic because the bridged LAN partitions.
4. ブリッジングされたLANに接続されているポートがスパニングツリー構成BPDU（セクションA.3.3を参照）を送信して、ブリッジングされたLANのパーティションを強制するように、RBridgeを構成します。 （注：スパニングツリーはRBridgeを介して形成されることはありませんが、常にRBridgeポートで終了します。）この手法を使用するには、RBridgeがこのオプション機能をサポートしている必要があり、それを使用するように構成する必要がありますが、関係するブリッジにはほとんどありません。構成されます。この手法では、ブリッジされたLANが分割されるため、トラフィックを介したTRILLでブリッジされたLANを使用できなくなります。
Conversely to item 3 above, there may be bridged LANs that use VLANs, or use more VLANs than would otherwise be necessary, to support the Multiple Spanning Tree Protocol or otherwise reduce the congestion that can be caused by a single spanning tree. Replacing the IEEE 802.1 bridges in such LANs with RBridges may enable a reduction in or elimination of VLANs and configuration complexity.
上記の項目3とは逆に、VLANを使用するブリッジLAN、またはマルチプルスパニングツリープロトコルをサポートするため、または単一のスパニングツリーによって引き起こされる可能性のある輻輳を軽減するために、必要以上に多くのVLANを使用するLANがある場合があります。そのようなLANのIEEE 802.1ブリッジをRBridgeに置き換えると、VLANと構成の複雑さを軽減または排除できる場合があります。
If 802.1 bridges are present and RBridges are not properly configured, the bridge spanning tree or the DRB may make inappropriate decisions. Below is a specific example of the more general problem that can occur when a bridged LAN is connected to multiple RBridges.
802.1ブリッジが存在し、RBridgeが適切に構成されていない場合、ブリッジスパニングツリーまたはDRBが不適切な決定を行う可能性があります。以下は、ブリッジLANが複数のRBridgeに接続されている場合に発生する可能性のある、より一般的な問題の具体例です。
In cases where there are two (or more) groups of end nodes, each attached to a bridge (say, B1 and B2), and each bridge is attached to an RBridge (say, RB1 and RB2, respectively), with an additional link connecting B1 and B2 (see Figure 13), it may be desirable to have the B1-B2 link only as a backup in case one of RB1 or RB2 or one of the links B1-RB1 or B2-RB2 fails.
エンドノードのグループが2つ（またはそれ以上）あり、それぞれがブリッジ（たとえば、B1およびB2）に接続されており、各ブリッジが追加のリンクを使用してRBridge（たとえば、それぞれRB1およびRB2）に接続されている場合B1とB2を接続する場合（図13を参照）、RB1またはRB2のいずれか、またはリンクB1-RB1またはB2-RB2の1つに障害が発生した場合のバックアップとしてのみ、B1-B2リンクを使用することが望ましい場合があります。
+-------------------------------+
| | | |
| Data +-----+ +-----+ |
| Center -| RB1 |----| RB2 |- |
| +-----+ +-----+ |
| | | |
+-------------------------------+
| |
| |
+-------------------------------+
| | | |
| +----+ +----+ |
| Wiring | B1 |-----| B2 | |
| Closet +----+ +----+ |
| Bridged |
| LAN |
+-------------------------------+
Figure 13: Wiring Closet Topology
図13：配線クローゼットトポロジ
For example, B1 and B2 may be in a wiring closet and it may be easy to provide a short, high-bandwidth, low-cost link between them while RB1 and RB2 are at a distant data center such that the RB1-B1 and RB2-B2 links are slower and more expensive.
たとえば、B1とB2はワイヤリングクローゼット内にあり、RB1とRB2がRB1-B1とRB2のように離れたデータセンターにあるときに、それらの間に短い高帯域幅で低コストのリンクを提供するのは簡単です。 -B2リンクは低速で、より高価です。
Default behavior might be that one of RB1 or RB2 (say, RB1) would become DRB for the bridged LAN including B1 and B2 and appoint itself forwarder for the VLANs on that bridged LAN. As a result, RB1 would forward all traffic to/from the link, so end nodes attached to B2 would be connected to the campus via the path B2-B1-RB1, rather than the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and cuts available bandwidth between the end stations and the data center in half. The desired behavior would be to make use of both the RB1-B1 and RB2-B2 links.
デフォルトの動作では、RB1またはRB2（たとえば、RB1）のいずれかが、B1とB2を含むブリッジLANのDRBになり、そのブリッジLAN上のVLANにフォワーダーを指定する場合があります。その結果、RB1はリンクとの間のすべてのトラフィックを転送するため、B2に接続されたエンドノードは、目的のB2-RB2ではなく、パスB2-B1-RB1を介してキャンパスに接続されます。これにより、B2-RB2パスの帯域幅が浪費され、エンドステーションとデータセンター間の使用可能な帯域幅が半分になります。望ましい動作は、RB1-B1リンクとRB2-B2リンクの両方を使用することです。
Three solutions to this problem are described below.
この問題の3つの解決策を以下に説明します。
Of course, if B1 and B2 are replaced with RBridges, the right thing will happen without configuration (other than VLAN support), but this may not be immediately practical if bridges are being incrementally replaced by RBridges.
もちろん、B1とB2がRBridgeに置き換えられた場合、（VLANサポート以外の）構成なしで正しいことが起こりますが、ブリッジがRBridgeに徐々に置き換えられている場合、これはすぐに実用的ではない可能性があります。
If the end stations attached to B1 and B2 are already divided among a number of VLANs, RB1 and RB2 could be configured so that whichever becomes DRB for this link will appoint itself forwarder for some of these VLANs and appoint the other RBridge for the remaining VLANs. Should either of the RBridges fail or become disconnected, the other will have only itself to appoint as forwarder for all the VLANs.
B1とB2に接続されたエンドステーションがすでにいくつかのVLANに分割されている場合、RB1とRB2は、このリンクのDRBになる方が、これらのVLANのいくつかにフォワーダーを指定し、残りのVLANに他のRBridgeを指定するように構成できます。 。いずれかのRBridgeで障害が発生したり、切断されたりした場合、もう一方のRBridgeは、すべてのVLANのフォワーダーとして指定する必要があります。
If the end stations are all on a single VLAN, then it would be necessary to assign them between at least two VLANs to use this solution. This may lead to connectivity problems that might require further measures to rectify.
エンドステーションがすべて単一のVLAN上にある場合、このソリューションを使用するには、少なくとも2つのVLAN間でエンドステーションを割り当てる必要があります。これにより、接続の問題が発生する可能性があり、修正するにはさらに対策が必要になる場合があります。
Another solution is to configure the relevant ports on RB1 and RB2 to be part of a "wiring closet group", with a configured per-RBridge port "Bridge Address" Bx (which may be RB1 or RB2's System ID). Both RB1 and RB2 emit spanning tree BPDUs on their configured ports as highest priority root Bx. This causes the spanning tree to logically partition the bridged LAN as desired by blocking the B1-B2 link at one end or the other (unless one of the bridges is configured to also have highest priority and has a lower ID, which we consider to be a misconfiguration). With the B1-B2 link blocked, RB1 and RB2 cannot see each other's TRILL-Hellos via that link and each acts as Designated RBridge and appointed forwarder for its respective partition. Of course, with this partition, no TRILL through traffic can flow through the RB1-B1-B2-RB2 path.
別の解決策は、RB1とRB2の関連するポートを「ワイヤリングクローゼットグループ」の一部として構成し、RBridgeごとに構成された「ブリッジアドレス」Bx（RB1またはRB2のシステムIDである場合があります）を構成することです。 RB1とRB2はどちらも、設定されたポートで最優先のルートBxとしてスパニングツリーBPDUを送信します。これにより、B1-B2リンクを一方または他方でブロックすることにより、スパニングツリーが必要に応じてブリッジングされたLANを論理的に分割します（ブリッジの1つが最も優先度が高く、IDが低く設定されている場合を除き、設定ミス）。 B1-B2リンクがブロックされていると、RB1とRB2はそのリンク経由で互いのTRILL-Helloを認識できず、それぞれが指定されたRBridgeとして機能し、それぞれのパーティションの指定されたフォワーダーになります。もちろん、このパーティションでは、トラフィックを通過するTRILLはRB1-B1-B2-RB2パスを通過できません。
In the spanning tree configuration BPDU, the Root is "Bx" with highest priority, cost to Root is 0, Designated Bridge ID is "RB1" when RB1 transmits and "RB2" when RB2 transmits, and port ID is a value chosen independently by each of RB1 and RB2 to distinguish each of its own ports. The topology change flag is zero, and the topology change acknowledgement flag is set if and only if a topology change BPDU has been received on the port since the last configuration BPDU was transmitted on the port. (If RB1 and RB2 were actually bridges on the same shared medium with no bridges between them, the result would be that the one with the larger ID sees "better" BPDUs (because of the tiebreaker on the third field: the ID of the transmitting bridge), and would turn off its port.)
スパニングツリー構成のBPDUでは、ルートは最優先の「Bx」、ルートへのコストは0、指定ブリッジIDはRB1が送信する場合は「RB1」、RB2が送信する場合は「RB2」、ポートIDはRB1とRB2のそれぞれで、それぞれのポートを区別します。トポロジー変更フラグはゼロであり、最後の構成BPDUがポートで送信されてからポートでトポロジー変更BPDUが受信された場合にのみ、トポロジー変更確認フラグが設定されます。 （RB1とRB2が実際に同じ共有メディア上のブリッジであり、それらの間にブリッジがない場合、結果は、より大きなIDを持つ方が「より良い」BPDUを参照することになります（3番目のフィールドのタイブレーカーのため：送信のIDブリッジ）、およびそのポートをオフにします。）
Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail, the spanning tree algorithm will stop seeing one of the RBx roots and will unblock the B1-B2 link maintaining connectivity of all the end stations with the data center.
RB1またはRB1-B1リンクまたはRB2またはRB2-B2リンクのいずれかに障害が発生した場合、スパニングツリーアルゴリズムはRBxルートの1つを検出しなくなり、B1-B2リンクのブロックを解除して、すべてのエンドステーションとデータセンターの接続を維持します。 。
If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and RB1 have been configured to believe they are part of a wiring closet group, the campus becomes partitioned as the link is blocked.
リンクRB1-B1-B2-RB2がキャンパスのカットセット上にあり、RB2とRB1がワイヤリングクローゼットグループの一部であると信じるように設定されている場合、リンクがブロックされるため、キャンパスはパーティション化されます。
Replacing all 802.1 customer bridges with RBridges is usually the best solution with the least amount of configuration required, possibly none.
すべての802.1カスタマーブリッジをRBridgesで置き換えることは、通常、必要な構成が最小限、おそらくない構成で、最良のソリューションです。
The VLAN solution works well with a relatively small amount of configuration if the end stations are already divided among a number of VLANs. If they are not, it becomes more complex and problematic.
エンドステーションがすでにいくつかのVLANに分割されている場合、VLANソリューションは比較的少量の構成で適切に機能します。そうでない場合、それはより複雑で問題になります。
The spanning tree solution does quite well in this particular case. But it depends on both RB1 and RB2 having implemented the optional feature of being able to configure a port to emit spanning tree BPDUs as described in Appendix A.3.3 above. It also makes the bridged LAN whose partition is being forced unavailable for through traffic. Finally, while in this specific example it neatly breaks the link between the two bridges B1 and B2, if there were a more complex bridged LAN, instead of exactly two bridges, there is no guarantee that it would partition into roughly equal pieces. In such a case, you might end up with a highly unbalanced load on the RB1-B1 link and the RB2-B2 link although this is still better than using only one of these links exclusively.
この特定のケースでは、スパニングツリーソリューションが非常に有効です。ただし、上記の付録A.3.3で説明されているように、スパニングツリーBPDUを送信するようにポートを構成できるオプション機能を実装しているRB1とRB2の両方に依存します。また、トラフィックが通過できないパーティションが強制的に使用されているブリッジLANも作成します。最後に、この特定の例では、2つのブリッジB1とB2間のリンクを適切に切断しますが、厳密に2つのブリッジではなく、より複雑なブリッジLANが存在する場合、ほぼ等しい部分に分割される保証はありません。このような場合、RB1-B1リンクとRB2-B2リンクに非常に不均衡な負荷がかかる可能性がありますが、これらのリンクの1つだけを排他的に使用するよりはなお良いです。
Many modern bridged LANs are organized into a core and access model, The core bridges have only point-to-point links to other bridges while the access bridges connect to end stations, core bridges, and possibly other access bridges. It seems likely that some RBridge campuses will be organized in a similar fashion.
現代の多くのブリッジLANはコアとアクセスモデルに編成されています。コアブリッジは他のブリッジへのポイントツーポイントリンクしかありませんが、アクセスブリッジはエンドステーション、コアブリッジ、および場合によっては他のアクセスブリッジに接続します。一部のRBridgeキャンパスも同様の方法で編成されるようです。
An RBridge port can be configured as a trunk port, that is, a link to another RBridge or RBridges, by configuring it to disable end-station support. There is no reason for such a port to have more than one VLAN enabled and in its Announcing Set on the port. Of course, the RBridge (or RBridges) to which it is connected must have the same VLAN enabled. There is no reason for this VLAN to be other than the default VLAN 1 unless the link is actually over carrier Ethernet or other facilities that only provide some other specific VLAN or the like. Such configuration minimizes wasted TRILL-Hellos and eliminates useless decapsulation and transmission of multi-destination traffic in native form onto the link (see Sections 4.2.4 and 4.9.1).
RBridgeポートは、エンドステーションのサポートを無効にするように構成することにより、トランクポート、つまり別のRBridgeへのリンクとして構成できます。このようなポートで複数のVLANが有効になっていて、そのポートのアナウンスセットに含まれている必要はありません。もちろん、接続先のRBridge（1つまたは複数）では、同じVLANを有効にする必要があります。リンクが実際にはキャリアイーサネットまたはその他の特定のVLANのみを提供するその他のファシリティを介していない場合を除き、このVLANがデフォルトのVLAN 1以外である理由はありません。このような構成により、無駄なTRILL-Helloが最小限に抑えられ、リンクへのネイティブ形式のマルチ宛先トラフィックの無駄なカプセル化と送信が排除されます（セクション4.2.4および4.9.1を参照）。
An RBridge access port would be expected to lead to a link with end stations and possibly one or more bridges. Such a link might also have more than one RBridge connected to it to provide more reliable service to the end stations. It would be a goal to minimize or eliminate transit traffic on such a link as it is intended for end-station native traffic. This can be accomplished by turning on the access port configuration bit for the RBridge port or ports connected to the link as further detailed in Section 4.9.1.
RBridgeアクセスポートは、エンドステーションおよびおそらく1つ以上のブリッジとのリンクにつながると予想されます。このようなリンクには、エンドステーションにより信頼性の高いサービスを提供するために、複数のRBridgeが接続されている場合もあります。端末リンクのネイティブトラフィックを対象としているため、このようなリンクのトランジットトラフィックを最小限に抑えるか、排除することが目標です。これは、4.9.1で詳しく説明されているように、リンクに接続されているRBridgeポートのアクセスポート構成ビットをオンにすることで実現できます。
When designing RBridge configuration user interfaces, consideration should be given to making it convenient to configure ports as trunk and access ports.
RBridge構成ユーザーインターフェイスを設計するときは、ポートをトランクポートおよびアクセスポートとして構成するのが便利になるように考慮する必要があります。
Rbridges support multipathing of both known unicast and multi-destination traffic. Implementation of multipathing is optional.
Rbridgeは、既知のユニキャストトラフィックと複数の宛先トラフィックの両方のマルチパスをサポートしています。マルチパスの実装はオプションです。
Multi-destination traffic can be multipathed by using different distribution tree roots for different frames. For example, assume that in Figure 14 end stations attached to RBy are the source of various multicast streams each of which has multiple listeners attached to various of RB1 through RB9. Assuming equal bandwidth links, a distribution tree rooted at RBy will predominantly use the vertical links among RB1 through RB9 while one rooted at RBz will predominantly use the horizontal. If RBy chooses its nickname as the distribution tree root for half of this traffic and an RBz nickname as the root for the other half, it may be able to substantially increase the aggregate bandwidth by making use of both the vertical and horizontal links among RB1 through RB9.
複数の宛先トラフィックは、異なるフレームに異なる配布ツリールートを使用することでマルチパス化できます。たとえば、図14で、RByに接続されたエンドステーションがさまざまなマルチキャストストリームのソースであり、それぞれがさまざまなRB1からRB9に接続された複数のリスナーを持つとします。等しい帯域幅のリンクを想定すると、RByをルートとする配信ツリーは主にRB1からRB9の間の垂直リンクを使用し、RBzをルートとする配信ツリーは主に水平を使用します。 RByがこのトラフィックの半分の配布ツリールートとしてニックネームを選択し、残りの半分のルートとしてRBzニックネームを選択した場合、RB1からRB1までの垂直リンクと水平リンクの両方を使用することにより、総帯域幅を大幅に増やすことができる場合があります。 RB9。
Since the distribution trees an RBridge must calculate are the same for all RBridges and transit RBridges MUST respect the tree root specified by the ingress RBridge, a campus will operate correctly with a mix of RBridges some of which use different roots for different multi-destination frames they ingress and some of which use a single root for all such frames.
RBridgeが計算する必要のある分散ツリーはすべてのRBridgeで同じであり、通過RBridgeは入力RBridgeによって指定されたツリールートを尊重する必要があるため、キャンパスはRBridgeの混合で正しく動作し、そのいくつかは異なる複数の宛先フレームに異なるルートを使用しますそれらは侵入し、そのいくつかはそのようなすべてのフレームに単一のルートを使用します。
+---+
|RBy|---------------+
+---+ |
/ | \ |
/ | \ |
/ | \ |
+---+ +---+ +---+ |
|RB1|---|RB2|---|RB3| |
+---+ +---+ +---+\ |
| | | \ |
+---+ +---+ +---+ \+---+
|RB4|---|RB5|---|RB6|-----|RBz|
+---+ +---+ +---+ /+---+
| | | /
+---+ +---+ +---+/
|RB7|---|RB8|---|RB9|
+---+ +---+ +---+
Figure 14: Multi-Destination Multipath
図14：複数の宛先のマルチパス
Known unicast Equal Cost Multipathing (ECMP) can occur at an RBridge if, instead of using a tiebreaker criterion when building SPF paths, information is retained about ports through which equal cost paths are available. Different unicast frames can then be sent through those different ports and will be forwarded by equal cost paths. For example, in Figure 15, which shows only RBridges and omits any bridges present, there are three equal cost paths between RB1 and RB2 and two equal cost paths between RB2 and RB5. Thus, for traffic transiting this part of the campus from left to right, RB1 may be able to perform three way ECMP and RB2 may be able to perform two-way ECMP.
既知のユニキャストEqual Cost Multipathing（ECMP）は、SPFパスを構築するときにタイブレーカー基準を使用する代わりに、等コストパスが利用できるポートに関する情報が保持されている場合、RBridgeで発生する可能性があります。次に、異なるユニキャストフレームをそれらの異なるポート経由で送信し、等コストパスで転送します。たとえば、図15では、RBridgeのみを示し、存在するすべてのブリッジを省略しています。RB1とRB2の間には3つの等コストパスがあり、RB2とRB5の間には2つの等コストパスがあります。したがって、キャンパスのこの部分を左から右に通過するトラフィックの場合、RB1は3方向のECMPを実行でき、RB2は2方向のECMPを実行できます。
A transit RBridge receiving a known unicast frame forwards it towards the egress RBridge and is not concerned with whether it believes itself to be on any particular path from the ingress RBridge or a previous transit RBridge. Thus, a campus will operate correctly with a mix of RBridges some of which implement ECMP and some of which do not.
既知のユニキャストフレームを受信する中継RBridgeは、それを出力RBridgeに転送し、それ自体が入力RBridgeからの特定のパス上にあると信じるかどうか、または以前の中継RBridgeにあるかどうかには関係ありません。したがって、キャンパスは、一部がECMPを実装し、一部が実装しないRBridgeを組み合わせて正しく動作します。
There are actually three possibilities for the parallel paths between RB1 and RB2 as follows:
RB1とRB2の間の並列パスには、次の3つの可能性があります。
1. If two or three of these paths have pseudonodes, then all three will be distinctly visible in the campus-wide link state and ECMP as described above is applicable.
1. これらのパスの2つまたは3つに疑似ノードがある場合、3つすべてがキャンパス全体のリンク状態で明確に表示され、前述のECMPが適用されます。
2. If the paths use P2P Hellos or otherwise do not have pseudonodes, these three paths would appear as a single adjacency in the link state. In this case, multipathing across them would be an entirely local matter for RB1 and RB2. It can be freely done for known unicast frames but not for multi-destination frames as described in Section 4.5.2.
2. パスがP2P Helloを使用している場合、または疑似ノードがない場合、これらの3つのパスはリンク状態で単一の隣接として表示されます。この場合、それらの間のマルチパスは、RB1とRB2にとって完全にローカルな問題になります。これは、既知のユニキャストフレームに対しては自由に実行できますが、セクション4.5.2で説明されているマルチ宛先フレームに対しては実行できません。
3. If and only if the three paths between RB1 and RB2 are single hop equal bandwidth links with no intervening bridges, then it would be permissible to combine them into one logical link through the [802.1AX] "link aggregation" feature. Rbridges MAY implement link aggregation since that feature operates below TRILL (see Section 4.9.2).
3. RB1とRB2の間の3つのパスが介在するブリッジのないシングルホップの等帯域幅リンクである場合に限り、[802.1AX]の「リンク集約」機能を介してそれらを1つの論理リンクに結合することが許容されます。 Rbridgeはリンク集約を実装してもよい（MAY）。その機能はTRILLの下で動作するためです（セクション4.9.2を参照）。
+---+ double line = 10 Gbps
----- ===|RB3|--- single line = 1 Gbps
/ \ // +---+ \
+---+ +---+ +---+
===|RB1|-----|RB2| |RB5|===
+---+ +---+ +---+
\ / \ +---+ //
----- ----|RB4|===
+---+
Figure 15: Known Unicast Multipath
図15：既知のユニキャストマルチパス
When multipathing is used, frames that follow different paths will be subject to different delays and may be re-ordered. While some traffic may be order/delay insensitive, typically most traffic consists of flows of frames where re-ordering within a flow is damaging. How to determine flows or what granularity flows should have is beyond the scope of this document. (This issue is discussed in [802.1AX].)
マルチパスを使用する場合、異なるパスをたどるフレームは異なる遅延の影響を受け、並べ替えられる場合があります。一部のトラフィックは順序/遅延の影響を受けない場合がありますが、通常、ほとんどのトラフィックはフレームのフローで構成されており、フロー内での並べ替えが悪影響を及ぼします。フローを決定する方法またはフローに必要な粒度は、このドキュメントの範囲を超えています。 （この問題は[802.1AX]で説明されています。）
A high-level, informative summary of how VLAN ID and priority are determined for incoming native frames, omitting some details, is given in the bulleted items below. For more detailed information, see [802.1Q-2005].
いくつかの詳細を省略して、着信ネイティブフレームのVLAN IDと優先順位がどのように決定されるかについての高レベルで有益な要約を、以下の箇条書き項目に示します。詳細については、[802.1Q-2005]を参照してください。
o When an untagged native frame arrives, an unconfigured RBridge associates the default priority zero and the VLAN ID 1 with it. It actually sets the VLAN for the untagged frame to be the "port VLAN ID" associated with that port. The port VLAN ID defaults to VLAN ID 1 but may be configured to be any other VLAN ID. An Rbridge may also be configured on a per-port basis to discard such frames or to associate a different priority code point with them. Determination of the VLAN ID associated with an incoming untagged non-control frame may also be made dependent on the Ethertype or NSAP (referred to in 802.1 as the Protocol) of the arriving frame, the source MAC address, or other local rules.
o タグなしのネイティブフレームが到着すると、未構成のRBridgeがデフォルトの優先度0とVLAN ID 1を関連付けます。タグなしフレームのVLANを、そのポートに関連付けられた「ポートVLAN ID」に設定します。ポートのVLAN IDのデフォルトはVLAN ID 1ですが、他のVLAN IDとして構成することもできます。 Rbridgeは、ポートごとに構成して、そのようなフレームを破棄するか、異なる優先度コードポイントをフレームに関連付けることもできます。着信タグなし非制御フレームに関連付けられたVLAN IDの決定は、到着フレームのEthertypeまたはNSAP（802.1ではプロトコルと呼ばれます）、送信元MACアドレス、またはその他のローカルルールにも依存します。
o When a priority tagged native frame arrives, an unconfigured RBridge associates with it both the port VLAN ID, which defaults to 1, and the priority code point provided in the priority tag in the frame. An Rbridge may be configured on a per-port basis to discard such frames or to associate them with a different VLAN ID as described in the point immediately above. It may also be configured to map the priority code point provided in the frame by specifying, for each of the eight possible values that might be in the frame, what actual priority code point will be associated with the frame by the RBridge.
o 優先度のタグが付けられたネイティブフレームが到着すると、未構成のRBridgeは、デフォルトの1であるポートVLAN IDと、フレームの優先度タグで提供される優先度コードポイントの両方に関連付けられます。上記のポイントで説明したように、ポートごとにRbridgeを構成して、そのようなフレームを破棄するか、フレームを別のVLAN IDに関連付けることができます。また、フレーム内に存在する可能性のある8つの可能な値のそれぞれについて、RBridgeによってフレームに関連付けられる実際の優先コードポイントを指定することにより、フレームで提供される優先コードポイントをマップするように構成することもできます。
o When a C-tagged (formerly called Q-tagged) native frame arrives, an unconfigured RBridge associates with it the VLAN ID and priority in the C-tag. An RBridge may be configured on a per-port per-VLAN basis to discard such frames. It may also be configured on a per-port basis to map the priority value as specified above for priority tagged frames.
o Cタグ付き（以前はQタグ付きと呼ばれていました）ネイティブフレームが到着すると、未構成のRBridgeがCタグ内のVLAN IDと優先度をそれに関連付けます。 RBridgeは、そのようなフレームを廃棄するために、ポートごと、VLANごとに構成できます。また、ポートごとに構成して、優先度タグ付きフレームに対して上記で指定した優先度値をマップすることもできます。
In 802.1, the process of associating a priority code point with a frame, including mapping a priority provided in the frame to another priority, is referred to as priority "regeneration".
802.1では、フレームに提供された優先度を別の優先度にマッピングすることを含む、優先度コードポイントをフレームに関連付けるプロセスは、優先度「再生成」と呼ばれます。
This informational appendix briefly comments on RBridge support for completed and in-process amendments to IEEE [802.1Q-2005]. There is no assurance that existing RBridge protocol specifications or existing bridges will support not yet specified future [802.1Q-2005] amendments just as there is no assurance that existing bridge protocol specifications or existing RBridges will support not yet specified future TRILL amendments.
この情報付録では、IEEE [802.1Q-2005]に対する完了済みおよび処理中の修正に対するRBridgeサポートについて簡単にコメントしています。既存のRBridgeプロトコル仕様または既存のブリッジがまだ指定されていない将来の[802.1Q-2005]修正をサポートするという保証はありません。これは、既存のブリッジプロトコル仕様または既存のRBridgeがまだ指定されていない将来のTRILL修正をサポートするという保証がないためです。
The information below is frozen as of 25 October 2009. For the latest status, see the IEEE 802.1 working group (http://grouper.ieee.org/groups/802/1/).
以下の情報は2009年10月25日の時点で凍結されています。最新のステータスについては、IEEE 802.1ワーキンググループ（http://grouper.ieee.org/groups/802/1/）を参照してください。
802.1ad-2005 Provider Bridges - Sometimes called "Q-in-Q", because VLAN tags used to be called "Q-tags", 802.1ad specifies Provider Bridges that tunnel customer bridge traffic within service VLAN tags (S-tags). If the customer LAN is an RBridge campus, that traffic will be bridged by Provider Bridges. Customer bridge features involving Provider Bridge awareness, such as the ability to configure a customer bridge port to add an S-tag to a frame before sending it to a Provider Bridge, are below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1ad-2005プロバイダーブリッジ-「Q-in-Q」と呼ばれることもあります。VLANタグは「Qタグ」と呼ばれていたため、802.1adは、サービスブリッジタグ（Sタグ）内でカスタマーブリッジトラフィックをトンネリングするプロバイダーブリッジを指定します。カスタマーLANがRBridgeキャンパスの場合、そのトラフィックはプロバイダーブリッジによってブリッジされます。プロバイダーブリッジに送信する前にフレームにSタグを追加するようにカスタマーブリッジポートを構成する機能など、プロバイダーブリッジの認識に関連するカスタマーブリッジ機能はEISSレイヤーの下にあり、変更せずにRBridgeポートでサポートできます。 TRILLプロトコル。
802.1ag-2007 Connectivity Fault Management (CFM) - This 802.1 feature is at least in part dependent on the symmetric path and other characteristics of spanning tree. The comments provided to the IETF TRILL working group by the IEEE 802.1 working group stated that "TRILL weakens the applicability of CFM".
802.1ag-2007接続障害管理（CFM）-この802.1機能は、少なくとも一部は対称パスとスパニングツリーの他の特性に依存しています。 IEEE 802.1ワーキンググループによってIETF TRILLワーキンググループに提供されたコメントは、「TRILLはCFMの適用性を弱める」と述べています。
802.1ak-2007 Multiple Registration Protocol - Supported to the extent described in Section 4.9.4.
802.1ak-2007多重登録プロトコル-セクション4.9.4で説明されている範囲でサポートされています。
802.1ah-2008 Provider Backbone Bridges - Sometimes called "MAC-in-MAC", 802.1ah provides for Provider Backbone Bridges that tunnel customer bridge traffic within different outer MAC addresses and using a tag (the "I-tag") to preserve the original MAC addresses and signal other information. If the customer LAN is an RBridge campus, that traffic will be bridged by Provider Backbone Bridges. Customer bridge features involving Provider Backbone Bridge awareness, such as the ability to configure a customer bridge port to add an I-tag to a frame before sending it to a Provider Backbone Bridge, are below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1ah-2008プロバイダーバックボーンブリッジ-「MAC-in-MAC」と呼ばれることもある802.1ahは、異なる外部MACアドレス内でカスタマーブリッジトラフィックをトンネリングし、タグ（「Iタグ」）を使用して元のMACアドレスとその他の情報を通知します。カスタマーLANがRBridgeキャンパスの場合、そのトラフィックはプロバイダーバックボーンブリッジによってブリッジされます。プロバイダーバックボーンブリッジに送信する前にフレームにIタグを追加するようにカスタマーブリッジポートを構成する機能など、プロバイダーバックボーンブリッジの認識に関連するカスタマーブリッジ機能はEISSレイヤーの下にあり、RBridgeポートなしでサポートできます。 TRILLプロトコルの変更。
802.1Qaw-2009 Management of Data-Driven and Data-Dependent Connectivity Fault - Amendment building on 802.1ag. See comments on 802.1ag-2007 above.
802.1Qaw-2009データ駆動型およびデータ依存型接続障害の管理-802.1agに基づく修正。上記の802.1ag-2007に関するコメントを参照してください。
802.1Qay-2009 Provider Backbone Bridge Traffic Engineering - Amendment building on 802.1ah to configure traffic engineered routing. See comments on 802.1ah-2008 above.
802.1Qay-2009プロバイダーバックボーンブリッジトラフィックエンジニアリング-トラフィックエンジニアリングルーティングを構成するための802.1ahに基づく修正。上記の802.1ah-2008に関するコメントを参照してください。
The following are amendments to IEEE [802.1Q-2005] that are in process. As such, the brief comments below are based on drafts and may be incorrect for later versions or any final amendment.
以下は、進行中のIEEE [802.1Q-2005]の修正です。そのため、以下の簡単なコメントはドラフトに基づいており、それ以降のバージョンや最終的な修正では正しくない可能性があります。
802.1aj Two-port MAC Relay [802.1aj] - This amendment specifies a MAC relay that will be transparent to RBridges. RBridges are compatible with IEEE 802.1aj devices as currently specified, in the same sense that IEEE 802.1Q-2005 bridges are compatible with such devices.
802.1aj 2ポートMACリレー[802.1aj]-この修正により、RBridgeに対して透過的なMACリレーが指定されます。 RBridgeは、IEEE 802.1Q-2005ブリッジがそのようなデバイスと互換性があるのと同じ意味で、現在指定されているIEEE 802.1ajデバイスと互換性があります。
802.1aq Shortest Path Bridging - This amendment provides for improved routing in bridged LANs.
802.1aq最短パスブリッジ-この修正により、ブリッジLANでのルーティングが改善されます。
802.1Qat Stream Reservation Protocol - Modification to 802.1Q to support the 802.1 Timing and Synchronization. This protocol reserves resources for streams at supporting bridges.
802.1Qatストリーム予約プロトコル-802.1Qの変更により、802.1タイミングと同期をサポートします。このプロトコルは、サポートするブリッジでストリーム用のリソースを予約します。
802.1Qau Congestion Notification - It currently appears that modifications to RBridge behavior above the EISS level would be needed to support this amendment. Such modifications are beyond the scope of this document.
802.1Qau輻輳通知-現在、この修正をサポートするには、EISSレベルを超えるRBridge動作を変更する必要があるようです。このような変更は、このドキュメントの範囲を超えています。
802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive Streams - Modification to 802.1Q to support the 802.1 Timing and Synchronization protocol. This amendment specifies methods to support the resource reservations made through the 802.1Qat protocol (see above).
時間依存のストリームの802.1Qav転送およびキューイングの機能拡張-802.1Qへの変更により、802.1タイミングおよび同期プロトコルをサポートします。この修正は、802.1Qatプロトコル（上記を参照）を介して行われたリソース予約をサポートする方法を指定します。
802.1Qaz Enhanced Transmission Selection - It appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1Qaz拡張伝送選択-この修正はEISSレイヤーの下にあり、TRILLプロトコルを変更せずにRBridgeポートでサポートできるようです。
802.1Qbb Priority-based Flow Control - Commonly called "per-priority pause", it appears that this amendment will be below the EISS layer and can be supported in RBridge ports without modification to the TRILL protocol.
802.1Qbb優先度ベースのフロー制御-一般に「優先度ごとの一時停止」と呼ばれ、この修正はEISSレイヤーの下にあり、TRILLプロトコルを変更せずにRBridgeポートでサポートできるようです。
802.1bc Remote Customer Service Interfaces. This is an extension to 802.1Q provider bridging. See 802.1ad-2005 above.
802.1bcリモートカスタマーサービスインターフェイス。これは、802.1Qプロバイダーブリッジングの拡張機能です。上記の802.1ad-2005を参照してください。
802.1Qbe Multiple Backbone Service Instance Identifier (I-SID) Registration Protocol (MIRP). This is an extension to 802.1Q provider backbone bridging. See 802.1ah-2008 above.
802.1Qbeマルチバックボーンサービスインスタンス識別子（I-SID）登録プロトコル（MIRP）。これは、802.1Qプロバイダーバックボーンブリッジングの拡張機能です。上記の802.1ah-2008を参照してください。
802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE) Infrastructure Segment Protection. This amendment extends 802.1Q to support certain types of failover between provider backbone bridges. See 802.1ah-2008 above.
802.1Qbfプロバイダーバックボーンブリッジトラフィックエンジニアリング（PBB-TE）インフラストラクチャセグメント保護。この修正により802.1Qが拡張され、プロバイダーのバックボーンブリッジ間の特定の種類のフェイルオーバーがサポートされます。上記の802.1ah-2008を参照してください。
Many people have contributed to this design, including the following, in alphabetic order:
以下を含む多くの人々がアルファベット順にこのデザインに貢献しました：
Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk, Bill Fenner, Eric Gray, Sujay Gupta, Joel Halpern, Andrew Lange, Acee Lindem, Vishwas Manral, Peter McCann, Israel Meilik, David Melman, Nandakumar Natarajan, Erik Nordmark, Jeff Pickering, Tim Polk, Dan Romascanu, Sanjay Sane, Pekka Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, Kate Zebrose.
Bernard Aboba、Alia Atlas、Ayan Banerjee、Caitlin Bestler、Suresh Boddapati、David Michael Bond、Stewart Bryant、Ross Callon、James Carlson、Pasi Eronen、Dino Farinacci、Adrian Farrell、Don Fedyk、Bill Fenner、Eric Grey、Sujay Gupta、Joel Halpern、Andrew Lange、Acee Lindem、Vishwas Manral、Peter McCann、Israel Meilik、David Melman、Nandakumar Natarajan、Erik Nordmark、Jeff Pickering、Tim Polk、Dan Romascanu、Sanjay Sane、Pekka Savola、Matthew R. Thomas、Joe Touch、Markタウンズリー、ケイト・ゼブローズ。
Authors' Addresses
著者のアドレス
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、カリフォルニア州95054-1549米国
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク、第3ファーウェイテクノロジーズ155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
Dinesh G. Dutt Cisco Systems 170 Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Silvano Gai Cisco Systems 170 Tasman Drive San Jose, CA 95134-1706 USA
Silvano Gai Cisco Systems 170 Tasman Drive San Jose、CA 95134-1706 USA
EMail: silvano@ip6.com
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
Way San Jose、K 95134 Us
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu