[要約] RFC 8377は、TRILL（Transparent Interconnection of Lots of Links）プロトコルの拡張であり、複数のトポロジをサポートすることを目的としています。このRFCは、TRILLネットワークの柔軟性とスケーラビリティを向上させるためのガイドラインを提供します。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8377 M. Zhang
Updates: 6325, 7177 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 Cisco
July 2018
Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
多数のリンクの透過的な相互接続（TRILL）：マルチトポロジ
Abstract
概要
This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177.
このドキュメントでは、RFC 5120で指定されているIS-IS（中間システムから中間システム）マルチトポロジに基づいて、ユニキャストおよびマルチ宛先トラフィックのマルチトポロジルーティングをサポートするために、IETF TRILL（リンクの多くの透過的相互接続）プロトコルの拡張を指定します。このドキュメントは、RFC 6325および7177を更新します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8377.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8377で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................4
2. Topologies ......................................................5
2.2. Links and Multi-Topology ...................................5
2.3. TRILL Switches and Multi-Topology ..........................6
2.4. TRILL Data Packets and Multi-Topology ......................6
2.4.1. Explicit Topology Labeling Support ..................7
2.4.2. The Explicit Topology Label .........................8
2.4.3. TRILL Use of the MT Label ...........................8
3. TRILL Multi-Topology Adjacency and Routing .....................10
3.1. Adjacency .................................................10
3.2. TRILL Switch Nicknames ....................................10
3.3. TRILL Unicast Routing .....................................11
3.4. TRILL Multi-Destination Routing ...........................11
3.4.1. Distribution Trees .................................11
3.4.2. Multi-Access Links .................................13
4. Mixed Links ....................................................13
5. Other Multi-Topology Considerations ............................14
5.1. Address Learning ..........................................14
5.1.1. Data Plane Learning ................................14
5.1.2. Multi-Topology ESADI ...............................14
5.2. Legacy Stubs ..............................................14
5.3. RBridge Channel Messages ..................................14
5.4. Implementations Considerations ............................15
6. Allocation Considerations ......................................15
6.1. IEEE Registration Authority Considerations ................15
6.2. IANA Considerations .......................................15
7. Security Considerations ........................................16
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Appendix A. Differences from RFC 5120 .............................19
Acknowledgements ..................................................19
Authors' Addresses ................................................20
This document specifies extensions to the IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7177] [RFC7780] to support multi-topology routing for both unicast and multi-destination traffic based on IS-IS (Intermediate System to Intermediate System) [IS-IS] multi-topology [RFC5120]. Implementation and use of multi-topology are optional, and use requires configuration. It is anticipated that not all TRILL campuses will need or use multi-topology.
このドキュメントでは、IETF TRILL（多くのリンクの透過的相互接続）プロトコル[RFC6325] [RFC7177] [RFC7780]への拡張を指定して、IS-IS（中間システムから中間システム）に基づくユニキャストとマルチ宛先トラフィックの両方のマルチトポロジルーティングをサポートします。システム）[IS-IS]マルチトポロジ[RFC5120]。マルチトポロジの実装と使用はオプションであり、使用には構成が必要です。すべてのTRILLキャンパスがマルチトポロジを必要とする、または使用するわけではないことが予想されます。
Multi-topology creates different topologies or subsets from a single physical TRILL campus topology. This is different from Data Labels (VLANs and Fine-Grained Labels (FGLs) [RFC7172]). Data Labels specify communities of end stations and can be viewed as creating virtual topologies of end station connectivity. However, in a single topology TRILL campus, TRILL Data packets can use any part of the physical topology of TRILL switches and links between TRILL switches, regardless of the Data Label of that packet's payload. In a multi-topology TRILL campus, TRILL data packets in a topology are restricted to the TRILL switches and links that are in their topology, regardless of the Data Label of their payload.
マルチトポロジは、単一の物理TRILLキャンパストポロジから異なるトポロジまたはサブセットを作成します。これは、データラベル（VLANおよび細粒度ラベル（FGL）[RFC7172]）とは異なります。データラベルはエンドステーションのコミュニティを指定し、エンドステーション接続の仮想トポロジを作成するものと見なすことができます。ただし、単一トポロジのTRILLキャンパスでは、TRILLデータパケットは、そのパケットのペイロードのデータラベルに関係なく、TRILLスイッチの物理トポロジの任意の部分とTRILLスイッチ間のリンクを使用できます。マルチトポロジのTRILLキャンパスでは、トポロジ内のTRILLデータパケットは、ペイロードのデータラベルに関係なく、トポロジ内にあるTRILLスイッチとリンクに制限されます。
The essence of multi-topology behavior is that a multi-topology router classifies packets as to the topology within which they should be routed and uses logically different routing tables for different topologies. If routers in the network do not agree on the topology classification of packets or links, persistent routing loops can occur. It is the responsibility of the network manager to consistently configure multi-topology to avoid such routing loops.
マルチトポロジ動作の本質は、マルチトポロジルーターがパケットをルーティングするトポロジについてパケットを分類し、トポロジごとに論理的に異なるルーティングテーブルを使用することです。ネットワーク内のルーターがパケットまたはリンクのトポロジ分類に同意しない場合、永続的なルーティングループが発生する可能性があります。このようなルーティングループを回避するためにマルチトポロジを一貫して構成するのは、ネットワーク管理者の責任です。
The multi-topology TRILL extensions can be used for a wide variety of purposes, such as maintaining separate routing domains for isolated multicast or IPv6 islands, routing a class of traffic so that it avoids certain TRILL switches that lack some characteristic needed by that traffic, or making a class of traffic avoid certain links due to security, reliability, or other concerns.
マルチトポロジTRILL拡張機能は、分離されたマルチキャストまたはIPv6アイランドの個別のルーティングドメインを維持し、トラフィックに必要な特性のない特定のTRILLスイッチを回避するようにトラフィックのクラスをルーティングするなど、さまざまな目的に使用できます。または、トラフィックのクラスを作成すると、セキュリティ、信頼性、またはその他の懸念のために特定のリンクを回避できます。
It is possible for a particular topology to not be fully connected, either intentionally or due to node or link failures or incorrect configuration. This results in two or more islands of that topology that cannot communicate. In such a case, end stations connected in that topology to different islands will be unable to communicate with each other.
意図的に、またはノードやリンクの障害、または誤った構成が原因で、特定のトポロジーが完全に接続されていない可能性があります。これにより、そのトポロジの2つ以上のアイランドが通信できなくなります。このような場合、そのトポロジで異なるアイランドに接続されたエンドステーションは、相互に通信できなくなります。
Multi-topology TRILL supports regions of topology-ignorant TRILL switches as part of a multi-topology campus; however, such regions can only ingress to, egress from, or transit TRILL Data packets in the special base topology zero.
マルチトポロジTRILLは、トポロジを無視するTRILLスイッチの領域をマルチトポロジキャンパスの一部としてサポートします。ただし、そのような領域は、特別な基本トポロジゼロのTRILLデータパケットにのみ入力、出力、または通過できます。
The terminology and abbreviations of [RFC6325] are used in this document. Some of these are paraphrased below for convenience. Some additional terms are also listed.
このドキュメントでは、[RFC6325]の用語と略語を使用します。これらのいくつかは、便宜上以下で言い換えられています。いくつかの追加用語もリストされています。
campus: The name for a TRILL network, like "bridged LAN" is a name for a bridged network. It does not have any academic implication.
キャンパス：「ブリッジLAN」のようなTRILLネットワークの名前は、ブリッジネットワークの名前です。学術的な意味はありません。
DRB: Designated RBridge [RFC7177].
DRB：指定RBridge [RFC7177]。
FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label [RFC7172]. By implication, an "FGL TRILL switch" does not support Multi-Topology (MT).
FGL：きめの細かいラベル付けまたはきめの細かいラベル付けまたはきめの細かいラベル[RFC7172]。暗黙的に、「FGL TRILLスイッチ」はマルチトポロジ（MT）をサポートしません。
IS: Intermediate System [IS-IS].
IS：中間システム[IS-IS]。
LSP: Link State PDU (Protocol Data Unit) [IS-IS]. For TRILL, this includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs [RFC7780].
LSP：リンク状態PDU（プロトコルデータユニット）[IS-IS]。 TRILLの場合、これにはレベル1 LSPと拡張レベル1フラッディングスコープLSP [RFC7780]が含まれます。
MT: Multi-Topology [RFC5120].
MT：マルチトポロジ[RFC5120]。
MT TRILL Switch: A TRILL switch supporting the multi-topology feature specified in this document. An MT TRILL switch MUST support FGL in the sense that it MUST be FGL safe [RFC7172].
MT TRILLスイッチ：このドキュメントで指定されているマルチトポロジ機能をサポートするTRILLスイッチ。 MT TRILLスイッチは、FGLセーフでなければならないという意味でFGLをサポートしなければなりません[RFC7172]。
RBridge: Routing Bridge; an alternative name for a TRILL switch.
RBridge：Routing Bridge; TRILLスイッチの別名。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer [RFC6325].
TRILL：リンク層の多数のリンクまたはトンネルルーティングの透過的な相互接続[RFC6325]。
TRILL Switch: A device implementing the TRILL protocol. TRILL switches are Intermediate Systems (routers) [IS-IS].
TRILLスイッチ：TRILLプロトコルを実装するデバイス。 TRILLスイッチは中間システム（ルーター）[IS-IS]です。
VL: VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172]. By implication, a "VL RBridge" or "VL TRILL switch" does not support FGL or MT.
VL：VLANラベル付けまたはVLANラベル付けまたはVLANラベル[RFC7172]。暗黙的に、「VL RBridge」または「VL TRILLスイッチ」はFGLまたはMTをサポートしません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In TRILL multi-topology, a topology is a subset of the TRILL switches and of the links between TRILL switches in the TRILL campus. TRILL Data packets are constrained to the subset of switches and links corresponding to the packet's topology. TRILL multi-topology is based on IS-IS multi-topology [RFC5120]. See Appendix A for differences between TRILL multi-topology and [RFC5120].
TRILLマルチトポロジでは、トポロジはTRILLスイッチのサブセットと、TRILLキャンパス内のTRILLスイッチ間のリンクのサブセットです。 TRILLデータパケットは、パケットのトポロジに対応するスイッチとリンクのサブセットに制限されます。 TRILLマルチトポロジは、IS-ISマルチトポロジ[RFC5120]に基づいています。 TRILLマルチトポロジと[RFC5120]の違いについては、付録Aを参照してください。
The zero topology is special, as described in Section 2.1. Sections 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and TRILL Data packets, respectively.
ゼロトポロジーは、セクション2.1で説明するように特別です。セクション2.2、2.3、および2.4では、それぞれ、リンク、TRILLスイッチ、およびTRILLデータパケットのトポロジについて説明します。
The zero topology is special as the default base topology. All TRILL switches and links are considered to be in, and MUST support, topology zero. Thus, for example, topology zero can be used for general TRILL switch access within a campus for management messages, Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge Channel messages [RFC7178], and the like.
ゼロトポロジは、デフォルトの基本トポロジとして特別です。すべてのTRILLスイッチとリンクはトポロジ0にあると見なされ、トポロジゼロをサポートする必要があります。したがって、たとえば、トポロジーゼロは、管理メッセージ、双方向転送検出（BFD）メッセージ[RFC7175]、RBridgeチャネルメッセージ[RFC7178]などのキャンパス内の一般的なTRILLスイッチアクセスに使用できます。
Multi-topology TRILL switches advertise the topologies for which they are willing to send and receive TRILL Data packets on a port by listing those topologies in one or more MT TLVs [RFC5120] appearing in every TRILL Hello [RFC7177] they send out that port, except that they MUST handle topology zero, which it is optional to list.
マルチトポロジTRILLスイッチは、ポートで送信するすべてのTRILL Hello [RFC7177]に表示される1つ以上のMT TLV [RFC5120]にトポロジをリストすることにより、ポートでTRILLデータパケットを送受信するトポロジをアドバタイズします。ただし、リストするオプションのトポロジゼロを処理する必要があります。
A link is usable for TRILL Data packets in non-zero topology T only if:
リンクは、次の場合にのみ、ゼロ以外のトポロジTのTRILLデータパケットに使用できます。
(1) all TRILL switch ports on the link advertise topology T support in their Hellos, and
（1）リンク上のすべてのTRILLスイッチポートは、HelloでトポロジTサポートをアドバタイズします。
(2) if any TRILL switch port on the link requires explicit TRILL Data packet topology labeling (see Section 2.4) every other TRILL switch port on the link is capable of generating explicit packet topology labeling.
（2）リンク上のTRILLスイッチポートが明示的なTRILLデータパケットトポロジラベル付けを必要とする場合（セクション2.4を参照）、リンク上の他のすべてのTRILLスイッチポートは明示的なパケットトポロジラベル付けを生成できます。
A TRILL switch advertises the topologies that it supports by listing them in one or more MT TLVs [RFC5120] in its LSP, except that it MUST support topology zero, which is optional to list. For robust and rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment zero.
TRILLスイッチは、LSPの1つ以上のMT TLV [RFC5120]にリストすることで、サポートするトポロジをアドバタイズします。ただし、リストするオプションのトポロジゼロをサポートする必要があります。堅牢で迅速なフラッディングの場合、MT TLVはコアLSPフラグメント0でアドバタイズされる必要があります。
There is no "MT capability bit". A TRILL switch advertises that it is MT capable by advertising in its LSP support for any topology or topologies with the MT TLV, even if it just explicitly advertises support for topology zero.
「MT機能ビット」はありません。 TRILLスイッチは、トポロジゼロのサポートを明示的にアドバタイズする場合でも、MT TLVを使用するトポロジのLSPサポートでアドバタイズすることにより、MT対応であることをアドバタイズします。
The topology of a TRILL Data packet is commonly determined from either (1) some field or fields present in the packet itself or (2) the port on which the packet was received; however, optional explicit topology labeling of TRILL Data packets is also proved. This can be included in the data labeling area of TRILL Data packets as specified below.
TRILLデータパケットのトポロジは、通常、（1）パケット自体に存在する1つまたは複数のフィールド、または（2）パケットが受信されたポートから決定されます。ただし、オプションのTRILLデータパケットの明示的なトポロジラベルも証明されます。これは、以下で指定するTRILLデータパケットのデータラベル付け領域に含めることができます。
Examples of fields that might be used to determine topology are values or ranges of values of the payload VLAN or FGL [RFC7172], packet priority, IP version (IPv6 versus IPv4) or IP protocol, Ethertype, unicast versus multi-destination payload, IP Differentiated Services Code Point (DSCP) bits, or the like.
トポロジの決定に使用できるフィールドの例は、ペイロードVLANまたはFGL [RFC7172]、パケットの優先度、IPバージョン（IPv6とIPv4）またはIPプロトコル、Ethertype、ユニキャストとマルチ宛先ペイロード、IPの値または値の範囲です。 DiffServコードポイント（DSCP）ビットなど。
Multi-topology does not apply to TRILL IS-IS packets or to link level control frames. Those messages are link local and can be thought of as being above all topologies. Multi-topology only applies to TRILL Data packets.
マルチトポロジは、TRILL IS-ISパケットやリンクレベル制御フレームには適用されません。これらのメッセージはリンクローカルであり、すべてのトポロジーの上にあると考えることができます。マルチトポロジはTRILLデータパケットにのみ適用されます。
Support of the topology label is optional. Support could depend on port hardware and is indicated by a 2-bit capability field in the Port TRILL Version sub-TLV [RFC7176] appearing in the Port Capabilities TLV in Hellos. If there is no Port TRILL Capabilities sub-TLV in a Hello, then it is assumed that explicit topology labeling is not supported on that port. See the table below for the meaning of values of the Explicit Topology capability field:
トポロジラベルのサポートはオプションです。サポートはポートハードウェアに依存する可能性があり、Helloのポート機能TLVに表示されるポートTRILLバージョンサブTLV [RFC7176]の2ビット機能フィールドで示されます。 HelloにポートTRILL機能サブTLVがない場合、そのポートでは明示的なトポロジラベルがサポートされていないと見なされます。明示的トポロジ機能フィールドの値の意味については、以下の表を参照してください。
Value Meaning
----- -------
0 No support. Cannot send TRILL Data packets with an
explicit topology label and will likely treat as
erroneous and discard any TRILL Data packet received with
a topology label. Such a port is assumed to have the
ability and configuration to correctly classify TRILL
Data packets into all topologies for which it is
advertising support in its Hellos, either by examining
those packets or because they are arriving at that port.
1 Capable of inserting an explicit topology label in TRILL Data packets sent and tolerant of such labels in received TRILL Data packets. Such a port is capable, for all of the topologies it supports, of determining TRILL Data packet topology without an explicit label. Thus, it does not require such a label in received TRILL Data packets. On receiving a packet whose explicit topology label differs from the port's topology determination for that packet, the TRILL switch MUST discard the packet.
1送信されたTRILLデータパケットに明示的なトポロジラベルを挿入でき、受信したTRILLデータパケットにそのようなラベルを許容します。そのようなポートは、サポートするすべてのトポロジで、明示的なラベルなしでTRILLデータパケットトポロジを決定できます。したがって、受信したTRILLデータパケットにそのようなラベルは必要ありません。明示的なトポロジラベルがそのパケットのポートのトポロジ決定と異なるパケットを受信すると、TRILLスイッチはパケットを破棄する必要があります。
2 & 3 Require an explicit topology label in received TRILL Data packets except for topology zero. Any TRILL Data packets received without such a label are classified as being in topology zero. Also capable of inserting an explicit topology label in TRILL Data packets sent. (Values 2 and 3 are treated the same, which is the same as saying that if the 2 bit is on, the 1 bit is ignored.)
2および3トポロジー0を除き、受信したTRILLデータパケットに明示的なトポロジーラベルが必要です。このようなラベルなしで受信されたTRILLデータパケットは、トポロジゼロに分類されます。送信されたTRILLデータパケットに明示的なトポロジラベルを挿入することもできます。 （値2と3は同じように扱われます。つまり、2ビットがオンの場合、1ビットは無視されるということです。）
In a Hello on Port P, a TRILL switch advertising support for topology T but not advertising that it requires explicit topology labeling is assumed to have the ability and configuration to correctly classify TRILL Data packets into topology T by examination of those TRILL Data packets and/or by using the fact that they are arriving at port P.
ポートPのHelloで、トポロジTのサポートをアドバタイズしているが明示的なトポロジラベル付けが必要であることをアドバタイズしていないTRILLスイッチは、TRILLデータパケットを調べてTRILLデータパケットをトポロジTに正しく分類する機能と構成を持っていると想定されます。または、ポートPに到着しているという事実を使用します。
When a TRILL switch transmits a TRILL Data packet onto a link, if any other TRILL switch on that link requires explicit topology labeling, an explicit topology label MUST be included unless the TRILL Data packet is in topology zero, in which case, an explicit topology label MAY be included. If a topology label is not so required, but all other TRILL switches on that link support explicit topology labeling, then such a label MAY be included.
TRILLスイッチがTRILLデータパケットをリンクに送信するとき、そのリンク上の他のTRILLスイッチが明示的なトポロジラベル付けを必要とする場合、TRILLデータパケットがトポロジゼロでない限り、明示的なトポロジラベルを含める必要があります。ラベルが含まれる場合があります。トポロジラベルがそれほど必要ではないが、そのリンク上の他のすべてのTRILLスイッチが明示的なトポロジラベルをサポートしている場合は、そのようなラベルを含めることができます（MAY）。
This section specifies the explicit topology label. Its use by TRILL is specified in Section 2.4.3. This label may be used by other technologies besides TRILL. The MT Label is structured as follows:
このセクションでは、明示的なトポロジラベルを指定します。 TRILLによるその使用は、セクション2.4.3で指定されています。このラベルは、TRILL以外のテクノロジーでも使用できます。 MTラベルは次のように構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype 0x9A22 | V | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MT Label
図1：MTラベル
Where the fields are as follows:
フィールドは次のとおりです。
MT Ethertype: The MT Label Ethertype (see Section 6.1).
MT Ethertype：MT Label Ethertype（セクション6.1を参照）。
V: The version number of the MT Label. This document specifies version zero.
V：MTラベルのバージョン番号。このドキュメントでは、バージョン0を指定しています。
R: A 2-bit reserved field that MUST be sent as zero and ignored on receipt.
R：2ビットの予約済みフィールド。ゼロとして送信され、受信時に無視される必要があります。
MT-ID: The 12-bit topology using the topology number space of the MT TLV [RFC5120].
MT-ID：MT TLV [RFC5120]のトポロジー番号スペースを使用する12ビットトポロジー。
With the addition of the version zero MT Label, the four standardized content varieties for the TRILL Data packet data labeling area (the area after the Inner.MacSA -- or Flag Word if the Flag Word is present [RFC7780] -- and before the payload) are as show below. TRILL Data packets received with any other data labeling are discarded. {PRI, D} is a 3-bit priority and a drop eligibility indicator bit [RFC7780].
バージョン0のMTラベルの追加により、TRILLデータパケットデータのラベル付け領域（Inner.MacSAの後の領域、またはフラグワードが存在する場合はフラグワード[RFC7780]-の前、およびペイロード）は以下のとおりです。 TRILL他のデータラベル付けで受信したデータパケットは破棄されます。 {PRI、D}は、3ビットの優先順位とドロップ適格性インジケータビット[RFC7780]です。
All MT TRILL switches MUST support FGL, in the sense of being FGL safe [RFC7172]; thus, they MUST support all four data labeling area contents shown below. (This requirement is imposed, rather than having FGL support and MT support be independent, to reduce the number of variations in RBridges and simplify testing.) 1. C-VLAN [RFC6325]
すべてのMT TRILLスイッチは、FGLセーフであるという意味で、FGLをサポートする必要があります[RFC7172]。したがって、以下に示す4つすべてのデータラベル付け領域コンテンツをサポートする必要があります。 （RBridgeのバリエーションの数を減らし、テストを簡素化するために、FGLサポートとMTサポートを独立させるのではなく、この要件が課されます。）1. C-VLAN [RFC6325]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. FGL [RFC7172]
2. FGL [RFC7172]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. MT C-VLAN [RFC8377]
3. MT C-VLAN [RFC8377]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-VLAN = 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. MT FGL [RFC8377] [RFC7172]
4. MT FGL [RFC8377] [RFC7172]
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT Ethertype = 0x9A22 | 0 | R | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL = 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inclusion or use of S-VLAN or further stacked tags are beyond the scope of this document, but, as stated in [RFC6325], are obvious extensions.
S-VLANまたはさらにスタックされたタグの包含または使用はこのドキュメントの範囲外ですが、[RFC6325]で述べられているように、明らかな拡張です。
Routing calculations in IS-IS are based on adjacency. Section 3.1 specifies multi-topology TRILL adjacency. Section 3.2 describes the handling of nicknames. Sections 3.3 and 3.4 specify how unicast and multi-destination TRILL multi-topology routing differ from the TRILL base protocol routing.
IS-ISのルーティング計算は隣接関係に基づいています。セクション3.1では、マルチトポロジTRILL隣接を指定しています。セクション3.2では、ニックネームの処理について説明します。セクション3.3および3.4では、ユニキャストおよびマルチ宛先TRILLマルチトポロジルーティングがTRILLベースプロトコルルーティングとどのように異なるかを指定します。
There is no change in the determination or announcement of adjacency for topology zero, which is as specified in [RFC7177]. When a topology zero adjacency reaches the Report state, as specified in [RFC7177], the adjacency is announced in core LSPs using the Extended Intermediate System Reachability TLV (#22). This will be compatible with any legacy topology-ignorant RBridges that might not support E-L1FS FS-LSPs [RFC7780].
[RFC7177]で指定されている、トポロジー0の隣接関係の決定またはアナウンスに変更はありません。 [RFC7177]で指定されているように、トポロジゼロ隣接がレポート状態に達すると、拡張中間システム到達可能性TLVを使用して、コアLSPで隣接がアナウンスされます（＃22）。これは、E-L1FS FS-LSP [RFC7780]をサポートしない可能性がある、レガシートポロジを無視したRBridgeと互換性があります。
Adjacency is announced for non-zero topologies in LSPs using the MT Reachable Intermediate Systems TLV (#222) as specified in [RFC5120]. A TRILL switch reports adjacency for non-zero topology T if and only if that adjacency is in the Report state [RFC7177] and the two conditions listed in Section 2.2 are true, namely:
[RFC5120]で指定されているように、MT Reachable Intermediate Systems TLV（＃222）を使用して、LSPの非ゼロトポロジに対して隣接関係がアナウンスされます。 TRILLスイッチは、非隣接トポロジTの隣接関係を報告します。その隣接関係がReport状態[RFC7177]であり、セクション2.2にリストされている2つの条件、つまり次の場合に限ります。
1. All the ports on the link are announcing support of topology T.
1. リンク上のすべてのポートはトポロジーTのサポートを発表しています。
2. If any port announces that it requires explicit topology labeling (Explicit Topology capability field value 2 or 3), all other ports advertise that they are capable of producing such labeling (Explicit Topology capability field value of 1, 2, or 3).
2. いずれかのポートが明示的なトポロジラベル付けが必要であることを通知する場合（明示的なトポロジー機能フィールド値2または3）、他のすべてのポートはそのようなラベル付けを生成できることを通知します（明示的なトポロジー機能フィールド値1、2、または3）。
TRILL switches are usually identified within the TRILL protocol (for example, in the TRILL Header) by nicknames [RFC6325] [RFC7780]. Such nicknames can be viewed as simply 16-bit abbreviation for a TRILL switch's (or pseudo-node's) 7-byte IS-IS System ID. A TRILL switch or pseudo-node can have more than one nickname, each of which identifies it.
TRILLスイッチは通常、ニックネーム[RFC6325] [RFC7780]によってTRILLプロトコル内（たとえば、TRILLヘッダー内）で識別されます。このようなニックネームは、TRILLスイッチ（または疑似ノード）の7バイトのIS-ISシステムIDの単なる16ビットの省略形と見なすことができます。 TRILLスイッチまたは疑似ノードには、複数のニックネームを付けることができ、それぞれがそれを識別します。
Nicknames are common across all topologies, just as IS-IS System IDs are. Nicknames are determined as specified in [RFC6325] and [RFC7780] using only the Nickname sub-TLVs appearing in Router Capabilities TLVs (#242) advertised by TRILL switches. In particular, the nickname allocation algorithm ignores Nickname sub-TLVs that appear in MT Router Capability TLVs (#144). (However, Nickname sub-TLVs that appear in MT Router Capability TLVs with a non-zero topology do affect the choice of distribution tree roots as described in Section 3.4.1.)
IS-ISシステムIDと同様に、ニックネームはすべてのトポロジで共通です。ニックネームは、[RFC6325]および[RFC7780]で指定されているように、TRILLスイッチによってアドバタイズされるルーター機能TLV（＃242）に表示されるニックネームサブTLVのみを使用して決定されます。特に、ニックネーム割り当てアルゴリズムは、MTルーター機能TLV（＃144）に表示されるニックネームサブTLVを無視します。 （ただし、非ゼロトポロジのMTルーター機能TLVに表示されるニックネームサブTLVは、セクション3.4.1で説明されているように、配布ツリールートの選択に影響します。）
To minimize transient inconsistencies, all Nickname sub-TLVs advertised by a TRILL switch for a particular nickname, whether in Router Capability or MT Router Capability TLVs, SHOULD appear in the same LSP PDU. If that is not the case, then all LSP PDUs in which they do occur SHOULD be flooded as an atomic action.
一時的な不整合を最小限に抑えるために、特定のニックネームのTRILLスイッチによってアドバタイズされるすべてのニックネームサブTLVは、ルーター機能またはMTルーター機能のTLVに関係なく、同じLSP PDUに表示される必要があります。そうでない場合、それらが発生するすべてのLSP PDUは、アトミックアクションとしてフラッディングされる必要があります。
TRILL Data packets being TRILL unicast (those with TRILL Header M bit = 0) are routed based on the egress nickname using logically separate forwarding tables per topology T, where each such table has been calculated based on least cost routing within T: that is, only using links and nodes that support T. Thus, the next hop when forwarding TRILL Data packets is determined by a lookup logically based on {topology, egress nickname}.
TRILLユニキャスト（TRILLヘッダーMビット= 0を持つもの）であるTRILLデータパケットは、トポロジTごとに論理的に別個の転送テーブルを使用して、出力ニックネームに基づいてルーティングされます。このような各テーブルは、T内の最小コストルーティングに基づいて計算されています。つまり、 Tをサポートするリンクとノードのみを使用します。したがって、TRILLデータパケットを転送するときのネクストホップは、{トポロジ、出力ニックネーム}に基づいて論理的にルックアップによって決定されます。
TRILL sends multi-destination data packets (those packets with TRILL Header M bit = 1) over a distribution tree. Trees are designated by nicknames that appear in the "egress nickname" field of multi-destination TRILL Data packet TRILL Headers. To constrain multi-destination packets to a topology T and still distribute them properly requires the use of a distribution tree constrained to T. Handling such TRILL Data packets and distribution trees in TRILL MT is as described in the subsections below.
TRILLは、複数の宛先データパケット（TRILLヘッダーMビット= 1のパケット）を配信ツリーで送信します。ツリーは、複数の宛先のTRILLデータパケットTRILLヘッダーの「出力ニックネーム」フィールドに表示されるニックネームで指定されます。マルチ宛先パケットをトポロジーTに制限し、それらを適切に配信するには、Tに制限された配信ツリーを使用する必要があります。このようなTRILLデータパケットとTRILL MTでの配信ツリーの処理は、以下のサブセクションで説明されています。
General provisions for distribution trees and how those trees are determined are as specified in [RFC6325], [RFC7172], and [RFC7780]. The distribution trees for topology zero are determined as specified in those references and are the same as they would be with topology-ignorant TRILL switches.
配布ツリーの一般的な規定とそれらのツリーの決定方法は、[RFC6325]、[RFC7172]、および[RFC7780]で指定されています。トポロジー0の分散ツリーは、これらの参照で指定されているように決定され、トポロジーを無視するTRILLスイッチの場合と同じです。
The TRILL distribution tree construction and packet handling for some non-zero topology T are determined as specified in [RFC6325], [RFC7172], and [RFC7780] with the following changes:
いくつかの非ゼロトポロジーTのTRILL配信ツリーの構築とパケット処理は、[RFC6325]、[RFC7172]、および[RFC7780]で指定されているように決定され、次の変更が加えられています。
o As specified in [RFC5120], only links usable with topology T TRILL Data packets are considered when building a distribution tree for topology T. As a result, such trees are automatically limited to and separately span every internally connected island of topology T. In other words, if non-zero topology T consists of disjoint islands, each distribution tree construction for topology T is local to one such island.
o [RFC5120]で指定されているように、トポロジーT TRILLデータパケットで使用可能なリンクのみがトポロジーTの配布ツリーを構築するときに考慮されます。つまり、ゼロ以外のトポロジーTが互いに素なアイランドで構成されている場合、トポロジーTの各配布ツリーの構成は、そのようなアイランドの1つに対してローカルです。
o Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-TLV, and Trees Used sub-TLV occurring in an MT Router Capabilities TLV (#144) specifying topology T are used in determining the tree root(s), if any, for a connected area of non-zero topology T.
o トポロジーTを指定するMTルーター機能TLV（＃144）で発生するニックネームサブTLV、ツリーサブTLV、ツリー識別子サブTLV、および使用ツリーSub-TLVのみが、ツリールートの決定に使用されます。任意、非ゼロトポロジーTの接続された領域の場合。
+ There may be non-zero topologies with no multi-destination traffic or, as described in [RFC5120], even topologies with no traffic at all. For example, if only known destination unicast IPv6 TRILL Data packets were in topology T and all multi-destination IPv6 TRILL Data packets were in some other topology, there would be no need for a distribution tree for topology T. For this reason, a Number of Trees to Compute field value of zero in the Trees sub-TLV for the TRILL switch holding the highest priority to be a tree root for a non-zero topology T is honored and causes no distribution trees to be calculated for non-zero topology T. This is different from the base topology zero where, as specified in [RFC6325], a zero Number of Trees to Compute field value causes one tree to be computed.
+ 複数の宛先トラフィックがないゼロ以外のトポロジ、または[RFC5120]で説明されているように、まったくトラフィックがないトポロジも存在する可能性があります。たとえば、既知の宛先ユニキャストIPv6 TRILLデータパケットのみがトポロジTにあり、すべての複数宛先IPv6 TRILLデータパケットが他のトポロジにあった場合、トポロジTの配布ツリーは必要ありません。このため、数値ゼロのトポロジーTのツリールートになるように最高の優先度を保持するTRILLスイッチのTreesサブTLVでゼロのフィールド値を計算するためのツリーの使用が尊重され、非ゼロのトポロジーTに対して分散ツリーが計算されないこれは、[RFC6325]で指定されているように、計算するツリーの数フィールド値が0の場合、1つのツリーが計算される基本トポロジゼロとは異なります。
o Nicknames are allocated as described in Section 3.2. If a TRILL switch advertising that it provides topology T service holds nickname N, the priority of N to be a tree root is given by the tree root priority field of the Nickname sub-TLV that has N in its nickname field and occurs in a topology T MT Router Capabilities TLV advertised by that TRILL switch. If no such Nickname sub-TLV can be found, the priority of N to be a tree root is the default for an FGL TRILL switch as specified in [RFC7172].
o ニックネームは、セクション3.2の説明に従って割り当てられます。トポロジーTサービスを提供することをアドバタイズするTRILLスイッチがニックネームNを保持している場合、ツリールートになるNの優先度は、ニックネームフィールドにNがありトポロジーで発生するニックネームサブTLVのツリールート優先度フィールドによって与えられます。そのTRILLスイッチによって通知されるT MTルーター機能TLV。そのようなニックネームサブTLVが見つからない場合、ツリールートになるNの優先度は、[RFC7172]で指定されているFGL TRILLスイッチのデフォルトです。
+ There could be multiple topology T Nickname sub-TLVs for N being advertised for a particular RBridge or pseudo-node, due to transient conditions or errors. In that case, any advertised in a core LSP PDU are preferred to those advertised in an E-L1FS FS-LSP PDU. Within those categories, the one in the lowest numbered fragment is used and if there are multiple in that fragment, the one with the smallest offset from the beginning of the PDU is used.
+ 一時的な状態またはエラーのために、特定のRBridgeまたは疑似ノードに対してアドバタイズされるNのトポロジTニックネームサブTLVが複数存在する可能性があります。その場合、コアLSP PDUでアドバタイズされるものは、E-L1FS FS-LSP PDUでアドバタイズされるものよりも優先されます。これらのカテゴリ内では、最も小さい番号のフラグメントのものが使用され、そのフラグメントに複数ある場合は、PDUの先頭からのオフセットが最も小さいものが使用されます。
o Tree pruning for topology T uses only the Interested VLANs sub-TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT Router Capabilities TLVs for topology T.
o トポロジーTのツリープルーニングは、トポロジーTのMTルーター機能TLVでアドバタイズされる対象VLANサブTLVと対象ラベルサブTLV [RFC7176]のみを使用します。
An MT TRILL switch MUST have logically separate routing tables per topology for the forwarding of multi-destination traffic.
MT TRILLスイッチは、複数の宛先のトラフィックを転送するために、トポロジごとに論理的に別個のルーティングテーブルを備えている必要があります。
Multi-destination TRILL Data packets are forwarded on broadcast (multi-access) links in such a way as to be received by all other TRILL switch ports on the link. For example, on Ethernet links they are sent with a multicast Outer.MacDA [RFC6325]. Care must be taken that a TRILL Data packet in a non-zero topology is only forwarded by an MT TRILL switch.
マルチ宛先TRILLデータパケットは、リンク上の他のすべてのTRILLスイッチポートで受信されるように、ブロードキャスト（マルチアクセス）リンクで転送されます。たとえば、イーサネットリンクでは、マルチキャストOuter.MacDA [RFC6325]で送信されます。ゼロ以外のトポロジのTRILLデータパケットは、MT TRILLスイッチによってのみ転送されることに注意する必要があります。
For this reason, a non-zero topology TRILL Data packet MUST NOT be forwarded onto a link unless the link meets the requirements specified in Section 2.2 for use in that topology even if there are one or more MT TRILL switch ports on the link.
このため、リンクにMT TRILLスイッチポートが1つ以上ある場合でも、そのトポロジで使用するためにセクション2.2で指定された要件をリンクが満たさない限り、ゼロ以外のトポロジTRILLデータパケットをリンクに転送しないでください。
There might be any combination of MT, FGL, or even VL TRILL switches [RFC7172] on a link. DRB (Designated RBridge) election and Forwarder appointment on the link work as previously specified in [RFC8139] and [RFC7177]. It is up to the network manager to configure and manage the TRILL switches on a link so that the desired switch is DRB and the desired switch is the Appointed Forwarder for the appropriate VLANs.
リンクには、MT、FGL、またはVL TRILLスイッチ[RFC7172]の任意の組み合わせが存在する可能性があります。 DRB（指定RBridge）の選択とリンクのフォワーダーの予約は、[RFC8139]と[RFC7177]で以前に指定されたように機能します。リンク上のTRILLスイッチを構成および管理するのはネットワークマネージャの責任です。これにより、目的のスイッチがDRBになり、目的のスイッチが適切なVLANのAppointed Forwarderになります。
Frames ingressed by MT TRILL switches can potentially be in any topology recognized by the switch and permitted on the ingress port. Frames ingressed by VL or FGL TRILL switches can only be in the base zero topology. Because FGL and VL TRILL switches do not understand topologies, all occurrences of the following sub-TLVs MUST occur only in MT Port Capability TLVs with a zero MT-ID. Any occurrence of these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is ignored.
MT TRILLスイッチによって入力されたフレームは、スイッチによって認識され、入力ポートで許可される任意のトポロジに存在する可能性があります。 VLまたはFGL TRILLスイッチが入力したフレームは、ベースゼロトポロジにのみ存在できます。 FGLおよびVL TRILLスイッチはトポロジーを理解しないため、次のサブTLVはすべて、MT-IDがゼロのMTポート機能TLVでのみ発生する必要があります。ゼロ以外のMT-IDを持つMTポート機能TLVでこれらのサブTLVが発生しても無視されます。
Special VLANs and Flags Sub-TLV Enabled-VLANs Sub-TLV Appointed Forwarders Sub-TLV VLANs Appointed Sub-TLV
特殊なVLANとフラグサブTLVが有効なVLANサブTLVが指定したフォワーダーサブTLV VLANが指定したサブTLV
Native frames cannot be explicitly labeled (see Section 2.4) as to their topology.
ネイティブフレームは、トポロジに関して明示的にラベルを付けることはできません（セクション2.4を参照）。
The learning of end station Media Access Control (MAC) addresses is per topology as well as per label (VLAN or FGL). The same MAC address can occur within a TRILL campus for different end stations that differ only in topology without confusion.
エンドステーションのメディアアクセス制御（MAC）アドレスの学習は、トポロジごとおよびラベルごと（VLANまたはFGL）です。同じMACアドレスが、混乱のないトポロジーのみが異なるさまざまな端末のTRILLキャンパス内で発生する可能性があります。
End station MAC addresses learned from ingressing native frames or egressing TRILL Data packets are, for MT TRILL switches, qualified by topology. That is, either the topology into which that TRILL switch classified the ingressed native frame or the topology that the egressed TRILL Data frame was in.
入力ネイティブフレームまたは出力TRILLデータパケットから学習した端末のMACアドレスは、MT TRILLスイッチの場合、トポロジによって修飾されます。つまり、そのTRILLスイッチが入ったトポロジーが入力されたネイティブフレームを分類したか、出力されたTRILLデータフレームがあったトポロジーでした。
In an MT TRILL switch, End Station Address Distribution Information (ESADI) [RFC7357] operates per label (VLAN or FGL) per topology. Since ESADI messages appear, to transit TRILL switches, like normal multi-destination TRILL Data packets, ESADI link state databases and ESADI protocol operation are per topology as well as per label and local to each area of multi-destination TRILL data connectivity for that topology.
MT TRILLスイッチでは、エンドステーションアドレス配布情報（ESADI）[RFC7357]はトポロジごとにラベル（VLANまたはFGL）ごとに動作します。 ESADIメッセージが表示されるため、通常の複数宛先TRILLデータパケットのようにTRILLスイッチを通過するため、ESADIリンク状態データベースとESADIプロトコル操作は、トポロジごと、およびラベルごとであり、そのトポロジの複数宛先TRILLデータ接続の各領域に対してローカルです。 。
Areas of topology-ignorant TRILL switches can be connected to and become part of an MT TRILL campus but will only be able to ingress to, transit, or egress from topology zero TRILL Data packets.
トポロジを無視するTRILLスイッチの領域は、MT TRILLキャンパスに接続してその一部にすることができますが、トポロジゼロTRILLデータパケットへの入力、通過、または出力のみが可能です。
RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175] appear, to transit TRILL switches, like normal multi-destination TRILL Data packets. Thus, they have a topology and, if that topology is non-zero, are constrained by topology like other TRILL Data packets. Generally, when sent for network management purposes, they are sent in topology zero to avoid such constraint.
BFD over TRILL [RFC7175]などのRBridgeチャネルメッセージ[RFC7178]が表示され、通常の複数宛先TRILLデータパケットのようにTRILLスイッチを通過させます。したがって、それらにはトポロジーがあり、そのトポロジーがゼロ以外の場合、他のTRILLデータパケットのようなトポロジーによって制約されます。一般に、ネットワーク管理の目的で送信される場合は、このような制約を回避するためにトポロジー0で送信されます。
MT is an optional TRILL switch capability.
MTはオプションのTRILLスイッチ機能です。
Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120] indicates that a single router handling more than eight topologies is rare. There may be many more than eight distinct topologies in a routed area, such as a TRILL campus; in that case, many of these topologies will be handled by disjoint sets of routers and/or links.
レイヤ3 IS-IS MT [RFC5120]の実際の展開の経験は、8つを超えるトポロジを処理する単一のルータはまれであることを示しています。 TRILLキャンパスなどのルーティングされたエリアには、8つ以上の異なるトポロジが存在する場合があります。その場合、これらのトポロジの多くは、ルーターやリンクの互いに素なセットによって処理されます。
Based on this deployment experience, a TRILL switch capable of handling eight or more topologies can be considered a full implementation while a TRILL switch capable of handling four topologies can be considered a minimal implementation but still useful under some circumstances.
この導入経験に基づいて、8つ以上のトポロジを処理できるTRILLスイッチは完全な実装と見なすことができ、4つのトポロジを処理できるTRILLスイッチは最小限の実装と見なすことができますが、状況によっては依然として有用です。
IEEE Registration Authority and IANA considerations are given below.
IEEE登録局とIANAの考慮事項を以下に示します。
The IEEE Registration Authority has allocated Ethertype 0x9A22 for the MT Label (see Section 2.4).
IEEE Registration Authorityは、MTラベルにEthertype 0x9A22を割り当てました（セクション2.4を参照）。
IANA has assigned a field of two adjacent bits (14-15) of the Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit Topology capability field and updated the "PORT-TRILL-VER Sub-TLV Capability Flags" registry as follows.
IANAは、明示的トポロジ機能フィールドにポートTRILLバージョンサブTLVの機能ビットの隣接する2ビット（14〜15）のフィールドを割り当て、「PORT-TRILL-VERサブTLV機能フラグ」レジストリを次のように更新しました。
Bit Description Reference
----- ------------------------- ---------------
14-15 Topology labeling support. [RFC8377]
IANA has created the informational "TRILL Ethertypes" subregistry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリに、情報提供「TRILL Ethertypes」サブレジストリを作成しました。
Name: TRILL Ethertypes Registration Procedure(s): Ethertypes are assigned by the IEEE Registration Authority. Updates to this registry are coordinated with the designated expert. Reference: [RFC8377]
名前：TRILL Ethertypes登録手順：Ethertypeは、IEEE Registration Authorityによって割り当てられます。このレジストリの更新は、指定された専門家と調整されます。参照：[RFC8377]
Note: This registry provides centralized documentation of Ethertypes that were assigned by the IEEE for initial use with TRILL. In some cases, particularly L2-IS-IS and MT, they may be used with other protocols.
注：このレジストリは、IEEEによってTRILLでの初期使用のために割り当てられたEthertypeの集中ドキュメントを提供します。一部のケース、特にL2-IS-ISとMTでは、他のプロトコルで使用される場合があります。
Value Mnemonic Explanation Reference
------ -------- --------------------- ---------
0x22F3 TRILL TRILL data [RFC6325]
0x22F4 L2-IS-IS IS-IS [RFC6325]
0x893B FGL Fine Grained Labeling [RFC7172]
0x8946 - TRILL RBridge Channel [RFC7178]
0x9A22 MT Multi-Topology [RFC8377]
Multiple topologies are sometimes used for the isolation or security of traffic. For example, if some links were more likely than others to be subject to adversarial observation, it might be desirable to classify certain sensitive traffic in a topology that excluded those links.
トラフィックの分離またはセキュリティのために、複数のトポロジが使用されることがあります。たとえば、一部のリンクが他のリンクよりも敵対的観測の対象となる可能性が高い場合、それらのリンクを除外したトポロジで特定の機密トラフィックを分類することが望ましい場合があります。
Delivery of data originating in one topology outside of that topology is generally a security policy violation to be avoided at all reasonable costs. Using IS-IS security [RFC5310] on all IS-IS PDUs and link security appropriate to the link technology on all links involved, particularly those between RBridges, supports the avoidance of such violations.
そのトポロジの外にある1つのトポロジで発生したデータの配信は、通常、セキュリティポリシー違反であり、妥当なコストで回避する必要があります。すべてのIS-IS PDUでIS-ISセキュリティ[RFC5310]を使用し、関連するすべてのリンク、特にRBridge間のリンクのリンクテクノロジーに適したリンクセキュリティを使用すると、このような違反を回避できます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
[IS-IS] ISO / IEC 10589：2002、第2版、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用する中間システムから中間システムのドメイン内ルーティング交換プロトコル」、2002年。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、DOI 10.17487 / RFC5120、 2008年2月、<https://www.rfc-editor.org/info/rfc5120>。
[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, <https://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月、<https://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, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<https://www.rfc-editor.org/info/rfc6325>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <https://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<https://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<https://www.rfc-editor.org/info/rfc7176>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<https://www.rfc-editor.org/info/rfc7177>。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <https://www.rfc-editor.org/info/rfc7178>.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、DOI 10.17487 / RFC7178、2014年5月、<https://www.rfc-editor.org/info/rfc7178>。
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <https://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<https://www.rfc-editor.org/info/rfc7357>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<https://www.rfc-editor.org/info/rfc7780>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, DOI 10.17487/RFC7175, May 2014, <https://www.rfc-editor.org/info/rfc7175>.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「多数のリンクの透過的相互接続（TRILL）：双方向転送検出（BFD）サポート」、RFC 7175、DOI 10.17487 / RFC7175、2014年5月、<https://www.rfc-editor.org/info/rfc7175>。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139, June 2017, <https://www.rfc-editor.org/info/rfc8139>.
[RFC8139] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and F. Hu、 "Transparent Interconnection of Lots of Links（TRILL）：Appointed Forwarders"、RFC 8139、DOI 10.17487 / RFC8139、2017年6月、<https://www.rfc-editor.org/info/rfc8139>。
TRILL multi-topology, as specified in this document, differs from RFC 5120 as follows:
このドキュメントで指定されているTRILLマルチトポロジは、RFC 5120と次の点で異なります。
1. [RFC5120] provides for unicast multi-topology. This document extends that to cover multi-destination TRILL data distribution (see Section 3.4).
1. [RFC5120]は、ユニキャストマルチトポロジを提供します。このドキュメントは、複数の宛先のTRILLデータ配信をカバーするように拡張します（セクション3.4を参照）。
2. [RFC5120] assumes the topology of data packets is always determined implicitly, that is, based on the port over which the packets are received and/or preexisting fields within the packet. This document supports such implicit determination, but it extends this by providing for optional explicit topology labeling of data packets (see Section 2.4).
2. [RFC5120]は、データパケットのトポロジが常に暗黙的に決定されることを前提としています。つまり、パケットが受信されるポートやパケット内の既存のフィールドに基づいています。このドキュメントはそのような暗黙の決定をサポートしますが、データパケットのオプションの明示的なトポロジラベル付けを提供することでこれを拡張します（セクション2.4を参照）。
3. [RFC5120] makes support of the default topology zero optional for MT routers and links. For simplicity and ease in network management, this document requires all TRILL switches and links between TRILL switches to support topology zero (see Section 2.1).
3. [RFC5120]は、MTルーターとリンクのデフォルトトポロジゼロのサポートをオプションにします。ネットワーク管理を単純かつ容易にするために、このドキュメントでは、トポロジゼロをサポートするために、すべてのTRILLスイッチとTRILLスイッチ間のリンクが必要です（セクション2.1を参照）。
Acknowledgements
謝辞
The comments and contributions of the following are gratefully acknowledged:
以下のコメントと貢献に感謝いたします。
Vishwas Manral and Martin Vigoureux
ヴィシュワス壁画とマーティン・ビゴレックス
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 United States of America
ドナルドイーストレイク3rd Huawei Technologies 1424 Pro Shop Court Davenport、FL 33896アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mingui Zhang Huawei Technologies Co., Ltd. HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, 100085 China
min鬼Zhang hu A is Technologies co。、Ltd. hu阿偉ビル、3番X in is RD。、shang-DI情報産業基地、h爱-Dイアン地区、北京、100085中国
Email: zhangmingui@huawei.com
Ayan Banerjee Cisco 170 W. Tasman Drive San Jose, CA 95134 United States of America
Ayan Banerjee Cisco 170 W. Tasman Drive San Jose、CA 95134アメリカ合衆国
Email: ayabaner@cisco.com