[要約] RFC 6326は、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
Request for Comments: 6326 Huawei
Category: Standards Track A. Banerjee
ISSN: 2070-1721 D. Dutt
Cisco
R. Perlman
Intel
A. Ghanwani
Brocade
July 2011
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
多くのリンクの透明な相互接続（TRILL）IS-ISの使用
Abstract
概要
The IETF has standardized the Transparent Interconnection of Lots of Links (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing. This document specifies the data formats and code points for the IS-IS extensions to support TRILL.
IETFは、多くのリンク（TRILL）プロトコルの透明な相互接続を標準化しました。これは、ホップカウントとIS-ISリンク状態のルーティングを使用したカプセル化を使用して、透明レイヤー2転送を提供します。このドキュメントは、TrillをサポートするIS-IS拡張機能のデータ形式とコードポイントを指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc6326.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6326で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eのセクション4で説明されているように、簡略化されたBSDライセンステキストを含める必要があります。
the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
信頼の法的規定と、簡略化されたBSDライセンスに記載されているように、保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................3
2.1. The Group Address TLV ......................................3
2.1.1. The Group MAC Address Sub-TLV .......................4
2.2. Multi-Topology-Aware Port Capability Sub-TLVs ..............5
2.2.1. The Special VLANs and Flags Sub-TLV .................6
2.2.2. Enabled-VLANs Sub-TLV ...............................7
2.2.3. Appointed Forwarders Sub-TLV ........................8
2.3. Sub-TLVs for the Router Capability TLV .....................9
2.3.1. The TRILL Version Sub-TLV ...........................9
2.3.2. The Nickname Sub-TLV ...............................10
2.3.3. The Trees Sub-TLV ..................................11
2.3.4. The Tree Identifiers Sub-TLV .......................11
2.3.5. The Trees Used Identifiers Sub-TLV .................12
2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...12
2.3.7. The VLAN Group Sub-TLV .............................15
2.4. MTU Sub-TLV of the Extended Reachability TLV ..............15
2.5. TRILL Neighbor TLV ........................................16
3. The MTU PDUs ...................................................18
4. Use of Existing PDUs and TLVs ..................................19
4.1. TRILL IIH PDUs ............................................19
4.2. Area Address ..............................................19
4.3. Protocols Supported .......................................19
5. IANA Considerations ............................................20
5.1. Allocations from Existing Registries ......................20
5.2. New Sub-Registries Created ................................21
6. Security Considerations ........................................22
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................23
8. Acknowledgements ...............................................23
Appendix A. Initial IS-IS PDU Registry ............................24
The IETF has standardized the TRILL protocol [RFC6325], which provides transparent Layer 2 forwarding using encapsulation 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 as well as supporting VLANs. Intermediate Systems (ISs) implementing TRILL can incrementally replace IEEE [802.1Q-2005] bridges.
IETFは、トリルプロトコル[RFC6325]を標準化しており、ホップカウントとリンク状態ルーティングを使用したカプセル化を使用して、透明レイヤー2転送を提供します。Trillは、構成なしで最適なペアワイズ転送、一時的なループの期間中でも安全な転送、ユニキャストトラフィックとマルチキャストトラフィックの両方のマルチパス、およびVLANのサポートのサポートを提供します。中間システム（ISS）Trillの実装は、IEEE [802.1Q-2005]ブリッジを段階的に置き換えることができます。
This document, in conjunction with [RFC6165], specifies the data formats and code points for the IS-IS [ISO-10589] [RFC1195] extensions to support TRILL.
このドキュメントは、[RFC6165]と併せて、IS-IS [ISO-10589] [RFC1195]拡張機能のデータ形式とコードポイントを指定して、Trillをサポートします。
The terminology and acronyms defined in [RFC6325] are used herein with the same meaning.
[RFC6325]で定義されている用語と頭字語は、本明細書で同じ意味で使用されます。
Additional acronyms used in this document are:
このドキュメントで使用される追加の頭字語は次のとおりです。
IIH - IS-IS Hello
IIH- IS -ISこんにちは
IS - Intermediate System (for this document, all relevant intermediate systems are RBridges)
IS-中間システム（このドキュメントの場合、関連する中間システムはすべてRBRIDGESです）
NLPID - Network Layer Protocol Identifier
NLPID-ネットワークレイヤープロトコル識別子
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This section, in conjunction with [RFC6165], specifies the data formats and code points for the TLVs and sub-TLVs added to IS-IS to support the TRILL standard. 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 provided in Section 5.
このセクションは、[RFC6165]と併せて、TLVSのデータ形式とコードポイントをIS-ISに追加してTRILL標準をサポートするために指定します。PDUまたはPDUのセット、またはTLVのSub-TLVのTLVなど、許可されている発生数に関する情報は、セクション5に記載されています。
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried only in an LSP PDU and carries sub-TLVs that in turn advertise multicast group listeners. Section 2.1.1 below specifies a sub-TLV that advertises listeners by MAC address. It is anticipated that
グループアドレス（GADDR）TLV、IS-IS TLVタイプ142は、LSP PDUでのみ運ばれ、マルチキャストグループリスナーを宣伝するサブTLVを運びます。以下のセクション2.1.1は、MACアドレスごとにリスナーを宣伝するSub-TLVを指定します。それは予想されています
additional sub-TLVs for additional address types such as IP addresses will be specified in other documents. The sub-TLVs under GADDR constitute a new series of sub-TLV types (see Section 5.2).
IPアドレスなどの追加アドレスタイプの追加のサブ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]で説明されているようにフォーマットされたSub-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 as specified in Section 4.5.5 of [RFC6325]. It has the following format:
グループMACアドレス（GMAC-ADDR）Sub-TLVは、GADDR TLV内のサブTLVタイプ番号1です。Trillでは、[RFC6325]のセクション4.5.5で指定されているように、マルチキャストリスナーを宣伝するために使用されます。次の形式があります。
+-+-+-+-+-+-+-+-+
|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 (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
各グループレコードは形式です。
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o タイプ：GADDR SUB-TLVタイプ、1（GMAC-ADDR）に設定。
o Length: Variable, minimum 5.
o 長さ：変数、最小5。
o RESV: Reserved. 4-bit fields that MUST be sent as zero and ignored on receipt.
o RESV：予約済み。ゼロとして送信し、受領時に無視する必要がある4ビットフィールド。
o Topology-ID: This field is not used in TRILL, where it is sent as zero and ignored on receipt, but is included for use by other technologies.
o Topology-ID：このフィールドはTrillでは使用されていません。このフィールドは、ゼロとして送信され、受信時に無視されますが、他のテクノロジーで使用するために含まれています。
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が指定されていない場合の値ゼロが含まれます。
o Number of Group Records: A 1-byte integer that is the number of group records in this sub-TLV.
o グループレコードの数：このサブTLVのグループレコードの数である1バイト整数。
o Group Record: Each group record carries the number of sources. It then has a 48-bit multicast address followed by 48-bit 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 グループレコード：各グループレコードには、ソースの数が含まれます。次に、48ビットのマルチキャストアドレスが続き、その後に48ビットのソースMACアドレスが続きます。ソースが単一のサブTLVに適合しない場合、グループアドレスTLVの別のインスタンスの別のサブTLVで異なるソースアドレスで同じグループアドレスを繰り返すことができます。
TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT-CAP) TLV as specified in [RFC6165]. The remainder of this section specifies the sub-TLVs that TRILL uses the MT-PORT-CAP TLV to transport.
Trillは、[RFC6165]で指定されているように、マルチトポロジーアウェアポート機能（MT-PORT-CAP）TLVを利用しています。このセクションの残りの部分では、TrillがMT-Port-CAP TLVを使用して輸送するサブTLVを指定します。
In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried in every IIH PDU. It has the following format:
Trillでは、特別なVLANとフラグ（VLAN-FLAGS）サブTLVがすべてのIIH PDUで運ばれます。次の形式があります。
+-+-+-+-+-+-+-+-+
| 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 | Desig.VLAN | (2 bytes)
+--+--+--+--+-------------------+
o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1.
o タイプ：Sub-TLVタイプ、MT-Port-Cap VLAN-Flags Sub-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で指定されているように、トリル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 encapsulated data frame. See [RFC6325], Section 4.6.2, point 8.
o 送信者ニックネーム：送信が[RFC6325]で説明されているようにニックネームを保持している場合、セクション3.7では、ここに含める必要があります。それ以外の場合、フィールドはゼロに設定されています。このフィールドは、ディレクトリサービスなどを介してユニキャストデータの出力IS（RBRIDGE）を決定するインテリジェントエンドステーションをサポートするためです。[RFC6325]、セクション4.6.2、ポイント8を参照してください。
o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH frame containing this sub-TLV when that frame was sent, as specified in [RFC6325], Section 4.4.5.
o outer.vlan：[RFC6325]で指定されているように、そのフレームが送信されたときにこのサブTLVを含むTRILL IIHフレームの12ビット外側VLAN IDのコピー、セクション4.4.5。
o Desig.VLAN: The 12-bit ID of the designated VLAN for the link, as specified in [RFC6325], Section 4.2.4.2.
o desig.vlan：[RFC6325]で指定されているリンクの指定VLANの12ビットID、セクション4.2.4.2。
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は、IIH PDUを含むIIH PDUが送信されたVLANおよびポートのフォワーダーに任命されていると考えられています。
AC 4.9.1 Originating port configured as an access port (TRILL traffic disabled).
AC 4.9.1アクセスポートとして構成された発信ポート（Trill Traffic Disabled）。
VM 4.4.5 VLAN mapping detected on this link.
VM 4.4.5このリンクで検出されたVLANマッピング。
BY 4.4.2 Bypass pseudonode.
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 for end station service at the port of the originating IS on which the Hello was sent, as specified in [RFC6325], Section 4.4.2. It has the following format:
オプションのEnabled-Vlans Sub-TLVは、[RFC6325]で指定されているように、Helloが送信された発信ポートでのエンドステーションサービスに有効化されたVLANを指定します。セクション4.4.2です。次の形式があります。
+-+-+-+-+-+-+-+-+
| 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 Enabled-VLANs sub-TLV 2.
o タイプ：Sub-TLVタイプ、MT-PORT-CAP 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がStart VLAN IDに等しいことを示します。次の最高ビットは、VLAN ID 1に等しいVLANを示し、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の有効化されたVLANサブTLVのそれぞれによって示されるVLANのセットの結合です。
The 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 Section 4.2.4 of [RFC6325]. It has the following format:
リンク上のDRBは、任命されたフォワーダーSub-TLVを使用して、[RFC6325]のセクション4.2.4で指定されているように、VLAN IDの1つ以上の範囲の指定されたVLAN-X転送業者であることをリンク上の他のISSに通知します。次の形式があります。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (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 AppointedFwrdrs sub-TLV 3.
o タイプ：サブTLVタイプ、MT-PORT-CAP任命されたfwrdrs 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 任命者のニックネーム：転送者に任命されているニックネーム。
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o RESV：ゼロとして送信し、受領時に無視する必要がある4ビット。
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the appointment range, inclusive. To specify a single VLAN, the VLAN's ID appears as both the start and end VLAN. As specified in Section 4.4 of [RFC6325], appointing an IS forwarder on a port for a VLAN not enabled on that port has no effect.
o start.vlan、end.vlan：これらのフィールドは、予約範囲のVLAN IDです。単一のVLANを指定するには、VLANのIDが開始と終了VLANの両方として表示されます。[RFC6325]のセクション4.4で指定されているように、そのポートで有効にされていないVLANのポートにISフォワーダーを任命することは効果がありません。
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.
ISのニックネームは、IIH PDU内の同じまたは異なるMTポート機能TLV内のこのサブTLVの発生により、複数のVLAN範囲の指定された転送者として発生する場合があります。
The Router Capability TLV is specified in [RFC4971]. All of the sub-sections of this Section 2.3 below specify sub-TLVs that can be carried in the Router Capability TLV for TRILL.
ルーター機能TLVは[RFC4971]で指定されています。以下のこのセクション2.3のサブセクションはすべて、トリル用のルーター機能TLVで運ぶことができるサブTLVを指定します。
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version of the TRILL standard supported. By implication, lower versions are also supported. If this sub-TLV is missing, the originating IS only supports the base version of the protocol [RFC6325].
Trillバージョン（Trill-ver）Sub-TLVは、サポートされているTrill標準の最大バージョンを示します。含意により、低いバージョンもサポートされています。このサブTLVが欠落している場合、発信元はプロトコル[RFC6325]の基本バージョンのみをサポートします。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Max-version | (1 byte)
+-+-+-+-+-+-+-+-+
o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).
o タイプ：ルーター機能サブTLVタイプ、13（Trill-ver）に設定。
o Length: 1.
o 長さ：1。
o Max-version: Set to maximum version supported.
o Max-version：サポートされている最大バージョンに設定します。
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 as specified in [RFC6325], Section 3.7.3. Multiple instances of this sub-TLV may be carried.
ニックネーム（ニックネーム）ルーター機能Sub-TLVは、[RFC6325]で指定されているようにそれらのニックネームを保持するための優先順位に関する情報とともに、発信元のニックネームに関する情報を伝達します。セクション3.7.3。このサブTLVの複数のインスタンスを運ぶことができます。
+-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 sub-TLV type, set to 6 (NICKNAME).
o タイプ：ルーター機能サブTLVタイプ、6（ニックネーム）に設定。
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:
それぞれが提供しているTrill Serviceは、[RFC6325]のセクション4.5で指定されているように、分布ツリーの計算に関連する3つの数値を発表するためにTrees Sub-TLVを使用しています。その形式は次のとおりです。
+-+-+-+-+-+-+-+-+
|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 sub-TLV type, set to 7 (TREES).
o タイプ：ルーター機能サブTLVタイプ、7（ツリー）に設定。
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 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）Sub-TLVは、ニックネームの順序付けられたリストです。最優先ツリールートが最も高いISによって発生する場合、[RFC6325]のセクション4.5で指定されているように、他のISSが計算する必要がある分布ツリーをリストします。この情報が複数のサブ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 sub-TLV type, set to 8 (TREE-RT-IDs).
o タイプ：ルーター機能Sub-TLVタイプ、8（Tree-RT-IDS）に設定。
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 a 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 開始ツリー番号：これにより、ドメイン用のツリーであるニックネームの開始ツリー番号が識別されます。これは、最初のリストを含むSub-TLVで1に設定されています。その他のツリーIDENTIFIERSサブTLVには、含まれる開始リストの数があります。このような2つのサブTLVからツリー識別子を計算でき、それらは異なる場合、これはクリアされる一時的な条件であると想定されます。この過渡期間中、そのような計算が存在するすべての関連するサブTLVによって示されない限り、そのようなツリーを計算しないでください。
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.
このルーター機能Sub-TLVは、セクション2.3.4で指定されたツリー識別子Sub-TLVと同じ構造を持っています。唯一の違いは、そのサブTLVタイプが9に設定されていること（Tree-Use-ID）であり、リストされている木は、[RFC6325]、セクション4.5で指定されているように使用することを望んでいるものです。
The value of this Router Capability 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.
このルーター機能Sub-TLVの値は、VLAN範囲と、発信元の範囲内のすべてのVLANと共通の情報で構成されています。この情報は、フラグ、スパニングツリールートブリッジIDの可変長リスト、および下記のそれぞれの情報項目がリストされている[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 precisely 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の範囲の結合は、まさに生産されるVLANのセットでなければなりません。ISの複数のVLANサブTLVは、VLANに関する情報がすべての場合に同じでない限り、重複しないでください。ただし、一時的な状態として、これらの条件に違反する可能性があります。VLANがISのINT-VLANサブTLVにリストされていない場合、そのVLANのトラフィックを受信することに興味がないと想定されています。VLANが異なるインスタンスで異なる情報を使用して複数のINT-VLAN SUB-TLVに表示される場合、次の場合は次のように適用されます。
- If those sub-TLVs provide different nicknames, it is unspecified which nickname takes precedence. - The largest appointed forwarder status lost counter 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が異なるニックネームを提供する場合、どのニックネームが優先されるかは特定されていません。 - 最大の任命されたフォワーダーステータスロストカウンターが使用されます。-INT-VLANサブTLVのいずれかがIPv6マルチキャストルーターアタッチメントについて同様に接続されていると主張する場合、そのVLANのマルチキャストIPv4ルーターには発生することが想定されます。-ROTION BRIDGEは、発信元の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への更新を宣伝する必要があります。これが不可能な場合、影響を受ける2つのLSPフラグメントは、原子作用として浸水する必要があります。既存の関心のあるVLANおよびスパニングツリールーツサブTLVのアップデートを受信すると、複数の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 sub-TLV type, set to 10 (INT-VLAN).
o タイプ：ルーター機能サブ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で指定されているように、このフィールドは、発信元によって保持されているニックネームを関連付けるために使用できます。この方法で使用されない場合、ゼロに設定されます。
o Interested VLANS: The Interested VLANs field is formatted as shown below.
o 興味のあるVLAN：興味のあるVLANSフィールドは、以下に示すようにフォーマットされています。
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]で指定されている指定された範囲のすべてのVLANの先頭にあるリンクに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. A range of one VLAN ID is indicated by setting them both to that VLAN ID value.
- vlan.start and vlan.End：このVLAN ID範囲は包括的です。1つのVLAN IDの範囲は、その両方をその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 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 任命されたフォワーダーステータスの失われたカウンター：これは、与えられた範囲のVLANのフォワーダーが任命されたポートの回数を数え、[RFC6325]のセクション4.8.3で説明されているように、指定されたフォワーダーであるというステータスを失いました。ゼロス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, only one spanning tree root could be seen on any particular port, there may be multiple ports in the same VLAN connected to different bridged LANs with different spanning tree roots.
o ルートブリッジ：ゼロ以上のスパニングツリールートブリッジIDのリストは、[RFC6325]、セクション4.9.3.2で説明されているように、指定された範囲のVLANのFORNISが指定されているすべてのポートに見られるルートブリッジIDのセットです。。もちろん、特定のポートには1つのスパニングツリールートのみが表示されますが、異なるスパニングツリールートを持つ異なるブリッジ付きLANに接続された同じVLANに複数のポートがある場合があります。
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 Sub-TLVは、提供された情報（マルチキャストルーターのアタッチメント、指定された転送状態のロストカウンター、およびルートブリッジ）が指定された範囲内のすべてのVLANで同じであると主張しています。そうでない場合、範囲はこの基準を満たすサブレンジに分割する必要があります。1つのVLAN IDの「範囲」でサブTLVを使用することは常に安全ですが、これはあまりにも冗長である可能性があります。
The VLAN Group Router Capability 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 announcing IS between the listed VLANs. It is structured as follows:
VLANグループルーター機能Sub-TLVは、[RFC6325]で指定されている2つ以上のVLAN IDで構成されています。セクション4.8.4。このサブTLVは、共有VLAN学習がリストされている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 sub-TLV type, set to 14 (VLAN-GROUP).
o タイプ：14（VLAN-GROUP）に設定されたルーター機能サブTLVタイプ。
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields, which may be zero.
o 長さ：4 2*n、nはゼロになる可能性のある二次VLAN IDフィールドの数です。
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：ゼロ以上のバイトペア。それぞれがRESVフィールドとして上位4ビット、VLAN IDとして12ビットが低い。
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 TLV (type 22).
MTU Sub-TLVは、[RFC6325]で指定されているリンクのMTUをオプションで発表するために使用されます。セクション4.2.4.4。拡張された到達可能性TLV内で発生します（タイプ22）。
+-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|F| Reserved | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability sub-TLV type, set to MTU sub-TLV 28.
o タイプ：MTU Sub-TLV 28に設定された拡張リーチビリティサブTLVタイプ。
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テストが失敗した場合のものです。
o Reserved: 7 bits that MUST be sent as zero and ignored on receipt.
o 予約済み：ゼロとして送信し、受領時に無視する必要がある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 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 [RFC6327]. The structure of the TRILL Neighbor TLV is as follows:
Trill Neighbor TLVは、[RFC6325]のセクション4.4.2.1および[RFC6327]で指定されているIS隣接TLVの代わりに、Trill IIH PDU（下のセクション4.1を参照）で使用されます。Trill Neighbor TLVの構造は次のとおりです。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|L| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information present for each neighbor is as follows:
各隣人に存在する情報は次のとおりです。
+-+-+-+-+-+-+-+-+
|F| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
| MAC Address | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+
o Type: TLV Type, set to TRILL Neighbor TLV 145.
o タイプ：TLVタイプ、Trill Neighbor TLV 145に設定。
o Length: 1 + 9*n, where n is the number of neighbor records which may be zero.
o 長さ：1 9*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 RESV: These 7 bits are reserved use and MUST be sent as zero and ignored on receipt.
o RESV：これらの7ビットは予約済みの使用であり、ゼロとして送信され、受領時に無視する必要があります。
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で失敗した場合のものです（[RFC6325]、セクション4.3.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 MAC Address: The MAC address of the neighbor as in the IS Neighbor TLV (6).
o MACアドレス：IS neighbor TLV（6）のように、隣人のMACアドレス。
As specified in [RFC6327] 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 RBridge 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.
[RFC6327]および[RFC6325]のセクション4.4.2.1で指定されているように、すべてのMACアドレスは1つのTLVに収まる場合があります。その場合、SフラグとLの両方のフラグがそのTLVの1つに設定されます。MACアドレスが1つのTLVに収まらない場合、L Flagゼロを備えたTrill Neighbor TLVの最高のMACアドレスも、他のTrill Neighbor TLV（おそらく別のTrill IIH PDU）のMACアドレスとして表示される必要があります。また、Sフラグゼロを備えたTrill Neighbor TLVの最低MACアドレスも、他のTrill Neighbor TLV（おそらく別のTrill IIH PDU）に表示される必要があります。Rbridgeに隣人がいないと考えている場合、SとLの両方がオンになる隣のレコードの空のリストを持つTrill Neighbor TLVを送信する必要があります。
Two PDUs are added to IS-IS, the MTU-probe and MTU-ack PDUs. They are used to optionally determine the MTU on a link between ISs as specified in [RFC6325], Section 4.3.2.
IS-IS、MTUプローブとMTU-ack PDUに2つのPDUが追加されます。これらは、[RFC6325]で指定されているISS間のリンクでMTUをオプションで決定するために使用されます。セクション4.3.2。
The MTU PDUs have the IS-IS PDU common header (up through the Maximum Area Addresses byte) with two new PDU Type numbers, one each, as listed in Section 6. They also have a 20-byte common fixed MTU PDU header as shown below.
MTU PDUには、セクション6に記載されている2つの新しいPDUタイプ番号を持つIS-IS PDU共通ヘッダー（最大領域アドレスアドレスバイト）があります。下。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (6 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パケット全体の長さを与えます。
The Probe ID field is an arbitrary 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プローブを発行し、対応するMTU-ACKにISによってコピーされたISによって設定された任意の48ビット数量です。たとえば、MTUプローブを作成すると、そのポートに比べてポート識別子とプローブシーケンス番号からこの数量を構成できます。
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.
プローブソースIDは、ANによって設定されています。ASは、MTUプローブをシステムIDに発行し、対応するMTU-ackにコピーされます。
The Ack Source ID is set to zero in MTU-probe PDUs. An IS issuing an MTU-ack sets this field to its System ID.
ACKソースIDは、MTUプローブPDUでゼロに設定されています。MTU-ackを発行しているのは、このフィールドをシステムIDに設定します。
The TLV area follows the MTU PDU header area. This area MAY contain an Authentication TLV and MUST be padded to the exact size being tested with the Padding TLV. 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 will be quite small compared with their minimum length (minimum 1470-byte MTU on an 802.3 link, for example), so this will not be a problem.
TLVエリアは、MTU PDUヘッダーエリアに従います。この領域には認証TLVが含まれている場合があり、パディングTLVでテストされる正確なサイズにパッドでパッドで塗装する必要があります。パディングTLVの最小サイズは2バイトであるため、固定フィールドとTLVを持つ必要な情報の合計長さが、目的の長さよりも1バイト少ない場合に、正確なサイズにパッドすることは不可能です。ただし、MTU PDUの固定フィールドの長さと実質的なTLVは、最小の長さ（たとえば、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 LAN IIH PDU used by the TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] specifies 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 Section 4.4 of [RFC6325] and in [RFC6327].
Trill IIH PDUは、Trillプロトコルで使用されるLAN IIH PDUのバリエーションです。Trill標準[RFC6325]のセクション4.4は、Trill IIHの内容とTrillでの使用がレイヤー3 LAN IIH PDUの使用とどのように異なるかを指定しています。Trill Neighborsの隣接状態機械は、[RFC6325]のセクション4.4および[RFC6327]で指定されています。
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses octet in the common header MUST be set to 0x01.
Trill IIH PDUでは、IS-IS共通ヘッダーと固定PDUヘッダーは、レベル1 LAN IIH PDUと同じです。最大面積は、一般的なヘッダーのOctetにアドレス指定する必要があります。0x01に設定する必要があります。
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor TLV (see Section 2.5).
IS-IS隣接TLV（6）はTrill IIHで使用されておらず、そこに現れると無視されます。代わりに、Trill IIH PDUSはTrill Neighbor 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 (1) as follows:
Trillは、[RFC6325]で指定されている固定ゼロエリアアドレスを使用します。セクション4.2.3。これは、次のように4バイトの領域アドレス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 0xC0 has been assigned to TRILL [RFC6328]. A Protocols Supported TLV (129, [RFC1195]) including that value MUST appear in TRILL IIH PDUs and LSP number zero PDUs.
NLPID 0XC0はTrill [RFC6328]に割り当てられています。その値を含むTLV（129、[RFC1195]）をサポートするプロトコルは、Trill IIH PDUSおよびLSP番号ゼロPDUに表示する必要があります。
IANA has allocated the existing registry code points listed in Section 5.1 and created two new registries with the initial contents as described in Section 5.2.
IANAは、セクション5.1にリストされている既存のレジストリコードポイントを割り当て、セクション5.2で説明されているように、初期コンテンツを含む2つの新しいレジストリを作成しました。
This document specifies two new 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 LSP, 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 Neighbor TLV（タイプ145）です。これらのTLVがトリルに対して許可されているPDUは、議論されているこのドキュメントのセクションとともに、下の表に示されています。最終的な「番号」列は、PDUのTLVの発生数、またはLSPの場合のPDUのセットの許容数を示します。これらの2つの場合、TLVが0、1、またはそれ以上に発生する可能性があることを示します。時代。
IANA 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 NUMBER
セクションTLV＃IIH LSP SNP番号
GADDR-TLV 2.1 142 - X - *
TRILL Neighbor TLV 2.5 145 X - - *
This document specifies eleven new sub-TLVs from existing sub-TLV sequences -- namely, VLAN-FLAGS, Enabled-VLANs, AppointedFwrdrs, TRILL Version (TRILL-VER), NICKNAME, TREES, TREE-RT-IDs, TREE-USE-IDs, INT-VLAN, VLAN-GROUP, and MTU. The TLVs in which these sub-TLVs occur are shown in the table below along with the section of this document where they are discussed.
このドキュメントは、既存のサブTLVシーケンスから11の新しいサブTLVを指定しています。つまり、VLAN-Flags、Enabled-Vlans、AditadedFwrdrs、Trill-ver（trill-ver）、nickname、trees、tree-rt-ids、tree-use-IDS、INT-VLAN、VLAN-GROUP、およびMTU。これらのサブTLVが発生するTLVは、議論されているこのドキュメントのセクションとともに、下の表に示されています。
Those sub-TLVs with an "X" in the column labeled "MT Port Capabil." are sub-TLVs of TLV 143 [RFC6165], the MT-PORT-CAP-TLV. Those sub-TLVs with an "X" in the column labeled "Router Capabil." are sub-TLVs of TLV 242, the IS-IS Router CAPABILITY TLV. Those sub-TLVs with an "X" in the column labeled "Extended IS Reach" are sub-TLVs of TLV 22, the Extended IS reachability TLV.
「MT Port Cabil」とラベル付けされた列に「x」があるこれらのサブTLV。TLV 143 [RFC6165]、MT-Port-CAP-TLVのサブTLVです。「ルーターキャパビル」とラベル付けされた列に「x」があるこれらのサブTLV。TLV 242のサブTLV、IS-ISルーター機能TLVです。「拡張IS REACH」というラベルのある列に「x」があるこれらのサブTLVは、TLV 22のサブTLVであり、拡張はReachability TLVです。
The final "NUM" column indicates the permitted number of occurrences of the sub-TLV cumulatively within all occurrences of their TLV in that TLV's carrying PDU (or set of PDUs in the case of LSP), as follows:
最終的な「num」列は、次のように、TLVがPDU（またはLSPの場合のPDUのセット）を運ぶTLVのすべての発生内で累積的にサブTLVの許可された発生数を示します。
0-1 = MAY occur zero or one times. If it occurs more than once, results are unspecified. 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 =ゼロまたは1回発生する場合があります。それが複数回発生した場合、結果は特定されていません。1 =正確に1回発生する必要があります。不在の場合、PDUは無視されます。それが複数回発生した場合、結果は特定されていません。* = 0、1、またはそれ以上発生する場合があります。
The values in the "Section" and "NUM" columns are irrelevant to the IANA sub-registries.
「セクション」と「num」列の値は、IANAサブリージストリーとは無関係です。
Section sub- MT Port Router Extended NUM
TLV# Capabil. Capabil. IS Reach
VLAN-FLAGS 2.2.1 1 X - - 1
Enabled-VLANs 2.2.2 2 X - - *
AppointedFwrdrs 2.2.3 3 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 - *
MTU 2.4 28 - - X 0-1
This document creates two new IS-IS PDUs -- namely, the MTU-PROBE-PDU and MTU-ACK-PDU, as described in Section 3. IANA assigned new PDU types to these PDUs and reflect them in a newly created PDU registry (see Appendix A).
このドキュメントでは、セクション3で説明されているように、2つの新しいIS-IS PDU、つまりMTU-Probe-PDUとMTU-FACK-PDUを作成します。IANAはこれらのPDUに新しいPDUタイプを割り当て、新しく作成されたPDUレジストリに反映しています（付録Aを参照してください）。
MTU-PROBE-PDU PDU Number: 23 MTU-ACK-PDU PDU Number: 28
mtu-probe-pdu pdu番号：23 mtu-ack-pdu pdu番号：28
IANA created a new sub-TLV IS-IS sub-registry for sub-TLVs within the Group Address (GADDR) TLV and specified an initial sub-TLV within that registry -- namely, the Group MAC Address (GMAC-ADDR) sub-TLV (1). The GMAC-ADDR sub-TLV may occur 0, 1, or more times in a GADDR TLV.
IANAは、グループアドレス（GADDR）TLV内のサブTLVの新しいSub-TLV IS-ISサブレジストリを作成し、そのレジストリ内で初期SUB-TLVを指定しました。TLV（1）。GMAC-ADDR SUB-TLVは、GADDR TLVで0、1、またはそれ以上発生する場合があります。
The initial sub-registry is shown below.
最初のサブレジストリを以下に示します。
Registry Name: IS-IS Group Address Type Codes for TLV 10 Reference: This document Registration Procedures: Expert Review [RFC5226]
レジストリ名：TLVのIS-ISグループアドレスタイプコード10リファレンス：このドキュメント登録手順：エキスパートレビュー[RFC5226]
Registry:
Value Group Address Type Code Reference
------- ----------------------------- ---------
0 Reserved This document
1 GMAC-ADDR This document
2-254 Unassigned This document
255 Reserved This document
For general TRILL protocol security considerations, see the TRILL base protocol standard [RFC6325].
一般的なTrillプロトコルのセキュリティに関する考慮事項については、Trill Base Protocol Standard [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認証が使用されている場合でも、ハローパケットのリプレイはサービス拒否条件を作成できます。詳細については、[RFC6039]を参照してください。これらの問題は、[RFC6325]のセクション6.2で説明されているものと範囲が類似しており、同じ緩和が適用される場合があります。
[ISO-10589] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002.
[ISO-10589] ISO/IEC 10589：2002、第2版、「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システムの中間システム内領域内領域内ルーティング交換プロトコル」、2002。
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、1990。
[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. and N. Shen, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", 2007.
[RFC4971] Vasseur、JP。N. Shen、「広告ルーター情報のための中間システム（IS-IS）拡張機能」、2007年。
[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、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", 2008.
[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、2008。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「レイヤー2システムのIS-ISへの拡張」、RFC 6165、2011年4月。
[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Rbridges：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", RFC 6327, July 2011.
[RFC6327] Eastlake、D.、Perlman、R.、Ghanwani、A.、Dutt、D。、およびV. Manral、「Rbridges：隣接」、RFC 6327、2011年7月。
[RFC6328] Eastlake, D., "IANA Considerations for Network Layer Protocol Identifiers", RFC 6328, July 2011.
[RFC6328] EastLake、D。、「ネットワークレイヤープロトコル識別子に対するIANAの考慮事項」、RFC 6328、2011年7月。
[802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006.
[802.1Q-2005]「ローカルおよびメトロポリタンエリアネットワーク /仮想ブリッジ付きローカルエリアネットワークのIEEE標準」、802.1Q-2005、2006年5月19日。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS暗号認証」、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、「ルーティングプロトコルの既存の暗号保護方法の問題」、RFC 6039、2010年10月。
The authors gratefully acknowledge the contributions and review by the following: Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular, thanks to Mike Shand for the detailed and helpful comments.
著者は、マイク・シャンド、スチュワート・ブライアント、ディノ・ファリナッチ、レス・ギンズバーグ、サム・ハートマン、ダン・ロマスカヌ、デイブ・ウォード、ラス・ホワイトの貢献とレビューに感謝し、レビューに感謝します。特に、詳細で有益なコメントをしてくれたMike Shandに感謝します。
The following is the suggested initial IS-IS PDU registry before MTU-PROBE-PDU and MTU-ACK-PDU, which should be added with this document as REFERENCE:
以下は、MTU-Probe-PDUおよびMTU-CACK-PDUの前に提案された初期IS-IS PDUレジストリです。このドキュメントを参照として追加する必要があります。
Registry Name: IS-IS PDUs Reference: This document Registration Procedures: IETF Review [RFC5226]
レジストリ名：IS-IS PDUSリファレンス：このドキュメント登録手順：IETFレビュー[RFC5226]
MNEMONIC PDU# REFERENCE
ニーモニックPDU＃参照
Unassigned 0-14
L1-LAN-HELLO-PDU 15 [ISO-10589]
L2-LAN-HELLO-PDU 16 [ISO-10589]
P2P-HELLO-PDU 17 [ISO-10589]
L1-LSP-PDU 18 [ISO-10589]
Unassigned 19
L2-LSP-PDU 20 [ISO-10589]
Unassigned 21-23
L1-CSNP-PDU 24 [ISO-10589]
L2-CSNP-PDU 25 [ISO-10589]
L1-PSNP-PDU 26 [ISO-10589]
L2-PSNP-PDU 27 [ISO-10589]
Unassigned 28-31
Authors' Addresses
著者のアドレス
Donald Eastlake Huawei 155 Beaver Street Milford, MA 01757 USA
ドナルド・イーストレイク・フアウェイ155ビーバー・ストリート・ミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
EMail: ayabaner@cisco.com
Dinesh Dutt Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA
Dinesh Dutt Cisco Systems 170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1-408-527-0955
EMail: ddutt@cisco.com
Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA
Radia Perlman Intel Labs 2200 Mission College Blvd.サンタクララ、CA 95054-1549 USA
Phone: +1-408-765-8080
EMail: Radia@alum.mit.edu
Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA
Anoop Ghanwani Brocade 130 Holger Way San Jose、CA 95134 USA
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu