Internet Engineering Task Force (IETF)                       D. Eastlake
Request for Comments: 6326                                        Huawei
Category: Standards Track                                    A. Banerjee
ISSN: 2070-1721                                                  D. Dutt
                                                              R. Perlman
                                                             A. Ghanwani
                                                               July 2011

Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS




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.


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


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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ドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。のセクション4.eで説明したように、コードのコンポーネントは、簡素化されたBSDライセンスのテキストを含める必要があり、この文書から抽出されました

the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


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
1. Introduction
1. はじめに

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は、ホップカウントとリンク状態ルーティングとカプセル化を使用して透明層2転送を提供TRILLプロトコル[RFC6325]を、標準化しました。 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]と連動して、TRILLをサポートするために、IS-IS [ISO-10589] [RFC1195]拡張のためのデータ形式とコード・ポイントを指定します。

1.1. Conventions Used in This Document
1.1. このドキュメントの表記規則

The terminology and acronyms defined in [RFC6325] are used herein with the same meaning.


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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。

2. TLV and Sub-TLV Extensions to IS-IS for TRILL
2. TLVとサブTLV拡張をするTRILLのためのIS-IS

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]に関連して、TLVのサブTLVのためのデータフォーマットとコードポイントがTRILL標準をサポートするようにIS-ISに追加指定します。 PDUまたはPDUの設定またはTLVサブTLVのためのそのようなTLVとして許容出現の数に関する情報は、セクション5で提供されます。

2.1. The Group Address TLV
2.1. グループアドレスTLV

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 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).

グループアドレス(GADDR)TLVは、LSP PDUにのみ実施されるTLVタイプ142、IS-ISと順番にマルチキャストグループのリスナーを広告することサブTLVを運びます。 2.1.1項では、以下のMACアドレスでリスナーをアドバタイズサブTLVを指定します。 IPアドレスなどの追加のアドレスの種類の追加のサブのTLVは、他の文書で指定されることが予想されます。 GADDR下サブTLVのサブTLVのタイプ(5.2節を参照)の新しいシリーズを構成します。

GADDR has the following format:


   |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 sub-TLVs: The Group Address TLV value consists of sub-TLVs formatted as described in [RFC5305].

下位のTLV O:グループアドレスTLV値は、[RFC5305]に記載されているようにフォーマットされたサブのTLVから成ります。

2.1.1. The Group MAC Address Sub-TLV
2.1.1. グループMACアドレスサブ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)サブ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 Length: Variable, minimum 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 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.

VLAN ID○:VLANが指定されていない場合、これは、このサブTLV、または値ゼロに後続のすべてのMACアドレスの12ビットのVLAN識別子を運びます。

o Number of Group Records: A 1-byte integer that is the number of group records in this sub-TLV.


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.


2.2. Multi-Topology-Aware Port Capability Sub-TLVs
2.2. マルチトポロジ対応ポート機能サブ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を指定します。

2.2.1. The Special VLANs and Flags Sub-TLV
2.2.1. 特別のVLANとフラグサブ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-フラグ)サブ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型:サブTLVのタイプ、MT-PORT-CAP VLAN-フラグサブTLV 1に設定。

o Length: 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]で指定されるように封入TRILL IIH PDUが送信されたポートのID、セクション4.4.2。

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節、一つはここに含まれなければなりません。それ以外の場合は、フィールドはゼロに設定されています。このフィールドは、ディレクトリサービス等を介してユニキャストデータの出力は(RBridge)を決定し、それらの最初のホップが正しくTRILLカプセル化データフレームをフォーマットする入口ニックネームとして挿入するため、そのニックネームを必要とするインテリジェントエンドステーションをサポートすることです。 [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

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]に記載されているセクションで指定されるように、いずれかに設定以下の意味を有します。

           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.

4.4.2発信はIS AFは、それが含むIIH PDUが送信されたVLANとポートのフォワーダに任命されると考えています。

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.


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.

R O:予約ビット。ゼロとして送られて、領収書の上で無視しなければなりません。

2.2.2. Enabled-VLANs Sub-TLV
2.2.2. 有効-VLANのサブTLV

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:


   |     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タイプ:サブTLVタイプ、MT-PORT-CAP有効-VLANのサブTLV 2に設定します。

o Length: Variable, minimum 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.

VLANビットマップ(O)最上位ビットは、開始VLAN IDにVLANが等しい示し、次の最上位ビットは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.


2.2.3. Appointed Forwarders Sub-TLV
2.2.3. 就任フォワーダサブTLV

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は、彼らは[RFC6325]のセクション4.2.4で指定されたVLAN IDの一つまたはそれ以上の範囲の指定VLAN-Xフォワーダであること、リンク上の他のISに通知するために任命フォワーダサブTLVを使用します。これは、次の形式になります。

   |     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のAppointedFwrdrsサブ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 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のポート上のフォワーダは何の影響もありません。

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範囲のための任命フォワーダーとして発生する可能性があります。

2.3. Sub-TLVs for the Router Capability TLV
2.3. ルータ能力TLVのためのサブのTLV

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.


2.3.1. The TRILL Version Sub-TLV
2.3.1. TRILLバージョンサブ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].


   | Type          |                  (1 byte)
   | Length        |                  (1 byte)
   | Max-version   |                  (1 byte)

o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).


o Length: 1.


o Max-version: Set to maximum version supported.


2.3.2. The Nickname Sub-TLV
2.3.2. ニックネームサブTLV

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.


   |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 Length: 5*N, where N is the number of nickname records present.

O長さ:N本ニックネームレコードの数である5 * 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 Nickname: This is an unsigned 16-bit integer as specified in Section 3.7 of [RFC6325].


2.3.3. The Trees Sub-TLV
2.3.3. 木サブTLV

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:


   |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 Length: 6.


o Number of trees to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].


o Maximum trees able to compute: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].


o Number of trees to use: An unsigned 16-bit integer as specified in Section 4.5 of [RFC6325].


2.3.4. The Tree Identifiers Sub-TLV
2.3.4. ツリー識別子サブTLV

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:


   |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 Length: 2 + 2*n, where n is the number of nicknames listed.

O長さ:nは、列挙されたニックネームの数は2 + 2 * 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 Nickname: The nickname at which a distribution tree is rooted.


2.3.5. The Trees Used Identifiers Sub-TLV
2.3.5. 木使用される識別子サブTLV

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.


2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV
2.3.6. 興味のVLANとスパニングツリーのルーツサブTLV

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.


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のセットでは、VLANの労働組合は、発信元が少なくとも1つのポート上でフォワーダに任命されたためにVLANの正確に設定する必要があります。このサブTLVのすべての出現の範囲である、とVLANは、の範囲でありますVLANについて提供された情報がすべてのインスタンスで同じでない限り、複数のVLANサブTLVのISのためには、重複してはなりません。しかし、過渡状態として、これらの条件に違反することができます。 VLANはISのための任意のINT-VLANサブTLVにリストされていない場合、それは、そのVLANのトラフィックの受信に興味であると仮定されます。 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 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ルータに取り付けることを想定しているされています。 - 元のための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.


The sub-TLV layout is as follows:


   |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 Length: 10 + 6*n, where n is the number of root bridge IDs.

O長さ:nはルートブリッジIDの数である10 + 6 * nを、。

o Nickname: As specified in [RFC6325], Section, 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 Interested VLANS: The Interested VLANs field is formatted as shown below.


        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, item 5.1.

- M4、M6:これらのビットは、セクション4.2.4.4 [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と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 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 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]で説明した通りであるが、指定された範囲内のVLANのフォワーダに任命されているすべてのポート、4.9節に見られるルートブリッジIDの集合です。 3.2。もちろん、唯一のスパニングツリールートは、任意の特定のポート上で見ることができ、一方で、異なるスパニングツリーの根と異なるブリッジ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サブTLVは、(ステータス失わカウンタ、およびルートブリッジフォワーダ任命マルチキャストルータアタッチメント)提供された情報が、指定された範囲内のすべてのVLANに対して同じであることを主張します。そうでない場合は、範囲がこの基準を満たすサブレンジに分割する必要があります。 1つのVLAN IDの「範囲」でサブTLVを使用することが常に安全であるが、これはあまりにも冗長かもしれません。

2.3.7. The VLAN Group Sub-TLV
2.3.7. VLANグループサブ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グループルータ機能サブTLVは、[RFC6325]、セクション4.8.4で指定されるように二つ以上のVLAN IDから成ります。このサブ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 Length: 4 + 2*n, where n is the number of secondary VLAN ID fields, which may be zero.

O長さ:nはゼロであってもよいセカンダリVLAN IDフィールドの数は4 + 2 * 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 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:VLAN IDとしてRESVフィールドとして上位4ビットと下位12ビットのゼロまたはそれ以上のバイトペア、それぞれ。

2.4. MTU Sub-TLV of the Extended Reachability TLV
2.4. 拡張到達可能性TLVのMTUサブTLV

The MTU sub-TLV is used to optionally announce the MTU of a link as specified in [RFC6325], Section It occurs within the Extended Reachability TLV (type 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型:拡張到達可能性サブTLVのタイプ、MTUサブTLV 28に設定されています。

o Length: 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 Reserved: 7 bits that MUST be sent as zero and ignored on receipt.


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].


2.5. TRILL Neighbor TLV
2.5. TRILLネイバーTLV

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 of [RFC6325] and in [RFC6327]. The structure of the TRILL Neighbor TLV is as follows:

[RFC6325]のセクション4.4.2.1および[RFC6327]で指定されるようにTLVがTRILL IIHのPDUで使用されてTRILLネイバーは、IS隣接TLVの代わりに(セクション4.1以下を参照のこと)。次のようにTRILL近隣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近隣TLV 145に設定します。

o Length: 1 + 9*n, where n is the number of neighbor records which may be zero.

O長さ:nはゼロであってもよい隣接レコードの数は、1つの+ 9×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 RESV: These 7 bits are reserved use and MUST be sent as zero and ignored on receipt.


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を参照)で失敗した場合、このビットが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 MAC Address: The MAC address of the neighbor as in the IS Neighbor TLV (6).

O MACアドレス:ISネイバーTLVのように、ネイバーのMACアドレス(6)。

As specified in [RFC6327] and Section 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アドレスとは、ケースSとLの両方のフラグがそのTLV内の1つに設定される、1 TLVに適合することができます。 MACアドレスは1 TLVに収まらない場合は、LフラグがゼロとTRILLの近隣TLVで最高のMACアドレスもいくつかの他のTRILLのネイバー(おそらく異なるTRILL IIH PDUで)TLVでのMACアドレスとして表示される必要があります。また、SフラグがゼロとTRILLネイバーTLV内で最小のMACアドレスはまた、いくつかの他のTRILLネイバー(おそらくは異なるTRILLのIIHのPDUで)TLVに現れなければなりません。 RBridgeは、それが何の隣人を持っていないと考えている場合は、上の両方のSとLのビットを持っていますネイバーRECORDSの空のリスト、とTRILLの近隣TLVを送らなければなりません。

3. The MTU PDUs

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.

2つのPDUは、IS-IS、MTU-プローブおよびMTU-ACK PDUのに追加されます。これらは、[RFC6325]で指定されるようにIS間のリンク上の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は(アップ最大面積アドレスを通じてバイト)のIS-IS PDU共通ヘッダを有する第6節に記載されているように示されるように、これらはまた、20バイトの共通固定MTU PDUヘッダを有する、2つの新しい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.


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.


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. An IS issuing an MTU-ack sets this field to its System 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)それらの最小の長さに比べて非常に小さくなるので、これは問題にならないであろう。

4. Use of Existing PDUs and TLVs

The sub-sections below provide details of TRILL use of existing PDUs and TLVs.



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ネイバーの隣接状態機械は、[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と同じです。共通ヘッダ内の最大面積アドレスオクテットは0×01に設定しなければなりません。

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 PDUはTRILL近隣TLVを使用します(セクション2.5を参照してください)。

4.2. Area Address
4.2. エリア住所

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:


             |   0x01, Area Address Type     |   (1 byte)
             |   0x02, Length of Value       |   (1 byte)
             |   0x01, Length of Address     |   (1 byte)
             |   0x00, zero Area Address     |   (1 byte)
4.3. Protocols Supported
4.3. サポートされるプロトコル

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のは、[RFC6328]をTRILLするために割り当てられています。プロトコルはTRILL IIH PDUおよびLSP番号ゼロのPDUに現れなければならないという値を含む(129、[RFC1195])TLVをサポートします。

5. IANA Considerations
5. IANAの考慮事項

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.


5.1. Allocations from Existing Registries
5.1. 既存のレジストリからの割り当て

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.

つまり、グループはTLVアドレス(GADDR-TLVを、タイプ142)とTRILLの近隣TLV(タイプ145) - この文書では、2つの新しいIS-IS TLVタイプを指定します。これらのTLVは、TRILLに対して許可されたPDUは、それらが議論されている。この文書のセクションと一緒に以下の表に示されています。最終的な「番号」欄は、TLVが0、1、または複数の発生する可能性があることを示す「*」は、そのPDUにTLVの出現の可能回数を示し、またはこれら2つの場合であるLSPの場合にはPDUのセット回。

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は、(「項」と、そのレジストリに無関係な「番号」の列を無視する)IANA IS-IS TLVレジストリにこれら2つのコード・ポイントを記録しました。



GADDR-TLV 2.1 142 - X - * TRILL Neighbor TLV 2.5 145 X - - *

GADDR-TLV 2.1 142 - X - * TRILL近隣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、有効-のVLAN、AppointedFwrdrs、TRILLバージョン(TRILL-VER)、ニックネーム、TREES、TREE-RT-IDは、TREE-USE- IDは、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.

ラベル欄の「X」とそれらのサブTLVの「MTポートCapabil。」 TLV 143 [RFC6165]のサブTLVの、MT-PORT-CAP-TLVです。標識された欄の「X」を有するものサブTLVの「ルータCapabil。」 TLV 242のサブTLVを、IS-ISルータCAPABILITY TLVです。標識された欄の「X」を有するものサブTLVのTLV 22のれるサブTLVは、IS拡張到達可能性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:


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 = 0または1回起こり得ます。それが複数回発生した場合、結果は不定です。 1 =は、一度だけ行う必要があります。不在の場合は、PDUは無視されます。それが複数回発生した場合、結果は不定です。 * = 0、1、または複数回発生するかもしれません。

The values in the "Section" and "NUM" columns are irrelevant to the IANA sub-registries.


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

セクションのサブMTポートルータは、NUM TLV#Capabilを拡張します。 Capabil。リーチVLAN-FLAGS IS 2.2.1 1 X - - 1有効-のVLAN 2.2.2 2 X - - * AppointedFwrdrs 2.2.3 3 X - - *ニックネーム2.3.2 6 - X - * TREES 2.3.3 7 - X - 0-1 TREE-RT-IDは2.3.4 8 - X - * TREE-USE-IDは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

5.2. New Sub-Registries Created
5.2. 作成した新しいサブレジストリ

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).

すなわち、MTU-PROBE-PDUおよびMTU-ACK-PDU、第3節で説明したようにIANAがこれらのPDUに新しいPDUタイプを割り当て、新しく作成されたPDUのレジストリに反映( - このドキュメントは、2つの新しいIS-IS PDUを作成し、 )の付録Aを参照してください。



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が新しいサブTLVは、IS-ISグループアドレス内のサブTLVのためのサブレジストリ(GADDR)TLVを作成し、そのレジストリ内の初期サブTLVを指定した - すなわち、グループMACアドレス(GMAC-ADDR)のサブTLV(1)。 GMAC-ADDRサブ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 10参考のためにIS-ISグループのアドレスタイプ・コード:この文書の登録手順:エキスパートレビュー[RFC5226]

      Value     Group Address Type Code        Reference
      -------   -----------------------------  ---------
       0        Reserved                       This document
       1        GMAC-ADDR                      This document
      2-254     Unassigned                     This document
      255       Reserved                       This document
6. Security Considerations

For general TRILL protocol security considerations, see the 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の認証が使用されている場合でも、Helloパケットのリプレイは、サービス拒否の状態を作成することができます。詳細については、[RFC6039]を参照してください。これらの問題は、[RFC6325]のセクション6.2で説明したものと範囲に同様であり、同一の緩和策が適用される場合があります。

7. References
7.1. Normative References
7.1. 引用規格

[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版、「中間システム中間にシステムのドメイン内ルーティング交換プロトコル接続モード・ネットワーク・サービス(ISO 8473)の提供のための議定書と併せて使用するために」、2002。

[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", 1990.

[RFC1195] Callon、R.は、1990年、 "OSIの使用は、TCP / IPやデュアル環境におけるルーティングのためのIS-IS"。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.シェン、「中間システムへの中間システム(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]李、T.とH.スミットは、2008年、 "トラフィックエンジニアリングのための拡張機能-IS IS"。

[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.

[RFC6165]バネルジー、A.、およびD.区、RFC 6165、2011年4月 "の拡張レイヤ2のシステムのためのIS-ISは、"。

[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, July 2011.

[RFC6325]パールマン、R.、イーストレーク、D.、ダット、D.、ガイ、S.、およびA. Ghanwani、 "RBridges:基本プロトコル仕様"、RFC 6325、2011年7月。

[RFC6327] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", RFC 6327, July 2011.

[RFC6327]イーストレイク、D.、パールマン、R.、Ghanwani、A.、ダット、D.、およびV. Manral、 "RBridges:隣接"、RFC 6327、2011年7月。

[RFC6328] Eastlake, D., "IANA Considerations for Network Layer Protocol Identifiers", RFC 6328, July 2011.

[RFC6328]イーストレイク、D.、 "ネットワーク層プロトコル識別子のためのIANAの考慮事項"、RFC 6328、2011年7月。

7.2. Informative References
7.2. 参考文献

[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]、802.1Q-2005 "ローカルおよびメトロポリタンエリアネットワーク/仮想ブリッジローカルエリアネットワークのためのIEEE規格"、2006年5月19日。

[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.

[RFC5304]李、T.、およびR.アトキンソンは、 "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]はバティア、M.、Manral、V.は、李、T.、アトキンソン、R.、ホワイト、R.、およびM. Fantoは、 "IS-ISジェネリック暗号認証"、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.、バティア、M.、Jaeggli、J.、およびR.ホワイト、 "ルーティングプロトコルのための既存の暗号化保護方法の問題"、RFC 6039、2010年10月。

8. Acknowledgements

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.


Appendix A. Initial IS-IS PDU Registry

付録A.の初期には、IS-IS PDUレジストリ

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:


Registry Name: IS-IS PDUs Reference: This document Registration Procedures: IETF Review [RFC5226]




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

割り当てられていない0-14 L1 LAN Hello PDUは15 [ISO 10589] L2 LAN Hello PDUは16 [ISO 10589] P2P Hello PDUは17 [ISO 10589] L1-PDU-LSP 18 [ISO 10589]未割り当て19 L2-LSP PDU 20 [ISO 10589]未割り当て21~23 CSNP L1-PDU 24 [ISO 10589] CSNP L2 PDU 25 [ISO 10589] L1 PSNP PDU 26 [ISO 10589] L2 PDU PSNP 27 [ISO 10589]未割り当て28-31

Authors' Addresses


Donald Eastlake Huawei 155 Beaver Street Milford, MA 01757 USA

ドナルドイーストレイクHuawei社155ビーバー通りミルフォード、MA 01757 USA

Phone: +1-508-333-2270 EMail:

電話:+ 1-508-333-2270 Eメール

Ayan Banerjee Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA

アヤンバネルジーシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134 USA



Dinesh Dutt Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA

ディネッシュダットシスコシステムズ170西タスマン・ドライブサンノゼ、CA 95134-1706 USA

Phone: +1-408-527-0955 EMail:

電話:+ 1-408-527-0955 Eメール

Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA

ラディア・パールマンインテル・ラボ2200ミッション・カレッジブルバードサンタクララ、CA 95054-1549 USA

Phone: +1-408-765-8080 EMail:

電話:+ 1-408-765-8080 Eメール

Anoop Ghanwani Brocade 130 Holger Way San Jose, CA 95134 USA

アヌープGhanwaniブロケード130ホルガー・ウェイサンノゼ、CA 95134 USA

Phone: +1-408-333-7149 EMail:

電話:+ 1-408-333-7149 Eメール