[要約] RFC 7357は、TRILLネットワークでのエンドステーションアドレスの配布情報を管理するためのESADIプロトコルに関するものです。このRFCの目的は、TRILLネットワーク内のエンドステーションアドレスの効率的な配布と管理を実現することです。
Internet Engineering Task Force (IETF) H. Zhai
Request for Comments: 7357 F. Hu
Updates: 6325 ZTE
Category: Standards Track R. Perlman
ISSN: 2070-1721 Intel Labs
D. Eastlake 3rd
Huawei
O. Stokes
Extreme Networks
September 2014
Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol
多数のリンクの透過的な相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル
Abstract
概要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).
IETF TRILL（多数のリンクの透過的相互接続）プロトコルは、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークで構成することなく、最小コストのペアワイズデータ転送を提供します。 TRILLは、ユニキャストとマルチキャストの両方のトラフィックのマルチパスをサポートしています。 TRILLプロトコルを実装するデバイスは、TRILLスイッチまたはRBridge（ルーティングブリッジ）と呼ばれます。
ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label (VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible.
ESADI（End Station Address Distribution Information）は、TRILLスイッチがデータラベル（VLANまたは細粒度ラベル）スコープの方法で、関連するESADIに参加しているTRILLスイッチにエンドステーションアドレスと到達可能性情報を通信できるオプションのプロトコルです。データラベル。このドキュメントはRFC 6325、特にESADIプロトコルのドキュメントを更新し、下位互換性はありません。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7357.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7357で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Content and Precedence .....................................5
1.2. Terminology ................................................5
2. ESADI Protocol Overview .........................................6
2.1. ESADI Virtual Link ........................................10
2.2. ESADI Neighbor Determination ..............................10
2.3. ESADI Payloads ............................................11
3. ESADI DRB (Designated RBridge) Determination ...................11
4. ESADI PDU Processing ...........................................12
4.1. Unicasting ESADI PDUs .....................................12
4.2. General Transmission of ESADI PDUs ........................13
4.3. General Receipt of ESADI PDUs .............................14
4.4. ESADI Reliable Flooding ...................................14
5. End Station Addresses ..........................................15
5.1. Learning Confidence Level .................................15
5.2. Forgetting End Station Addresses ..........................16
5.3. Duplicate MAC Address .....................................16
6. ESADI-LSP Contents .............................................18
6.1. ESADI Parameter Data ......................................19
6.2. MAC-Reachability TLV ......................................20
6.3. Default Authentication ....................................21
7. IANA Considerations ............................................21
7.1. ESADI Participation and Capability Flags ..................22
7.2. TRILL GENINFO TLV .........................................23
8. Security Considerations ........................................24
8.1. Privacy Considerations ....................................25
9. Acknowledgements ...............................................26
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................28
Appendix A. Interoperability and Changes to RFC 6325 ..............29
A.1. ESADI PDU Changes .........................................29
A.2. Unicasting Changes ........................................30
A.3. Message Timing Changes and Suggestions ....................30
A.4. Duplicate Address Reachability ............................30
The TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this with the IS-IS (Intermediate System to Intermediate System) [IS-IS] [RFC1195] [RFC7176] link-state routing protocol using a header with a hop count. The design supports optimization of the distribution of multi-destination frames and two types of data labeling: VLANs (Virtual Local Area Networks) [RFC6325] and FGLs (fine-grained labels) [RFC7172]. Devices that implement TRILL are called TRILL switches or RBridges (Routing Bridges).
TRILL（多数のリンクの透過的相互接続）プロトコル[RFC6325]は、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークでの構成なしで、最小コストのペアワイズデータ転送、一時的なループの期間中も安全な転送、およびマルチパスのサポートを提供しますユニキャストとマルチキャストの両方のトラフィックの。 TRILLは、IS-IS（中間システムから中間システム）[IS-IS] [RFC1195] [RFC7176]リンクステートルーティングプロトコルで、ホップカウントのあるヘッダーを使用してこれを実現します。この設計は、複数宛先フレームの配布の最適化と、VLAN（仮想ローカルエリアネットワーク）[RFC6325]およびFGL（細粒度ラベル）[RFC7172]の2種類のデータラベル付けをサポートしています。 TRILLを実装するデバイスは、TRILLスイッチまたはRBridge（ルーティングブリッジ）と呼ばれます。
There are five ways a TRILL switch can learn end station addresses, as described in Section 4.8 of [RFC6325]. One of these is the ESADI (End Station Address Distribution Information) protocol, which is an optional Data Label scoped way by which TRILL switches can communicate with each other information such as end station addresses and their TRILL switch of attachment. A TRILL switch that is announcing interest in a Data Label MAY use the ESADI protocol to announce the end station address of some or all of its attached end stations in that Data Label to other TRILL switches that are running ESADI for that Data Label. (In the future, ESADI may also be used for other address and reachability information.)
[RFC6325]のセクション4.8で説明されているように、TRILLスイッチが端末のアドレスを学習する方法は5つあります。これらの1つはESADI（End Station Address Distribution Information）プロトコルです。これは、オプションのデータラベルスコープの方法で、TRILLスイッチは、エンドステーションアドレスやアタッチメントのTRILLスイッチなどの相互情報と通信できます。データラベルに関心があることを通知しているTRILLスイッチは、ESADIプロトコルを使用して、そのデータラベルに接続されている一部またはすべてのエンドステーションのエンドステーションアドレスを、そのデータラベルのESADIを実行している他のTRILLスイッチに通知できます。 （将来、ESADIは他のアドレスおよび到達可能性情報にも使用される可能性があります。）
By default, TRILL switches with connected end stations learn addresses from the data plane when ingressing and egressing native frames, although such learning can be disabled. The ESADI protocol's potential advantages over data plane learning include the following:
デフォルトでは、接続されたエンドステーションを持つTRILLスイッチは、ネイティブフレームの入出力時にデータプレーンからアドレスを学習しますが、そのような学習は無効にすることができます。 ESADIプロトコルのデータプレーン学習に対する潜在的な利点は次のとおりです。
1. Security advantages:
1. セキュリティ上の利点：
a) The ESADI protocol can be used to announce end stations with an authenticated enrollment (for example, enrollment authenticated by cryptographically based EAP (Extensible Authentication Protocol) [RFC3748] methods via [802.1X]).
a) ESADIプロトコルは、認証された登録（たとえば、暗号化ベースのEAP（Extensible Authentication Protocol）[RFC3748]メソッド[[802.1X]を介して認証された登録）でエンドステーションをアナウンスするために使用できます。
b) The ESADI protocol supports cryptographic authentication of its message payloads for more secure transmission.
b) ESADIプロトコルは、メッセージペイロードの暗号化認証をサポートし、より安全な伝送を実現します。
2. Fast update advantages: The ESADI protocol provides a fast update of end station MAC (Media Access Control) addresses and their TRILL switch of attachment. If an end station is unplugged from one TRILL switch and plugged into another, ingressed frames with that end station's MAC address as their destination can be black-holed. That is, they can be sent just to the older egress TRILL switch that the end station was connected to until cached address information at some remote ingress TRILL switch times out, possibly for tens of seconds [RFC6325].
2.高速更新の利点：ESADIプロトコルは、エンドステーションのMAC（Media Access Control）アドレスと、アタッチメントのTRILLスイッチの高速更新を提供します。端末が1つのTRILLスイッチから外され、別のTRILLスイッチに接続されている場合、宛先としてその端末のMACアドレスを持つ入力フレームがブラックホールになる可能性があります。つまり、リモートイングレスTRILLスイッチのキャッシュされたアドレス情報がタイムアウトするまで、おそらく数十秒間[RFC6325]になるまで、エンドステーションが接続されていた古いエグレスTRILLスイッチにのみ送信できます。
MAC address reachability information, some ESADI parameters, and optional authentication information are carried in ESADI packets rather than in the TRILL IS-IS protocol. As specified below, ESADI is, for each Data Label, a virtual logical topology overlay in the TRILL topology. An advantage of using ESADI over using TRILL IS-IS is that the end station attachment information is not flooded to all TRILL switches but only to TRILL switches advertising ESADI participation for the Data Label in which those end stations occur.
MACアドレス到達可能性情報、一部のESADIパラメータ、およびオプションの認証情報は、TRILL IS-ISプロトコルではなく、ESADIパケットで伝送されます。以下に示すように、ESADIは、データラベルごとに、TRILLトポロジ内の仮想論理トポロジオーバーレイです。 TRILL IS-ISを使用するよりもESADIを使用する利点は、エンドステーション接続情報がすべてのTRILLスイッチにフラッディングされるのではなく、それらのエンドステーションが発生するデータラベルのESADI参加をアドバタイズするTRILLスイッチにのみフラッディングされることです。
This document updates [RFC6325], the TRILL base protocol specification, replacing the description of the TRILL ESADI protocol (Section 4.2.5 of [RFC6325], including all subsections), providing more detail on ESADI, updating other ESADI-related sections of [RFC6325], and prevailing over [RFC6325] in any case where they conflict. For this reason, familiarity with [RFC6325] is particularly assumed. These changes include a change to the format of ESADI-LSPs (ESADI Link State Protocol Data Units) that is not backwards compatible; this change is justified by the substantially increased amount of information that can be carried and in light of the very limited, if any, deployment of RFC 6325 ESADI. These changes are further discussed in Appendix A.
このドキュメントは、TRILL基本プロトコル仕様である[RFC6325]を更新し、TRILL ESADIプロトコルの説明（[RFC6325]のセクション4.2.5、すべてのサブセクションを含む）を置き換え、ESADIの詳細を提供し、[の他のESADI関連セクションを更新します。 RFC6325]、およびそれらが競合するすべての場合において[RFC6325]に優勢。このため、特に[RFC6325]に精通していることを前提としています。これらの変更には、下位互換性のないESADI-LSP（ESADIリンク状態プロトコルデータユニット）の形式の変更が含まれます。この変更は、運ぶことができる情報量が大幅に増加し、RFC 6325 ESADIの展開が非常に限られている場合はそれに照らして正当化されます。これらの変更については、付録Aでさらに説明します。
Section 2 of this document is the ESADI protocol overview. Section 3 specifies ESADI DRB (Designated RBridge) determination. Section 4 discusses the processing of ESADI PDUs. Section 5 discusses interaction with other modes of end station address learning. Section 6 describes the ESADI-LSP and its contents.
このドキュメントのセクション2は、ESADIプロトコルの概要です。セクション3では、ESADI DRB（指定RBridge）の決定を指定しています。セクション4では、ESADI PDUの処理について説明します。セクション5では、エンドステーションアドレス学習の他のモードとの相互作用について説明します。セクション6では、ESADI-LSPとその内容について説明します。
This document uses the acronyms defined in [RFC6325], in addition to the following:
この文書では、以下に加えて、[RFC6325]で定義されている頭字語を使用しています。
Data Label: VLAN or FGL.
データラベル：VLANまたはFGL。
ESADI RBridge: An RBridge that is participating in ESADI for one or more Data Labels.
ESADI RBridge：1つ以上のデータラベルのESADIに参加しているRBridge。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
LSP: Link State PDU [IS-IS].
LSP：リンク状態PDU [IS-IS]。
LSP number zero: A Link State PDU with fragment number equal to zero.
LSP番号ゼロ：フラグメント番号がゼロに等しいリンク状態PDU。
PDU: Protocol Data Unit.
PDU：プロトコルデータユニット。
TRILL switch: An alternative name for an RBridge.
TRILLスイッチ：RBridgeの別名。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Capitalized IANA-related terms such as "IETF Review" are to be interpreted as described in [RFC5226].
「IETFレビュー」などのIANA関連の用語は、[RFC5226]で説明されているように解釈されます。
ESADI is a Data Label scoped way for TRILL switches (also known as RBridges) to announce and learn end station addresses rapidly and securely. An RBridge that is announcing participation in ESADI for one or more Data Labels is called an ESADI RBridge.
ESADIは、TRILLスイッチ（RBridgeとも呼ばれます）がエンドステーションのアドレスを迅速かつ安全に通知および学習するためのデータラベルスコープの方法です。 1つ以上のデータラベルのESADIへの参加を発表しているRBridgeは、ESADI RBridgeと呼ばれます。
ESADI is an optional protocol that is separate from the mandatory TRILL IS-IS implemented by all RBridges in a campus. There is a separate ESADI instance for each Data Label (VLAN or FGL) if ESADI is being used for that Data Label. In essence, for each such Data Label, there is a modified instance of the IS-IS reliable flooding mechanism in which ESADI RBridges may choose to participate. (These are not the instances specified in [RFC6822].) Multiple ESADI instances may share implementation components within an RBridge as long as that sharing preserves the independent operation of each instance of the ESADI protocol. For example, the ESADI link state database could be a single database with a field in each record indicating the Data Label to which it applies, or it could be a separate database per Data Label. However, the ESADI update process operates separately for each ESADI instance and independently from the TRILL IS-IS update process.
ESADIは、キャンパス内のすべてのRBridgeによって実装される必須のTRILL IS-ISとは別のオプションのプロトコルです。 ESADIがそのデータラベルに使用されている場合、データラベル（VLANまたはFGL）ごとに個別のESADIインスタンスがあります。本質的に、そのような各データラベルに対して、ESADI RBridgeが参加することを選択できるIS-IS信頼性の高いフラッディングメカニズムの変更されたインスタンスがあります。 （これらは[RFC6822]で指定されたインスタンスではありません。）複数のESADIインスタンスは、共有によってESADIプロトコルの各インスタンスの独立した動作が維持される限り、RBridge内の実装コンポーネントを共有できます。たとえば、ESADIリンク状態データベースは、それが適用されるデータラベルを示す各レコード内のフィールドを持つ単一のデータベースであるか、またはデータラベルごとに個別のデータベースである可能性があります。ただし、ESADI更新プロセスは、ESADIインスタンスごとに個別に、TRILL IS-IS更新プロセスとは独立して動作します。
ESADI does no routing calculations, so there is no reason for pseudonodes in ESADI and none are created. (Pseudonodes [IS-IS] are a construct for optimizing routing calculations.) Furthermore, a relatively large amount of ESADI data will have to be distributed, under some circumstances, using ESADI mechanisms; this would require a large number of ESADI-LSP fragments. ESADI-LSP, ESADI-CSNP, and ESADI-PSNP (ESADI Link State PDU, Complete Sequence Number PDU, and Partial Sequence Number PDU) payloads are therefore formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356] (see also Section 6). This allows up to 2**16 fragments but does not support link state data associated with pseudonodes.
ESADIはルーティング計算を行わないため、ESADIに疑似ノードが存在する理由はなく、何も作成されません。 （疑似ノード[IS-IS]は、ルーティング計算を最適化するための構成です。）さらに、状況によっては、ESADIメカニズムを使用して、比較的大量のESADIデータを配布する必要があります。これには、多数のESADI-LSPフラグメントが必要になります。したがって、ESADI-LSP、ESADI-CSNP、およびESADI-PSNP（ESADIリンク状態PDU、完全シーケンス番号PDU、および部分シーケンス番号PDU）ペイロードは、拡張レベル1サーキットスコープ（E-L1CS）PDU [RFC7356]としてフォーマットされます（参照セクション6も）。これにより、最大2 ** 16のフラグメントが許可されますが、疑似ノードに関連付けられたリンク状態データはサポートされません。
After the TRILL Header, ESADI packets have an inner Ethernet header with the Inner.MacDA of "All-Egress-RBridges" (formerly called "All-ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL of interest, and the "L2-IS-IS" Ethertype followed by the ESADI payload, as shown in Figure 1.
TRILLヘッダーの後、ESADIパケットには、 "All-Egress-RBridges"（以前は "All-ESADI-RBridges"と呼ばれていた）のInner.MacDAを持つ内部イーサネットヘッダー、対象のVLANまたはFGLを指定する内部データラベル、および図1に示すように、「L2-IS-IS」Ethertypeの後にESADIペイロードが続きます。
+--------------------------------+
| Link Header |
+--------------------------------+
| TRILL Data Header |
+--------------------------------+
| Inner Ethernet Addresses |
+--------------------------------+
| Data Label |
+--------------------------------+
| L2-IS-IS Ethertype |
+--------------------------------+
| ESADI Payload |
+--------------------------------+
| Link Trailer |
+--------------------------------+
Figure 1: TRILL ESADI Packet Overview
図1：TRILL ESADIパケットの概要
TRILL ESADI packets sent on an Ethernet link are structured as shown in Figure 2. The outer VLAN tag will not be present if it was not included by the Ethernet port that sent the packet.
イーサネットリンクで送信されるTRILL ESADIパケットは、図2に示すように構成されます。外部VLANタグは、パケットを送信したイーサネットポートに含まれていない場合、存在しません。
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Destination Addr. | Sending RBridge Port MAC Addr.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending RBridge Port MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Ethernet frame tagging including optional Outer.VLAN tag...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = TRILL 0x22F3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges (cont.) | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS 0x22F4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS (Frame Check Sequence) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ESADI Ethernet Link Packet Format
図2：ESADIイーサネットリンクパケットの形式
The Next Hop Destination Address or Outer.MacDA is the All-RBridges multicast address if the ESADI PDU is being multicast. If it is being unicast, the Next Hop Destination Address is the unicast address of the next-hop RBridge. The VLAN for the Outer.VLAN information, if present, will be the Designated VLAN for the link on which the packet is sent. The V and R fields will be zero while the M bit will be one, unless the ESADI PDU was unicast, in which case the M bit will be zero. The Data Label specified will be the VLAN or FGL to which the ESADI packet applies. The Origin RBridge MAC Address or Inner.MacSA MUST be a MAC address unique across the campus owned by the RBridge originating the ESADI packet -- for example, any of its port MAC addresses if it has any Ethernet ports -- and each ESADI RBridge MUST use the same Inner.MacSA for all of the ESADI packets it originates.
ESADI PDUがマルチキャストされている場合、Next Hop Destination AddressまたはOuter.MacDAはAll-RBridgesマルチキャストアドレスです。ユニキャストの場合、ネクストホップ宛先アドレスはネクストホップRBridgeのユニキャストアドレスです。 Outer.VLAN情報のVLANは、存在する場合、パケットが送信されるリンクの指定VLANになります。 ESADI PDUがユニキャストでなかった場合を除き、VおよびRフィールドはゼロであり、Mビットは1です。その場合、Mビットはゼロになります。指定されたデータラベルは、ESADIパケットが適用されるVLANまたはFGLです。オリジンRBridge MACアドレスまたはInner.MacSAは、ESADIパケットを発信するRBridgeが所有するキャンパス全体で一意のMACアドレスである必要があります-たとえば、イーサネットポートがある場合、そのポートMACアドレスのいずれか-そして各ESADI RBridgeは発生するすべてのESADIパケットに同じInner.MacSAを使用します。
TRILL ESADI packets sent on a PPP link are structured as shown in Figure 3 [RFC6361].
PPPリンクで送信されるTRILL ESADIパケットは、図3 [RFC6361]に示すように構成されます。
PPP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP = TNP (TRILL Data) 0x005D |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | R |M|Op-Length| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress Nickname | Ingress (Origin) Nickname |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| All-Egress-RBridges (cont.) | Origin RBridge MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin RBridge MAC Address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = L2-IS-IS 0x22F4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESADI Payload (formatted as IS-IS):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPP Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ESADI PPP Link Packet Format
図3：これはPPPリンクパケット形式です
All RBridges forward ESADI packets as if they were ordinary TRILL Data packets. Because of this forwarding, it appears to an instance of the ESADI protocol at an RBridge that it is directly connected by a multi-access virtual link to all RBridges in the campus that are "data reachable" from it (see Section 2 of [RFC7180]) and are running ESADI for that Data Label. No "routing" calculation (least-cost path or distribution tree construction) ever has to be performed by ESADI. An ESADI RBridge merely transmits the ESADI packets it originates on this virtual link as described for TRILL Data packets in [RFC6325] and [RFC7172]. For multicast ESADI packets, it may use any distribution tree that it might use for an ordinary multi-destination TRILL Data packet. RBridges that do not implement the ESADI protocol, do not have it enabled, or are not participating in the ESADI protocol for the Data Label of an ESADI packet do not decapsulate or locally process the ESADI packet. Thus, ESADI packets are transparently tunneled through transit RBridges.
すべてのRBridgeは、通常のTRILLデータパケットであるかのようにESADIパケットを転送します。この転送により、RBridgeのESADIプロトコルのインスタンスからは、マルチアクセス仮想リンクによって、「データ到達可能」であるキャンパス内のすべてのRBridgeに直接接続されているように見えます（[RFC7180のセクション2を参照]。 ]）とそのデータラベルのESADIを実行しています。 ESADIが「ルーティング」計算（最小コストパスまたは配布ツリーの構築）を実行する必要はありません。 ESADI RBridgeは、[RFC6325]と[RFC7172]のTRILLデータパケットで説明されているように、この仮想リンクで発生するESADIパケットを送信するだけです。マルチキャストESADIパケットの場合、通常の複数宛先TRILLデータパケットに使用する可能性のある任意の配布ツリーを使用できます。 ESADIプロトコルを実装していない、有効にしていない、またはESADIパケットのデータラベルのESADIプロトコルに参加していないRBridgeは、ESADIパケットのカプセル化を解除したり、ローカルで処理したりしません。したがって、ESADIパケットは通過RBridgeを通じて透過的にトンネリングされます。
The ESADI instance for Data Label X at an RBridge RB1 determines who its adjacent ESADI neighbors are by examining the TRILL IS-IS link state database for RBridges that are data reachable from RB1 (see Section 2 of [RFC7180]) and are announcing their participation in Data Label X ESADI. When an RBridge RB2 becomes data unreachable from RB1 or the relevant entries for RB2 are purged from the core IS-IS link state database, it is lost as a neighbor and also dropped from any ESADI instances from the point of view of RB1, and when RB2 is no longer announcing participation in Data Label X ESADI, it ceases to be a neighbor for any Data Label X ESADI instance. All these considerations are Data Label scoped. Because of these mechanisms whereby an ESADI instance at an ESADI RBridge can determine its ESADI adjacencies by examining the TRILL IS-IS link state database, there are no "Hellos" sent in ESADI and no adjacency information is carried in ESADI-LSPs.
RBridge RB1のデータラベルXのESADIインスタンスは、RB1から到達可能なデータ（[RFC7180]のセクション2を参照）であり、その参加を発表しているRBridgeのTRILL IS-ISリンク状態データベースを調べて、隣接するESADIネイバーが誰であるかを判別しますデータラベルX ESADI。 RBridge RB2がRB1から到達不能なデータになるか、RB2の関連エントリがコアIS-ISリンク状態データベースから削除されると、ネイバーとして失われ、RB1の観点からESADIインスタンスからもドロップされます。 RB2はData Label X ESADIへの参加を発表しなくなり、Data Label X ESADIインスタンスのネイバーでなくなります。これらの考慮事項はすべて、データラベルのスコープです。 ESADI RBridgeのESADIインスタンスがTRILL IS-ISリンク状態データベースを調べることによってESADI隣接関係を判別できるこれらのメカニズムのため、ESADIで送信される「Hello」はなく、隣接情報はESADI-LSPで運ばれません。
A participation announcement in a VLAN scoped ESADI instance is generated by setting a flag bit in the Interested VLANs sub-TLV, and an announcement for an FGL scoped ESADI instance is generated by setting a flag bit in the Interested Labels sub-TLV [RFC7176] (see Section 7.1).
VLANスコープのESADIインスタンスへの参加のアナウンスは、関係するVLANサブTLVにフラグビットを設定することで生成され、FGLスコープのESADIインスタンスのアナウンスは、関係するラベルサブTLVにフラグビットを設定することで生成されます[RFC7176] （セクション7.1を参照）。
TRILL ESADI packet payloads are structured like IS-IS Extended Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356], except as indicated below, but are always TRILL encapsulated on the wire as if they were TRILL Data packets. The information distributed by the ESADI protocol includes a list of local end station MAC addresses connected to the originating RBridge and, for each such address, a 1-octet unsigned "Confidence" rating in the range 0-254 (see Section 6.2). It is entirely up to the originating RBridge which locally connected MAC addresses it wishes to advertise via ESADI and with what Confidence. It MAY advertise all, some, or none of such addresses. In addition, some ESADI parameters of the advertising RBridge (see Section 6.1) and, optionally, authentication information (see Section 6.3) are included. Future uses of ESADI may distribute other similar address and reachability information.
TRILL ESADIパケットペイロードは、IS-IS拡張レベル1サーキットスコープ（E-L1CS）LSP、CSNP、およびPSNP PDU [RFC7356]のように構成されますが、以下に示す場合を除き、TRILLデータであるかのように、常にTRILLカプセル化されます。パケット。 ESADIプロトコルによって配布される情報には、発信元のRBridgeに接続されたローカルエンドステーションのMACアドレスのリストと、そのような各アドレスについて、0〜254の範囲の1オクテットの署名されていない「信頼度」レーティングが含まれます（セクション6.2を参照）。 ESADIを介してアドバタイズしたいローカルに接続されたMACアドレスを発信元のRBridgeに完全に任せ、どのような信頼度でそれを行います。そのようなアドレスのすべて、一部、またはすべてをアドバタイズする場合があります。さらに、アドバタイジングRBridgeの一部のESADIパラメータ（セクション6.1を参照）、およびオプションで認証情報（セクション6.3を参照）が含まれています。 ESADIの将来の使用により、他の同様のアドレスおよび到達可能性情報が配布される可能性があります。
TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload. The Data Label to which the ESADI data applies is the Data Label of the TRILL Data packet enclosing the ESADI payload. If a Data Label ID could occur within the payload, it might conflict with that TRILL Data packet Data Label and could conflict with any future Data Label mapping scheme that may be adopted [VLANmapping]. If a VLAN or FGL ID field within an ESADI-LSP PDU does include a value, that field's contents MUST be ignored.
TRILL ESADI-LSPは、ペイロードにデータラベルIDを含めてはなりません。 ESADIデータが適用されるデータラベルは、ESADIペイロードを囲むTRILLデータパケットのデータラベルです。ペイロード内でデータラベルIDが発生する可能性がある場合、そのTRILLデータパケットデータラベルと競合する可能性があり、採用される可能性のある将来のデータラベルマッピングスキームと競合する可能性があります[VLANmapping]。 ESADI-LSP PDU内のVLANまたはFGL IDフィールドに値が含まれている場合、そのフィールドの内容は無視する必要があります。
Because ESADI does no adjacency announcement or routing, the ESADI-DRB never creates a pseudonode. However, a DRB [RFC7177] is still needed to issue ESADI-CSNP PDUs and respond to ESADI-PSNP PDUs for ESADI-LSP synchronization.
ESADIは隣接関係のアナウンスやルーティングを行わないため、ESADI-DRBは疑似ノードを作成しません。ただし、ESADI-CSNP PDUを発行し、ESADI-LSP同期のESADI-PSNP PDUに応答するには、DRB [RFC7177]が引き続き必要です。
Generally speaking, the DRB election on the ESADI virtual link (see Section 2.1) operates similarly to the DRB election on a TRILL IS-IS broadcast link, as described in Section 4.2.1 ("DRB Election Details") of [RFC7177], with the following exceptions: in the Data Label X ESADI-DRB election at RB1 on an ESADI virtual link, the candidates are the local ESADI instance for Data Label X and all remote ESADI instances at RBridges that are (1) data reachable from RB1 [RFC7180] and (2) announcing in their TRILL IS-IS LSP that they are participating in ESADI for Data Label X. The winner is the instance with the highest ESADI Parameter 7-bit priority field with ties broken by the System ID, comparing fields as unsigned integers with the larger magnitude considered higher priority. "SNPA/MAC address" (Subnetwork Point of Attachment / MAC address) is not considered in this tiebreaking, and there is no "Port ID".
[RFC7177]のセクション4.2.1（「DRB選挙の詳細」）で説明されているように、ESADI仮想リンク（セクション2.1を参照）でのDRB選出は、TRILL IS-ISブロードキャストリンクでのDRB選出と同様に動作します。次の例外を除いて：ESADI仮想リンク上のRB1でのデータラベルX ESADI-DRB選択では、候補は、データラベルXのローカルESADIインスタンス、および（1）RB1からデータに到達できるRBridgeのすべてのリモートESADIインスタンスです。 RFC7180]と（2）TRILL IS-IS LSPで、データラベルXのESADIに参加していることを発表します。勝者は、システムIDによって分割されたタイを持つESADIパラメータ7ビットの優先度フィールドが最も高いインスタンスで、フィールドを比較します。大きい方の優先度が高いと見なされる符号なし整数として。 「SNPA / MACアドレス」（サブネットワーク接続点/ MACアドレス）はこのタイブレイクでは考慮されず、「ポートID」はありません。
Data Label X ESADI neighbors are usually not connected directly by a physical link but are always logically connected by a virtual link (see Section 2.1). There could be hundreds or thousands of ESADI RBridges (TRILL switches) on the virtual link. The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs. In particular, there are no Hello or MTU PDUs, because ESADI does not build a topology, does not do any routing calculations, and does not determine MTU. Instead, ESADI uses the distribution trees and the Sz campus minimum link MTU determined by the core TRILL IS-IS (see [RFC6325] and [RFC7180]).
データラベルX ESADIネイバーは通常、物理リンクによって直接接続されていませんが、常に仮想リンクによって論理的に接続されています（セクション2.1を参照）。仮想リンクには数百または数千のESADI RBridge（TRILLスイッチ）が存在する可能性があります。 ESADIで使用される唯一のPDUは、ESADI-LSP、ESADI-CSNP、およびESADI-PSNP PDUです。特に、ESADIはトポロジを構築せず、ルーティングの計算を行わず、MTUを決定しないため、Hello PDUまたはMTU PDUはありません。代わりに、ESADIは配布ツリーとコアTRILL IS-ISによって決定されるSzキャンパスの最小リンクMTUを使用します（[RFC6325]と[RFC7180]を参照）。
For [IS-IS], PDU multicasting is normal on a local link and no effort is made to optimize to unicast, because on the typical physical link for which IS-IS was designed (commonly a piece of multi-access Ethernet cable), any frame made the link busy for that frame time. However, to ESADI instances, what appears to be a simple multi-access link is generally a set of multi-hop distribution trees that may or may not be pruned. Thus, transmitting a multicast frame on such a tree can impose a substantially greater load than transmitting a unicast frame. This load may be justified if there are likely to be multiple listeners but may not be justified if there is only one recipient of interest. For this reason, under some circumstances, ESADI PDUs MAY be TRILL unicast if it is confirmed that the destination RBridge supports receiving unicast ESADI PDUs (see Section 6.1).
[IS-IS]の場合、ローカルリンクではPDUマルチキャストが正常であり、IS-ISが設計された一般的な物理リンク（通常、マルチアクセスイーサネットケーブルの一部）のため、ユニキャストに最適化するための努力は行われません。フレームは、そのフレーム時間の間リンクをビジーにしました。ただし、ESADIインスタンスにとって、単純なマルチアクセスリンクのように見えるのは、一般にプルーニングされているかどうかに関係なく、マルチホップ分散ツリーのセットです。したがって、そのようなツリーでマルチキャストフレームを送信すると、ユニキャストフレームを送信するよりもかなり大きな負荷がかかる可能性があります。この負荷は、複数のリスナーが存在する可能性がある場合には正当化されますが、関心のある受信者が1人だけの場合には正当化されない場合があります。このため、状況によっては、宛先RBridgeがユニキャストESADI PDUの受信をサポートしていることが確認されている場合、ESADI PDUはTRILLユニキャストになる場合があります（セクション6.1を参照）。
The format of a unicast ESADI packet is the format of a multicast TRILL ESADI packet as described in Section 2 above, except as follows:
ユニキャストESADIパケットのフォーマットは、上記のセクション2で説明したマルチキャストTRILL ESADIパケットのフォーマットですが、次の点が異なります。
o On an Ethernet link, in the outer Ethernet header the Outer.MacDA is the unicast address of the next-hop RBridge.
o イーサネットリンクでは、外側のイーサネットヘッダーのOuter.MacDAは、ネクストホップRBridgeのユニキャストアドレスです。
o In the TRILL Header, the M bit is set to zero and the Egress Nickname is the nickname of the destination RBridge.
o TRILLヘッダーでは、Mビットはゼロに設定され、出力ニックネームは宛先RBridgeのニックネームです。
To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is replaced with the following:
ESADI PDUのユニキャストをサポートするために、[RFC6325]のセクション4.6.2.2は以下に置き換えられます。
4.6.2.2. TRILL ESADI Packets
4.6.2.2. 3つのsdパケット
If M = 1, the egress nickname designates the distribution tree. The packet is forwarded as described in Section 4.6.2.5. In addition, if (1) the forwarding RBridge is interested in the specified VLAN or fine-grained label [RFC7172], (2) the forwarding RBridge implements the TRILL ESADI protocol, and (3) ESADI is enabled for the specified VLAN or fine-grained label, then the inner frame is decapsulated and provided to that local ESADI protocol.
M = 1の場合、出力ニックネームは配布ツリーを指定します。パケットは、セクション4.6.2.5で説明されているように転送されます。さらに、（1）転送RBridgeが指定されたVLANまたは細粒度ラベル[RFC7172]に関心がある場合、（2）転送RBridgeがTRILL ESADIプロトコルを実装し、（3）指定されたVLANまたは罰金に対してESADIが有効になっている場合粒度のラベル、次に内部フレームがカプセル化解除され、そのローカルESADIプロトコルに提供されます。
If M = 0 and the egress nickname is not that of the receiving RBridge, the packet is forwarded as for known unicast TRILL Data frames as described in Section 4.6.2.4. If M = 0 and the egress nickname is that of the receiving RBridge, and the receiving RBridge supports unicast ESADI PDUs, then the ESADI packet is decapsulated and processed if it meets the three numbered conditions in the paragraph above; otherwise, it is discarded.
M = 0で、出力ニックネームが受信RBridgeのニックネームではない場合、セクション4.6.2.4で説明されているように、既知のユニキャストTRILLデータフレームの場合と同様にパケットが転送されます。 M = 0で、出力ニックネームが受信RBridgeのニックネームであり、受信RBridgeがユニキャストESADI PDUをサポートしている場合、ESADIパケットはカプセル化解除され、上記の段落の3つの番号付き条件を満たす場合に処理されます。それ以外の場合は破棄されます。
The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to those sections in [RFC6325].
上記の「4.6.2.2」、「4.6.2.4」、および「4.6.2.5」への参照は、[RFC6325]のこれらのセクションを参照します。
Following the usual [IS-IS] rules, an ESADI instance does not transmit any ESADI PDUs if it has no ESADI adjacencies. Such transmission would just be a waste of bandwidth.
通常の[IS-IS]ルールに従い、ESADI隣接がない場合、ESADIインスタンスはESADI PDUを送信しません。このような送信は、帯域幅の浪費になるだけです。
The MTU available to ESADI payloads is at least 24 bytes less than that available to TRILL IS-IS because of the additional fields required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 6(Inner.MacSA) + 4/8(Data Label) bytes ). Thus, the inner ESADI payload, starting with the Intradomain Routeing Protocol Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI instance or Sz minus 28 for an FGL ESADI instance; however, if a larger payload is received, it is processed normally (see [RFC6325] and [RFC7180] for discussions of Sz and MTU).
ESADIペイロードで使用可能なMTUは、TRILL IS-ISで使用可能なMTUよりも少なくとも24バイト少なくなります（2（TRILL Ethertype）+ 6（TRILLヘッダー）+ 6（Inner.MacDA）+ 6（Inner。 MacSA）+ 4/8（データラベル）バイト）。したがって、内部ESADIペイロードは、ドメイン内ルーティングプロトコルディスクリミネーターバイトで始まり、VLAN ESADIインスタンスの場合はSzマイナス24、FGL ESADIインスタンスの場合はSzマイナス28を超えてはなりません。ただし、より大きなペイロードが受信された場合、それは正常に処理されます（SzおよびMTUの説明については、[RFC6325]および[RFC7180]を参照してください）。
In all cases where this document says that an ESADI PDU is multicast, if the transmitting RBridge has only one neighbor and that neighbor advertises support for unicast, the PDU MAY be unicast (see Section 4.1).
このドキュメントでESADI PDUがマルチキャストであると説明されているすべてのケースで、送信RBridgeに1つだけのネイバーがあり、そのネイバーがユニキャストのサポートをアドバタイズする場合、PDUはユニキャストである可能性があります（セクション4.1を参照）。
A priority bit to indicate that an LSP fragment should be flooded with high priority is provided by [RFC7356]. This bit SHOULD be set on ESADI-LSP fragment zero because it is important that the ESADI Parameter APPsub-TLV get through promptly. This bit SHOULD NOT be set on other ESADI-LSP fragments to avoid giving undue priority to less urgent PDUs.
LSPフラグメントを高い優先度でフラッディングする必要があることを示す優先度ビットは、[RFC7356]によって提供されます。 ESADIパラメータAPPsub-TLVが迅速に通過することが重要であるため、このビットはESADI-LSPフラグメントゼロに設定する必要があります（SHOULD）。このビットは、緊急性の低いPDUに過度の優先順位を与えることを避けるために、他のESADI-LSPフラグメントに設定してはなりません（SHOULD NOT）。
In contrast with Layer 3 IS-IS PDU acceptance tests, which check the source inner and outer SNPA/MAC in order to verify that a PDU is from an adjacent TRILL switch, in TRILL ESADI adjacency is based on the system ID, so the system ID inside the PDU is all that is tested for.
レイヤー3 IS-IS PDU受け入れテスト（PDUが隣接するTRILLスイッチからのものであることを確認するためにソースの内部および外部SNPA / MACをチェックする）とは対照的に、TRILL ESADI隣接はシステムIDに基づいているため、システムテストされるのは、PDU内のIDだけです。
If an ESADI instance believes that it has no ESADI neighbors, it ignores any ESADI PDUs it receives.
ESADIインスタンスは、ESADIネイバーがないと判断した場合、受信したESADI PDUをすべて無視します。
The IS-IS reliable flooding mechanism (the Update Process) is modified for ESADI in the ways listed below. Except as otherwise stated, the ESADI update process works as described in [IS-IS], [RFC1195], and [RFC7356].
IS-ISの信頼性の高いフラッディングメカニズム（更新プロセス）は、ESADI用に以下の方法で変更されています。特に明記しない限り、ESADI更新プロセスは、[IS-IS]、[RFC1195]、および[RFC7356]で説明されているように機能します。
When an ESADI instance sees that it has a new ESADI neighbor, its self-originated ESADI-LSP fragments are scheduled to be sent and MAY be unicast to that neighbor if the neighbor is announcing in its LSP that it supports unicast ESADI (see Section 6.1). If all the other ESADI instances for the same Data Label send their self-originated ESADI-LSPs immediately, there may be a surge of traffic to that new neighbor. Therefore, the ESADI instances SHOULD wait an interval of time before sending their ESADI-LSP(s) to a new neighbor. The interval time value is up to the device implementation. One suggestion is that the interval time can be assigned a random value with a range based on the RBridge's nickname (or any one of its nicknames, if it holds more than one), such as ( 2000 * nickname / 2**16 ) milliseconds, assuming "nickname" to be an unsigned quantity.
ESADIインスタンスが新しいESADIネイバーを持っていることを確認すると、その自己発信ESADI-LSPフラグメントが送信されるようにスケジュールされ、ネイバーがLSPでユニキャストESADIをサポートしていることをアナウンスしている場合は、そのネイバーにユニキャストされる場合があります（セクション6.1を参照） ）。同じデータラベルの他のすべてのESADIインスタンスが自己生成のESADI-LSPをすぐに送信する場合、その新しいネイバーへのトラフィックが急増する可能性があります。したがって、ESADIインスタンスは、ESADI-LSPを新しいネイバーに送信する前に一定の時間待機する必要があります。インターバル時間の値はデバイスの実装次第です。 1つの提案は、（2000 *ニックネーム/ 2 ** 16）ミリ秒など、RBridgeのニックネーム（または複数ある場合はそのニックネームのいずれか）に基づく範囲でランダムな値をインターバル時間に割り当てることができることです、「ニックネーム」を符号なしの数量と想定。
All the TRILL switches participating in an ESADI instance for some Data Label appear to ESADI to be adjacent. Thus, the originator of any active ESADI-LSP fragment always appears to be on link and, to spread the burden of such a response, could be the RBridge to respond to any ESADI-CSNP or PSNP request for that fragment. However, under very rare circumstances, it could be that some version of the LSP fragment with a higher sequence number is actually held by another ESADI RBridge on the link, so non-originators need to be able to respond eventually. Thus, when the receipt of a CSNP or PSNP causes the SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP
一部のデータラベルのESADIインスタンスに参加しているすべてのTRILLスイッチは、ESADIからは隣接しているように見えます。したがって、アクティブなESADI-LSPフラグメントの発信元は常にリンクしているように見え、そのような応答の負担を分散するために、そのフラグメントに対するESADI-CSNPまたはPSNP要求に応答するRBridgeである可能性があります。ただし、非常にまれな状況では、より高いシーケンス番号を持つLSPフラグメントの一部のバージョンが実際にはリンク上の別のESADI RBridgeによって保持されているため、非発信者が最終的に応答できる必要がある場合があります。したがって、CSNPまたはPSNPを受信すると、SRMフラグ（ルーティングメッセージの送信フラグ[IS-IS]）がLSPに設定されます。
fragment, action is as specified in [IS-IS] for the originating ESADI RBridge of the fragment; however, at a non-originating ESADI RBridge, when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] is also set to the current time minus
フラグメント、アクションは、フラグメントの元のESADI RBridgeの[IS-IS]で指定されているとおりです。ただし、非発信ESADI RBridgeでは、SRMflagを0から1に変更すると、lastSentタイムスタンプ[IS-IS]も現在の時間からマイナスされた値に設定されます。
minimumLSPTransmissionInterval * Random (Jitter) / 100
minimumLSPTransmissionInterval *ランダム（ジッター）/ 100
(where minimumLSPTransmissionInterval, Random, and Jitter are as in [IS-IS]). This will delay and jitter the transmission of the LSP fragment by non-originators. This gives the originator more time to send the fragment and provides more time for such an originator-transmitted copy to traverse the likely multi-hop path to non-originators and clear the SRMflag for the fragment at non-originators.
（ここで、minimumLSPTransmissionInterval、Random、およびJitterは[IS-IS]と同じです）。これにより、発信者以外によるLSPフラグメントの送信が遅延し、ジッターが発生します。これにより、発信者はフラグメントを送信するためにより多くの時間を与え、そのような発信者が送信したコピーが非発信者への可能性のあるマルチホップパスをトラバースし、非発信者でフラグメントのSRMフラグをクリアするためにより多くの時間を提供します。
The multi-hop distribution tree method with Reverse Path Forwarding Check used for multicast distribution by TRILL will typically be less reliable than transmission over a single local broadcast link hop. For LSP synchronization robustness, in addition to sending ESADI-CSNPs as usual when it is the DRB, an ESADI RBridge SHOULD also transmit an ESADI-CSNP for an ESADI instance if all of the following conditions are met:
TRILLによるマルチキャスト配信に使用されるリバースパス転送チェックを使用したマルチホップ配信ツリー方式は、通常、単一のローカルブロードキャストリンクホップを介した送信よりも信頼性が低くなります。 LSP同期の堅牢性のために、DRAの場合は通常どおりESADI-CSNPを送信することに加えて、ESADI RBridgeは、次の条件がすべて満たされた場合にESADIインスタンスのESADI-CSNPも送信する必要があります（SHOULD）。
o it sees one or more ESADI neighbors for that instance, and
o そのインスタンスの1つ以上のESADIネイバーを確認し、
o it does not believe it is the DRB for the ESADI instance, and
o ESADIインスタンスのDRBであるとは思わない。
o it has not received or sent an ESADI-CSNP PDU for the instance for the average of the CSNP Time (see Section 6.1) of the DRB and its CSNP Time.
o DRBのCSNP時間（セクション6.1を参照）の平均とそのCSNP時間のインスタンスのESADI-CSNP PDUを受信または送信していません。
The subsections below discuss end station address considerations in the context of ESADI.
以下のサブセクションでは、ESADIのコンテキストにおけるエンドステーションアドレスの考慮事項について説明します。
The Confidence level mechanism [RFC6325] allows an RBridge campus manager to cause certain address learning sources to prevail over others. MAC address information learned through a registration protocol, such as [802.1X] with a cryptographically based EAP [RFC3748] method, might be considered more reliable than information learned through the mere observation of data traffic. When such authenticated learned address information is transmitted via the ESADI protocol, the use of authentication in the TRILL ESADI-LSP packets could make tampering with it in transit very difficult. As a result, it might be reasonable to announce such authenticated information via the ESADI protocol with a high Confidence, so it would be used in preference to any alternative learning from data observation.
信頼レベルメカニズム[RFC6325]により、RBridgeキャンパスマネージャーは、特定のアドレス学習ソースを他のソースよりも優先させることができます。暗号化ベースのEAP [RFC3748]方式の[802.1X]などの登録プロトコルを通じて学習したMACアドレス情報は、データトラフィックの単なる観察を通じて学習した情報よりも信頼性が高いと考えられます。このように認証された学習済みアドレス情報がESADIプロトコルを介して送信される場合、TRILL ESADI-LSPパケットで認証を使用すると、転送中の情報の改ざんが非常に困難になる可能性があります。その結果、ESADIプロトコルを介してそのような認証された情報を高い信頼度でアナウンスすることは理にかなっている可能性があるため、データ観測からの代替学習よりも優先して使用されます。
The end station addresses learned through the TRILL ESADI protocol should be forgotten through changes in ESADI-LSPs. The timeout of the learned end station address is up to the originating RBridge that decides when to remove such information from its ESADI-LSPs (or up to ESADI protocol timeouts if the originating RBridge becomes unreachable).
TRILL ESADIプロトコルを介して学習された端末アドレスは、ESADI-LSPの変更によって忘れられる必要があります。学習したエンドステーションアドレスのタイムアウトは、その情報をESADI-LSPからいつ削除するかを決定する元のRBridgeまでです（または、元のRBridgeが到達不能になった場合は、ESADIプロトコルタイムアウトまで）。
If RBridge RBn participating in the TRILL ESADI protocol for Data Label X no longer wishes to participate in ESADI, it ceases to participate by (1) clearing the ESADI Participation bit in the appropriate Interested VLANs or Interested Labels sub-TLV and (2) sending a final ESADI-LSP nulling out its ESADI-LSP information.
データラベルXのTRILL ESADIプロトコルに参加しているRBridge RBnがESADIに参加したくない場合は、（1）適切な対象VLANまたは対象ラベルのサブTLVのESADI参加ビットをクリアし、（2）送信することで参加を停止します。最終的なESADI-LSPがESADI-LSP情報を無効化する。
With ESADI, it is possible to persistently see occurrences of the same MAC address in the same Data Label being advertised as reachable by two or more RBridges. The specification of how to handle this situation in [RFC6325] is updated by this document, by replacing the last sentence of the last paragraph of Section 4.2.6 of [RFC6325] as shown below to provide better traffic-spreading while avoiding possible address flip-flopping.
ESADIを使用すると、2つ以上のRBridgeから到達可能であるとアドバタイズされている、同じデータラベル内の同じMACアドレスの発生を永続的に確認できます。 [RFC6325]でのこの状況への対処方法の仕様は、このドキュメントによって更新され、[RFC6325]のセクション4.2.6の最後の段落の最後の文を次のように置き換えることで、アドレスフリップを回避しながらトラフィックの分散を改善しています。 -フロッピング。
As background, assume some end station or set of end stations ESn have two or more ports with the same MAC address in the same Data Label with the ports connected to different RBridges (RB1, RB2, ...) by separate links. With ESADI, some other RBridge, RB0, can persistently see that MAC address in that Data Label connected to multiple RBridges. When RB0 ingresses a frame, say from ES0, destined for that MAC and label, the current [RFC6325] text permits a wide range of behavior. In particular, [RFC6325] would permit RB0 to use some rule, such as "always encapsulate to the egress with the lowest System ID", which would put all of this traffic through only one of the egress RBridges and one of the end station ports. With that behavior, there would be no load-spreading, even if there were multiple different ingress RBridges and/or different MAC addresses with the same reachability. [RFC6325] would also permit RB0 to send different traffic to different egresses by doing ECMP (Equal Cost Multipath) at a flow level, which would likely result in return traffic for RB0 to egress to ES0 from various of RB1, RB2, ... for the same MAC and label. The resulting address reachability flip-flopping perceived at RB0 could cause problems.
背景として、一部のエンドステーションまたはエンドステーションのセットESnに、同じデータラベル内に同じMACアドレスを持つ2つ以上のポートがあり、ポートが別々のリンクによって異なるRBridge（RB1、RB2など）に接続されていると想定します。 ESADIを使用すると、他の一部のRBridgeであるRB0は、複数のRBridgeに接続されているそのデータラベルのMACアドレスを永続的に確認できます。 ES0から、そのMACとラベルを宛先とするフレームにRB0が入ると、現在の[RFC6325]テキストは幅広い動作を許可します。特に、[RFC6325]は、RB0が「常に最小のシステムIDを持つ出口にカプセル化する」などの規則を使用することを許可します。これにより、このトラフィックのすべてが1つの出口RBridgeと1つのエンドステーションポートのみを通過します。 。その動作により、同じ到達可能性を持つ複数の異なる入力RBridgeや異なるMACアドレスがあったとしても、負荷分散はありません。 [RFC6325]は、フローレベルでECMP（Equal Cost Multipath）を実行することにより、RB0が異なるトラフィックを異なる出口に送信することも許可します。これにより、RB0のリターントラフィックがさまざまなRB1、RB2、...からES0に出力される可能性があります。同じMACとラベル。結果のアドレス到達可能性フリップフロップがRB0で認識されると、問題が発生する可能性があります。
This update to [RFC6325] avoids these potential difficulties by requiring that RB0 use one of the following two policies: (1) only encapsulate to one egress RBridge for any particular MAC and label, but select that egress pseudorandomly, based on the topology (including MAC reachability) or (2) if RB0 will not be disturbed by the returning TRILL Data packets showing the same MAC or by label flip-flopping between different ingresses, RB0 may use ECMP. Assuming multiple ingress RBridges and/or multiple MAC and label addresses, strategy 1 should result in load-spreading without address flip-flopping, while strategy 2 will produce better load-spreading than strategy 1 but with address flip-flopping from the point of view of RB0.
この[RFC6325]への更新では、RB0が次の2つのポリシーのいずれかを使用するように要求することで、これらの潜在的な問題を回避します。（1）特定のMACおよびラベルの1つの出力RBridgeにのみカプセル化し、トポロジに基づいてその出力を擬似ランダムに選択します（含むMAC到達可能性）または（2）同じMACを示すTRILLデータパケットが返されたり、異なる入力間のラベルフリップフロップによってRB0が妨害されない場合、RB0はECMPを使用できます。複数の入力RBridgeや複数のMACアドレスとラベルアドレスを想定すると、戦略1はアドレスフリップフロップなしの負荷分散をもたらすはずですが、戦略2は戦略1よりも負荷分散が優れていますが、アドレスフリップフロップの観点からRB0の。
OLD [RFC6325] Section 4.2.6 text:
旧[RFC6325]セクション4.2.6テキスト：
"... If confidences are also tied between the duplicates, for consistency it is suggested that RB2 direct all such frames (or all such frames in the same ECMP flow) toward the same egress RBridge; however, the use of other policies will not cause a network problem since transit RBridges do not examine the Inner.MacDA for known unicast frames."
"...信頼性も重複間で関連付けられている場合、一貫性のために、RB2はそのようなすべてのフレーム（または同じECMPフロー内のすべてのそのようなフレーム）を同じ出口RBridgeに転送することをお勧めします。ただし、他のポリシーの使用は中継RBridgeは既知のユニキャストフレームについてInner.MacDAを検査しないため、ネットワークの問題が発生します。」
NEW [RFC6325] Section 4.2.6 text:
NEW [RFC6325]セクション4.2.6のテキスト：
"... If confidences are also tied between the duplicates, then RB2 MUST adopt one of the following two strategies:
"...信頼性が重複の間でも結び付けられている場合、RB2は次の2つの戦略のいずれかを採用する必要があります。
1. In a pseudorandom way [RFC4086], select one of the egress RBridges that is least cost from RB2 and to which the destination MAC appears to be attached, and send all traffic for the destination MAC and VLAN (or FGL [RFC7172]) to that egress. This pseudorandom choice need only be changed when there is a change in campus topology or MAC attachment information. Such pseudorandom selection will, over a population of ingress RBridges, probabilistically spread traffic over the possible egress RBridges. Reasonable inputs to the pseudorandom selection are the ingress RBridge System ID and/or nickname, the VLAN or FGL, the destination MAC address, and a vector of the RBridges with connectivity to that MAC and VLAN or FGL. There is no need for different RBridges to use the same pseudorandom function.
1. 疑似ランダムな方法[RFC4086]で、RB2からのコストが最も低く、宛先MACが接続されているように見える出力RBridgeの1つを選択し、宛先MACおよびVLAN（またはFGL [RFC7172]）のすべてのトラフィックをそれに送信します出口。この疑似ランダムの選択は、キャンパストポロジまたはMACアタッチメント情報に変更がある場合にのみ変更する必要があります。このような疑似ランダム選択は、入力RBridgeの母集団にわたって、可能性のある出力RBridgeに確率的にトラフィックを分散します。疑似ランダム選択への合理的な入力は、入力RBridgeシステムIDまたはニックネーム、あるいはその両方、VLANまたはFGL、宛先MACアドレス、およびそのMACおよびVLANまたはFGLへの接続を備えたRBridgeのベクトルです。異なるRBridgeが同じ擬似ランダム関数を使用する必要はありません。
As an example of such a pseudorandom function, if there are k egress RBridges (RB0, RB1, ..., RB(k-1)) all reporting attachment to address MACx in Data Label DLy, then an ingress RBridge RBin could select the one to which it will send all unicast TRILL Data packets addressed to MACx in DLy based on the following:
そのような疑似ランダム関数の例として、k個の出力RBridge（RB0、RB1、...、RB（k-1））があり、すべてデータラベルDLyのアドレスMACxへのアタッチメントを報告している場合、入力RBridge RBinは次のものに基づいて、DLyのMACxにアドレス指定されたすべてのユニキャストTRILLデータパケットを送信する1つ：
FNV-32(RBin | MACx | DLy | RB0 | RB1 | ... | RB(k-1)) mod k
FNV-32（RBin | MACx | DLy | RB0 | RB1 | ... | RB（k-1））mod k
where the FNV (Fowler/Noll/Vo) algorithm is specified in [FNV], RBx means the nickname for RBridge RBx, "|" means concatenation, MACx is the destination MAC address, DLy is the Data Label, and "mod k" means the integer division remainder of the output of the FNV-32 function considered as a positive integer divided by k.
FNV（Fowler / Noll / Vo）アルゴリズムが[FNV]で指定されている場合、RBxはRBridge RBxのニックネームを意味し、「|」は連結、MACxは宛先MACアドレス、DLyはデータラベル、「mod k」はFNV-32関数の出力の整数除算の余りをkで割った正の整数と見なすことを意味します。
2. If RB2 supports ECMP and will not be disturbed by return traffic from the same MAC and VLAN (or FGL [RFC7172]) coming from a variety of different RBridges, then it MAY send traffic using ECMP at the flow level to the egress RBridges that are least cost from RB2 and to which the destination MAC appears to be attached."
2. RB2がECMPをサポートし、さまざまな異なるRBridgeからの同じMACおよびVLAN（またはFGL [RFC7172]）からのリターントラフィックによって妨害されない場合、ECMPを使用して、フローレベルで出力RBridgeにトラフィックを送信できます（MAY）。 RB2からの最小コストで、宛先MACが接続されているように見えます。」
The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs. Currently, the contents of an ESADI-LSP consist of zero or more MAC-Reachability TLVs, optionally an Authentication TLV, and exactly one ESADI parameter APPsub-TLV. Other similar data may be included in the future and, as in [IS-IS], an ESADI instance ignores any TLVs or sub-TLVs it does not understand. Because these PDUs are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356], the Type and Length fields in the TLVs are 16-bit.
ESADIで使用される唯一のPDUは、ESADI-LSP、ESADI-CSNP、およびESADI-PSNP PDUです。現在、ESADI-LSPのコンテンツは、ゼロ以上のMAC到達可能性TLV、オプションで認証TLV、および1つのESADIパラメータAPPsub-TLVで構成されています。他の同様のデータが将来含まれる可能性があり、[IS-IS]の場合と同様に、ESADIインスタンスは、理解できないTLVまたはサブTLVを無視します。これらのPDUは拡張レベル1サーキットスコープ（E-L1CS）PDU [RFC7356]としてフォーマットされているため、TLVのタイプフィールドと長さフィールドは16ビットです。
This section specifies the format for the ESADI Parameter APPsub-TLV, gives the reference for the ESADI MAC-Reachability TLV, and discusses default authentication configuration.
このセクションでは、ESADIパラメータAPPsub-TLVの形式を指定し、ESADI MAC到達可能性TLVのリファレンスを提供し、デフォルトの認証設定について説明します。
For robustness, the payload for an ESADI-LSP number zero and any ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470 minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN, or 1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL. However, if an ESADI-LSP number zero or such an ESADI-CSNP or ESADI-PSNP is received that is longer, it is still processed normally. (As stated in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to make it extremely unlikely that a TRILL control packet, even with reasonable additional headers, tags, and/or encapsulation, would encounter MTU problems on an inter-RBridge link.)
堅牢性のために、ESADI-LSP番号ゼロおよびフラグメントゼロをカバーするESADI-CSNPまたはESADI-PSNPのペイロードは、Inner.VLANがある場合、1470-24バイト（1446バイト）を超えてはならず、1470-28バイトを超えてはなりません。 （1442バイト）Inner.FGLがある場合。ただし、ESADI-LSP番号がゼロまたはそれより長いESADI-CSNPまたはESADI-PSNPを受信した場合でも、正常に処理されます。 （[RFC6325]のセクション4.3.1で述べられているように、1470バイトは、妥当な追加のヘッダー、タグ、および/またはカプセル化があっても、TRILL制御パケットがRBridge間でMTU問題に遭遇する可能性を極めて低くするために選択されましたリンク。）
Figure 4 presents the format of the ESADI parameter data. This APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP number zero. If it is missing from ESADI-LSP number zero or if ESADI-LSP number zero is not known, priority for the sending RBridge defaults to 0x40 and CSNP Time defaults to 30. If there is more than one occurrence in ESADI-LSP number zero, the first occurrence will be used. Occurrences of the ESADI Parameter APPsub-TLV in non-zero ESADI-LSP fragments are ignored.
図4は、ESADIパラメータデータの形式を示しています。このAPPsub-TLVは、ESADI-LSP番号0のTRILL GENINFO TLVに含まれている必要があります。 ESADI-LSP番号ゼロから欠落している場合、またはESADI-LSP番号ゼロが不明である場合、送信RBridgeの優先順位はデフォルトで0x40になり、CSNP時間はデフォルトで30になります。ESADI-LSP番号ゼロに複数のオカレンスがある場合、最初に出現したものが使用されます。ゼロ以外のESADI-LSPフラグメントでのESADIパラメータAPPsub-TLVの発生は無視されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
| Reserved for expansion (variable)
+-+-+-+-...
Figure 4: ESADI Parameter APPsub-TLV
図4：ESADIパラメータAPPsub-TLV
Type: Set to ESADI-PARAM sub-TLV (TRILL APPsub-TLV type 0x0001). Two bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
タイプ：ESADI-PARAM sub-TLV（TRILL APPsub-TLVタイプ0x0001）に設定します。このAPPsub-TLVは拡張TLV [RFC7356]に表示されるため、2バイト。
Length: Variable, with a minimum of 3, but must fit within the ESADI packet. This field is encoded as an unsigned integer in network byte order [RFC7356].
長さ：可変、最小3、ただしESADIパケット内に収まる必要があります。このフィールドは、ネットワークバイトオーダーの符号なし整数としてエンコードされます[RFC7356]。
R: A reserved bit that MUST be sent as zero and ignored on receipt.
R：予約ビット。ゼロとして送信し、受信時に無視する必要があります。
Priority: Gives the originating RBridge's priority for being the DRB on the ESADI instance virtual link (see Section 3) for the Data Label in which the PDU containing the parameter data was sent. It is an unsigned 7-bit integer with the larger magnitude indicating higher priority. It defaults to 0x40 for an RBridge participating in ESADI for which it has not been configured.
優先度：パラメータデータを含むPDUが送信されたデータラベルのESADIインスタンス仮想リンク（セクション3を参照）でDRBになるための元のRBridgeの優先度を指定します。これは符号なしの7ビット整数で、大きさが大きいほど優先順位が高くなります。構成されていないESADIに参加しているRBridgeのデフォルトは0x40です。
CSNP Time: An unsigned byte that gives the amount of time in seconds during which the originating RBridge, if it is the DRB on the ESADI virtual link, will send at least three ESADI-CSNP PDUs. It defaults to 30 seconds for an RBridge participating in ESADI for which it has not been configured.
CSNP時間：発信元のRBridgeがESADI仮想リンク上のDRBである場合、少なくとも3つのESADI-CSNP PDUを送信する時間を秒単位で示す符号なしバイト。設定されていないESADIに参加しているRBridgeのデフォルトは30秒です。
Flags: A byte of flags associated with the originating ESADI instance, as follows:
フラグ：次のように、元のESADIインスタンスに関連付けられた1バイトのフラグ：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| UN| RESV |
+---+---+---+---+---+---+---+---+
The UN flag indicates that the RBridge originating the ESADI-LSP, including this ESADI parameter data, will accept and properly process ESADI PDUs sent by TRILL unicast (see Section 4.1). The remaining RESV bits are reserved for future use and MUST be sent as zero and ignored on receipt.
UNフラグは、ESADI-LSPを発信するRBridgeが、このESADIパラメータデータを含め、TRILLユニキャストによって送信されたESADI PDUを受け入れて適切に処理することを示します（セクション4.1を参照）。残りのRESVビットは将来の使用のために予約されており、ゼロとして送信し、受信時に無視する必要があります。
Reserved for future expansion: Future versions of the ESADI Parameter APPsub-TLV may have additional information. A receiving ESADI RBridge ignores any additional data here, unless it implements such future expansion(s).
将来の拡張のために予約済み：ESADIパラメータAPPsub-TLVの将来のバージョンには、追加情報が含まれる可能性があります。受信側のESADI RBridgeは、将来の拡張を実装しない限り、ここで追加のデータを無視します。
The primary information in TRILL ESADI-LSP PDUs consists of MAC-Reachability (MAC-RI) TLVs specified in [RFC6165]. These TLVs contain one or more unicast MAC addresses of end stations that are both on a port and in a VLAN for which the originating RBridge is Appointed Forwarder, along with the 1-octet unsigned Confidence in this information with a value in the range 0-254. If such a TLV is received containing a Confidence of 255, it is treated as if the Confidence was 254. (This is to assure that any received address information can be overridden by local address information statically configured with a Confidence of 255.)
TRILL ESADI-LSP PDUの主要な情報は、[RFC6165]で指定されているMAC到達可能性（MAC-RI）TLVで構成されています。これらのTLVには、発信元のRBridgeがAppointed ForwarderであるポートとVLANの両方にあるエンドステーションの1つ以上のユニキャストMACアドレスと、この情報の1オクテットの署名されていない信頼度（範囲は0〜）の値が含まれます。 254。このようなTLVが255の信頼度を含んで受信された場合、信頼度は254であるかのように扱われます（これは、255の信頼度で静的に構成されたローカルアドレス情報によって受信アドレス情報が上書きされることを保証するためです）。
The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT contain the Data Label ID. If a Data Label ID is present in the MAC-RI TLV, it is ignored. In the ESADI PDU, only the Inner.VLAN or Inner.FGL tag indicates the Data Label to which the ESADI-LSP applies.
MAC-RI TLVを含むTRILL ESADI PDUのTLVには、データラベルIDを含めることはできません。データラベルIDがMAC-RI TLVに存在する場合、それは無視されます。 ESADI PDUでは、Inner.VLANまたはInner.FGLタグのみが、ESADI-LSPが適用されるデータラベルを示します。
The Authentication TLV may be included in ESADI PDUs [RFC5310] [IS-IS]. The default for ESADI PDU authentication is based on the state of TRILL IS-IS shared secret authentication for TRILL IS-IS LSP PDUs. If TRILL IS-IS authentication and ESADI are implemented at a TRILL switch, then ESADI MUST be able to use the authentication algorithms implemented for TRILL IS-IS and implement the keying material derivation function given below. If ESADI authentication has been manually configured, that configuration is not restricted by the configuration of TRILL IS-IS security.
認証TLVはESADI PDU [RFC5310] [IS-IS]に含まれる場合があります。 ESADI PDU認証のデフォルトは、TRILL IS-IS LSP PDUのTRILL IS-IS共有秘密認証の状態に基づいています。 TRILL IS-IS認証とESADIがTRILLスイッチで実装されている場合、ESADIはTRILL IS-ISに実装されている認証アルゴリズムを使用し、以下に示すキーマテリアル導出関数を実装できる必要があります。 ESADI認証が手動で構成されている場合、その構成はTRILL IS-ISセキュリティの構成によって制限されません。
If TRILL IS-IS authentication is not in effect for LSP PDUs originated by a TRILL switch, then ESADI PDUs originated by that TRILL switch are by default also unsecured.
TRILLスイッチによって発信されたLSP PDUに対してTRILL IS-IS認証が有効でない場合、そのTRILLスイッチによって発信されたESADI PDUもデフォルトで非セキュアになります。
If such IS-IS LSP PDU authentication is in effect at a TRILL switch, then, unless configured otherwise, ESADI PDUs sent by that switch MUST use the same algorithm in their Authentication TLVs. The ESADI authentication keying material used is derived from the IS-IS LSP shared secret keying material as detailed below. However, such authentication MAY be configured to use some other keying material.
そのようなIS-IS LSP PDU認証がTRILLスイッチで有効である場合、特に設定されていない限り、そのスイッチによって送信されるESADI PDUは、認証TLVで同じアルゴリズムを使用する必要があります。使用されるESADI認証キーイングマテリアルは、以下に詳述するIS-IS LSP共有秘密キーイングマテリアルから派生しています。ただし、そのような認証は、他の鍵情報を使用するように構成できます。
HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key )
HMAC-SHA256（「TRILL ESADI」、IS-IS-LSP-shared-key）
In the algorithm above, HMAC-SHA256 is as described in [FIPS180] and [RFC6234], and "TRILL ESADI" is the 11-byte US ASCII [ASCII] string indicated. IS-IS-LSP-shared-key is secret keying material being used by the originating TRILL switch for IS-IS LSP authentication.
上記のアルゴリズムでは、HMAC-SHA256は[FIPS180]および[RFC6234]で説明されているとおりであり、「TRILL ESADI」は11バイトのUS ASCII [ASCII]文字列です。 IS-IS-LSP-shared-keyは、IS-IS LSP認証用の元のTRILLスイッチによって使用されている秘密鍵情報です。
IANA allocation and registry considerations are given below. Three new sub-registries have been created in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry located at <http://www.iana.org/assignments/trill-parameters> -- two in Section 7.1 and one in Section 7.2 -- and various code points have been assigned.
IANAの割り当てとレジストリの考慮事項を以下に示します。 <http://www.iana.org/assignments/trill-parameters>にある「リンクの透過的な相互接続（TRILL）パラメータ」レジストリに、3つの新しいサブレジストリが作成されました。セクション7.1の2つと1つセクション7.2で-およびさまざまなコードポイントが割り当てられています。
IANA Action 1:
IANAアクション1：
IANA has created the following new sub-registry called "Interested VLANs Flag Bits" in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリに「対象VLANフラグビット」と呼ばれる次の新しいサブレジストリを作成しました。
Sub-registry: Interested VLANs Flag Bits
サブレジストリ：関心のあるVLANフラグビット
Registration Procedures: IETF Review
登録手順：IETFレビュー
Note: These bits appear in the Interested VLANs record within the Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN) specified in [RFC7176].
注：これらのビットは、[RFC7176]で指定された対象VLANおよびスパニングツリールートサブTLV（INT-VLAN）内の対象VLANレコードに表示されます。
References: [RFC7176], [RFC7357]
参照：[RFC7176]、[RFC7357]
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC7176]
1 M6 IPv6 Multicast Router Attached [RFC7176]
2 - Unassigned
3 ES ESADI Participation [RFC7357]
4-15 - (used for a VLAN ID) [RFC7176]
16-19 - Unassigned
20-31 - (used for a VLAN ID) [RFC7176]
The creation of this sub-registry (as immediately above) assigned bit 3 as the ESADI Participation bit in the Interested VLANs and Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a one, it indicates that the originating RBridge is participating in ESADI for the indicated Data Label(s).
このサブレジストリの作成（上記のとおり）は、関係するVLANおよびスパニングツリールートサブTLVのESADI参加ビットとしてビット3を割り当てました。 ESADI参加ビットが1の場合、それは発信元のRBridgeが示されたデータラベルのESADIに参加していることを示します。
IANA Action 2:
IANAアクション2：
IANA has created the following new sub-registry called "Interested Labels Flag Bits" in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry.
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリに、「対象ラベルフラグビット」と呼ばれる次の新しいサブレジストリを作成しました。
Sub-registry: Interested Labels Flag Bits
サブレジストリ：興味のあるラベルフラグビット
Registration Procedures: IETF Review
登録手順：IETFレビュー
Note: These bits appear in the Interested Labels record within the Interested Labels and Spanning Tree Roots Sub-TLV (INT-LABEL) specified in [RFC7176].
注：これらのビットは、[RFC7176]で指定されたInterest Labels and Spanning Tree Roots Sub-TLV（INT-LABEL）内のInterest Labelsレコードに表示されます。
References: [RFC7176], [RFC7357]
参照：[RFC7176]、[RFC7357]
Bit Mnemonic Description Reference
--- -------- ----------- ---------
0 M4 IPv4 Multicast Router Attached [RFC7176]
1 M6 IPv6 Multicast Router Attached [RFC7176]
2 BM Bit Map [RFC7176]
3 ES ESADI Participation [RFC7357]
4-7 - Unassigned
The creation of this sub-registry (as immediately above) assigned bit 3 as the ESADI Participation bit in the Interested Labels and Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a one, it indicates that the originating RBridge is participating in ESADI for the indicated Data Label(s).
このサブレジストリを作成すると（上記のように）、関係するラベルとスパニングツリールートのサブTLVのESADI参加ビットとしてビット3が割り当てられました。 ESADI参加ビットが1の場合、それは発信元のRBridgeが示されたデータラベルのESADIに参加していることを示します。
IANA Action 3:
IANAアクション3：
IANA has allocated the IS-IS Application Identifier 1 under the Generic Information TLV (#251) [RFC6823] for TRILL.
IANAは、TRILLのIS-ISアプリケーションID 1をGeneric Information TLV（＃251）[RFC6823]に割り当てました。
IANA Action 4:
IANAアクション4：
IANA has created a sub-registry in the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
IANAは、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリに次のようにサブレジストリを作成しました。
Sub-registry: TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1
サブレジストリ：IS-IS TLV 251アプリケーション識別子1に基づくTRILL APPサブTLVタイプ
Registration Procedures: IETF Review with additional requirements on the documentation of the use being registered as specified in Section 7.2 of [RFC7357].
登録手順：[RFC7357]のセクション7.2で指定されているように、登録されている使用のドキュメントに関する追加要件を含むIETFレビュー。
Note: Types greater than 255 are only usable in contexts permitting a type larger than one byte, such as extended TLVs [RFC7356].
注：255より大きい型は、拡張TLV [RFC7356]など、1バイトより大きい型を許可するコンテキストでのみ使用できます。
Reference: [RFC7357]
参照：[RFC7357]
Type Name Reference
---------- -------- -----------
0 Reserved [RFC7357]
1 ESADI-PARAM [RFC7357]
2-254 Unassigned [RFC7357]
255 Reserved [RFC7357]
256-65534 Unassigned [RFC7357]
65535 Reserved [RFC7357]
TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are available for assignment by IETF Review. The RFC causing such an assignment will also include a discussion of security issues and of the rate of change of the information being advertised. TRILL APPsub-TLVs MUST NOT alter basic IS-IS protocol operation including the establishment of adjacencies, the update process, and the decision process for TRILL IS-IS [IS-IS] [RFC1195] [RFC7177]. The TRILL Generic Information TLV MUST NOT be used in an IS-IS instance zero [RFC6822] LSP but may be used in Flooding Scoped LSPs (FS-LSPs) [RFC7356].
TRILL APPsub-TLVタイプ2〜254および256〜65534は、IETFレビューによる割り当てに使用できます。そのような割り当てを引き起こすRFCには、セキュリティの問題と、宣伝されている情報の変化率の議論も含まれます。 TRILL APPsub-TLVは、隣接の確立、更新プロセス、およびTRILL IS-IS [IS-IS] [RFC1195] [RFC7177]の決定プロセスを含む基本的なIS-ISプロトコル操作を変更してはなりません（MUST NOT）。 TRILL Generic Information TLVはIS-ISインスタンスゼロ[RFC6822] LSPで使用してはなりません（MUST NOT）が、フラッディングスコープLSP（FS-LSP）[RFC7356]で使用できます。
The V, I, D, and S flags in the initial flags byte of a TRILL Generic Information TLV have the meanings specified in [RFC6823] but are not currently used, as TRILL operates as a Level 1 IS-IS area and no semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6 address via the I and V flags. Thus, these I and V flags MUST be zero; however, if either or both are one, the space that should be taken by an IPv4 and/or IPv6 address, respectively, is skipped over and ignored. Furthermore, the use of multilevel IS-IS is an obvious extension for TRILL [MultiLevel], and future IETF Standards Actions may update or obsolete this specification to provide for the use of any or all of these flags in the TRILL GENINFO TLV.
TRILL Generic Information TLVの初期フラグバイトのV、I、D、およびSフラグは[RFC6823]で指定された意味を持っていますが、TRILLはレベル1 IS-IS領域として動作し、セマンティクスがないため、現在使用されていませんこれにより、IフラグとVフラグを介してIPv4および/またはIPv6アドレスを含めるように割り当てられます。したがって、これらのIおよびVフラグはゼロでなければなりません。ただし、一方または両方が1つである場合、IPv4アドレスまたはIPv6アドレス、あるいはその両方がそれぞれ取る必要があるスペースはスキップされ、無視されます。さらに、マルチレベルIS-ISの使用はTRILL [MultiLevel]の明らかな拡張であり、将来のIETF標準アクションはこの仕様を更新または廃止して、TRILL GENINFO TLVでこれらのフラグの一部またはすべてを使用できるようにする可能性があります。
The ESADI Parameters information, for which TRILL APPsub-TLV 1 is hereby assigned, is compact and slow changing (see Section 6.1).
これによりTRILL APPsub-TLV 1が割り当てられるESADIパラメータ情報は、コンパクトでゆっくりと変化します（セクション6.1を参照）。
For security considerations related to ESADI and the ESADI Parameter APPsub-TLV, see Section 8.
ESADIおよびESADIパラメータAPPsub-TLVに関連するセキュリティの考慮事項については、セクション8を参照してください。
ESADI PDUs can be authenticated through the inclusion of the Authentication TLV [RFC5310]. Defaults for such authentication are described in Section 6.3.
ESADI PDUは、認証TLV [RFC5310]を含めることで認証できます。このような認証のデフォルトについては、セクション6.3で説明しています。
The ESADI-LSP data primarily announces MAC address reachability within a Data Label. Such reachability can, in some cases, be an authenticated registration (for example, a Layer 2 authenticated registration using cryptographically based EAP (Extensible Authentication Protocol [RFC3748]) methods via [802.1X]). The combination of these techniques can cause ESADI MAC reachability information to be substantially more trustworthy than MAC reachability learned from observation of the data plane. Nevertheless, ESADI still involves trusting all other RBridges in the TRILL campus, at least those that have the keying material necessary to construct a valid Authentication TLV.
ESADI-LSPデータは、主にデータラベル内のMACアドレスの到達可能性を通知します。そのような到達可能性は、場合によっては、認証された登録（たとえば、[802.1X]を介した暗号ベースのEAP（Extensible Authentication Protocol [RFC3748]）メソッドを使用したレイヤー2認証登録）である可能性があります。これらの技術の組み合わせにより、ESADI MAC到達可能性情報は、データプレーンの観察から学習したMAC到達可能性よりも実質的に信頼できるようになります。それでも、ESADIは、TRILLキャンパス内の他のすべてのRBridgeを信頼することを含みます。少なくとも、有効な認証TLVを構築するために必要なキー情報を持っているRBridgeを信頼します。
However, there may be cases where authenticated registration is used for end stations, because of a significant threat of forged packets on end station links, but it is not necessary to authenticate ESADI PDUs because that threat is not present for inter-RBridge trunks. For example, a TRILL campus with secure RBridges and inter-RBridge links configured as trunks but with some end stations connected via IEEE 802.11 wireless access links might use 802.11 authentication for the connection of such end stations but might not necessarily authenticate ESADI PDUs. Note that if the IS-IS LSPs in a TRILL campus are authenticated, perhaps due to a concern about forged packets, the ESADI PDUs will be authenticated by default as provided in Section 6.3.
ただし、エンドステーションリンク上の偽造されたパケットの重大な脅威のために、認証済み登録がエンドステーションに使用される場合がありますが、その脅威はRBridge間トランクには存在しないため、ESADI PDUを認証する必要はありません。たとえば、セキュアなRBridgeとRBridge間リンクがトランクとして構成されているが、IEEE 802.11ワイヤレスアクセスリンクを介して接続されている一部のエンドステーションを持つTRILLキャンパスは、そのようなエンドステーションの接続に802.11認証を使用する場合がありますが、ESADI PDUを認証する必要はありません。 TRILLキャンパス内のIS-IS LSPが認証された場合、おそらく偽造されたパケットに関する懸念のために、ESADI PDUはセクション6.3で規定されているようにデフォルトで認証されます。
MAC reachability learned from the data plane (the TRILL default) is overwritten by any future learning of the same type. ESADI advertisements are represented in the Data Label scoped link state database. Thus, ESADI makes visible any multiple attachments of the same MAC address within a Data Label to different RBridges (see Section 5.3). This may or may not be an error or misconfiguration, but ESADI at least makes it explicitly and persistently visible, which would not be the case with data plane learning.
データプレーンから学習したMAC到達可能性（TRILLのデフォルト）は、同じタイプの今後の学習によって上書きされます。 ESADIアドバタイズは、Data Labelスコープのリンク状態データベースで表されます。したがって、ESADIは、データラベル内の同じMACアドレスの複数のアタッチメントを異なるRBridgeに可視にします（セクション5.3を参照）。これはエラーまたは構成ミスである場合とそうでない場合がありますが、ESADIは少なくともそれを明示的かつ永続的に表示します。これはデータプレーン学習の場合とは異なります。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
The address reachability information distributed by ESADI has substantial privacy considerations under many, but not all, circumstances.
ESADIによって配布されるアドレス到達可能性情報には、すべてではありませんが、多くの状況でプライバシーに関する重要な考慮事項があります。
For example, if ESADI were used in a TRILL campus with independent user end stations at the edge, the MAC addresses of such end stations could uniquely identify the users of those end stations. Their reachability would be sensitive information and, particularly if logged, could reveal such user information. On the other hand, if TRILL is being used to implement an Internet Exchange Point (IXP) to connect Internet Service Providers (ISPs), the MAC addresses being advertised in ESADI would typically be those of the ISP's directly connected IP router ports, since Layer 3 routers bound the TRILL campus, for which there would be few privacy concerns.
たとえば、ESADIが、独立したユーザーエンドステーションがエッジにあるTRILLキャンパスで使用された場合、そのようなエンドステーションのMACアドレスは、それらのエンドステーションのユーザーを一意に識別できます。それらの到達可能性は機密情報であり、特にログに記録された場合、そのようなユーザー情報が明らかになる可能性があります。一方、インターネットサービスプロバイダー（ISP）を接続するためにインターネットエクスチェンジポイント（IXP）を実装するためにTRILLが使用されている場合、ESADIでアドバタイズされるMACアドレスは、通常、ISPの直接接続されたIPルーターポートのMACアドレスになります。 3台のルーターがTRILLキャンパスを囲んでおり、プライバシーの問題はほとんどありません。
However, records of MAC attachment that include a modest amount of history, perhaps a few days' worth, can be useful in managing a network and troubleshooting network problems. It might, in some cases, also be legally required, or required for billing purposes or the like.
ただし、MACアタッチメントの記録には、適度な履歴（おそらく数日分）が含まれているため、ネットワークの管理やネットワークの問題のトラブルシューティングに役立ちます。場合によっては、法的に必要な場合や、請求目的などで必要になる場合もあります。
Network operators should seek a reasonable balance between these competing considerations, customized for the circumstances of their particular networks where ESADI is in use. They should not maintain logs of MAC reachability information for any longer than is clearly required.
ネットワークオペレーターは、ESADIが使用されている特定のネットワークの状況に合わせてカスタマイズされた、これらの競合する考慮事項の間の合理的なバランスを模索する必要があります。明確に必要とされるよりも長い間、MAC到達可能性情報のログを保持するべきではありません。
The authors thank the following, listed in alphabetic order, for their suggestions and contributions:
著者は、彼らの提案と貢献に対してアルファベット順にリストされた以下に感謝します：
David Black, Somnath Chatterjee, Adrian Farrel, Stephen Farrell, Sujay Gupta, Russ Housley, Pearl Liang, Kathleen Moriarty, Thomas Narten, Erik Nordmark, and Mingui Zhang.
デビッドブラック、サムナスチャタジー、エイドリアンファレル、スティーブンファレル、スジェイグプタ、ラスハウズリー、パールリャン、キャスリーンモリアーティ、トーマスナルテン、エリックノードマーク、ミンギチャン。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII] American National Standards Institute（旧United States of America Standards Institute）、「USA Code for Information Interchange」、ANSI X3.4-1968、1968。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968は、わずかな変更を加えた新しいバージョンに置き換えられましたが、1968バージョンはインターネットにとって決定的なものです。
[FIPS180] "Secure Hash Standard (SHS)", National Institute of Standards and Technology, Federal Information Processing Standard (FIPS) 180-4, March 2012, <http://csrc.nist.gov/ publications/fips/fips180-4/fips-180-4.pdf>.
[FIPS180]「Secure Hash Standard（SHS）」、米国連邦情報・技術局、連邦情報処理標準（FIPS）180-4、2012年3月、<http://csrc.nist.gov/publications/fips/fips180- 4 / fips-180-4.pdf>。
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", 2002.
[IS-IS] ISO / IEC 10589：2002、Second Edition、 "Information technology-Telecommunications and information exchange between systems-Intermediate System to Intermediate System intra-domain routinging information exchange protocol with used with with the protocol with with with using the protocol toコネクションレスモードのネットワークサービス（ISO 8473）」、2002年。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[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月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、June 2005。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、2011年4月。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、2011年7月。
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol", RFC 6361, August 2011.
[RFC6361] Carlson、J。およびD. Eastlake 3度、「PPP Transparent Interconnection of Lots of Links（TRILL）Protocol Control Protocol」、RFC 6361、2011年8月。
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, December 2012.
[RFC6823] Ginsberg、L.、Previdi、S。、およびM. Shand、「IS-ISでの一般情報のアドバタイズ」、RFC 6823、2012年12月。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、May 2014。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, May 2014.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、May 2014。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, May 2014.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、May 2014。
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7180, May 2014.
[RFC7180] Eastlake 3rd、D.、Zhang、M.、Ghanwani、A.、Manral、V.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、and Updates"、RFC 7180 、2014年5月。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, September 2014.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-ISフラッディングスコープのリンク状態PDU（LSP）」、RFC 7356、2014年9月。
[802.1X] IEEE 802.1, "IEEE Standard for Local and metropolitan area networks--Port-Based Network Access Control", IEEE Standard 802.1X-2010, February 2010.
[802.1X] IEEE 802.1、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-ポートベースのネットワークアクセスコントロール」、IEEE標準802.1X-2010、2010年2月。
[FNV] Fowler, G., Noll, L., Vo, K., and D. Eastlake 3rd, "The FNV Non-Cryptographic Hash Algorithm", Work in Progress, April 2014.
[FNV] Fowler、G.、Noll、L.、Vo、K.、and D. Eastlake 3rd、 "The FNV Non-Cryptographic Hash Algorithm"、Work in Progress、2014年4月。
[MultiLevel] Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai, "Flexible Multilevel TRILL (Transparent Interconnection of Lots of Links)", Work in Progress, June 2014.
[MultiLevel] Perlman、R.、Eastlake 3rd、D.、Gwanwani、A。、およびH. Zhai、「Flexible Multilevel TRILL（Transparent Interconnection of Lots of Links）」、Work in Progress、2014年6月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
[RFC6822] Previdi、S.、Ed。、Ginsberg、L.、Shand、M.、Roy、A。、およびD. Ward、「IS-IS Multi-Instance」、RFC 6822、2012年12月。
[VLANmapping] Perlman, R., Rijhsinghani, A., Eastlake 3rd, D., Banerjee, A., and D. Dutt, "TRILL: Campus Label and Priority Regions", Work in Progress, January 2014.
[VLANmapping] Perlman、R.、Rijhsinghani、A.、Eastlake 3rd、D.、Banerjee、A.、and D. Dutt、 "TRILL：Campus Label and Priority Regions"、Work in Progress、2014年1月。
This appendix summarizes the significant changes this document makes to the TRILL base protocol specification [RFC6325]. Although simultaneous use of [RFC6325] ESADI and ESADI as specified in this document in a TRILL campus is very unlikely due to non-deployment of [RFC6325] ESADI, this appendix also discusses, for each change, the interoperability considerations should such simultaneous use occur.
この付録は、このドキュメントがTRILLベースプロトコル仕様[RFC6325]に加える重要な変更をまとめたものです。 [RFC6325] ESADIとESADIを同時に使用することは、このドキュメントでTRILLキャンパスで指定されているため、[RFC6325] ESADIが展開されていないため、ほとんどありませんが、この付録では、変更ごとに、相互運用性に関する考慮事項が同時に発生した場合の考慮事項についても説明します。 。
The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is changed from the IS-IS Level 1 format [IS-IS] to the Extended Level 1 Circuit Scope format (E-L1CS) specified in [RFC7356]. This change is not backwards compatible with [RFC6325]. It is made in light of the information-carrying capacity of the E-L1CS format, which is 256 times greater than that of the base IS-IS format. It is anticipated that this greater information-carrying capacity will be needed, under some circumstances, to carry end station addressing information or other similar address and reachability information when it is added to ESADI in the future.
ESADI-LSP、ESADI-CSNP、およびESADI-PSNP PDUペイロードの形式は、IS-ISレベル1形式[IS-IS]から[RFC7356]で指定されている拡張レベル1サーキットスコープ形式（E-L1CS）に変更されます。 。この変更は[RFC6325]との後方互換性はありません。 E-L1CSフォーマットの情報伝送容量を考慮して作成されています。これは、ベースIS-ISフォーマットの256倍の容量です。状況によっては、将来ESADIに追加されるときに、エンドステーションのアドレッシング情報または他の同様のアドレスと到達可能性情報を伝送するために、このより大きな情報伝達能力が必要になると予想されます。
The PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in [RFC6325] are 18, 24, and 26 [IS-IS]. With this document, the format changes, and the PDU numbers change to 10, 11, and 12 [RFC7356]. The use of different PDU numbers assures that a PDU will not be mis-parsed. Because of this, implementations of this document and implementations of [RFC6325] ESADI will discard each other's PDUs. Thus, address reachability or other information distributed through either type of ESADI implementation will only be communicated to other implementations of the same type, and the two communities will not communicate any information with each other.
[RFC6325]でESADI LSP、CSNP、およびPSNP PDUに使用されるPDU番号は、18、24、および26 [IS-IS]です。このドキュメントでは、形式が変更され、PDU番号が10、11、および12に変更されます[RFC7356]。異なるPDU番号を使用すると、PDUが誤って解析されることがなくなります。このため、このドキュメントの実装と[RFC6325] ESADIの実装は、互いのPDUを破棄します。したがって、どちらかのタイプのESADI実装を通じて配信されるアドレス到達可能性またはその他の情報は、同じタイプの他の実装にのみ通信され、2つのコミュニティは互いに情報を通信しません。
Note that RBridges can use the TRILL mandatory-to-implement, enabled-by-default data plane address learning in addition to ESADI. (Section 5 of this document and the material it references explain how to handle conflicts between different sources of address reachability information.) Simply leaving data plane address learning enabled would enable smooth incremental migration from [RFC6325] ESADI to the ESADI specification in this document, should that be necessary. The data plane address learning would fill in any gaps due to non-communication between the two types of ESADI implementations, although without the speed or security advantages of ESADI.
RBridgeは、ESADIに加えて、実装が必須で、デフォルトで有効になっているTRILLデータプレーンアドレス学習を使用できることに注意してください。 （このドキュメントのセクション5およびそれが参照する資料は、アドレス到達可能性情報のさまざまなソース間の競合を処理する方法を説明しています。）データプレーンアドレス学習を有効のままにするだけで、このドキュメントの[RFC6325] ESADIからESADI仕様へのスムーズな増分移行が可能になります。それが必要な場合。データプレーンアドレス学習は、ESADIの速度やセキュリティの利点がなくても、2種類のESADI実装間の非通信によるギャップを埋めます。
Unicasting of ESADI PDUs is optionally supported, including replacing Section 4.6.2.2 of [RFC6325] with the new text given in Section 4.1 of this document. This unicast support is backwards compatible because it is only used when the recipient RBridge signals its support.
ESADI PDUのユニキャストはオプションでサポートされており、[RFC6325]のセクション4.6.2.2を、このドキュメントのセクション4.1に記載されている新しいテキストに置き換えることが含まれます。このユニキャストサポートは、受信者のRBridgeがサポートを通知するときにのみ使用されるため、下位互換性があります。
The following timing-related ESADI message changes and suggestions are included in this document:
このドキュメントには、次のタイミング関連のESADIメッセージの変更と提案が含まれています。
1. Provide for staggered delay for non-originators of ESADI-LSP fragments in response to requests for such fragments by CSNP and PSNP messages.
1. CSNPおよびPSNPメッセージによるそのようなフラグメントの要求に応答して、ESADI-LSPフラグメントの非発信者に時間差を設けます。
2. Suggest staggered timing of unicast ESADI-LSPs when a new ESADI RBridge appears on the ESADI virtual link.
2. ESADI仮想リンクに新しいESADI RBridgeが表示される場合、ユニキャストESADI-LSPのタイミングをずらして提案します。
These relate only to the timing of messages for congestion minimization. Should a message be lost, due to congestion or otherwise, it will be later retransmitted as a normal part of the robust flooding mechanism used by ESADI.
これらは、輻輳を最小化するためのメッセージのタイミングにのみ関連しています。輻輳などによりメッセージが失われた場合、ESADIが使用する堅牢なフラッディングメカニズムの通常の部分として後で再送信されます。
The handling of persistent reachability of the same MAC within the same Data Label from two or more RBridges is substantially modified, including the explicit replacement of some text in Section 4.2.6 of [RFC6325] (see Section 5.3 of this document). There is no problem with a mixture of ESADI implementations in a TRILL campus, some conforming to [RFC6325] and some conforming to this document, for handling this condition. The more implementations conform to the improved behavior specified in this document for this condition, the better the traffic-spreading will be, and the less likely address flip-flopping problems will be.
[RFC6325]のセクション4.2.6の一部のテキストの明示的な置換を含め、2つ以上のRBridgeからの同じデータラベル内の同じMACの永続的な到達可能性の処理が大幅に変更されました（このドキュメントのセクション5.3を参照）。この状態を処理するために、TRILLキャンパスでのESADI実装の混合、一部は[RFC6325]に準拠、一部はこのドキュメントに準拠しても問題はありません。このドキュメントは、このドキュメントで指定されている改善された動作に準拠する実装が多いほど、トラフィックの拡散が向上し、アドレスフリップフロップの問題が発生する可能性が低くなります。
Authors' Addresses
著者のアドレス
Hongjun Zhai ZTE Corporation 68 Zijinghua Road Nanjing 200012 China Phone: +86-25-52877345 EMail: zhai.hongjun@zte.com.cn
NZ ZT E Corporation 68 Z i essence road NaNjing 200012 China電話による電話：+ 86-25-52877345メール：宅。红军@中特.com。Talent
Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China Phone: +86-21-68896273 EMail: hu.fangwei@zte.com.cn
ファンGはhu ZT E法人889 BI Bo道路上海201203中国電話：+ 86-21-68896273メール：Hu.fangwei @中特.com。Talent
Radia Perlman EMC 2010 256th Ave. NE, #200 Bellevue, WA 98007 USA EMail: Radia@alum.mit.edu
らぢあ ぺｒｌまん えＭＣ ２０１０ ２５６ｔｈ あゔぇ。 ね、 ＃２００ べっぇゔえ、 わ ９８００７ うさ えまいｌ： らぢあ＠あぅｍ。みｔ。えづ
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 EMail: d3e3e3@gmail.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 USA電話：+ 1-508-333-2270メール：d3e3e3@gmail.com
Olen Stokes Extreme Networks 2121 RDU Center Drive, Suite 300 Morrisville, NC 27560 USA EMail: ostokes@extremenetworks.com
Olen Stokes Extreme Networks 2121 RDU Center Drive、Suite 300 Morrisville、NC 27560 USAメール：ostokes@extremenetworks.com