[要約] RFC 7783は、TRILL（Transparent Interconnection of Lots of Links）のためのCoordinated Multicast Trees（CMT）に関するものであり、CMTの目的は、効率的なマルチキャストトラフィックの配信を実現することです。
Internet Engineering Task Force (IETF) T. Senevirathne
Request for Comments: 7783 Consultant
Updates: 6325 J. Pathangi
Category: Standards Track Dell
ISSN: 2070-1721 J. Hudson
Brocade
February 2016
Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)
多数のリンクの透過的な相互接続（TRILL）のための協調マルチキャストツリー（CMT）
Abstract
概要
TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of an Appointed Forwarder for a set of VLANs. Appointed Forwarders provide VLAN-based load sharing with an active-standby model. High-performance applications require an active-active load-sharing model. The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtual RBridge (also referred to as a virtual Routing Bridge or virtual TRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF (Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility to RBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325.
TRILL（多数のリンクの透過的相互接続）は、一連のVLANにAppointed Forwarderを選択することにより、TRILL以外のネットワークへのループのない接続を容易にします。 Appointed Forwardersは、アクティブスタンバイモデルでVLANベースのロードシェアリングを提供します。高性能アプリケーションには、アクティブ/アクティブの負荷分散モデルが必要です。アクティブ-アクティブ負荷分散モデルは、単一の仮想RBridge（仮想ルーティングブリッジまたは仮想TRILLスイッチとも呼ばれる）を使用して、特定の非TRILLネットワークを表すことで実現できます。単一のRBridgeを持つ非TRILLネットワークの仮想表現は、複数の宛先のRPF（Reverse Path Forwarding）チェックの計算に深刻な課題をもたらします。このドキュメントでは、関連するRPF問題を解決するためにTRILLキャンパス内で協調型マルチキャストツリー（CMT）を構築するために必要な拡張機能について説明します。ソフトウェアのアップグレードのみが必要なCMTは、RBridgeに、特定のTRILL複数宛先配布ツリーへの関連付けの望ましいパスを選択する際の柔軟性を提供します。このドキュメントはRFC 6325を更新します。
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/rfc7783.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7783で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Scope and Applicability ....................................4
2. Conventions Used in This Document ...............................5
2.1. Acronyms and Phrases .......................................5
3. The Affinity Sub-TLV ............................................6
4. Multicast Tree Construction and Use of Affinity Sub-TLV .........6
4.1. Update to RFC 6325 .........................................7
4.2. Announcing Virtual RBridge Nickname ........................8
4.3. Affinity Sub-TLV Capability ................................8
5. Theory of Operation .............................................8
5.1. Distribution Tree Assignment ...............................8
5.2. Affinity Sub-TLV Advertisement .............................9
5.3. Affinity Sub-TLV Conflict Resolution .......................9
5.4. Ingress Multi-Destination Forwarding ......................10
5.4.1. Forwarding when n < k ..............................10
5.5. Egress Multi-Destination Forwarding .......................11
5.5.1. Traffic Arriving on an Assigned Tree to RBk-RBv ....11
5.5.2. Traffic Arriving on Other Trees ....................11
5.6. Failure Scenarios .........................................11
5.6.1. Edge RBridge RBk Failure ...........................11
5.7. Backward Compatibility ....................................12
6. Security Considerations ........................................13
7. IANA Considerations ............................................13
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Acknowledgments ...................................................16
Contributors ......................................................16
Authors' Addresses ................................................16
TRILL (Transparent Interconnection of Lots of Links), as presented in [RFC6325] and other related documents, provides methods of utilizing all available paths for active forwarding, with minimum configuration. TRILL utilizes IS-IS (Intermediate System to Intermediate System) [IS-IS] as its control plane and uses a TRILL Header that includes a Hop Count.
[RFC6325]やその他の関連文書に示されているTRILL（多くのリンクの透過的相互接続）は、最小限の構成で、アクティブな転送に利用可能なすべてのパスを利用する方法を提供します。 TRILLは、IS-IS（中間システムから中間システム）[IS-IS]をコントロールプレーンとして使用し、ホップカウントを含むTRILLヘッダーを使用します。
[RFC6325], [RFC7177], and [RFC6439] provide methods for interoperability between TRILL and Ethernet end stations and bridged networks. [RFC6439] provides an active-standby solution, where only one of the RBridges (aka Routing Bridges or TRILL switches) on a link with end stations is in the active forwarding state for end-station traffic for any given VLAN. That RBridge is referred to as the Appointed Forwarder (AF). All frames ingressed into a TRILL network via the AF are encapsulated with the TRILL Header with a nickname held by the ingress AF RBridge. Due to failures, reconfigurations, and other network dynamics, the AF for any set of VLANs may change. RBridges maintain forwarding tables that contain bindings for destination Media Access Control (MAC) addresses and Data Labels (VLAN or Fine-Grained Labels (FGLs)) to egress RBridges. In the event of an AF change, forwarding tables of remote RBridges may continue to forward traffic to the previous AF. That traffic may get discarded at the egress, causing traffic disruption.
[RFC6325]、[RFC7177]、および[RFC6439]は、TRILLとイーサネットエンドステーションおよびブリッジネットワーク間の相互運用性のための方法を提供します。 [RFC6439]は、アクティブスタンバイソリューションを提供します。そこでは、エンドステーションとのリンク上のRBridge（別名ルーティングブリッジまたはTRILLスイッチ）の1つだけが、特定のVLANのエンドステーショントラフィックのアクティブフォワーディングステートになります。そのRBridgeはAppointed Forwarder（AF）と呼ばれます。 AFを介してTRILLネットワークに進入するすべてのフレームは、進入AF RBridgeが保持するニックネームを持つTRILLヘッダーでカプセル化されます。障害、再構成、およびその他のネットワークダイナミクスにより、VLANセットのAFが変更される場合があります。 RBridgeは、出力RBridgeへの宛先メディアアクセス制御（MAC）アドレスとデータラベル（VLANまたは細粒度ラベル（FGL））のバインディングを含む転送テーブルを維持します。 AFが変更された場合、リモートRBridgeの転送テーブルは、前のAFにトラフィックを転送し続ける場合があります。そのトラフィックは出口で破棄され、トラフィックの中断を引き起こす可能性があります。
High-performance applications require resiliency during failover. The active-active forwarding model minimizes impact during failures and maximizes the available network bandwidth. A typical deployment scenario, depicted in Figure 1, may have end stations and/or bridges attached to the RBridges. These devices typically are multi-homed to several RBridges and treat all of the uplinks independently using a Local Active-Active Link Protocol (LAALP) [RFC7379], such as a single Multi-Chassis Link Aggregation (MC-LAG) bundle or Distributed Resilient Network Interconnect [802.1AX]. The AF designation presented in [RFC6439] requires each of the edge RBridges to exchange TRILL Hello packets. By design, an LAALP does not forward packets received on one of the member ports of the MC-LAG to other member ports of the same MC-LAG. As a result, the AF designation methods presented in [RFC6439] cannot be applied to the deployment scenario depicted in Figure 1.
高性能アプリケーションには、フェイルオーバー中の復元力が必要です。アクティブ-アクティブ転送モデルは、障害時の影響を最小限に抑え、使用可能なネットワーク帯域幅を最大化します。図1に示されている典型的な展開シナリオでは、RBridgeに接続されたエンドステーションやブリッジがある場合があります。これらのデバイスは通常、いくつかのRBridgeにマルチホームされており、単一のマルチシャーシリンク集約（MC-LAG）バンドルや分散復元などのローカルアクティブ-アクティブリンクプロトコル（LAALP）[RFC7379]を使用して、すべてのアップリンクを個別に処理しますネットワーク相互接続[802.1AX]。 [RFC6439]で示されているAFの指定では、各エッジRBridgeがTRILL Helloパケットを交換する必要があります。設計上、LAALPは、MC-LAGのメンバーポートの1つで受信したパケットを同じMC-LAGの他のメンバーポートに転送しません。その結果、[RFC6439]で提示されているAF指定方法は、図1に示されている展開シナリオには適用できません。
An active-active load-sharing model can be implemented by representing the edge of the network connected to a specific edge group of RBridges by a single virtual RBridge. Each virtual RBridge MUST have a nickname unique within its TRILL campus. In addition to an active-active forwarding model, there may be other applications that may require similar representations.
アクティブ-アクティブ負荷分散モデルは、RBridgeの特定のエッジグループに接続されたネットワークのエッジを単一の仮想RBridgeで表すことによって実装できます。各仮想RBridgeには、そのTRILLキャンパス内で一意のニックネームが必要です。アクティブ-アクティブ転送モデルに加えて、同様の表現を必要とする可能性のある他のアプリケーションが存在する場合があります。
Sections 4.5.1 and 4.5.2 of [RFC6325], as updated by [RFC7780], specify distribution tree calculation and RPF (Reverse Path Forwarding) check calculation algorithms for multi-destination forwarding. These algorithms strictly depend on link cost and parent RBridge priority. As a result, based on the network topology, it may be possible that a given edge RBridge, if it is forwarding on behalf of the virtual RBridge, may not have a candidate multicast tree on which it (the edge RBridge) can forward traffic, because there is no tree for which the virtual RBridge is a leaf node from the edge RBridge.
[RFC6325]のセクション4.5.1と4.5.2は、[RFC7780]によって更新され、配布先ツリー計算とRPF（Reverse Path Forwarding）チェック計算アルゴリズムを指定して、複数の宛先への転送を行います。これらのアルゴリズムは、リンクコストと親RBridge優先度に厳密に依存しています。その結果、ネットワークトポロジに基づいて、特定のエッジRBridgeが仮想RBridgeに代わって転送している場合、それ（エッジRBridge）がトラフィックを転送できるマルチキャストツリーの候補がない可能性があります。これは、仮想RBridgeがエッジRBridgeからのリーフノードであるツリーがないためです。
In this document, we present a method that allows RBridges to specify the path of association for real or virtual child nodes to distribution trees. Remote RBridges calculate their forwarding tables and derive the RPF for distribution trees based on the distribution tree association advertisements. In the absence of distribution tree association advertisements, remote RBridges derive the SPF (Shortest Path First) based on the algorithm specified in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. This document updates [RFC6325] by changing, when Coordinated Multicast Trees (CMT) sub-TLVs are present, [RFC6325] mandatory provisions as to how distribution trees are constructed.
このドキュメントでは、RBridgeが実際のまたは仮想の子ノードの関連付けのパスを分散ツリーに指定できるようにする方法を示します。リモートRBridgeは、転送テーブルを計算し、配布ツリーの関連付けの通知に基づいて配布ツリーのRPFを導出します。配布ツリーアソシエーションアドバタイズメントがない場合、リモートRBridgeは、[RFC7780]によって更新された[RFC6325]のセクション4.5.1で指定されたアルゴリズムに基づいてSPF（Shortest Path First）を導出します。このドキュメントは、協調型マルチキャストツリー（CMT）サブTLVが存在する場合、[RFC6325]配信ツリーの構築方法に関する必須規定を変更することにより[RFC6325]を更新します。
In addition to the above-mentioned active-active forwarding model, other applications may utilize the distribution tree association framework presented in this document to associate to distribution trees through a preferred path.
上記のアクティブ-アクティブ転送モデルに加えて、他のアプリケーションは、このドキュメントで提示されている配布ツリー関連付けフレームワークを利用して、優先パスを通じて配布ツリーに関連付けることができます。
This proposal requires (1) the presence of multiple multi-destination trees within the TRILL campus and (2) that all the RBridges in the network be updated to support the new Affinity sub-TLV (Section 3). It is expected that both of these requirements will be met, as they are control-plane changes and will be common deployment scenarios. In case either of the above two conditions is not met, RBridges MUST support a fallback option for interoperability. Since the fallback is expected to be a temporary phenomenon until all RBridges are upgraded, this proposal gives guidelines for such fallbacks and does not mandate or specify any specific set of fallback options.
この提案では、（1）TRILLキャンパス内に複数の宛先ツリーが複数存在すること、および（2）ネットワーク内のすべてのRBridgeを更新して新しいAffinityサブTLV（セクション3）をサポートすることが必要です。これらの要件はコントロールプレーンの変更であり、一般的な導入シナリオであるため、これらの要件の両方が満たされることが期待されています。上記の2つの条件のいずれかが満たされない場合、RBridgeは相互運用性のためのフォールバックオプションをサポートする必要があります。フォールバックはすべてのRBridgeがアップグレードされるまでの一時的な現象であると予想されるため、この提案はそのようなフォールバックのガイドラインを提供し、フォールバックオプションの特定のセットを強制または指定しません。
This document specifies an Affinity sub-TLV to solve RPF issues at the active-active edge. Specific methods in this document for making use of the Affinity sub-TLV are applicable where a virtual RBridge is used to represent multiple RBridges connected to an edge Customer Equipment (CE) device through an LAALP, such as MC-LAG or some similar arrangement where the RBridges cannot see each other's Hellos.
このドキュメントでは、アクティブ/アクティブエッジでRPF問題を解決するためのアフィニティサブTLVを指定します。 MC-LAGなどのLAALPを介してエッジCustomer Equipment（CE）デバイスに接続された複数のRBridgeを表すために仮想RBridgeが使用される場合、このドキュメントのアフィニティサブTLVを使用する特定の方法が適用されます。 RBridgeはお互いのHelloを見ることができません。
This document does not provide other required operational elements to implement an active-active edge solution, such as MC-LAG methods. Solution-specific operational elements are outside the scope of this document and will be covered in other documents. (See, for example, [RFC7781].)
このドキュメントでは、MC-LAGメソッドなど、アクティブ-アクティブエッジソリューションを実装するために必要なその他の運用要素については説明していません。ソリューション固有の運用要素は、このドキュメントの範囲外であり、他のドキュメントでカバーされます。 （たとえば、[RFC7781]を参照してください。）
Examples provided in this document are for illustration purposes only.
このドキュメントで提供されている例は、説明のみを目的としています。
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]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying [RFC2119] significance.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、[RFC2119]の意味を持つと解釈されるべきではありません。
The following acronyms and phrases are used in this document:
このドキュメントでは、次の頭字語と語句が使用されています。
AF: Appointed Forwarder [RFC6439].
AF：Appointed Forwarder [RFC6439]。
CE: Customer Equipment device, that is, a device that performs forwarding based on 802.1Q bridging. This also can be an end station or a server.
CE：Customer Equipmentデバイス、つまり、802.1Qブリッジングに基づいて転送を実行するデバイス。これは、エンドステーションまたはサーバーにすることもできます。
Data Label: VLAN or FGL.
データラベル：VLANまたはFGL。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
LAALP: Local Active-Active Link Protocol [RFC7379].
LAALP：ローカルアクティブ-アクティブリンクプロトコル[RFC7379]。
MC-LAG: Multi-Chassis Link Aggregation. A proprietary extension to [802.1AX] that facilitates connecting a group of links from an originating device (A) to a group of discrete devices (B). Device (A) treats all of the links in a given MC-LAG bundle as a single logical interface and treats all devices in Group (B) as a single logical device for all forwarding purposes. Device (A) does not forward packets received on the multi-chassis link bundle out of the same multi-chassis link bundle. Figure 1 depicts a specific use case example.
MC-LAG：マルチシャーシリンク集約。 [802.1AX]の独自の拡張機能であり、発信デバイス（A）からディスクリートデバイス（B）のグループへのリンクグループの接続を容易にします。デバイス（A）は、特定のMC-LAGバンドルのすべてのリンクを単一の論理インターフェイスとして扱い、グループ（B）のすべてのデバイスをすべての転送目的で単一の論理デバイスとして扱います。デバイス（A）は、マルチシャーシリンクバンドルで受信したパケットを同じマルチシャーシリンクバンドルから転送しません。図1は、特定の使用例を示しています。
RPF: Reverse Path Forwarding. See Section 4.5.2 of [RFC6325].
RPF：リバースパス転送。 [RFC6325]のセクション4.5.2をご覧ください。
Virtual RBridge: A purely conceptual RBridge that represents an active-active edge group and is in turn represented by a nickname. For example, see [RFC7781].
仮想RBridge：純粋に概念的なRBridge。アクティブ-アクティブエッジグループを表し、ニックネームで表されます。たとえば、[RFC7781]を参照してください。
Association of an RBridge to a multi-destination distribution tree through a specific path is accomplished by using a new IS-IS sub-TLV, the Affinity sub-TLV.
特定のパスを介してRBridgeを複数の宛先の配布ツリーに関連付けるには、新しいIS-ISサブTLV、AffinityサブTLVを使用します。
The Affinity sub-TLV appears in Router Capability TLVs or MT Capability TLVs that are within Link State PDUs (LSPs), as described in [RFC7176]. [RFC7176] specifies the code point and data structure for the Affinity sub-TLV.
[RFC7176]で説明されているように、リンク状態PDU（LSP）内のルーター機能TLVまたはMT機能TLVにアフィニティサブTLVが表示されます。 [RFC7176]は、アフィニティサブTLVのコードポイントとデータ構造を指定します。
Figures 1 and 2 below show the reference topology and a logical topology using CMT to provide active-active service.
以下の図1および2は、CMTを使用してアクティブ/アクティブサービスを提供する参照トポロジと論理トポロジを示しています。
--------------------
/ \
| |
| TRILL Campus |
| |
\ /
--------------------
| | |
----- | --------
| | |
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
(| | |) <-- MC-LAG (| | |) <-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
Figure 1: Reference Topology
図1：参照トポロジ
-------------------- Sample Multicast Tree (T1)
/ \
| | |
| TRILL Campus | o RBn
| | / | \
\ / / | ---\
-------------------- RB1 o o o
| | | | RB2 RBk
| | -------------- |
| | | o RBv
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|--|--|-------------+ |
| +-|---|--+ +--------------+ |
| | | +------------------+ | |
MC-LAG -->(| | |) (| | |)<-- MC-LAG
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
RBv: virtual RBridge
RBv：仮想RBridge
Figure 2: Example Logical Topology
図2：論理トポロジの例
This document updates Section 4.5.1 of [RFC6325] and changes the calculation of distribution trees, as specified below:
このドキュメントは、[RFC6325]のセクション4.5.1を更新し、以下に指定されているように、分布ツリーの計算を変更します。
Each RBridge that desires to be the parent RBridge for a child RBridge (RBy) in a multi-destination distribution tree (Tree x) announces the desired association using an Affinity sub-TLV. The child is specified by its nickname. If an RBridge (RB1) advertises an Affinity sub-TLV designating one of its own nicknames (N1) as its "child" in some distribution tree, the effect is that nickname N1 is ignored when constructing other distribution trees. Thus, the RPF check will enforce the rule that only RB1 can use nickname N1 to do ingress/egress on Tree x. (This has no effect on least-cost path calculations for unicast traffic.)
複数の宛先の配布ツリー（ツリーx）の子RBridge（RBy）の親RBridgeになることを希望する各RBridgeは、アフィニティサブTLVを使用して目的の関連付けを通知します。子はニックネームで指定されます。 RBridge（RB1）が独自のニックネーム（N1）の1つをある配布ツリーの「子」として指定するアフィニティサブTLVをアドバタイズする場合、他の配布ツリーを構築するとき、ニックネームN1は無視されます。したがって、RPFチェックは、RB1のみがニックネームN1を使用してツリーxでの入力/出力を実行できるというルールを適用します。 （これは、ユニキャストトラフィックの最小コストパス計算には影響しません。）
When such an Affinity sub-TLV is present, the association specified by the Affinity sub-TLV MUST be used when constructing the multi-destination distribution tree, except in the case of a conflicting Affinity sub-TLV; such cases are resolved as specified in Section 5.3. In the absence of such an Affinity sub-TLV, or if there are any RBridges in the campus that do not support the Affinity sub-TLV, distribution trees are calculated as specified in Section 4.5.1 of [RFC6325], as updated by [RFC7780]. Section 4.3 below specifies how to identify RBridges that support the Affinity sub-TLV.
このようなアフィニティサブTLVが存在する場合、アフィニティサブTLVで指定された関連付けは、競合するアフィニティサブTLVの場合を除いて、マルチ宛先配布ツリーを構築するときに使用する必要があります。そのような場合は、セクション5.3で指定されているように解決されます。そのようなアフィニティサブTLVがない場合、またはキャンパス内にアフィニティサブTLVをサポートしていないRBridgeがある場合、[RFC6325]のセクション4.5.1で指定されているように、[ RFC7780]。以下のセクション4.3は、AffinityサブTLVをサポートするRBridgeを識別する方法を指定しています。
Each edge RBridge (RB1 to RBk) advertises its LSP virtual RBridge nickname (RBv) by using the Nickname sub-TLV (6) [RFC7176], along with their regular nickname or nicknames.
各エッジRBridge（RB1からRBk）は、Nickname sub-TLV（6）[RFC7176]と通常のニックネームを使用して、LSP仮想RBridgeニックネーム（RBv）を通知します。
It will be possible for any RBridge to determine that RBv is a virtual RBridge, because each RBridge (RB1 to RBk) that appears to be advertising that it is holding RBv is also advertising an Affinity sub-TLV asking that RBv be its child in one or more trees.
どのRBridgeも、RBvが仮想RBridgeであると判断する可能性があります。これは、RBvを保持していることをアドバタイズしているように見える各RBridge（RB1からRBk）も、RBvが1つの子であることを要求するアフィニティサブTLVをアドバタイズしているためです。以上の木。
Virtual RBridges are ignored when determining the distribution tree roots for the campus.
キャンパスの配布ツリールートを決定するとき、仮想RBridgeは無視されます。
All RBridges outside the edge group assume that multi-destination packets with their TRILL Header Ingress Nickname field set to RBv might use any of the distribution trees that any member of the edge group advertises that it might use.
エッジグループ外のすべてのRBridgeは、TRILLヘッダー入力ニックネームフィールドがRBvに設定された複数の宛先のパケットが、エッジグループのメンバーが使用するとアドバタイズする配信ツリーのいずれかを使用すると想定しています。
RBridges that announce the TRILL Version sub-TLV [RFC7176] and set the Affinity capability bit (Section 7) support the Affinity sub-TLV, calculation of multi-destination distribution trees, and RPF checks, as specified herein.
TRILLバージョンサブTLV [RFC7176]をアナウンスし、アフィニティ機能ビットを設定するRBridge（セクション7）は、ここで指定されているように、アフィニティサブTLV、マルチ宛先配布ツリーの計算、およびRPFチェックをサポートします。
Let's assume that there are n distribution trees and k edge RBridges in the edge group of interest.
対象のエッジグループにn個の分布ツリーとk個のエッジRBridgeがあると仮定します。
If n >= k
n> = kの場合
Let's assume that edge RBridges are sorted in numerically ascending order by IS-IS System ID such that RB1 < RB2 < RBk. Each RBridge in the numerically sorted list is assigned a monotonically increasing number j such that RB1 = 0, RB2 = 1, RBi = j, and RBi + 1 = j + 1. (See Section 4.5 of [RFC6325], as updated by Section 3.4 of [RFC7780], for how tree numbers are determined.)
エッジRBridgeが、RB1 <RB2 <RBkとなるように、IS-ISシステムIDによって数値の昇順で並べ替えられていると仮定します。数値で並べ替えられたリストの各RBridgeには、RB1 = 0、RB2 = 1、RBi = j、およびRBi + 1 = j + 1のように単調に増加する番号jが割り当てられます（セクション[RFC6325]のセクション4.5を参照） [RFC7780]の3.4、ツリー番号の決定方法。）
Assign each tree to RBi such that tree number (((tree_number) % k) + 1) is assigned to edge group RBridge i for tree_number from 1 to n, where n is the number of trees, k is the number of edge group RBridges considered for tree allocation, and "%" is the integer division remainder operation.
ツリー番号（（（tree_number）％k）+ 1）が1からnまでのtree_numberのエッジグループRBridge iに割り当てられるように、各ツリーをRBiに割り当てます（nはツリーの数、kはエッジグループRBridgeの数）ツリーの割り当てを考慮し、「％」は整数除算の剰余演算です。
If n < k
n <kの場合
Distribution trees are assigned to edge group RBridges RB1 to RBn, using the same algorithm as the n >= k case. RBridges RBn + 1 to RBk do not participate in the active-active forwarding process on behalf of RBv.
分布ツリーは、n> = kの場合と同じアルゴリズムを使用して、エッジグループRBridge RB1〜RBnに割り当てられます。 RBridge RBn + 1からRBkは、RBvに代わってアクティブ-アクティブ転送プロセスに参加しません。
Each RBridge in the RB1 through RBk domain advertises an Affinity sub-TLV for RBv to be its child.
RB1からRBkドメインの各RBridgeは、RBvがその子になるようにAffinity sub-TLVを通知します。
As an example, let's assume that RB1 has chosen Trees t1 and tk + 1 on behalf of RBv.
例として、RB1がRBvの代わりにツリーt1およびtk + 1を選択したと仮定します。
RB1 advertises the Affinity sub-TLV; {RBv, Num of Trees = 2, t1, tk + 1}.
RB1はアフィニティサブTLVをアドバタイズします。 {RBv、ツリーの数= 2、t1、tk + 1}。
Other RBridges in the RB1 through RBk edge group follow the same procedure.
RB1〜RBkエッジグループ内の他のRBridgeも同じ手順に従います。
In TRILL, multi-destination distribution trees are built outward from the root by each RBridge so that they all derive the same set of distribution trees [RFC6325].
TRILLでは、複数の宛先の配布ツリーが各RBridgeによってルートから外側に構築されるため、それらはすべて同じ配布ツリーのセット[RFC6325]を導出します。
If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for RBridge RBroot to be its child in a tree rooted at RBroot, that AFFINITY RECORD is in conflict with TRILL distribution tree root determination and MUST be ignored.
RBridge RB1が、RBridgeをルートとするツリーの子になるようにRBridge RBrootを要求するAFFINITY RECORDでアフィニティサブTLVをアドバタイズする場合、そのAFFINITY RECORDはTRILL配布ツリールートの決定と競合しているため、無視する必要があります。
If RBridge RB1 advertises an Affinity sub-TLV with an AFFINITY RECORD that asks for nickname RBn to be its child in any tree and RB1 is not adjacent to RBn nor does nickname RBn identify RB1 itself, that AFFINITY RECORD is in conflict with the campus topology and MUST be ignored.
RBridge RB1がAFFINITY RECORDを使用してアフィニティサブTLVをアドバタイズし、ニックネームRBnがツリーの子になることを要求し、RB1がRBnに隣接していないか、ニックネームRBnがRB1自体を識別していない場合、そのAFFINITY RECORDはキャンパストポロジと競合しています無視する必要があります。
If different RBridges advertise Affinity sub-TLVs that try to associate the same virtual RBridge as their child in the same tree or trees, those Affinity sub-TLVs are in conflict with each other for those trees. The nicknames of the conflicting RBridges are compared to identify which RBridge holds the nickname that is the highest priority to be a tree root, with the System ID as the tiebreaker.
異なるRBridgeが、同じ仮想ツリーまたはツリー内の子として同じ仮想RBridgeを関連付けようとするアフィニティサブTLVをアドバタイズする場合、それらのアフィニティサブTLVはそれらのツリーで互いに競合しています。競合するRBridgeのニックネームが比較され、どのRBridgeがシステムルートをタイブレーカーとして持つ、ツリールートになるための最高の優先度であるニックネームを保持しているかが識別されます。
The RBridge with the highest priority to be a tree root will retain the Affinity association. Other RBridges with lower priority to be a tree root MUST stop advertising their conflicting Affinity sub-TLVs, recalculate the multicast tree affinity allocation, and, if appropriate, advertise new non-conflicting Affinity sub-TLVs.
ツリールートになるために最も高い優先順位を持つRBridgeは、アフィニティの関連付けを保持します。ツリールートになるために優先度の低い他のRBridgeは、競合するアフィニティサブTLVのアドバタイズを停止し、マルチキャストツリーアフィニティ割り当てを再計算し、必要に応じて、競合しない新しいアフィニティサブTLVをアドバタイズする必要があります。
Similarly, remote RBridges MUST honor the Affinity sub-TLV from the RBridge with the highest priority to be a tree root (using System ID as the tiebreaker in the event of conflicting priorities) and ignore the conflicting Affinity sub-TLV entries advertised by the RBridges with lower priorities to be tree roots.
同様に、リモートRBridgeは、優先順位が最も高いRBridgeからのアフィニティサブTLVをツリールートにして（優先順位が競合する場合にシステムブレーカーとしてシステムIDを使用）、RBridgeによってアドバタイズされる競合するアフィニティサブTLVエントリを無視する必要があります優先順位を低くしてツリーのルートにします。
If there is at least one tree on which RBv has affinity via RBk, then RBk performs the following operations for multi-destination frames received from a CE node:
RBvがRBkを介してアフィニティを持つツリーが少なくとも1つある場合、RBkはCEノードから受信した複数の宛先フレームに対して次の操作を実行します。
1. Flood to locally attached CE nodes subjected to VLAN and multicast pruning.
1. VLANおよびマルチキャストプルーニングの対象となる、ローカルに接続されたCEノードへのフラッド。
2. Ingress (by encapsulating with a TRILL Header) and set the Ingress Nickname field of the TRILL Header to RBv (the nickname of the virtual RBridge).
2. Ingress（TRILLヘッダーでカプセル化することにより）、TRILLヘッダーのIngress NicknameフィールドをRBv（仮想RBridgeのニックネーム）に設定します。
3. Forward to one of the distribution trees, Tree x, in which RBv is associated with RBk.
3. RBvがRBkに関連付けられている配布ツリーの1つであるTree xに転送します。
If there is no tree on which RBv can claim affinity via RBk (probably because the number of trees (n) built is less than the number of RBridges (k) announcing the Affinity sub-TLV), then RBk MUST fall back to one of the following:
RBvがRBkを介してアフィニティを要求できるツリーがない場合（おそらく、構築されたツリーの数（n）がアフィニティサブTLVを通知するRBridges（k）の数よりも少ないため）、RBkは次のいずれかにフォールバックする必要があります。以下：
1. This RBridge (RBk) should stop forwarding frames from the CE nodes and should mark its port towards those CE nodes as disabled. This will prevent the CE nodes from forwarding data to this RBridge. Thus, the CE nodes will only use those RBridges that have been assigned a tree.
1. このRBridge（RBk）は、CEノードからのフレームの転送を停止し、それらのCEノードへのポートを無効としてマークする必要があります。これにより、CEノードはこのRBridgeにデータを転送できなくなります。したがって、CEノードは、ツリーが割り当てられているRBridgeのみを使用します。
-OR-
-または-
2. This RBridge tunnels multi-destination frames received from attached native devices to an RBridge RBy that has an assigned tree. The tunnel destination should forward it to the TRILL network and also to its local access links. (The mechanism of tunneling and handshaking between the tunnel source and destination are out of scope for this specification and may be addressed in other documents, such as [ChannelTunnel].)
2. このRBridgeは、接続されたネイティブデバイスから受信した複数の宛先フレームを、割り当てられたツリーを持つRBridge RByにトンネリングします。トンネルの宛先は、それをTRILLネットワークとローカルアクセスリンクに転送する必要があります。 （トンネルの送信元と宛先の間のトンネリングとハンドシェイクのメカニズムは、この仕様の範囲外であり、[ChannelTunnel]などの他のドキュメントで説明されている場合があります。）
The above fallback options may be specific to the active-active forwarding scenario. However, as stated above, the Affinity sub-TLV may be used in other applications. In such an event, the application SHOULD specify applicable fallback options.
上記のフォールバックオプションは、アクティブ/アクティブ転送シナリオに固有の場合があります。ただし、前述のように、Affinity sub-TLVは他のアプリケーションで使用できます。そのような場合、アプリケーションは適切なフォールバックオプションを指定する必要があります（SHOULD）。
Multi-destination frames arriving at RBk on a Tree x, where RBk has announced the affinity of RBv via x, MUST be forwarded to CE members of RBv that are in the frame's VLAN. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325].
ツリーx上のRBkに到着する複数の宛先フレーム（RBkがxを介してRBvのアフィニティを発表している）は、フレームのVLANにあるRBvのCEメンバーに転送する必要があります。仮想RBridgeニックネーム（RBv）で表されるネットワークの一部ではない他のエンドノードおよびRBridgeへの転送は、[RFC6325]で指定された転送ルールに従う必要があります。
Multi-destination frames arriving at RBk on a Tree y, where RBk has not announced the affinity of RBv via y, MUST NOT be forwarded to CE members of RBv. Forwarding to other end nodes and RBridges that are not part of the network represented by the virtual RBridge nickname (RBv) MUST follow the forwarding rules specified in [RFC6325].
ツリーyのRBkに到着する複数の宛先フレーム（RBkがyを介してRBvのアフィニティを通知していない）は、RBvのCEメンバーに転送してはなりません（MUST NOT）。仮想RBridgeニックネーム（RBv）で表されるネットワークの一部ではない他のエンドノードおよびRBridgeへの転送は、[RFC6325]で指定された転送ルールに従う必要があります。
The failure recovery algorithm below is presented only as a guideline. An active-active edge group MAY use other failure recovery algorithms; it is recommended that only one algorithm be used in an edge group at a time. Details of such algorithms are outside the scope of this document.
以下の障害回復アルゴリズムは、ガイドラインとしてのみ提示されています。アクティブ-アクティブエッジグループは、他の障害回復アルゴリズムを使用する場合があります。エッジグループでは一度に1つのアルゴリズムのみを使用することをお勧めします。そのようなアルゴリズムの詳細は、このドキュメントの範囲外です。
Each of the member RBridges of a given virtual RBridge edge group is aware of its member RBridges through configuration, LSP advertisements, or some other method.
特定の仮想RBridgeエッジグループの各メンバーRBridgeは、構成、LSPアドバタイズメント、またはその他の方法を通じて、メンバーRBridgeを認識しています。
Member RBridges detect nodal failure of a member RBridge through IS-IS LSP advertisements or lack thereof.
メンバーRBridgeは、IS-IS LSPアドバタイズメントまたはその欠如を通じて、メンバーRBridgeのノード障害を検出します。
Upon detecting a member failure, each of the member RBridges of the RBv edge group start recovery timer T_rec for failed RBridge RBi. If the previously failed RBridge RBi has not recovered after the expiry of timer T_rec, member RBridges perform the distribution tree assignment algorithm specified in Section 5.1. Each of the member RBridges re-advertises the Affinity sub-TLV with the new tree assignment. This action causes the campus to update the tree calculation with the new assignment.
メンバー障害を検出すると、RBvエッジグループの各メンバーRBridgeは、障害が発生したRBridge RBiのリカバリタイマーT_recを開始します。以前に失敗したRBridge RBiがタイマーT_recの満了後に回復しない場合、メンバーRBridgeは、セクション5.1で指定された分散ツリー割り当てアルゴリズムを実行します。メンバーの各RBridgeは、新しいツリーの割り当てでアフィニティサブTLVを再アドバタイズします。このアクションにより、キャンパスは新しい割り当てでツリー計算を更新します。
RBi, upon startup, advertises its presence through IS-IS LSPs and starts a timer T_i. Other member RBridges of the edge group, detecting the presence of RBi, start a timer T_j.
RBiは、起動時にIS-IS LSPを介してその存在をアドバタイズし、タイマーT_iを開始します。エッジグループの他のメンバーRBridgeは、RBiの存在を検出し、タイマーT_jを開始します。
Upon expiry of timer T_j, other member RBridges recalculate the multi-destination tree assignment and advertise the related trees using the Affinity sub-TLV. Upon expiry of timer T_i, RBi recalculates the multi-destination tree assignment and advertises the related trees using the Affinity sub-TLV.
タイマーT_jが満了すると、他のメンバーのRBridgeは、マルチ宛先ツリー割り当てを再計算し、アフィニティサブTLVを使用して関連ツリーをアドバタイズします。タイマーT_iが満了すると、RBiはマルチ宛先ツリー割り当てを再計算し、アフィニティサブTLVを使用して関連ツリーをアドバタイズします。
If the new RBridge in the edge group calculates trees and starts to use one or more of them before the existing RBridges in the edge group recalculate, there could be duplication of packets (for example, more than one edge group RBridge could decapsulate and forward a multi-destination frame on links into the active-active group) or loss of packets (for example, due to the Reverse Path Forwarding check, in the rest of the campus, if two edge group RBridges are trying to forward on the same tree, those from one will be discarded). Alternatively, if the new RBridge in the edge group calculates trees and starts to use one or more of them after the existing RBridges recalculate, there could be loss of data due to frames arriving at the new RBridge being black-holed. Timers T_i and T_j should be initialized to values designed to minimize these problems, keeping in mind that, in general, duplication of packets is a more serious problem than dropped packets. It is RECOMMENDED that T_j be less than T_i, and a reasonable default is 1/2 of T_i.
エッジグループ内の新しいRBridgeがツリーを計算し、エッジグループ内の既存のRBridgeが再計算する前に1つ以上のツリーを使用し始めると、パケットが重複する可能性があります（たとえば、複数のエッジグループRBridgeがカプセル化を解除して転送する可能性があります） 2つのエッジグループRBridgeが同じツリー上で転送しようとしている場合、アクティブ-アクティブグループへのリンク上のマルチ宛先フレーム）またはパケットの損失（たとえば、キャンパスの残りの部分でのリバースパス転送チェックによる） 1つからのものは破棄されます）。または、エッジグループ内の新しいRBridgeがツリーを計算し、既存のRBridgeが再計算した後で1つ以上のツリーを使用し始めると、ブラックホール化された新しいRBridgeに到着するフレームが原因でデータが失われる可能性があります。タイマーT_iおよびT_jは、これらの問題を最小限に抑えるように設計された値に初期化する必要があります。一般に、パケットの複製は、ドロップされたパケットよりも深刻な問題です。 T_jはT_i未満であることが推奨され、妥当なデフォルトはT_iの1/2です。
Implementations MUST support a backward compatibility modes to interoperate with "pre-Affinity sub-TLV" RBridges in the network. Such backward compatibility operations MAY include, but are not limited to, tunneling and/or active-standby modes of operation. It should be noted that tunneling would require silicon changes. However, CMT in itself is a software upgrade.
実装は、ネットワーク内の「pre-Affinity sub-TLV」RBridgesと相互運用するための下位互換性モードをサポートする必要があります。このような下位互換性操作には、トンネルおよび/またはアクティブ/スタンバイモードの操作が含まれる場合がありますが、これらに限定されません。トンネリングにはシリコンの変更が必要になることに注意してください。ただし、CMT自体はソフトウェアのアップグレードです。
Example:
例：
Step 1. Stop using the virtual RBridge nickname for traffic ingressing from CE nodes.
ステップ1. CEノードからのトラフィックの仮想RBridgeニックネームの使用を停止します。
Step 2. Stop performing active-active forwarding. Fall back to active standby forwarding, based on locally defined policies. The definition of such policies is outside the scope of this document and may be addressed in other documents.
ステップ2.アクティブ-アクティブ転送の実行を停止します。ローカルに定義されたポリシーに基づいて、アクティブスタンバイ転送にフォールバックします。そのようなポリシーの定義はこのドキュメントの範囲外であり、他のドキュメントで扱われる場合があります。
In general, the RBridges in a campus are trusted routers, and the authenticity of their link-state information (LSPs) and link-local PDUs (e.g., Hellos) can be enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310]. This includes authenticating the contents of the PDUs used to transport Affinity sub-TLVs.
一般に、キャンパス内のRBridgeは信頼できるルーターであり、リンク状態情報（LSP）とリンクローカルPDU（Helloなど）の信頼性は、通常のIS-ISセキュリティメカニズム[IS-IS]を使用して実施できます。 RFC5310]。これには、アフィニティサブTLVの転送に使用されるPDUの内容の認証が含まれます。
The particular security considerations involved with different applications of the Affinity sub-TLV will be covered in the document(s) specifying those applications.
AffinityサブTLVのさまざまなアプリケーションに関連する特定のセキュリティの考慮事項は、それらのアプリケーションを指定するドキュメントで説明されています。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
This document serves as the reference for the registration of "Affinity sub-TLV support" (bit 0) in the "TRILL-VER Sub-TLV Capability Flags" registry.
このドキュメントは、「TRILL-VER Sub-TLV Capability Flags」レジストリに「Affinity sub-TLV support」（ビット0）を登録するためのリファレンスとして機能します。
This document mentions the registration of "AFFINITY" (value 17) in the "Sub-TLVs for TLV 144" registry, but it is intentionally not listed as a reference for that registration; the reference remains [RFC7176].
このドキュメントでは、「TLV 144のSub-TLVs」レジストリでの「AFFINITY」（値17）の登録について説明していますが、意図的にその登録のリファレンスとして記載されていません。参照は残ります[RFC7176]。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A.、and F. Hu、 "Routing Bridges（RBridges）：Appointed Forwarders"、RFC 6439、DOI 10.17487 / RFC6439、November 2011、 <http://www.rfc-editor.org/info/rfc6439>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<http://www.rfc-editor.org/info/rfc7177>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <http://www.rfc-editor.org/info/rfc7781>.
[RFC7781] Zhai、H.、Senevirathne、T.、Perlman、R.、Zhang、M.、Y。Li、「多数のリンクの透過的な相互接続（TRILL）：アクティブ-アクティブアクセスの疑似ニックネーム」、RFC 7781、DOI 10.17487 / RFC7781、2016年2月、<http://www.rfc-editor.org/info/rfc7781>。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2014、DOI 10.1109 / IEEESTD.2014.7055197、2014年12月。
[ChannelTunnel] Eastlake 3rd, D., Umair, M., and Y. Li, "TRILL: RBridge Channel Tunnel Protocol", Work in Progress, draft-ietf-trill-channel-tunnel-07, August 2015.
[ChannelTunnel] Eastlake 3rd、D.、Umair、M.、Y。Li、「TRILL：RBridge Channel Tunnel Protocol」、作業中、draft-ietf-trill-channel-tunnel-07、2015年8月。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントと、リンクの透過的な相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標」 "、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<http://www.rfc-editor.org/info/rfc7379>。
Acknowledgments
謝辞
The authors wish to extend their appreciations towards individuals who volunteered to review and comment on the work presented in this document and who provided constructive and critical feedback. Specific acknowledgments are due for Anoop Ghanwani, Ronak Desai, Gayle Noble, and Varun Shah. Very special thanks to Donald Eastlake for his careful review and constructive comments.
著者は、このドキュメントに示されている作業のレビューとコメントに志願し、建設的で批判的なフィードバックを提供してくれた個人に感謝の意を表したいと思います。具体的な謝辞は、Anoop Ghanwani、Ronak Desai、Gayle Noble、Varun Shahによるものです。ドナルドイーストレイクの注意深いレビューと建設的なコメントに大変感謝しています。
Contributors
貢献者
The work in this document is a result of many passionate discussions and contributions from the following individuals, listed in alphabetical order by their first names:
このドキュメントでの作業は、以下の個人からの多くの情熱的な議論と貢献の結果であり、名のアルファベット順にリストされています。
Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Hongjun Zhai, Mingui Zhang, Radia Perlman, Sam Aldrin, and Shivakumar Sundaram.
Ayan Banerjee、Dinesh Dutt、Donald Schistleke、Hongjun Zahe、Meengi Zahang、Radia Pearlman、San Aldrin、Sivakumar Sundaram。
Authors' Addresses
著者のアドレス
Tissa Senevirathne Consultant
Tissa Senevirathneコンサルタント
Email: tsenevir@gmail.com
Janardhanan Pathangi Dell/Force10 Networks Olympia Technology Park Guindy Chennai 600 032 India
Janardanam Patangi Dell / FASS10 Networks Olympia Technology Park Guindy Chennai 9001 India
Phone: +91-44-42208400
Email: Pathangi_Janardhanan@Dell.com
Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 United States
Jon Hudson Brocade 130 Holger Way San Jose、CA 95134アメリカ合衆国
Phone: +1-408-333-4062
Email: jon.hudson@gmail.com