[要約] RFC 7176は、TRILL（Transparent Interconnection of Lots of Links）がIS-IS（Intermediate System to Intermediate System）を使用する方法について説明しています。このRFCの目的は、TRILLネットワークでIS-ISを効果的に使用するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 7176 Huawei
Obsoletes: 6326 T. Senevirathne
Category: Standards Track Cisco
ISSN: 2070-1721 A. Ghanwani
Dell
D. Dutt
Cumulus Networks
A. Banerjee
Insieme Networks
May 2014
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
多くのリンクの透過的な相互接続（TRILL）IS-ISの使用
Abstract
概要
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326.
IETFの多くのリンクの透過的相互接続（TRILL）プロトコルは、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークで構成せずに、最適なペアワイズデータフレーム転送を提供します。また、ユニキャストトラフィックとマルチキャストトラフィックの両方のマルチパスのサポートも提供します。このドキュメントでは、TRILLをサポートするIS-IS拡張のデータ形式とコードポイントを指定します。これらのデータ形式とコードポイントは、TRILL以外のテクノロジーでも使用できます。このドキュメントはRFC 6326を廃止します。
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/rfc7176.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7176で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Conventions Used in This Document ..........................4
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
2.1. Group Address TLV ..........................................5
2.1.1. Group MAC Address Sub-TLV ...........................5
2.1.2. Group IPv4 Address Sub-TLV ..........................7
2.1.3. Group IPv6 Address Sub-TLV ..........................8
2.1.4. Group Labeled MAC Address Sub-TLV ...................9
2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
2.2.1. Special VLANs and Flags Sub-TLV ....................12
2.2.2. Enabled-VLANs Sub-TLV ..............................13
2.2.3. Appointed Forwarders Sub-TLV .......................14
2.2.4. Port TRILL Version Sub-TLV .........................15
2.2.5. VLANs Appointed Sub-TLV ............................17
2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
2.3.1. TRILL Version Sub-TLV ..............................18
2.3.2. Nickname Sub-TLV ...................................19
2.3.3. Trees Sub-TLV ......................................20
2.3.4. Tree Identifiers Sub-TLV ...........................20
2.3.5. Trees Used Identifiers Sub-TLV .....................21
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
2.3.7. VLAN Group Sub-TLV .................................24
2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
2.3.9. RBridge Channel Protocols Sub-TLV ..................27
2.3.10. Affinity Sub-TLV ..................................29
2.3.11. Label Group Sub-TLV ...............................30
2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
2.5. TRILL Neighbor TLV ........................................31
3. MTU PDUs .......................................................33
4. Use of Existing PDUs and TLVs ..................................35
4.1. TRILL IIH PDUs ............................................35
4.2. Area Address ..............................................35
4.3. Protocols Supported .......................................35
4.4. Link State PDUs (LSPs) ....................................35
4.5. Originating LSP Buffer Size ...............................36
5. IANA Considerations ............................................36
5.1. TLVs ......................................................36
5.2. Sub-TLVs ..................................................36
5.3. PDUs ......................................................38
5.4. Reserved and Capability Bits ..............................38
5.5. TRILL Neighbor Record Flags ...............................39
6. Security Considerations ........................................39
7. Changes from RFC 6326 ..........................................39
8. References .....................................................41
8.1. Normative References ......................................41
8.2. Informative References ....................................43
9. Acknowledgements ...............................................44
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] [RFC7177] provides transparent forwarding in multi-hop networks with arbitrary topology and link technologies using a header with a hop count and link-state routing. TRILL provides optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. Intermediate Systems (ISs) implementing TRILL are called Routing Bridges (RBridges) or TRILL Switches.
IETFの多くのリンクの透過的相互接続（TRILL）プロトコル[RFC6325] [RFC7177]は、ホップカウントのあるヘッダーとリンク状態ルーティングを使用して、任意のトポロジとリンクテクノロジーを備えたマルチホップネットワークで透過的な転送を提供します。 TRILLは、構成なしの最適なペアワイズ転送、一時的なループの期間中も安全な転送、およびユニキャストとマルチキャストの両方のトラフィックのマルチパスをサポートします。 TRILLを実装する中間システム（IS）は、ルーティングブリッジ（RBridges）またはTRILLスイッチと呼ばれます。
This document, in conjunction with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL.
このドキュメントは、[RFC6165]と組み合わせて、TRILLをサポートするIS-IS [ISO-10589] [RFC1195]拡張のデータ形式とコードポイントを指定します。これらのデータ形式とコードポイントは、TRILL以外のテクノロジーでも使用できます。
This document obsoletes [RFC6326], which generally corresponded to the base TRILL protocol [RFC6325]. There has been substantial development of TRILL since the publication of those documents. The main changes from [RFC6326] are summarized below, and a full list is given in Section 7.
この文書は廃止されました[RFC6326]。これは基本的にTRILLプロトコル[RFC6325]に対応していました。それらの文書の公開以来、TRILの実質的な発展がありました。 [RFC6326]からの主な変更点を以下にまとめます。完全なリストはセクション7にあります。
1. Added multicast group announcements by IPv4 and IPv6 address.
1. IPv4およびIPv6アドレスによるマルチキャストグループアナウンスが追加されました。
2. Added facilities for announcing capabilities supported.
2. サポートされている機能を通知する機能が追加されました。
3. Added a tree affinity sub-TLV whereby ISs can request distribution tree association.
3. ISが配布ツリーの関連付けを要求できるツリーアフィニティサブTLVを追加しました。
4. Added multi-topology support.
4. マルチトポロジサポートが追加されました。
5. Added control-plane support for TRILL Data frame fine-grained labels. This support is independent of the data-plane representation.
5. TRILLデータフレームの細粒度ラベルのコントロールプレーンサポートが追加されました。このサポートは、データプレーンの表現とは無関係です。
6. Fixed the verified erratum [Err2869] in [RFC6326].
6. [RFC6326]で検証されたエラッタ[Err2869]を修正しました。
Changes herein to TLVs and sub-TLVs specified in [RFC6326] are backward compatible.
[RFC6326]で指定されているTLVおよびサブTLVへの変更は、下位互換性があります。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning.
[RFC6325]で定義されている用語と頭字語は、ここでは同じ意味で使用されます。
Additional acronyms and phrases used in this document are:
このドキュメントで使用されている追加の頭字語とフレーズは次のとおりです。
BVL - Bit Vector Length
BVL-ビットベクトル長
BVO - Bit Vector Offset
GFA-ビットベクトルオフセット
IIH - IS-IS Hello
IIH-IS-ISこんにちは
IS - Intermediate System. For this document, all relevant intermediate systems are RBridges [RFC6325].
IS-中間システム。このドキュメントでは、関連するすべての中間システムはRBridges [RFC6325]です。
MAC - Media Access Control
MAC-メディアアクセスコントロール
MT - Multi-Topology
MT-マルチトポロジ
NLPID - Network Layer Protocol Identifier
NLPID-ネットワーク層プロトコル識別子
SNPA - Subnetwork Point of Attachment (MAC Address)
SNPA-サブネットワーク接続ポイント（MACアドレス）
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]で説明されているように解釈されます。
This section, in conjunction with [RFC6165], specifies the data formats and code points for the TLVs and sub-TLVs for IS-IS to support the IETF TRILL protocol. Information as to the number of occurrences allowed, such as for a TLV in a PDU or set of PDUs or for a sub-TLV in a TLV, is summarized in Section 5.
このセクションは、[RFC6165]と組み合わせて、IETF TRILLプロトコルをサポートするIS-ISのTLVとサブTLVのデータ形式とコードポイントを指定します。 PDUまたはPDUのセットのTLVやTLVのサブTLVなど、許可される発生回数に関する情報は、セクション5にまとめられています。
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an LSP PDU and carries sub-TLVs that in turn advertise multicast group listeners. The sub-TLVs that advertise listeners are specified below. The sub-TLVs under GADDR constitute a new series of sub-TLV types (see Section 5.2).
グループアドレス（GADDR）TLV、IS-IS TLVタイプ142は、LSP PDUで伝送され、サブTLVを伝送します。サブTLVは、マルチキャストグループリスナーをアドバタイズします。リスナーを通知するサブTLVを以下に示します。 GADDRの下のサブTLVは、新しい一連のサブTLVタイプを構成します（セクション5.2を参照）。
GADDR has the following format:
GADDRの形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Type=GADDR-TLV | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: TLV type, set to GADDR-TLV 142.
o タイプ：TLVタイプ、GADDR-TLV 142に設定。
o Length: variable depending on the sub-TLVs carried.
o 長さ：運ばれるサブTLVによって異なります。
o sub-TLVs: The Group Address TLV value consists of sub-TLVs formatted as described in [RFC5305].
o サブTLV：グループアドレスTLV値は、[RFC5305]で説明されているようにフォーマットされたサブTLVで構成されます。
The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 within the GADDR TLV. In TRILL, it is used to advertise multicast listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. It has the following format:
グループMACアドレス（GMAC-ADDR）サブTLVは、GADDR TLV内のサブTLVタイプ番号1です。 TRILLでは、[RFC6325]のセクション4.5.5で指定されているように、MACアドレスでマルチキャストリスナーをアドバタイズするために使用されます。次の形式があります。
+-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6:
各グループレコードは、k = 6の次の形式です。
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o タイプ：GADDRサブTLVタイプ、1に設定（GMAC-ADDR）。
o Length: 5 + m + k*n = 5 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：5 + m + k * n = 5 + m + 6 * n。ここで、mはグループレコードの数、nはグループとソースアドレスの数の合計です。
o RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored on receipt.
o RESV：予約済み。ゼロとして送信し、受信時に無視する必要がある4ビットのフィールド。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o トポロジーID：このフィールドにはトポロジーID [RFC5120]が含まれます。トポロジーが使用されていない場合は0になります。
o VLAN ID: This carries the 12-bit VLAN identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：これは、このサブTLV内の後続のすべてのMACアドレスの12ビットのVLAN識別子、またはVLANが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast MAC address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、6バイト（48ビット）のマルチキャストMACアドレスと、それに続く6バイトの送信元MACアドレスがあります。ソースが単一のサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスを使用して同じグループアドレスを繰り返すことができます。
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.
GMAC-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2 within the GADDR TLV. It has the same format as the Group MAC Address sub-TLV described in Section 2.1.1 except that k=4. The fields are as follows:
グループIPv4アドレス（GIP-ADDR）サブTLVは、GADDR TLV内のIS-ISサブTLVタイプ2です。これは、セクション2.1.1で説明したグループMACアドレスサブTLVと同じ形式ですが、k = 4です。フィールドは次のとおりです。
o Type: sub-TLV type, set to 2 (GIP-ADDR).
o タイプ：サブTLVタイプ、2（GIP-ADDR）に設定。
o Length: 5 + m + k*n = 5 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：5 + m + k * n = 5 + m + 4 * n。ここで、mはグループレコードの数、nはグループアドレスと送信元アドレスの数の合計です。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o トポロジーID：このフィールドにはトポロジーID [RFC5120]が含まれます。トポロジーが使用されていない場合は0になります。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV：送信時にはゼロとして送信する必要があり、受信時には無視されます。
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：これは、このサブTLV内の後続のすべてのアドレスに有効な12ビットのVLAN識別子、またはVLANが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、4バイト（32ビット）のIPv4グループアドレスがあり、その後に4バイトのソースIPv4アドレスが続きます。ソースの数が1つのサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスで同じグループアドレスを繰り返すことが許可されます。
The GIP-ADDR sub-TLV is carried only within a GADDR TLV.
GIP-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3 within the GADDR TLV. It has the same format as the Group MAC Address sub-TLV described in Section 2.1.1 except that k=16. The fields are as follows:
グループIPv6アドレス（GIPV6-ADDR）サブTLVは、GADDR TLV内のIS-ISサブTLVタイプ3です。これは、セクション2.1.1で説明したグループMACアドレスサブTLVと同じ形式ですが、k = 16です。フィールドは次のとおりです。
o Type: sub-TLV type, set to 3 (GIPV6-ADDR).
o タイプ：サブTLVタイプ、3（GIPV6-ADDR）に設定。
o Length: 5 + m + k*n = 5 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：5 + m + k * n = 5 + m + 16 * n。ここで、mはグループレコードの数、nはグループアドレスと送信元アドレスの数の合計です。
o Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o Topology-Id：このフィールドには、トポロジID [RFC5120]が含まれます。トポロジが使用されていない場合は0になります。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV：送信時にはゼロとして送信する必要があり、受信時には無視されます。
o VLAN ID: This carries a 12-bit VLAN identifier that is valid for all subsequent addresses in this sub-TLV, or the value zero if no VLAN is specified.
o VLAN ID：これは、このサブTLV内の後続のすべてのアドレスに有効な12ビットのVLAN識別子、またはVLANが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、16バイト（128ビット）のIPv6グループアドレスがあり、その後に16バイトのソースIPv6アドレスが続きます。ソースの数が1つのサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスで同じグループアドレスを繰り返すことが許可されます。
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
GIPV6-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in Section 2.1.1 provides for a VLAN ID. The Group Labeled MAC Address sub-TLV, below, extends this to a fine-grained label.
セクション2.1.1で指定されたグループアドレス（GADDR）TLVのGMAC-ADDRサブTLVは、VLAN IDを提供します。以下のGroup Labeled MAC AddressサブTLVは、これをきめ細かいラベルに拡張します。
+-+-+-+-+-+-+-+-+
|Type=GLMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fine-Grained Label | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6:
各グループレコードは、k = 6の次の形式です。
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 4 (GLMAC-ADDR).
o タイプ：GADDRサブTLVタイプ、4に設定（GLMAC-ADDR）。
o Length: 6 + m + k*n = 6 + m + 6*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：6 + m + k * n = 6 + m + 6 * n。ここで、mはグループレコードの数、nはグループアドレスとソースアドレスの数の合計です。
o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored on receipt.
o RESV：予約済み。ゼロとして送信し、受信時に無視する必要がある4ビットのフィールド。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o トポロジーID：このフィールドにはトポロジーID [RFC5120]が含まれます。トポロジーが使用されていない場合は0になります。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent MAC addresses in this sub-TLV, or the value zero if no label is specified.
o ラベル：これは、このサブTLV内の後続のすべてのMACアドレスのきめの細かいラベル[RFC7172]識別子、またはラベルが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 6-byte (48-bit) multicast address followed by 6-byte source MAC addresses. If the sources do not fit in a single sub-TLV, the same group address may be repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、6バイト（48ビット）のマルチキャストアドレスの後に6バイトの送信元MACアドレスが続きます。ソースが単一のサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスを使用して同じグループアドレスを繰り返すことができます。
The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.
GLMAC-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV type 5 within the GADDR TLV. It has the same format as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 except that k=4. The fields are as follows:
グループラベル付きIPv4アドレス（GLIP-ADDR）サブTLVは、GADDR TLV内のIS-ISサブTLVタイプ5です。これは、セクション2.1.4で説明されているグループラベル付きMACアドレスサブTLVと同じ形式ですが、k = 4です。フィールドは次のとおりです。
o Type: sub-TLV type, set to 5 (GLIP-ADDR).
o タイプ：サブTLVタイプ、5（GLIP-ADDR）に設定。
o Length: 6 + m + k*n = 6 + m + 4*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：6 + m + k * n = 6 + m + 4 * n。ここで、mはグループレコードの数、nはグループとソースアドレスの数の合計です。
o Topology-ID: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o トポロジーID：このフィールドにはトポロジーID [RFC5120]が含まれます。トポロジーが使用されていない場合は0になります。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV：送信時にはゼロとして送信する必要があり、受信時には無視されます。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv4 addresses in this sub-TLV, or the value zero if no label is specified.
o ラベル：これは、このサブTLV内の後続のすべてのIPv4アドレスのきめの細かいラベル[RFC7172]識別子、またはラベルが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 4-byte (32-bit) IPv4 Group Address followed by 4-byte source IPv4 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、4バイト（32ビット）のIPv4グループアドレスがあり、その後に4バイトのソースIPv4アドレスが続きます。ソースの数が1つのサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスで同じグループアドレスを繰り返すことが許可されます。
The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.
GLIP-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 6 within the GADDR TLV. It has the same format as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 except that k=16. The fields are as follows:
グループラベル付きIPv6アドレス（GLIPV6-ADDR）サブTLVは、GADDR TLV内のIS-ISサブTLVタイプ6です。これは、セクション2.1.4で説明されているグループラベル付きMACアドレスサブTLVと同じ形式ですが、k = 16です。フィールドは次のとおりです。
o Type: sub-TLV type, set to 6 (GLIPV6-ADDR).
o タイプ：サブTLVタイプ、6に設定（GLIPV6-ADDR）。
o Length: 6 + m + k*n = 6 + m + 16*n, where m is the number of group records and n is the sum of the number of group and source addresses.
o 長さ：6 + m + k * n = 6 + m + 16 * n。ここで、mはグループレコードの数、nはグループとソースアドレスの数の合計です。
o Topology-Id: This field carries a topology ID [RFC5120] or zero if topologies are not in use.
o Topology-Id：このフィールドには、トポロジID [RFC5120]が含まれます。トポロジが使用されていない場合は0になります。
o RESV: Must be sent as zero on transmission and is ignored on receipt.
o RESV：送信時にはゼロとして送信する必要があり、受信時には無視されます。
o Label: This carries the fine-grained label [RFC7172] identifier for all subsequent IPv6 addresses in this sub-TLV, or the value zero if no label is specified.
o ラベル：これは、このサブTLV内の後続のすべてのIPv6アドレスのきめ細かいラベル[RFC7172]識別子、またはラベルが指定されていない場合は値0を伝送します。
o Num Group Recs: A 1-byte unsigned integer that is the number of group records in this sub-TLV.
o Num Group Recs：このサブTLVのグループレコードの数である1バイトの符号なし整数。
o GROUP RECORDS: Each group record carries the number of sources. If this field is zero, it indicates a listener for (*,G), that is, a listener not restricted by source. It then has a 16-byte (128-bit) IPv6 Group Address followed by 16-byte source IPv6 addresses. If the number of sources do not fit in a single sub-TLV, it is permitted to have the same group address repeated with different source addresses in another sub-TLV of another instance of the Group Address TLV.
o GROUP RECORDS：各グループレコードには、ソースの数が含まれます。このフィールドがゼロの場合、（*、G）のリスナー、つまりソースによって制限されていないリスナーを示します。次に、16バイト（128ビット）のIPv6グループアドレスがあり、その後に16バイトのソースIPv6アドレスが続きます。ソースの数が1つのサブTLVに収まらない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで、異なるソースアドレスで同じグループアドレスを繰り返すことが許可されます。
The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
GLIPV6-ADDRサブTLVは、GADDR TLV内でのみ実行されます。
TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT-Port-Cap-TLV) as specified in [RFC6165]. The following subsections specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL.
TRILLは、[RFC6165]で指定されているマルチトポロジ対応ポート機能TLV（MT-Port-Cap-TLV）を利用します。以下のサブセクションでは、MT-Port-Cap-TLVによってTRILL用に転送されるサブTLVを指定します。
In TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV is carried in every IIH PDU. It has the following format:
TRILLでは、すべてのIIH PDUに特別なVLANおよびフラグ（VLAN-FLAGS）サブTLVが搭載されています。次の形式があります。
+--+--+--+--+--+--+--+--+
| Type | (1 byte)
+--+--+--+--+--+--+--+--+
| Length | (1 byte)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Port ID | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Sender Nickname | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TR|R |R |R | Designated-VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV 1.
o タイプ：サブTLVタイプ、MT-Port-Cap-TLV VLAN-FLAGSサブTLV 1に設定。
o Length: 8.
o 長さ：8。
o Port ID: An ID for the port on which the enclosing TRILL IIH PDU is being sent as specified in [RFC6325], Section 4.4.2.
o ポートID：[RFC6325]のセクション4.4.2で指定されているように、外側のTRILL IIH PDUが送信されているポートのID。
o Sender Nickname: If the sending IS is holding any nicknames as discussed in [RFC6325], Section 3.7, one MUST be included here. Otherwise, the field is set to zero. This field is to support intelligent end stations that determine the egress IS (RBridge) for unicast data through a directory service or the like and that need a nickname for their first hop to insert as the ingress nickname to correctly format a TRILL Data frame (see [RFC6325], Section 4.6.2, point 8). It is also referenced in connection with the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as the egress on one-hop RBridge Channel messages [RFC7178], for example, those use for BFD over TRILL [RFC7175].
o 送信者のニックネーム：[RFC6325]のセクション3.7で説明されているように、送信側のISがニックネームを保持している場合は、ここにニックネームを1つ含める必要があります。それ以外の場合、フィールドはゼロに設定されます。このフィールドは、ディレクトリサービスなどを介してユニキャストデータの出力IS（RBridge）を決定し、最初のホップにニックネームを入力ニックネームとして挿入してTRILLデータフレームを正しくフォーマットするインテリジェントエンドステーションをサポートするためのものです（ [RFC6325]、セクション4.6.2、ポイント8）。 VLANs Appointed Sub-TLV（セクション2.2.5を参照）に関連して参照され、1ホップのRBridgeチャネルメッセージ[RFC7178]の出力として使用できます。たとえば、BFD over TRILL [RFC7175]で使用されます。 。
o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV, as specified in [RFC6325], Section 4.4.5.
o Outer.VLAN：[RFC6325]のセクション4.4.5で指定されている、このサブTLVを含むTRILL IIHフレームの12ビットの外部VLAN IDのコピー。
o Designated-VLAN: The 12-bit ID of the Designated VLAN for the link, as specified in [RFC6325], Section 4.2.4.2.
o Designated-VLAN：[RFC6325]のセクション4.2.4.2で指定されている、リンクのDesignated VLANの12ビットID。
o AF, AC, VM, BY, and TR: These flag bits have the following meanings when set to one, as specified in the listed section of [RFC6325]:
o AF、AC、VM、BY、およびTR：これらのフラグビットは、[RFC6325]のリストされたセクションで指定されているように、1に設定されている場合、次の意味を持ちます。
RFC 6325
Bit Section Meaning if bit is one
--------------------------------------
AF 4.4.2 Originating IS believes it is Appointed Forwarder for the VLAN and port on which the containing IIH PDU was sent.
AF 4.4.2発信ISは、それが含まれているIIH PDUが送信されたVLANおよびポートのAppointed Forwarderであると信じています。
AC 4.9.1 Originating port configured as an access port (TRILL traffic disabled).
AC 4.9.1アクセスポートとして構成された発信ポート（TRILLトラフィックは無効）。
VM 4.4.5 VLAN mapping detected on this link.
このリンクでVM 4.4.5 VLANマッピングが検出されました。
BY 4.4.2 Bypass pseudonode.
BY 4.4.2疑似ノードをバイパスします。
TR 4.9.1 Originating port configured as a trunk port (end-station service disabled).
TR 4.9.1トランクポートとして構成された発信元ポート（端末サービスは無効）。
o R: Reserved bit. MUST be sent as zero and ignored on receipt.
o R：予約ビット。ゼロとして送信し、受信時に無視する必要があります。
The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the port of the originating IS on which the containing Hello was sent, as specified in [RFC6325], Section 4.4.2. It has the following format:
オプションのEnabled-VLANsサブTLVは、[RFC6325]のセクション4.4.2で指定されているように、含まれているHelloが送信された元のISのポートで有効なVLANを指定します。次の形式があります。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV 2.
o タイプ：サブTLVタイプ、MT-Port-Cap-TLV Enabled-VLANs sub-TLV 2に設定。
o Length: Variable, minimum 3.
o 長さ：可変、最小3。
o RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4つの予約済みビット。
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-order bit of the first byte of the VLAN bit-map.
o 開始VLAN ID：VLANビットマップの最初のバイトの上位ビットで表される12ビットのVLAN ID。
o VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field.
o VLANビットマップ：最上位ビットは、VLANが開始VLAN IDと等しいことを示し、次に高いビットは、VLANが開始VLAN ID + 1と等しいことを示し、VLANビットマップフィールドの最後まで続きます。
If this sub-TLV occurs more than once in a Hello, the set of enabled VLANs is the union of the sets of VLANs indicated by each of the Enabled-VLAN sub-TLVs in the Hello.
このサブTLVがHello内で複数回発生する場合、有効なVLANのセットは、Hello内の各Enabled-VLANサブTLVによって示されるVLANのセットの和集合です。
The Designated RBridge (DRB) on a link uses the Appointed Forwarders sub-TLV to inform other ISs on the link that they are the designated VLAN-x forwarder for one or more ranges of VLAN IDs as specified in [RFC6439]. It has the following format:
リンク上のDesignated RBridge（DRB）はAppointed ForwardersサブTLVを使用して、リンク上の他のISに、[RFC6439]で指定されているVLAN IDの1つ以上の範囲の指定VLAN-xフォワーダーであることを通知します。次の形式があります。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each appointment is of the form:
各予定の形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV
3.
o Length: 6*n bytes, where there are n appointments.
o 長さ：6 * nバイト。n個の予定があります。
o Appointee Nickname: The nickname of the IS being appointed a forwarder.
o Appointee Nickname：フォワーダーに任命されているISのニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting both Start.VLAN and VLAN.end to the same value indicates a range of one VLAN ID. If Start.VLAN is not equal to VLAN.end and Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN was 0x001. If Start.VLAN is not equal to VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than Start.VLAN, the sub-TLV is ignored. If both Start.VLAN and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be enabled for them.
o Start.VLAN、End.VLAN：このVLAN IDの範囲は包括的です。 Start.VLANとVLAN.endの両方を同じ値に設定すると、1つのVLAN IDの範囲を示します。 Start.VLANがVLAN.endと等しくなく、Start.VLANが0x000である場合、サブTLVはStart.VLANが0x001であるかのように解釈されます。 Start.VLANがVLAN.endと等しくなく、VLAN.endが0xFFFである場合、サブTLVはVLAN.endが0xFFEであるかのように解釈されます。 VLAN.endがStart.VLANより小さい場合、サブTLVは無視されます。 Start.VLANとVLAN.endの両方が0x000または両方が0xFFFの場合、サブTLVは無視されます。値0x000または0xFFFは有効なVLAN IDではなく、ポートを有効にすることはできません。
An IS's nickname may occur as Appointed Forwarder for multiple VLAN ranges by occurrences of this sub-TLV within the same or different MT Port Capability TLVs within an IIH PDU. See [RFC6439].
ISのニックネームは、IIH PDU内の同じまたは異なるMTポート機能TLV内のこのサブTLVの出現によって、複数のVLAN範囲の指定フォワーダーとして発生する場合があります。 [RFC6439]を参照してください。
The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported and the support of optional hop-by-hop capabilities. By implication, lower versions are also supported. If this sub-TLV is missing from an IIH, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325] and supports no optional capabilities indicated by this sub-TLV.
ポートTRILLバージョン（PORT-TRILL-VER）サブTLVは、サポートされるTRILL標準の最大バージョンとオプションのホップバイホップ機能のサポートを示します。暗黙的に、下位バージョンもサポートされています。このサブTLVがIIHにない場合、元のISはプロトコル[RFC6325]のベースバージョン（バージョン0）のみをサポートし、このサブTLVが示すオプション機能をサポートしていないと想定されます。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
o Type: MT-Port-Cap-TLV sub-TLV type, set to 7 (PORT-TRILL-VER).
o タイプ：MT-Port-Cap-TLVサブTLVタイプ、7に設定（PORT-TRILL-VER）。
o Length: 5.
o 長さ：5。
o Max-version: A one-byte unsigned integer set to the maximum version supported.
o 最大バージョン：サポートされている最大バージョンに設定された1バイトの符号なし整数。
o Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 3 through 13 indicate that the corresponding TRILL Header hop-by-hop extended flags [RFC7179] are supported. Bits 0 through 2 and 14 to 31 are reserved to indicate support of optional capabilities. A one bit indicates that the flag or capability is supported by the sending IS. Bits in this field MUST be set to zero except as permitted for a capability being advertised or if a hop-by-hop extended header flag is supported.
o サポートされる機能とヘッダーフラグ：ネットワークの順序で0から31まで番号が付けられた32ビットのビットベクトル。ビット3〜13は、対応するTRILLヘッダーのホップバイホップ拡張フラグ[RFC7179]がサポートされていることを示します。ビット0〜2および14〜31は、オプション機能のサポートを示すために予約されています。 1ビットは、フラグまたは機能が送信側ISによってサポートされていることを示します。このフィールドのビットは、アドバタイズされる機能で許可されている場合、またはホップバイホップの拡張ヘッダーフラグがサポートされている場合を除いて、ゼロに設定する必要があります。
This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL IIH. If there is more than one occurrence, the minimum of the supported versions is assumed to be correct and a capability or header flag is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the TRILL-VER sub-TLV (Section 2.3.1) so they cannot conflict. The flags and capabilities indicated in this sub-TLV relate to hop-by-hop processing that can differ between the ports of an IS (RBridge) and thus must be advertised in IIHs. For example, a capability requiring cryptographic hardware assist might be supported on some ports and not others. However, the TRILL version is the same as that in the PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of TRILL version sub-TLV(s), uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s).
このサブTLVが存在する場合は、TRILL IIHのMT-Port-Cap-TLVで発生する必要があります。複数のオカレンスがある場合、サポートされるバージョンの最小値は正しいと見なされ、機能またはヘッダーフラグは、すべてのオカレンスで示される場合にのみサポートされると見なされます。このサブTLVでサポートを示すことができるフラグと機能は、TRILL-VERサブTLV（セクション2.3.1）のフラグと機能から切り離されているため、競合することはありません。このサブTLVに示されているフラグと機能は、IS（RBridge）のポート間で異なる可能性があるホップバイホップ処理に関連するため、IIHでアドバタイズする必要があります。たとえば、暗号化ハードウェアアシストを必要とする機能は、一部のポートではサポートされ、他のポートではサポートされない場合があります。ただし、TRILLのバージョンはPORT-TRILL-VERサブTLVのバージョンと同じです。 ISは、TRILLバージョンのサブTLVの送信ISに隣接している場合、PORT-TRILL-VERサブTLVで受信したTRILLバージョンをTRILL-VERサブで受信したバージョンよりも優先して使用します。 TLV。
The optional VLANs Appointed sub-TLV specifies, for the port of the originating IS on which the containing Hello was sent, the VLANs for which it is Appointed Forwarder. This sub-TLV has the following format:
オプションのVLAN Appointed sub-TLVは、含まれるHelloが送信された元のISのポートに対して、それがAppointed ForwarderであるVLANを指定します。このサブTLVの形式は次のとおりです。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV 8.
o タイプ：サブTLVタイプ、MT-Port-Cap-TLV VLANS-Appointed sub-TLV 8に設定
o Length: Variable, minimum 3.
o 長さ：可変、最小3。
o RESV: 4 reserved bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4つの予約済みビット。
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-order bit of the first byte of the VLAN bit-map.
o 開始VLAN ID：VLANビットマップの最初のバイトの上位ビットで表される12ビットのVLAN ID。
o VLAN bit-map: The highest-order bit indicates the VLAN equal to the start VLAN ID, the next highest bit indicates the VLAN equal to start VLAN ID + 1, continuing to the end of the VLAN bit-map field.
o VLANビットマップ：最上位ビットは、VLANが開始VLAN IDと等しいことを示し、次に高いビットは、VLANが開始VLAN ID + 1と等しいことを示し、VLANビットマップフィールドの最後まで続きます。
If this sub-TLV occurs more than once in a Hello, the originating IS is declaring that it believes itself to be Appointed Forwarder on the port on which the enclosing IIH was sent for the union of the sets of VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.
このサブTLVがHelloで2回以上発生する場合、元のISは、それが自身を、各VLANによって示されるVLANのセットのユニオンに対して送信されたIIHが送信されたポート上のAppointed Forwarderであると信じていることを宣言しています。 -Helloで指定されたサブTLV。
The Router Capability TLV is specified in [RFC4971] and the MT-Capability TLV in [RFC6329]. All of the following sub-sections specify sub-TLVs that can be carried in the Router Capability TLV (#242) and the MT-Capability TLV (#144) with the same sub-TLV number for both TLVs. These TLVs are in turn carried only by LSPs.
ルーター機能TLVは[RFC4971]で、MT機能TLVは[RFC6329]で指定されています。以下のすべてのサブセクションでは、ルーター機能TLV（＃242）およびMT機能TLV（＃144）で伝送できるサブTLVを、両方のTLVに同じサブTLV番号で指定しています。これらのTLVは、LSPによってのみ伝送されます。
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported and the support of optional capabilities by the originating IS. By implication, lower versions are also supported. If this sub-TLV is missing, it is assumed that the originating IS only supports the base version (version zero) of the protocol [RFC6325], and no optional capabilities indicated by this sub-TLV are supported.
TRILLバージョン（TRILL-VER）サブTLVは、サポートされるTRILL標準の最大バージョンと、元のISによるオプション機能のサポートを示します。暗黙的に、下位バージョンもサポートされています。このサブTLVがない場合、元のISはプロトコル[RFC6325]のベースバージョン（バージョン0）のみをサポートし、このサブTLVが示すオプション機能はサポートされていないと見なされます。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).
o タイプ：ルーター機能サブTLVタイプ、13（TRILL-VER）に設定。
o Length: 5.
o 長さ：5。
o Max-version: A one-byte unsigned integer set to the maximum version supported.
o 最大バージョン：サポートされている最大バージョンに設定された1バイトの符号なし整数。
o Capabilities and Header Flags Supported: A bit vector of 32 bits numbered 0 through 31 in network order. Bits 14 through 31 indicate that the corresponding TRILL Header extended flags [RFC7179] are supported. Bits 0 through 13 are reserved to indicate support of optional capabilities. A one bit indicates that the originating IS supports the flag or capability. For example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in this field MUST be set to zero except as permitted for a capability being advertised or an extended header flag supported.
o サポートされる機能とヘッダーフラグ：ネットワークの順序で0から31まで番号が付けられた32ビットのビットベクトル。ビット14〜31は、対応するTRILLヘッダー拡張フラグ[RFC7179]がサポートされていることを示します。ビット0〜13は、オプション機能のサポートを示すために予約されています。 1ビットは、元のISがフラグまたは機能をサポートしていることを示します。たとえば、マルチレベルTRILL IS-IS [MultiLevel]のサポート。このフィールドのビットは、アドバタイズされる機能またはサポートされる拡張ヘッダーフラグで許可されている場合を除いて、ゼロに設定する必要があります。
This sub-TLV, if present in a Router Capability TLV, MUST occur in the LSP number zero for the originating IS. If found in a Router Capability TLV in other fragments, it is ignored. If there is more than one occurrence in LSP number zero, the minimum of the supported versions is assumed to be correct, and an extended header flag or capability is assumed to be supported only if indicated by all occurrences. The flags and capabilities for which support can be indicated in this sub-TLV are disjoint from those in the PORT-TRILL-VER sub-TLV (Section 2.2.4) so they cannot conflict. However, the
このサブTLVは、ルーター機能TLVに存在する場合、発信ISのLSP番号0で発生する必要があります。他のフラグメントのルーター機能TLVで見つかった場合、それは無視されます。 LSP番号0に複数のオカレンスがある場合、サポートされるバージョンの最小は正しいと見なされ、拡張ヘッダーフラグまたは機能は、すべてのオカレンスによって示される場合にのみサポートされると見なされます。このサブTLVでサポートを示すことができるフラグと機能は、PORT-TRILL-VERサブTLV（セクション2.2.4）のそれらから切り離されているため、競合することはありません。しかし
TRILL version is the same as that in the PORT-TRILL-VER sub-TLV, and an IS that is adjacent to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-TLV(s).
TRILLのバージョンはPORT-TRILL-VERサブTLVのバージョンと同じであり、TRILL-VERサブTLVの元のISに隣接するISは、PORT-TRILL-VERで受け取ったTRILLバージョンを使用します。 TRILL-VERサブTLVで受信したものよりも優先されるサブTLV。
For multi-topology-aware TRILL Switches, the TRILL version and capabilities announced for the base topology are assumed to apply to all topologies for which a separate TRILL version announcement does not occur in an MT-Capability TLV. Such announcements for non-zero topologies need not occur in fragment zero.
マルチトポロジ対応のTRILLスイッチの場合、基本トポロジに対して発表されたTRILLバージョンと機能は、MT機能TLVで個別のTRILLバージョンの発表が行われないすべてのトポロジに適用されると想定されます。ゼロ以外のトポロジに対するこのようなアナウンスは、フラグメントゼロで発生する必要はありません。
The Nickname (NICKNAME) Router Capability sub-TLV carries information about the nicknames of the originating IS, along with information about its priority to hold those nicknames and the priority for each nickname to be a tree root as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may occur.
ニックネーム（NICKNAME）ルーター機能サブTLVは、元のISのニックネームに関する情報と、それらのニックネームを保持するための優先度、および[RFC6325]のセクション3.7で指定されているように、ツリールートとなる各ニックネームの優先度に関する情報を運ぶ.3。このサブTLVの複数のインスタンスが発生する可能性があります。
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each nickname record is of the form:
各ニックネームレコードの形式は次のとおりです。
+-+-+-+-+-+-+-+-+
| Nickname.Pri | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 6 (NICKNAME).
o タイプ：ルーター機能とMT機能のサブTLVタイプ。6（NICKNAME）に設定。
o Length: 5*n, where n is the number of nickname records present.
o 長さ：5 * n、ここでnは存在するニックネームレコードの数です。
o Nickname.Pri: An 8-bit unsigned integer priority to hold a nickname as specified in Section 3.7.3 of [RFC6325].
o Nickname.Pri：[RFC6325]のセクション3.7.3で指定されているニックネームを保持するための8ビットの符号なし整数の優先度。
o Tree Root Priority: This is an unsigned 16-bit integer priority to be a tree root as specified in Section 4.5 of [RFC6325].
o ツリールートの優先度：これは、[RFC6325]のセクション4.5で指定されているように、ツリールートとなる符号なし16ビット整数の優先度です。
o Nickname: This is an unsigned 16-bit integer as specified in Section 3.7 of [RFC6325].
o ニックネーム：これは、[RFC6325]のセクション3.7で指定されている符号なし16ビット整数です。
Each IS providing TRILL service uses the TREES sub-TLV to announce three numbers related to the computation of distribution trees as specified in Section 4.5 of [RFC6325]. Its format is as follows:
[RFC6325]のセクション4.5で指定されているように、TRILLサービスを提供する各ISは、TREESサブTLVを使用して、分布ツリーの計算に関連する3つの数値を発表します。その形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 7 (TREES).
o タイプ：ルーター機能とMT機能サブTLVタイプ。7（TREES）に設定。
o Length: 6.
o 長さ：6。
o Number of trees to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 計算するツリーの数：[RFC6325]のセクション4.5で指定されている符号なし16ビット整数。
o Maximum trees able to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 計算できる最大ツリー：[RFC6325]のセクション4.5で指定されている符号なし16ビット整数。
o Number of trees to use: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].
o 使用するツリーの数：[RFC6325]のセクション4.5で指定されている符号なし16ビット整数。
The Tree Identifiers (TREE-RT-IDs) sub-TLV is an ordered list of nicknames. When originated by the IS that has the highest priority to be a tree root, it lists the distribution trees that the other ISs are required to compute as specified in Section 4.5 of [RFC6325]. If this information is spread across multiple sub-TLVs, the starting tree number is used to allow the ordered lists to be correctly concatenated. The sub-TLV format is as follows:
ツリー識別子（TREE-RT-ID）サブTLVは、ニックネームの順序付きリストです。ツリールートになるために最も優先度の高いISから発信された場合、[RFC6325]のセクション4.5で指定されているように、他のISが計算する必要がある配布ツリーがリストされます。この情報が複数のサブTLVに分散している場合は、開始ツリー番号を使用して、順序付きリストを正しく連結できます。サブTLV形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 8 (TREE-RT-IDs).
o タイプ：ルーター機能およびMT機能サブTLVタイプ、8（TREE-RT-ID）に設定。
o Length: 2 + 2*n, where n is the number of nicknames listed.
o 長さ：2 + 2 *n。nはリストされたニックネームの数です。
o Starting Tree Number: This identifies the starting tree number of the nicknames that are trees for the domain. This is set to 1 for the sub-TLV containing the first list. Other Tree-Identifiers sub-TLVs will have the number of the starting list they contain. In the event the same tree identifier can be computed from two such sub-TLVs and they are different, then it is assumed that this is a transient condition that will get cleared. During this transient time, such a tree SHOULD NOT be computed unless such computation is indicated by all relevant sub-TLVs present.
o 開始ツリー番号：これは、ドメインのツリーであるニックネームの開始ツリー番号を識別します。これは、最初のリストを含むサブTLVに対して1に設定されます。他のツリー識別子サブTLVには、それらに含まれる開始リストの番号が含まれます。同じツリー識別子が2つのそのようなサブTLVから計算でき、それらが異なる場合、これはクリアされる一時的な状態であると想定されます。この一時的な時間の間、そのようなツリーは、そのような計算が存在するすべての関連するサブTLVによって示されない限り、計算されるべきではありません（SHOULD NOT）。
o Nickname: The nickname at which a distribution tree is rooted.
o ニックネーム：配布ツリーのルートとなるニックネーム。
This Router Capability sub-TLV has the same structure as the Tree Identifiers sub-TLV specified in Section 2.3.4. The only difference is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees listed are those that the originating IS wishes to use as specified in [RFC6325], Section 4.5.
このルーター機能サブTLVは、セクション2.3.4で指定されたツリー識別子サブTLVと同じ構造です。唯一の違いは、サブTLVタイプが9（TREE-USE-ID）に設定されていること、およびリストされているツリーは、[RFC6325]のセクション4.5で指定されているように、元のISが使用したいツリーであることです。
The value of this sub-TLV consists of a VLAN range and information in common to all of the VLANs in the range for the originating IS. This information consists of flags, a variable length list of spanning tree root bridge IDs, and an Appointed Forwarder status lost counter, all as specified in the sections of [RFC6325] listed with the respective information items below.
このサブTLVの値は、VLAN範囲と、元のISの範囲内のすべてのVLANに共通の情報で構成されます。この情報は、フラグ、スパニングツリールートブリッジIDの可変長リスト、およびAppointed Forwarderステータスロストカウンターで構成されます。これらはすべて、[RFC6325]のセクションで指定されており、以下の各情報項目とともにリストされています。
In the set of LSPs originated by an IS, the union of the VLAN ranges in all occurrences of this sub-TLV MUST be the set of VLANs for which the originating IS is Appointed Forwarder on at least one port, and the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap unless the information provided about a VLAN is the same in every instance. However, as a transient state, these conditions may be violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, that IS is assumed to be uninterested in receiving traffic for that VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS with different information in the different instances, the following apply:
ISによって発信されたLSPのセットでは、このサブTLVのすべてのオカレンスのVLAN範囲の和集合は、発信元のISが少なくとも1つのポートで指定されたフォワーダーであるVLANのセットであり、VLAN範囲は複数のISのVLANサブTLVは、VLANについて提供される情報がすべてのインスタンスで同じでない限り、重複してはなりません（MUST NOT）。ただし、一時的な状態として、これらの条件に違反する可能性があります。 ISのINT-VLANサブTLVにVLANがリストされていない場合、そのISはそのVLANのトラフィックの受信に関心がないと見なされます。 1つのVLANがISの複数のINT-VLANサブTLVに出現し、インスタンスごとに情報が異なる場合は、以下が適用されます。
- If those sub-TLVs provide different nicknames, it is unspecified which nickname takes precedence. - The largest Appointed Forwarder status lost counter, using serial number arithmetic [RFC1982], is used. - The originating IS is assumed to be attached to a multicast IPv4 router for that VLAN if any of the INT-VLAN sub-TLVs assert that it is so connected and similarly for IPv6 multicast router attachment. - The root bridge lists from all of the instances of the VLAN for the originating IS are merged.
- それらのサブTLVが異なるニックネームを提供する場合、どのニックネームが優先されるかは指定されていません。 -シリアル番号演算[RFC1982]を使用した最大のAppointed Forwarderステータスロストカウンターが使用されます。 -元のISは、INT-VLANサブTLVのいずれかがそのように接続されていると断言した場合、そのVLANのマルチキャストIPv4ルーターに接続されていると見なされ、IPv6マルチキャストルーター接続の場合も同様です。 -元のISのVLANのすべてのインスタンスからのルートブリッジリストがマージされます。
To minimize such occurrences, wherever possible, an implementation SHOULD advertise the update to an interested VLAN and Spanning Tree Roots sub-TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action. An IS that receives an update to an existing interested VLAN and Spanning Tree Roots sub-TLV can minimize the potential disruption associated with the update by employing a hold-down timer prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
そのような発生を最小限に抑えるために、実装は、可能なアドバタイズメントと同じLSPフラグメント内の関係するVLANおよびスパニングツリールートサブTLVに更新をアドバタイズする必要があります（SHOULD）。これが不可能な場合は、影響を受ける2つのLSPフラグメントをアトミックアクションとしてフラッディングする必要があります。既存の関心のあるVLANおよびスパニングツリールートサブTLVの更新を受信するISは、更新を処理する前にホールドダウンタイマーを使用して、複数のLSPフラグメントの受信を可能にすることにより、更新に関連する潜在的な混乱を最小限に抑えることができます。処理を開始する前に同じ更新に関連付けられています。
The sub-TLV layout is as follows:
サブTLVレイアウトは次のとおりです。
+-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 10 (INT-VLAN).
o タイプ：ルーター機能およびMT機能サブTLVタイプ、10（INT-VLAN）に設定。
o Length: 10 + 6*n, where n is the number of root bridge IDs.
o 長さ：10 + 6 *n。nはルートブリッジIDの数です。
o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field may be used to associate a nickname held by the originating IS with the VLAN range indicated. When not used in this way, it is set to zero.
o ニックネーム：[RFC6325]のセクション4.2.4.4で指定されているように、このフィールドを使用して、元のISが保持するニックネームを、指定されたVLAN範囲に関連付けることができます。この方法で使用しない場合は、ゼロに設定されます。
o Interested VLANS: The Interested VLANs field is formatted as shown below.
o 関係するVLAN：関係するVLANフィールドは、以下のようにフォーマットされます。
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+
- M4, M6: These bits indicate, respectively, that there is an IPv4 or IPv6 multicast router on a link for which the originating IS is Appointed Forwarder for every VLAN in the indicated range as specified in [RFC6325], Section 4.2.4.4, item 5.1.
- M4、M6：これらのビットはそれぞれ、[RFC6325]のセクション4.2.4.4で指定されている範囲内のすべてのVLANについて、発信元ISがAppointed ForwarderであるリンクにIPv4またはIPv6マルチキャストルーターがあることを示します。 5.1。
- R, RESV: These reserved bits MUST be sent as zero and are ignored on receipt.
- R、RESV：これらの予約ビットはゼロとして送信する必要があり、受信時に無視されます。
- VLAN.start and VLAN.end: This VLAN ID range is inclusive. Setting both VLAN.start and VLAN.end to the same value indicates a range of one VLAN ID. If VLAN.start is not equal to VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be enabled for them.
-VLAN.startおよびVLAN.end：このVLAN IDの範囲は包括的です。 VLAN.startとVLAN.endの両方を同じ値に設定すると、1つのVLAN IDの範囲を示します。 VLAN.startがVLAN.endと等しくなく、VLAN.startが0x000である場合、サブTLVはVLAN.startが0x001であるかのように解釈されます。 VLAN.startがVLAN.endと等しくなく、VLAN.endが0xFFFである場合、サブTLVはVLAN.endが0xFFEであるかのように解釈されます。 VLAN.endがVLAN.startより小さい場合、サブTLVは無視されます。 VLAN.startとVLAN.endの両方が0x000または両方が0xFFFの場合、サブTLVは無視されます。値0x000または0xFFFは有効なVLAN IDではなく、ポートを有効にすることはできません。
o Appointed Forwarder Status Lost Counter: This is a count of how many times a port that was Appointed Forwarder for the VLANs in the range given has lost the status of being an Appointed Forwarder for some port as discussed in Section 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the zeroth LSP sequence number is initialized. No special action need be taken at rollover; the counter just wraps around.
o Appointed Forwarder Status Lost Counter：これは、[RFC6325]のセクション4.8.3で説明されているように、指定された範囲のVLANのAppointed Forwarderであったポートが、一部のポートのAppointed Forwarderのステータスを失った回数のカウントです。 。 0番目のLSPシーケンス番号が初期化されると、ISでゼロに初期化されます。ロールオーバー時に特別なアクションを実行する必要はありません。カウンターはぐるぐる回っています。
o Root Bridges: The list of zero or more spanning tree root bridge IDs is the set of root bridge IDs seen for all ports for which the IS is Appointed Forwarder for the VLANs in the specified range as discussed in [RFC6325], Section 4.9.3.2. While, of course, at most one spanning tree root could be seen on any particular port, there may be multiple ports in the same VLANs connected to different bridged LANs with different spanning tree roots.
o ルートブリッジ：0個以上のスパニングツリールートブリッジIDのリストは、[RFC6325]のセクション4.9.3.2で説明されているように、指定された範囲のVLANに対してISが指定されたフォワーダーであるすべてのポートに表示されるルートブリッジIDのセットです。 。もちろん、特定のポートで最大1つのスパニングツリールートが表示される場合がありますが、同じVLAN内に複数のポートがあり、異なるスパニングツリールートを持つ異なるブリッジLANに接続されている場合があります。
An INT-VLAN sub-TLV asserts that the information provided (multicast router attachment, Appointed Forwarder status lost counter, and root bridges) is the same for all VLANs in the range specified. If this is not the case, the range MUST be split into subranges meeting this criteria. It is always safe to use sub-TLVs with a "range" of one VLAN ID, but this may be too verbose.
INT-VLANサブTLVは、提供された情報（マルチキャストルーターアタッチメント、Appointed Forwarderステータスロストカウンター、およびルートブリッジ）が、指定された範囲内のすべてのVLANで同じであることを表明します。そうでない場合、範囲はこの基準を満たすサブ範囲に分割する必要があります。 1つのVLAN IDの「範囲」でサブTLVを使用することは常に安全ですが、これは冗長すぎる場合があります。
The VLAN Group sub-TLV consists of two or more VLAN IDs as specified in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN learning is occurring at the originating IS between the listed VLANs. It is structured as follows:
[RFC6325]のセクション4.8.4で指定されているように、VLANグループサブTLVは2つ以上のVLAN IDで構成されています。このサブTLVは、リストされたVLAN間の発信ISで共有VLAN学習が行われていることを示しています。次のように構成されています。
+-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 14
(VLAN-GROUP).
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero.
o 長さ：4 + 2 * n。ここで、nは最初のものを超えるセカンダリVLAN IDフィールドの数です。 nはゼロでもかまいません。
o RESV: a 4-bit field that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある4ビットのフィールド。
o Primary VLAN ID: This identifies the primary VLAN ID.
o プライマリVLAN ID：プライマリVLAN IDを識別します。
o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN Group.
o セカンダリVLAN ID：これは、VLANグループ内のセカンダリVLANを識別します。
o more Secondary VLAN IDs: zero or more byte pairs, each with the top 4 bits as a RESV field and the low 12 bits as a VLAN ID.
o セカンダリVLAN IDの増加：ゼロ以上のバイトペア。それぞれ上位4ビットがRESVフィールドとして、下位12ビットがVLAN IDとして使用されます。
An IS that can handle fine-grained labeling [RFC7172] announces its fine-grained label connectivity and related information in the Interested Labels and Spanning Tree Roots sub-TLV (INT-LABEL). It is a variation of the Interested VLANs and Spanning Tree Roots sub-TLV (INT-VLAN) and is structured as follows.
きめ細かいラベル付けを処理できるIS [RFC7172]は、きめ細かいラベル接続と関連情報をInterests Labels and Spanning Tree RootsサブTLV（INT-LABEL）で発表します。これは、関係するVLANおよびスパニングツリールートのサブTLV（INT-VLAN）のバリエーションであり、次のように構成されています。
+-+-+-+-+-+-+-+-+
|Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 15 (INT-LABEL).
o タイプ：ルーター機能およびMT機能サブTLVタイプ、15（INT-LABEL）に設定。
o Length: 11 + 6*n, where n is the number of root bridge IDs.
o 長さ：11 + 6 *n。nはルートブリッジIDの数です。
o Nickname: This field may be used to associate a nickname held by the originating IS with the Interested Labels indicated. When not used in this way, it is set to zero.
o ニックネーム：このフィールドを使用して、元のISが保持するニックネームを、示された興味のあるラベルに関連付けることができます。この方法で使用しない場合は、ゼロに設定されます。
o Interested Labels: The Interested Labels field is seven bytes long and formatted as shown below.
o Interest Labels：Interest Labelsフィールドは7バイト長で、以下のようにフォーマットされています。
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- M4, M6: These bits indicate, respectively, that there is an IPv4 or IPv6 multicast router on a link to which the originating IS is Appointed Forwarder for the VLAN corresponding to every label in the indicated range.
- M4、M6：これらのビットはそれぞれ、指定された範囲のすべてのラベルに対応するVLANの発信元ISがAppointed ForwarderであるリンクにIPv4またはIPv6マルチキャストルーターがあることを示します。
- BM: If the BM (bit-map) bit is zero, the last three bytes of the Interested Labels is a Label.end label number. If the BM bit is one, those bytes are a bit-map as described below.
- BM：BM（ビットマップ）ビットがゼロの場合、対象ラベルの最後の3バイトはLabel.endラベル番号です。 BMビットが1の場合、これらのバイトは、以下で説明するビットマップです。
- R: These reserved bits MUST be sent as zero and are ignored on receipt.
- R：これらの予約済みビットはゼロとして送信する必要があり、受信時には無視されます。
- Label.start and Label.end: If the BM bit is zero, this fine-grained label [RFC7172] ID range is inclusive. These fields are treated as unsigned integers. Setting them both to the same label ID value indicates a range of one label ID. If Label.end is less than Label.start, the sub-TLV is ignored.
- Label.startおよびLabel.end：BMビットがゼロの場合、この細かいラベル[RFC7172] IDの範囲は包括的です。これらのフィールドは、符号なし整数として扱われます。両方を同じラベルID値に設定すると、1つのラベルIDの範囲を示します。 Label.endがLabel.startより小さい場合、サブTLVは無視されます。
- Label.start and bit-map: If the BM bit is one, the fine-grained labels that the IS is interested in are indicated by a 24-bit bit-map. The interested labels are the Label.start number plus the bit number of each one bit in the bit-map. So, if bit zero of the bit-map is a one, the IS is interested in the label with value Label.start, and if bit 23 of the bit-map is a one, the IS is interested in the label with value Label.start+23.
- Label.startとビットマップ：BMビットが1の場合、ISが関心のある細かいラベルは24ビットのビットマップで示されます。関係するラベルは、Label.start番号とビットマップ内の各1ビットのビット番号です。したがって、ビットマップのビット0が1の場合、ISは値Label.startのラベルに関心があり、ビットマップのビット23が1の場合、ISは値Labelのラベルに関心があります。 .start + 23。
o Appointed Forwarder Status Lost Counter: This is a count of how many times a port that was Appointed Forwarder for a VLAN mapping to the fine-grained label in the range or bit-map given has lost the status of being an Appointed Forwarder as discussed in Section 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the zeroth LSP sequence number is initialized. No special action need be taken at rollover; the counter just wraps around.
o Appointed Forwarder Status Lost Counter：これは、指定された範囲またはビットマップ内のファイングレインラベルへのVLANマッピングに対してAppointed Forwarderであったポートが、Appointed Forwarderであるというステータスを失った回数のカウントです。 [RFC6325]のセクション4.8.3。 0番目のLSPシーケンス番号が初期化されると、ISでゼロに初期化されます。ロールオーバー時に特別なアクションを実行する必要はありません。カウンターはぐるぐる回っています。
o Root Bridges: The list of zero or more spanning tree root bridge IDs is the set of root bridge IDs seen for all ports for which the IS is Appointed Forwarder for a VLAN mapping to the fine-grained label in the specified range or bit-map. (See [RFC6325], Section 4.9.3.2.) While, of course, at most one spanning tree root could be seen on any particular port, there may be multiple relevant ports connected to different bridged LANs with different spanning tree roots.
o ルートブリッジ：0個以上のスパニングツリールートブリッジIDのリストは、指定された範囲またはビットマップの細かいラベルへのVLANマッピングのためにISがAppointed Forwarderであるすべてのポートに表示されるルートブリッジIDのセットです。 。 （[RFC6325]のセクション4.9.3.2を参照してください。）もちろん、最大1つのスパニングツリールートが特定のポートに表示される可能性がありますが、異なるスパニングツリールートを持つ異なるブリッジLANに接続された複数の関連ポートがある場合があります。
An INT-LABEL sub-TLV asserts that the information provided (multicast router attachment, Appointed Forwarder status lost counter, and root bridges) is the same for all labels specified. If this is not the case, the sub-TLV MUST be split into subranges and/or separate bit maps meeting this criteria. It is always safe to use sub-TLVs with a "range" of one VLAN ID, but this may be too verbose.
INT-LABELサブTLVは、指定されたすべてのラベルについて、提供された情報（マルチキャストルーターアタッチメント、Appointed Forwarderステータスロストカウンター、およびルートブリッジ）が同じであることを表明します。これが当てはまらない場合、サブTLVは、この基準を満たすサブ範囲および/または個別のビットマップに分割する必要があります。 1つのVLAN IDの「範囲」でサブTLVを使用することは常に安全ですが、これは冗長すぎる場合があります。
An IS announces the RBridge Channel protocols [RFC7178] it supports through use of this sub-TLV.
ISは、このサブTLVを使用してサポートするRBridge Channelプロトコル[RFC7178]を発表します。
+-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Zero or more bit vectors (variable)
+-+-+-+-...
o Type: Router Capability and MT-Capability RBridge Channel Protocols sub-TLV, set to 16 (RBCHANNELS).
o タイプ：ルーター機能およびMT機能RBridgeチャネルプロトコルサブTLV、16（RBCHANNELS）に設定。
o Length: variable.
o 長さ：可変。
o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit indicates support of a particular RBridge Channel protocol. Each byte-aligned bit vector is formatted as follows:
o ビット・ベクトル：1ビットが特定のRBridgeチャネル・プロトコルのサポートを示す、ゼロ以上のバイト境界のビット・ベクトル。各バイト境界のビットベクトルは次のようにフォーマットされます。
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits
+--+--+--...
The Bit Vector Length (BVL) is a seven-bit unsigned integer field giving the number of bytes of bit vector. The Bit Vector Offset (BVO) is a nine-bit unsigned integer field.
ビットベクトル長（BVL）は、ビットベクトルのバイト数を示す7ビットの符号なし整数フィールドです。ビットベクトルオフセット（BVO）は、9ビットの符号なし整数フィールドです。
The bits in each bit vector are numbered in network order, the high-order bit of the first byte of bits being bit 0 + 8*BVO, the low-order bit of that byte being 7 + 8*BVO, the high order bit of the second byte being 8 + 8*BVO, and so on for BVL bytes. A bit vector of RBridge Channel protocols supported MUST NOT extend beyond the end of the value in the sub-TLV in which it occurs. If it does, it is ignored. If multiple byte-aligned bit vectors are present in one such sub-TLV, their representations are contiguous, the BVL field for the next starting immediately after the last byte of bits for the previous bit vector. The one or more bit vectors present MUST exactly fill the sub-TLV value. If there are one or two bytes of value left over, they are ignored; if more than two, an attempt is made to parse them as one or more bit vectors.
各ビットベクトルのビットはネットワーク順に番号が付けられており、ビットの最初のバイトの上位ビットはビット0 + 8 * BVO、そのバイトの下位ビットは7 + 8 * BVO、上位ビットです。 2番目のバイトは8 + 8 * BVOであり、BVLバイトの場合も同様です。サポートされるRBridgeチャネルプロトコルのビットベクトルは、それが発生するサブTLVの値の終わりを超えてはなりません（MUST NOT）。存在する場合は無視されます。そのような1つのサブTLVに複数のバイト境界のビットベクトルが存在する場合、それらの表現は連続しています。次のBVLフィールドは、前のビットベクトルのビットの最後のバイトの直後から始まります。存在する1つ以上のビットベクトルは、サブTLV値を正確に埋める必要があります。 1バイトまたは2バイトの値が残っている場合、それらは無視されます。 3つ以上の場合、それらを1つ以上のビットベクトルとして解析しようとします。
If different bit vectors overlap in the protocol number space they refer to and they have inconsistent bit values for a channel protocol, support for the protocol is assumed if any of these bit vectors has a 1 for that protocol.
異なるビットベクトルが参照するプロトコル番号空間で重複し、それらがチャネルプロトコルに対して一貫性のないビット値を持っている場合、これらのビットベクトルのいずれかにそのプロトコルの1がある場合、プロトコルのサポートが想定されます。
The absence of any occurrences of this sub-TLV in the LSP for an IS implies that the IS does not support the RBridge Channel facility. To avoid wasted space, trailing bit vector zero bytes SHOULD be eliminated by reducing BVL, any null bit vectors (ones with BVL equal to zero) eliminated, and generally the most compact encoding used. For example, support for channel protocols 1 and 32 could be encoded as
ISのLSPでこのサブTLVが発生しないことは、ISがRBridge Channel機能をサポートしていないことを意味します。無駄なスペースを避けるために、BVLを減らすことで後続のビットベクトルゼロバイトを削除し（SHOULD）、ヌルビットベクトル（BVLがゼロに等しいもの）を削除し、一般的に最もコンパクトなエンコーディングを使用します。たとえば、チャネルプロトコル1および32のサポートは、次のようにエンコードできます。
BVL = 5 BVO = 0 0b01000000 0b00000000 0b00000000 0b00000000 0b10000000
BVL = 5 GFA = 0 0b01000000 0b00000000 0b00000000 0b00000000 0b10000000
or as
またはとして
BVL = 1 BVO = 0 0b01000000 BLV = 1 BVO = 4 0b1000000
BVL = 1 GFA = 0 0b01000000 BLV = 1 GFA = 4 0b1000000
The first takes 7 bytes while the second takes only 6; thus, the second would be preferred.
最初のバイトは7バイト、2番目のバイトは6バイトです。したがって、2番目が好ましいでしょう。
In multi-topology-aware RBridges, RBridge Channel protocols for which support is announced in the base topology are assumed to be supported in all topologies for which there is no separate announcement for RBridge Channel protocol support.
マルチトポロジ対応のRBridgeでは、ベーストポロジでサポートがアナウンスされるRBridgeチャネルプロトコルは、RBridgeチャネルプロトコルのサポートに関する個別のアナウンスがないすべてのトポロジでサポートされると想定されます。
Association of an IS to a multi-destination distribution tree through a specific path is accomplished by using the Affinity sub-TLV. The announcement of an Affinity sub-TLV by RB1 with the nickname of RB2 as the first part of an Affinity Record in the sub-TLV value is a request by RB1 that all ISs in the campus connect RB2 as a child of RB1 when calculating any of the trees listed in that Affinity Record. Examples of use include [Affinity] and [Resilient].
ISを特定のパスを介して複数の宛先の配布ツリーに関連付けるには、アフィニティサブTLVを使用します。サブTLV値のアフィニティレコードの最初の部分としてRB2のニックネームを持つRB1によるアフィニティサブTLVのアナウンスは、キャンパス内のすべてのISがRB1の子としてRB2を接続することをRB1の子として接続するというRB1による要求ですそのアフィニティレコードにリストされているツリーの。使用例としては「アフィニティ」「レジリエント」などがあります。
The structure of the Affinity sub-TLV is shown below.
AffinityサブTLVの構造を以下に示します。
+-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each AFFINITY RECORD is structured as follows:
各AFFINITY RECORDは次のように構成されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 17
(AFFINITY).
o Length: size of all Affinity Records included, where an Affinity Record listing n tree roots is 4+2*n bytes long.
o 長さ：含まれるすべてのアフィニティレコードのサイズ。n個のツリールートをリストするアフィニティレコードは4 + 2 * nバイトの長さです。
o Nickname: 16-bit nickname of the IS whose associations to the multi-destination trees listed in the Affinity Record are through the originating IS.
o ニックネーム：アフィニティレコードにリストされているマルチ宛先ツリーへの関連付けが元のISを介しているISの16ビットのニックネーム。
o Affinity Flags: 8 bits reserved for future needs to provide additional information about the affinity being announced. MUST be sent as zero and ignored on receipt.
o アフィニティフラグ：8ビットは、アナウンスされるアフィニティに関する追加情報を提供するために将来の必要性のために予約されています。ゼロとして送信し、受信時に無視する必要があります。
o Number of trees: A one-byte unsigned integer giving the number of trees for which affinity is being announced by this Affinity Record.
o ツリーの数：このアフィニティレコードによってアフィニティがアナウンスされているツリーの数を示す1バイトの符号なし整数。
o Tree-num of roots: The tree numbers of the distribution trees this Affinity Record is announcing.
o ルートのツリー番号：このアフィニティレコードが発表している配布ツリーのツリー番号。
There is no need for a field giving the number of Affinity Records as this can be determined by processing those records.
アフィニティレコードの数を指定するフィールドは必要ありません。これは、これらのレコードを処理することによって決定できるためです。
The Label Group sub-TLV consists of two or more fine-grained label [RFC7172] IDs. This sub-TLV indicates that shared label MAC address learning is occurring at the announcing IS between the listed labels. It is structured as follows:
ラベルグループサブTLVは、2つ以上のきめの細かいラベル[RFC7172] IDで構成されます。このサブTLVは、リストされたラベル間の通知ISで共有ラベルMACアドレスラーニングが発生していることを示しています。次のように構成されています。
+-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 18 (LABEL-GROUP).
o タイプ：ルーター機能およびMT機能サブTLVタイプ、18（LABEL-GROUP）に設定。
o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields beyond the first. n MAY be zero.
o 長さ：6 + 3 * n、ここでnは最初のものを超えるセカンダリVLAN IDフィールドの数です。 nはゼロでもかまいません。
o Primary Label ID: This identifies the primary Label ID.
o プライマリラベルID：プライマリラベルIDを識別します。
o Secondary Label ID: This identifies a secondary Label ID in the Label Group.
o セカンダリラベルID：ラベルグループのセカンダリラベルIDを識別します。
o more Secondary Label IDs: zero or more byte triples, each with a Label ID.
o セカンダリラベルIDの数：ゼロまたはそれ以上のバイトトリプル。それぞれにラベルIDが付いています。
The MTU sub-TLV is used to optionally announce the MTU of a link as specified in [RFC6325], Section 4.2.4.4. It occurs within the Extended Reachability (#22) and MT-ISN (Intermediate System Neighbors) (#222) TLVs.
MTUサブTLVは、[RFC6325]のセクション4.2.4.4で指定されているリンクのMTUをオプションでアナウンスするために使用されます。これは、拡張到達可能性（＃22）およびMT-ISN（中間システムネイバー）（＃222）TLV内で発生します。
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability and MT-ISN sub-TLV type, set to MTU sub-TLV 28.
o タイプ：拡張到達可能性およびMT-ISNサブTLVタイプ、MTUサブTLV 28に設定。
o Length: 3.
o 長さ：3。
o F: Failed. This bit is a one if MTU testing failed on this link at the required campus-wide MTU.
o F：失敗しました。必要なキャンパス全体のMTUでこのリンクのMTUテストが失敗した場合、このビットは1です。
o RESV: 7 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受信時に無視する必要がある7ビット。
o MTU: This field is set to the largest successfully tested MTU size for this link or zero if it has not been tested, as specified in Section 4.3.2 of [RFC6325].
o MTU：[RFC6325]のセクション4.3.2で指定されているように、このフィールドは、このリンクの正常にテストされた最大のMTUサイズ、またはテストされていない場合はゼロに設定されます。
The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see Section 4.1 below) in place of the IS Neighbor TLV, as specified in Section 4.4.2.1 of [RFC6325] and in [RFC7177]. The structure of the TRILL Neighbor TLV is as follows:
[RFC6325]のセクション4.4.2.1と[RFC7177]で指定されているように、TRILLネイバーTLVは、ISネイバーTLVの代わりにTRILLブロードキャストリンクIIH PDU（セクション4.1を参照）で使用されます。 TRILL Neighbor TLVの構造は次のとおりです。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information present for each neighbor is as follows:
各ネイバーに存在する情報は次のとおりです。
+-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
o Type: TLV type, set to TRILL Neighbor TLV 145.
o タイプ：TLVタイプ。TRILLNeighbor TLV 145に設定します。
o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records, which may be zero.
o 長さ：1 +（SIZE + 3）* n。ここで、nは隣接するレコードの数であり、ゼロの場合もあります。
o S: Smallest flag. If this bit is a one, then the list of neighbors includes the neighbor with the smallest MAC address considered as an unsigned integer.
o S：最小のフラグ。このビットが1の場合、ネイバーのリストには、符号なし整数と見なされる最小のMACアドレスを持つネイバーが含まれます。
o L: Largest flag. If this bit is a one, then the list of neighbors includes the neighbor with the largest MAC address considered as an unsigned integer.
o L：最大のフラグ。このビットが1の場合、ネイバーのリストには、最大のMACアドレスが符号なし整数と見なされるネイバーが含まれます。
o R, RESV: These bits are reserved and MUST be sent as zero and ignored on receipt.
o R、RESV：これらのビットは予約されており、ゼロとして送信し、受信時に無視する必要があります。
o SIZE: The SNPA size as an unsigned integer in bytes except that 6 is encoded as zero. An actual size of zero is meaningless and cannot be encoded. The meaning of the value 6 in this field is reserved, and TRILL Neighbor TLVs received with a SIZE of 6 are ignored. The SIZE is inherent to the technology of a link and is fixed for all TRILL Neighbor TLVs on that link but may vary between different links in the campus if those links are different technologies, for example, 6 for EUI-48 SNPAs or 8 for EUI-64 SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL campus is independent of the System ID size.)
o SIZE：6がゼロとしてエンコードされることを除いて、バイト単位の符号なし整数としてのSNPAサイズ。ゼロの実際のサイズは意味がなく、エンコードできません。このフィールドの値6の意味は予約されており、SIZEが6で受信されたTRILLネイバーTLVは無視されます。 SIZEはリンクのテクノロジーに固有であり、そのリンク上のすべてのTRILLネイバーTLVに対して固定されていますが、それらのリンクが異なるテクノロジーの場合、キャンパス内の異なるリンク間で異なる場合があります。たとえば、EUI-48 SNPAの場合は6、EUIの場合は8 -64 SNPA [RFC7042]。 （TRILLキャンパス内のさまざまなリンクのSNPAサイズは、システムIDサイズとは無関係です。）
o F: Failed. This bit is a one if MTU testing to this neighbor failed at the required campus-wide MTU (see [RFC6325], Section 4.3.1).
o F：失敗しました。このビットは、このネイバーへのMTUテストが必要なキャンパス全体のMTUで失敗した場合に1になります（[RFC6325]、セクション4.3.1を参照）。
o O: OOMF. This bit is a one if the IS sending the enclosing TRILL Neighbor TLV is willing to offer the Overload Originated Multi-destination Frame (OOMF) service [RFC7180] to the IS whose port has the SNPA in the enclosing Neighbor RECORD.
o O：OOMF。このビットは、包含TRILLネイバーTLVを送信するISが、過負荷発信マルチ宛先フレーム（OOMF）サービス[RFC7180]を、包含ネイバーレコードにSNPAを持つポートを持つISに提供する用意がある場合に1になります。
o MTU: This field is set to the largest successfully tested MTU size for this neighbor or to zero if it has not been tested.
o MTU：このフィールドは、このネイバーの正常にテストされた最大のMTUサイズに設定されます。テストされていない場合はゼロに設定されます。
o SNPA (MAC Address): Subnetwork Point of Attachment of the neighbor.
o SNPA（MACアドレス）：ネイバーの接続のサブネットワークポイント。
As specified in [RFC7177] and Section 4.4.2.1 of [RFC6325], all MAC addresses may fit into one TLV, in which case both the S and L flags would be set to one in that TLV. If the MAC addresses don't fit into one TLV, the highest MAC address in a TRILL Neighbor TLV with the L flag zero MUST also appear as a MAC address in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST also appear in some other TRILL Neighbor TLV (possibly in a different TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will have both the S and L bits on.
[RFC7177]および[RFC6325]のセクション4.4.2.1で指定されているように、すべてのMACアドレスが1つのTLVに収まる場合があります。その場合、そのTLVではSフラグとLフラグの両方が1に設定されます。 MACアドレスが1つのTLVに適合しない場合、LフラグがゼロのTRILLネイバーTLVの最上位MACアドレスは、他のTRILLネイバーTLV（おそらく別のTRILL IIH PDU内）のMACアドレスとしても表示される必要があります。また、SフラグがゼロのTRILLネイバーTLVの最も低いMACアドレスは、他のTRILLネイバーTLVにも（おそらく別のTRILL IIH PDUに）出現する必要があります。 ISがネイバーがないと判断した場合は、SとLの両方のビットがオンになっているネイバーRECORDSの空のリストを含むTRILLネイバーTLVを送信する必要があります。
The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine the MTU on a link between ISs as specified in Section 4.3.2 of [RFC6325] and in [RFC7177].
IS-IS MTUプローブおよびMTU-ack PDUは、[RFC6325]のセクション4.3.2および[RFC7177]で指定されているIS間のリンクのMTUをオプションで決定するために使用されます。
The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with PDU Type numbers as indicated in Section 5. They also have a common fixed MTU PDU header as shown below that is 8 + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes System IDs.
MTU PDUには、セクション5に示すように、PDUタイプ番号が付いたIS-IS PDU共通ヘッダー（最大エリアアドレスバイトまで）があります。また、以下に示すように、8 + 2 *（ID長さ）バイト長、通常の6バイトのシステムIDの場合は20バイト。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
As with other IS-IS PDUs, the PDU Length gives the length of the entire IS-IS packet starting with and including the IS-IS common header.
他のIS-IS PDUと同様に、PDUの長さは、IS-IS共通ヘッダーで始まりIS-IS共通ヘッダーを含むIS-ISパケット全体の長さを示します。
The Probe ID field is an opaque 48-bit quantity set by the IS issuing an MTU-probe and copied by the responding IS into the corresponding MTU-ack. For example, an IS creating an MTU-probe could compose this quantity from a port identifier and probe sequence number relative to that port.
プローブIDフィールドは、MTUプローブを発行するISによって設定され、応答するISによって対応するMTU-ackにコピーされる不透明な48ビットの数量です。たとえば、MTUプローブを作成するISは、ポート識別子とそのポートに関連するプローブシーケンス番号からこの数量を構成できます。
The Probe Source ID is set by an IS issuing an MTU-probe to its System ID and copied by the responding IS into the corresponding MTU-ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to its System ID. The System ID length is usually 6 bytes but could be a different value as indicated by the ID Length field in the IS-IS PDU Header.
プローブソースIDは、ISがシステムIDにMTUプローブを発行することによって設定され、応答するISによって対応するMTU-ackにコピーされます。 ACKソースIDはMTUプローブPDUでゼロに設定され、受信時に無視されます。 ISがMTU-ackを発行すると、Ack Source IDフィールドがそのシステムIDに設定されます。システムIDの長さは通常6バイトですが、IS-IS PDUヘッダーのID長フィールドで示されるように、異なる値になる場合があります。
The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded with the Padding TLV to the exact size being tested. Since the minimum size of the Padding TLV is 2 bytes, it would be impossible to pad to exact size if the total length of the required information-bearing fixed fields and TLVs added up to 1 byte less than the desired length. However, the length of the fixed fields and substantive TLVs for MTU PDUs is expected to be quite small compared with their minimum length (minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this should not be a problem.
TLV領域はMTU PDUヘッダー領域の後に続きます。この領域には認証TLVが含まれている場合があり、テストされる正確なサイズになるようにパディングTLVでパディングする必要があります。パディングTLVの最小サイズは2バイトであるため、必要な情報を保持する固定フィールドとTLVの合計の長さが、必要な長さよりも1バイト少ない場合、正確なサイズにパディングすることは不可能です。ただし、MTU PDUの固定フィールドおよび実質的なTLVの長さは、それらの最小長（たとえば、IEEE 802.3リンクでの最小1470バイトMTU）と比較して非常に短いと予想されるため、これは問題になりません。
The sub-sections below provide details of TRILL use of existing PDUs and TLVs.
以下のサブセクションでは、既存のPDUおよびTLVのTRILL使用の詳細について説明します。
The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC7177] specify the contents of the TRILL IIH and how its use in TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state machinery for TRILL neighbors is specified in detail in [RFC7177].
TRILL IIH PDUは、TRILLプロトコルで使用されるIIH PDUのバリエーションです。 TRILL標準[RFC6325]および[RFC7177]のセクション4.4は、TRILL IIHの内容と、TRILLでのその使用がレイヤ3 LAN IIH PDUの使用とどのように異なるかを指定しています。 TRILLネイバーの隣接状態機構は、[RFC7177]で詳細に指定されています。
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 IIH PDU.
TRILL IIH PDUでは、IS-IS共通ヘッダーと固定PDUヘッダーはレベル1 IIH PDUと同じです。
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL Neighbor TLV (see Section 2.5).
IS-ISネイバーTLV（6）はTRILL IIHでは使用されず、そこに表示されても無視されます。代わりに、TRILL LAN IIH PDUはTRILLネイバーTLVを使用します（セクション2.5を参照）。
TRILL uses a fixed zero Area Address as specified in [RFC6325], Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) as follows:
TRILLは、[RFC6325]のセクション4.2.3で指定されている固定のゼロエリアアドレスを使用します。これは、次のように4バイトのエリアアドレスTLV（TLV＃1）でエンコードされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Area Address Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02, Length of Value | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Length of Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00, zero Area Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that value appears in TRILL IIH PDUs and LSP number zero PDUs.
NLPID（ネットワーク層プロトコルID）0xC0がTRILL [RFC6328]に割り当てられました。その値を含むプロトコルでサポートされるTLV（＃129、[RFC1195]）は、TRILL IIH PDUとLSP番号ゼロPDUに表示されます。
An LSP number zero MUST NOT be originated larger than 1470 bytes, but a larger LSP number zero successfully received MUST be processed and forwarded normally.
LSP番号0は1470バイトを超えて発信してはなりません（MUST NOT）。ただし、正常に受信されたより大きなLSP番号0は通常どおりに処理および転送される必要があります。
The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; however, if found in other LSP fragments, it is processed normally. Should there be more than one originatingLSPBufferSize TLV for an IS, the minimum size, but not less than 1470, is used.
originatingLSPBufferSize TLV（＃14）はLSP番号0でなければなりません。ただし、他のLSPフラグメントで見つかった場合は、通常どおり処理されます。 ISに複数のoriginatingLSPBufferSize TLVがある場合、最小サイズで1470以上が使用されます。
This section gives IANA considerations for the TLVs, sub-TLVs, and PDUs specified herein. A number of new code points are assigned, and those that were assigned by [RFC6326] are included here for convenience. IANA has replaced all [RFC6326] references in the IANA registries with references to this document.
このセクションでは、ここで指定されたTLV、サブTLV、およびPDUに関するIANAの考慮事項について説明します。いくつかの新しいコードポイントが割り当てられ、[RFC6326]によって割り当てられたコードポイントが便宜上ここに含まれています。 IANAは、IANAレジストリのすべての[RFC6326]参照をこのドキュメントへの参照に置き換えました。
This document specifies two IS-IS TLV types -- namely, the Group Address TLV (GADDR-TLV; type 142) and the TRILL Neighbor TLV (type 145). The PDUs in which these TLVs are permitted for TRILL are shown in the table below along with the section of this document where they are discussed. The final "NUMBER" column indicates the permitted number of occurrences of the TLV in their PDU, or set of PDUs in the case of LSPs, which in these two cases is "*" indicating that the TLV MAY occur 0, 1, or more times.
このドキュメントでは、2つのIS-IS TLVタイプ、つまりグループアドレスTLV（GADDR-TLV、タイプ142）とTRILLネイバーTLV（タイプ145）を指定しています。これらのTLVがTRILLに許可されているPDUは、このドキュメントのセクションと一緒に以下の表に示されています。最後の「NUMBER」列は、PDUでのTLVの許容発生数、またはLSPの場合はPDUのセットの数を示します。これらの2つの場合は「*」で、TLVが0、1、またはそれ以上発生する可能性があることを示します。回。
IANA has registered these two code points in the IANA IS-IS TLV registry (ignoring the "Section" and "NUMBER" columns, which are irrelevant to that registry).
IANAは、これらの2つのコードポイントをIANA IS-IS TLVレジストリに登録しました（「レジストリ」に関係のない「セクション」および「番号」列は無視されます）。
Section TLV IIH LSP SNP Purge NUMBER
======= === === === === ===== ======
GADDR-TLV 2.1 142 n y n n *
TRILL Neighbor TLV 2.5 145 y n n n *
This document specifies a number of sub-TLVs. The TLVs in which these sub-TLVs occur are shown in the second table below along with the section of this document where they are discussed. The TLVs within which these sub-TLVs can occur are determined by the presence of an "X" in the relevant column; the column headers are described in the first table below. In some cases, the column header corresponds to two different TLVs in which the sub-TLV can occur.
このドキュメントでは、いくつかのサブTLVを指定します。これらのサブTLVが発生するTLVは、このドキュメントのセクションと一緒に、次の2番目の表で説明されています。これらのサブTLVが発生する可能性のあるTLVは、関連する列の「X」の存在によって決定されます。列ヘッダーについては、下の最初の表で説明しています。場合によっては、列ヘッダーは、サブTLVが発生する可能性のある2つの異なるTLVに対応しています。
Column Head TLV RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
MT Port 143 6165 MT-Port-Cap-TLV
MTポート143 6165 MT-Port-Cap-TLV
MT Cap. 242 4971 Router CAPABILITY 144 6329 MT-Capability
MTキャップ。 242 4971ルーター機能144 6329 MT機能
Ext. Reach 22 5305 Extended IS Reachability 222 5120 MT-ISN
内線Reach 22 5305 Extended IS Reachability 222 5120 MT-ISN
The final "NUMBER" column below indicates the permitted number of occurrences of the sub-TLV cumulatively within all occurrences of their TLV(s) in those TLVs' carrying a PDU (or set of PDUs in the case of LSPs), as follows:
以下の最後の「NUMBER」列は、次のように、PDU（またはLSPの場合はPDUのセット）を伝送するTLVのTLVのすべてのオカレンス内で累積的にサブTLVの許容オカレンス数を示します。
0-1 = MAY occur zero or one times. 1 = MUST occur exactly once. If absent, the PDU is ignored. If it occurs more than once, results are unspecified. * = MAY occur 0, 1, or more times.
0-1 = 0回または1回発生する可能性があります。 1 =必ず1回発生する必要があります。存在しない場合、PDUは無視されます。複数回発生する場合、結果は不定です。 * = 0、1、またはそれ以上発生する場合があります。
The values in the "Section" and "NUMBER" columns are irrelevant to the IANA sub-registries.
「セクション」および「番号」列の値は、IANAサブレジストリとは無関係です。
sub- Grp. MT MT Ext.
Name Section TLV# Adr. Port Cap. Reach NUMBER
=================================================================
GMAC-ADDR 2.1.1 1 X - - - *
GIP-ADDR 2.1.2 2 X - - - *
GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 6 X - - - *
VLAN-FLAGS 2.2.1 1 - X - - 1
Enabled-VLANs 2.2.2 2 - X - - *
AppointedFwrdrs 2.2.3 3 - X - - *
PORT-TRILL-VER 2.2.4 7 - X - - 0-1
VLANs-Appointed 2.2.5 8 - X - - *
NICKNAME 2.3.2 6 - - X - *
TREES 2.3.3 7 - - X - 0-1
TREE-RT-IDs 2.3.4 8 - - X - *
TREE-USE-IDs 2.3.5 9 - - X - *
INT-VLAN 2.3.6 10 - - X - *
TRILL-VER 2.3.1 13 - - X - 0-1
VLAN-GROUP 2.3.7 14 - - X - *
INT-LABEL 2.3.8 15 - - X - *
RBCHANNELS 2.3.9 16 - - X - *
AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1
=================================================================
Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. Reach
IANA has entered the newly assigned sub-TLV numbers in the above table in the relevant existing sub-TLV registries, as determined by which column has an X for that sub-TLV. For the sub-TLVs from NICKNAME through and including VLAN-GROUP, which previously existed only in the registry of sub-TLVs under TLV 242, IANA has added each sub-TLV with the same sub-TLV number to the existing registry for sub-TLVs under TLV 144.
IANAは、上記の表の新しく割り当てられたサブTLV番号を、関連する既存のサブTLVレジストリに入力しました。これは、そのサブTLVのXがある列によって決定されます。 NICKNAMEからVLAN-GROUPまでのサブTLV（以前はTLV 242のサブTLVのレジストリにのみ存在していた）について、IANAは同じサブTLV番号を持つ各サブTLVを既存のサブTLVレジストリに追加しましたTLV 144の下のTLV。
The IS-IS PDUs registry remains as established in [RFC6326] except that the references to [RFC6326] are updated to reference this document.
IS-IS PDUレジストリは、[RFC6326]への参照がこのドキュメントを参照するように更新されていることを除いて、[RFC6326]で確立されたままです。
Any reserved bits (R), bits in reserved fields (RESV), or capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which are specified herein as "MUST be sent as zero and ignored on receipt" or the like, are allocated based on IETF Review [RFC5226].
予約済みビット（R）、予約済みフィールド（RESV）のビット、またはPORT-TRILL-VERおよびTRILL-VERサブTLVの機能ビット。これらは、ここでは「0として送信し、受信時に無視する必要がある」として指定されています。同様のものは、IETFレビュー[RFC5226]に基づいて割り当てられます。
Two sub-registries have been created within the TRILL Parameters Registry as follows:
次のように、2つのサブレジストリがTRILLパラメータレジストリ内に作成されています。
Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags Registration Procedures: IETF Review Reference: (This document)
サブレジストリ名：TRILL-VERサブTLV機能フラグ登録手順：IETFレビューリファレンス：（このドキュメント）
Bit Description Reference
===== ============= ===========
0 Affinity sub-TLV support. [Affinity]
1 FGL-safe [RFC7172]
2-13 Unassigned
14-31 Extended header flag support. [RFC7179]
Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review
Reference: (This document)
Bit Description Reference
===== ============= ===========
0 Hello reduction support. [RFC7180]
1-2 Unassigned
3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned
A sub-registry has been created within the TRILL Parameters Registry as follows:
次のように、TRILLパラメータレジストリ内にサブレジストリが作成されました。
Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags Registration Procedures: Standards Action Reference: (This document)
サブレジストリ名：TRILLネイバーTLV NEIGHBOR RECORDフラグ登録手順：標準アクションリファレンス：（このドキュメント）
Bit Short Name Description Reference
============== ============= ===========================
0 Fail Failed MTU test [RFC6325][RFC7176][RFC7177]
1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned
For general TRILL protocol security considerations, see the TRILL base protocol standard [RFC6325].
TRILLプロトコルのセキュリティに関する一般的な考慮事項については、TRILLベースプロトコル標準[RFC6325]を参照してください。
This document raises no new security issues for IS-IS. IS-IS security may be used to secure the IS-IS messages discussed here. See [RFC5304] and [RFC5310]. Even when IS-IS authentication is used, replays of Hello packets can create denial-of-service conditions; see [RFC6039] for details. These issues are similar in scope to those discussed in Section 6.2 of [RFC6325], and the same mitigations may apply.
このドキュメントでは、IS-ISの新しいセキュリティ問題は発生しません。 IS-ISセキュリティを使用して、ここで説明するIS-ISメッセージを保護できます。 [RFC5304]と[RFC5310]を参照してください。 IS-IS認証が使用されている場合でも、Helloパケットのリプレイにより、サービス拒否の状態が発生する可能性があります。詳細については、[RFC6039]を参照してください。これらの問題の範囲は、[RFC6325]のセクション6.2で説明されている問題と同様であり、同じ軽減策が適用される場合があります。
Non-editorial changes from [RFC6326] are summarized in the list below:
[RFC6326]からの非編集上の変更は以下のリストに要約されています：
1. Added five sub-TLVs under the Group Address (GADDR) TLV covering VLAN-labeled IPv4 and IPv6 addresses and fine-grained-labeled MAC, IPv4, and IPv6 addresses (Sections 2.1.2, 2.1.3, 2.1.4, 2.1.5, and 2.1.6).
1. VLANラベル付きのIPv4およびIPv6アドレスと、きめ細かいラベル付きのMAC、IPv4、およびIPv6アドレスをカバーするグループアドレス（GADDR）TLVに5つのサブTLVを追加しました（セクション2.1.2、2.1.3、2.1.4、2.1。 5、および2.1.6）。
2. Added the PORT-TRILL-VER sub-TLV (Section 2.2.4).
2. PORT-TRILL-VERサブTLV（セクション2.2.4）を追加しました。
3. Added the VLANs-Appointed sub-TLV (Section 2.2.5).
3. VLAN-Appointed sub-TLVを追加しました（セクション2.2.5）。
4. Changed the TRILL-VER sub-TLV as listed below.
4. 以下に示すように、TRILL-VERサブTLVを変更しました。
a. Added 4 bytes of TRILL Header extended flags and capabilities supported information.
a. 4バイトのTRILLヘッダー拡張フラグと機能サポート情報が追加されました。
b. Required that the TRILL-VER sub-TLV appear in LSP number zero.
b. TRILL-VERサブTLVがLSP番号0に表示される必要があります。
The above changes to TRILL-VER are backward compatible because
the [RFC6326]-conformant implementations of TRILL thus far have
only supported version zero and not supported any optional
capabilities or extended flags, the level of support indicated by
the absence of the TRILL-VER sub-TLV. Thus, if an
[RFC6326]-conformant implementation of TRILL rejects this sub-TLV
due to the changes specified in this document, it will, at worst,
decide that support of version zero and no extended flags or
capabilities is indicated, which is the best an
[RFC6326]-conformant implementation of TRILL can do anyway.
Similarly, a TRILL implementation that supports TRILL-VER as
specified herein and rejects TRILL-VER sub-TLVs in an
[RFC6326]-conformant TRILL implementation because they are not in
LSP number zero will decide that the implementation supports only
version zero with no extended flag or capabilities support, which
will be correct (Section 2.3.1).
5. Clarified the use of invalid VLAN IDs (0x000 and 0xFFF) in the Appointed Forwarders sub-TLV and the Interested VLANs and Spanning Tree Roots sub-TLV (Sections 2.2.3 and 2.3.6).
5. Appointed ForwardersサブTLVおよび関係するVLANとスパニングツリールートサブTLVでの無効なVLAN ID（0x000および0xFFF）の使用を明確にしました（セクション2.2.3および2.3.6）。
6. Added the Interested Labels and Spanning Tree Roots sub-TLV to indicate attachment of an IS to a fine-grained label [RFC7172] analogous to the existing Interested VLANs and Spanning Tree Roots sub-TLV for VLANs (Section 2.3.8).
6. 既存の対象VLANとVLANのスパニングツリールートサブTLV（セクション2.3.8）に類似した細かいラベル[RFC7172]へのISの添付を示すために、関係ラベルとスパニングツリールートサブTLVを追加しました。
7. Added the RBridge Channel Protocols sub-TLV so ISs can announce the RBridge Channel protocols they support (Section 2.3.9).
7. ISがサポートするRBridgeチャネルプロトコルをアナウンスできるように、RBridgeチャネルプロトコルサブTLVを追加しました（セクション2.3.9）。
8. Permitted specification of the length of the link SNPA field in TRILL Neighbor TLVs. This change is backward compatible because the size of 6 bytes is specially encoded as zero, the previous value of the bits in the new SIZE field (Section 2.5).
8. TRILLネイバーTLVのリンクSNPAフィールドの長さの許可された指定。この変更は下位互換性があります。これは、6バイトのサイズが、新しいSIZEフィールドのビットの以前の値（セクション2.5）であるゼロとして特別にエンコードされているためです。
9. Made the size of the MTU PDU Header Probe Source ID and Ack Source ID fields be the ID Length from the IS-IS PDU Header rather than the fixed value 6 (Section 3).
9. MTU PDUヘッダープローブのソースIDおよびACKソースIDフィールドのサイズを、固定値6（セクション3）ではなく、IS-IS PDUヘッダーからのID長にした。
10. For robustness, required that LSP number zero PDUs be originated as no larger than 1470 bytes but processed regardless of size (Section 4.4).
10. 堅牢性のために、LSP番号0のPDUが1470バイト以下として発信され、サイズに関係なく処理される必要があります（セクション4.4）。
11. Required that the originatingLSPBufferSize TLV, if present, appear in LSP number zero (Section 4.5).
11. originatingLSPBufferSize TLVが存在する場合は、LSP番号ゼロに表示する必要があります（セクション4.5）。
12. Created sub-registries for and specified the IANA Considerations policy for reserved and capability bits in the TRILL version sub-TLVs (Section 5.4).
12. TRILLバージョンのサブTLV（セクション5.4）で予約ビットと機能ビットのIANA考慮事項ポリシーのサブレジストリを作成および指定しました。
13. Added the distribution tree Affinity sub-TLV so ISs can request distribution tree attachments (Section 2.3.10).
13. ISが配布ツリーの添付ファイルをリクエストできるように、配布ツリーアフィニティサブTLVを追加しました（セクション2.3.10）。
14. Added the LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV (Section 2.3.11).
14. VLAN-GROUPサブTLV（セクション2.3.11）に類似したLABEL-GROUPサブTLVを追加しました。
15. Added multi-topology to permit sub-TLVs previously only in the Router Capability TLV to also appear in the MT-Capability TLV and to permit the MTU sub-TLV previously limited to the Extended Reachability TLV to also appear in the MT-ISN TLV.
15. 以前はルーター機能TLVでのみサブTLVをMT機能TLVにも表示できるようにし、以前は拡張到達可能性TLVに制限されていたMTUサブTLVをMT-ISN TLVにも表示できるようにするマルチトポロジを追加しました。
16. Added a sub-registry for Neighbor TLV Neighbor RECORD flag bits (Section 5.5).
16. Neighbor TLV Neighbor RECORDフラグビットのサブレジストリを追加しました（セクション5.5）。
17. Explicitly stated that if the number of sources in a GADDR-TLV sub-TLV is zero, it indicates a listener for (*,G), that is, a listener not restricted by source (Section 2.1).
17. GADDR-TLVサブTLVのソースの数がゼロの場合、それは（*、G）のリスナー、つまりソースによって制限されていないリスナーを示していることを明示的に述べました（セクション2.1）。
[ISO-10589] International Organization for Standardization, "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)", Second Edition, November 2002.
[ISO-10589]国際標準化機構、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システム間ドメイン内ルーティング情報交換プロトコル」、第2版、2002年11月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982] Elz、R。およびR. Bush、「Serial Number Arithmetic」、RFC 1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[RFC4971] Vasseur、JP。、Ed。、Shen、N.、Ed。、and R. Aggarwal、Ed。、 "Intermediate System to Intermediate System（IS-IS）Extensions for Advertising Router Information"、RFC 4971、July 2007 。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、Shen、N。、およびN. Sheth、「M-ISIS：Multi Topology（MT）Routing in Intermediate System to Intermediate Systems（IS-ISs）」、RFC 5120、2008年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、2008年10月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、2011年4月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer Protocol Identifiers", BCP 164, RFC 6328, July 2011.
[RFC6328] Eastlake 3rd、D。、「ネットワークレイヤープロトコル識別子に関するIANAの考慮事項」、BCP 164、RFC 6328、2011年7月。
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, April 2012.
[RFC6329] Fedyk、D.、Ed。、Ashwood-Smith、P.、Ed。、Allan、D.、Bragg、A.、and P. Unbehagen、 "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging"、 RFC 6329、2012年4月。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, November 2011.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A。、およびF. Hu、「Routing Bridges（RBridges）：Appointed Forwarders」、RFC 6439、2011年11月。
[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, May 2014.
[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、May 2014。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, Y., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、Y.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[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, May 2014.
[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、May 2014 。
[RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C. Bestler, "Transparent Interconnection of Lots of Links (TRILL): Header Extension", RFC 7179, May 2014.
[RFC7179] Eastlake 3rd、D.、Ghanwani、A.、Manral、V.、Li、Y.、and C. Bestler、 "Transparent Interconnection of Lots of Links（TRILL）：Header Extension"、RFC 7179、May 2014。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、2014年5月。
[Err2869] RFC Errata, Errata ID 2869, RFC 6326, <http://www.rfc-editor.org>.
[Err2869] RFC Errata、Errata ID 2869、RFC 6326、<http://www.rfc-editor.org>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、2008年10月。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、2009年2月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039] Manral、V.、Bhatia、M.、Jaeggli、J。、およびR. White、「Issues with Existing Cryptographic Protection Methods for Routing Protocols」、RFC 6039、2010年10月。
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 6326, July 2011.
[RFC6326] Eastlake、D.、Banerjee、A.、Dutt、D.、Perlman、R。、およびA. Ghanwani、「リンクの多くの透過的な相互接続（TRILL）IS-ISの使用」、RFC 6326、2011年7月。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, October 2013.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項とIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、2013年10月。
[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, May 2014.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「Transparent Interconnection of Lots of Links（TRILL）：Bidirectional Forwarding Detection（BFD）Support」、RFC 7175、2014年5月。
[Affinity] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for TRILL", Work in Progress, April 2014.
[アフィニティ] Senevirathne、T.、Pathangi、J。、およびJ. Hudson、「TRILLの協調型マルチキャストツリー（CMT）」、作業中、2014年4月。
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, January 2014.
[MultiLevel] Perlman、R.、Eastlake 3rd、D.、Ghanwani、A。、およびH. Zhai、「Flexible Multilevel TRILL（Transparent Interconnection of Lots of Links）」、進行中の作業、2014年1月。
[Resilient] Zhang, M. Senevirathne, T., Pathangi, J., Banerjee, A., and A. Ghanwani, "TRILL Resilient Distribution Trees", Work in Progress, December 2013.
[レジリエント] Zhang、M。Senevirathne、T.、Pathangi、J.、Banerjee、A。、およびA. Ghanwani、「TRILL Resilient Distribution Trees」、Work in Progress、2013年12月。
The authors gratefully acknowledge the contributions and reviews by the following individuals: Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, Radia Perlman, Carlos Pignataro, and Joe Touch.
著者は以下の個人による貢献とレビューに感謝します：ロスカロン、スペンサードーキンス、エイドリアンファレル、アレクセイメルニコフ、ラディアパールマン、カルロスピニャタロ、ジョータッチ。
The authors also acknowledge the contributions to [RFC6326] by the following individuals: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for his detailed and helpful comments.
著者はまた、次の個人による[RFC6326]への貢献を認めます：マイクシャンド、スチュワートブライアント、ディノファリナッチ、レギンズバーグ、サムハートマン、ダンローマスカヌ、デイブウォード、およびラスホワイト。特に、詳細で役立つコメントを提供してくれたMike Shandに感謝します。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Tissa Senevirathne Cisco Systems 375 East Tasman Drive, San Jose, CA 95134 USA
Tissa Senevirathne Cisco Systems 375 East Tasman Drive、San Jose、CA 95134 USA
Phone: +1-408-853-2291
EMail: tsenevir@cisco.com
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara, CA 95054 USA
Anoop Ghanwani Dell 5450 Great America Parkway Santa Clara、CA 95054 USA
EMail: anoop@alumni.duke.edu
Dinesh Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale, CA 94086 USA
Dinesh Dutt Cumulus Networks 1089 West Evelyn Avenue Sunnyvale、CA 94086 USA
EMail: ddutt.ietf@hobbesdutt.com
Ayan Banerjee Insieme Networks 210 West Tasman Drive San Jose, CA 95134 USA
Ayan Banerjee Insieme Networks 210 West Tasman Drive San Jose、CA 95134 USA
EMail: ayabaner@gmail.com