[要約] RFC 8171は、TRILL（Transparent Interconnection of Lots of Links）のエッジディレクトリアシスタンスメカニズムに関するものであり、TRILLネットワーク内のエッジデバイスの検索とアシストを目的としています。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 8171 L. Dunbar
Category: Standards Track Huawei
ISSN: 2070-1721 R. Perlman
EMC
Y. Li
Huawei
June 2017
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
多数のリンクの透過的な相互接続（TRILL）：エッジディレクトリ支援メカニズム
Abstract
概要
This document describes mechanisms for providing directory service to TRILL (Transparent Interconnection of Lots of Links) edge switches. The directory information provided can be used in reducing multi-destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses.
このドキュメントでは、TRILL（リンクの透過的な相互接続）エッジスイッチにディレクトリサービスを提供するメカニズムについて説明します。提供されるディレクトリ情報は、複数の宛先のトラフィック、特にARP /近隣探索（ND）と未知のユニキャストフラッディングを減らすのに使用できます。また、送信元アドレスが偽造されたトラフィックを検出するためにも使用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8171.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8171で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Uses of Directory Information ..............................5
1.2. Terminology ................................................6
2. Push Model Directory Assistance Mechanisms ......................7
2.1. Requesting Push Service ....................................7
2.2. Push Directory Servers .....................................8
2.3. Push Directory Server State Machine ........................9
2.3.1. Push Directory States ...............................9
2.3.2. Push Directory Events and Conditions ...............11
2.3.3. State Transition Diagram and Table .................13
2.4. End Stations and Push Directories .........................15
2.5. Additional Push Details ...................................15
2.6. Providing Secondary Servers with Data from a
Primary Server ............................................16
2.7. Push Directory Configuration ..............................17
3. Pull Model Directory Assistance Mechanisms .....................17
3.1. Pull Directory Message: Common Format .....................19
3.1.1. Version Negotiation ................................20
3.2. Pull Directory Query and Response Messages ................21
3.2.1. Pull Directory Query Message Format ................21
3.2.2. Pull Directory Responses ...........................24
3.2.2.1. Pull Directory Response Message Format ....24
3.2.2.2. Pull Directory Forwarding .................27
3.3. Cache Consistency .........................................28
3.3.1. Update Message Format ..............................32
3.3.2. Acknowledge Message Format .........................33
3.4. Summary of Record Formats in Messages .....................34
3.5. End Stations and Pull Directories .........................34
3.5.1. Pull Directory Hosted on an End Station ............35
3.5.2. Use of Pull Directory by End Stations ..............36
3.5.3. Native Pull Directory Messages .....................37
3.6. Pull Directory Message Errors .............................38
3.6.1. Error Codes ........................................39
3.6.2. Sub-errors under Error Codes 1 and 3 ...............39
3.6.3. Sub-errors under Error Codes 128 and 131 ...........40
3.7. Additional Pull Details ...................................40
3.8. The "No Data" Flag ........................................40
3.9. Pull Directory Service Configuration ......................42
4. Directory Use Strategies and Push-Pull Hybrids .................42
5. TRILL ES-IS ....................................................44
5.1. PDUs and System IDs .......................................45
5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46
5.3. Link State ................................................47
6. Security Considerations ........................................47
6.1. Directory Information Security ............................47
6.2. Directory Confidentiality and Privacy .....................47
6.3. Directory Message Security Considerations .................48
7. IANA Considerations ............................................48
7.1. ESADI-Parameter Data Extensions ...........................48
7.2. RBridge Channel Protocol Numbers ..........................49
7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49
7.4. TRILL Pull Directory QTYPEs ...............................50
7.5. Pull Directory Error Code Registries ......................50
7.6. TRILL-ES-IS MAC Address ...................................51
8. References .....................................................51
8.1. Normative References ......................................51
8.2. Informative References ....................................54
Acknowledgments ...................................................55
Authors' Addresses ................................................55
[RFC7067] gives a problem statement and high-level design for using directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in reducing multi-destination ARP / Neighbor Discovery (ND) [ARPND], reducing unknown unicast flooding traffic, and improving security against address spoofing within a TRILL campus. Because multi-destination traffic becomes an increasing burden as a network scales up in number of nodes, reducing ARP/ND and unknown unicast flooding improves TRILL network scalability. This document describes specific mechanisms for TRILL directory servers.
[RFC7067]は、ディレクトリサーバーを使用してTRILL [RFC6325] [RFC7780]エッジノードがマルチ宛先ARP /近隣探索（ND）[ARPND]を削減し、不明なユニキャストフラッディングトラフィックを削減するための問題ステートメントと高レベルの設計を示しています。 TRILLキャンパス内でのアドレスのなりすましに対するセキュリティの向上。ネットワークがノード数を拡大するにつれて、複数の宛先のトラフィックの負荷が増大するため、ARP / NDおよび未知のユニキャストフラッディングを削減することで、TRILLネットワークのスケーラビリティが向上します。このドキュメントでは、TRILLディレクトリサーバーの特定のメカニズムについて説明します。
The information held by the directory or directories is address mapping and reachability information -- most commonly, what MAC (Media Access Control) address [RFC7042] corresponds to an IP address within a Data Label (VLAN or FGL (Fine-Grained Label) [RFC7172]) and the egress TRILL switch (RBridge), and, optionally, what specific port on that TRILL switch, from which that MAC address is reachable. But it could be what IP address corresponds to a MAC address or possibly other address mapping or reachability information.
ディレクトリが保持する情報は、アドレスマッピングと到達可能性情報です。最も一般的には、どのMAC（Media Access Control）アドレス[RFC7042]がデータラベル（VLANまたはFGL（Fine-Grained Label））内のIPアドレスに対応しますか。 RFC7172]）と出力TRILLスイッチ（RBridge）、およびオプションで、そのMACアドレスに到達できる、そのTRILLスイッチの特定のポート。ただし、MACアドレスに対応するIPアドレスや、場合によっては他のアドレスマッピングまたは到達可能性情報になる可能性があります。
The mechanism used to initially populate directory data in primary servers is beyond the scope of this document. A primary server can use the Push Directory service to provide directory data to secondary servers, as described in Section 2.6. In the data-center environment, it is common for orchestration software to know and control where all the IP addresses, MAC addresses, and VLANs/tenants are in a data center. Thus, such orchestration software can be appropriate for providing the directory function or for supplying the directory or directories with directory information.
プライマリサーバーのディレクトリデータを最初に入力するために使用されるメカニズムは、このドキュメントの範囲外です。プライマリサーバーは、セクション2.6で説明されているように、プッシュディレクトリサービスを使用して、セカンダリサーバーにディレクトリデータを提供できます。データセンター環境では、オーケストレーションソフトウェアがすべてのIPアドレス、MACアドレス、およびVLAN /テナントがデータセンター内のどこにあるかを認識して制御するのが一般的です。したがって、そのようなオーケストレーションソフトウェアは、ディレクトリ機能を提供したり、ディレクトリにディレクトリ情報を提供したりするのに適しています。
Efficient routing of unicast traffic in a TRILL campus assumes that the mapping of destination MAC addresses to edge RBridges is stable enough that the default data-plane learning of TRILL and/or the use of directories reduces to an acceptable level the need to flood packets where the location of the destination is unknown. Although not prohibited, "ephemeral" MAC addresses are unlikely to be used in such an environment. Directories need not be complete, and in the case that any ephemeral MAC addresses were in use, they would probably not be included in directory information.
TRILLキャンパスでのユニキャストトラフィックの効率的なルーティングは、宛先MACアドレスのエッジRBridgeへのマッピングが十分に安定しており、TRILLのデフォルトのデータプレーン学習および/またはディレクトリの使用が、パケットをフラッディングする必要性を許容レベルまで低下させることを前提としています。目的地の場所は不明です。 「エフェメラル」MACアドレスは禁止されていませんが、そのような環境では使用されない可能性があります。ディレクトリは完全である必要はなく、エフェメラルMACアドレスが使用されている場合は、おそらくディレクトリ情報に含まれません。
Directory services can be offered in a Push Mode, Pull Mode, or both [RFC7067] at the discretion of the server. Push Mode, in which a directory server pushes information to TRILL switches indicating interest, is specified in Section 2. Pull Mode, in which a TRILL switch queries a server for the information it wants, is specified in Section 3. More detail on modes of operation, including hybrid Push/Pull, are provided in Section 4.
ディレクトリサービスは、サーバーの裁量でプッシュモード、プルモード、またはその両方[RFC7067]で提供できます。ディレクトリサーバーが興味を示すTRILLスイッチに情報をプッシュするプッシュモードは、セクション2で指定されています。必要な情報をTRILLスイッチがサーバーに照会するプルモードは、セクション3で指定されています。モードの詳細ハイブリッドプッシュ/プルを含む操作については、セクション4で説明します。
A TRILL switch can consult directory information whenever it wants by (1) searching through information that has been retained after being pushed to it or pulled by it or (2) requesting information from a Pull Directory. However, the following are expected to be the most common circumstances leading to the use of directory information. All of these are cases of ingressing (or originating) a native frame.
TRILLスイッチは、（1）プッシュまたはプルされた後に保持されている情報を検索するか、（2）プルディレクトリに情報を要求することにより、必要なときにいつでもディレクトリ情報を参照できます。ただし、ディレクトリ情報の使用につながる最も一般的な状況は次のとおりです。これらはすべて、ネイティブフレームへの侵入（または発信）の場合です。
1. ARP requests and replies [RFC826] are normally broadcast. But a directory-assisted edge TRILL switch could intercept ARP messages and reply if the TRILL switch has the relevant information [ARPND].
1. ARP要求と応答[RFC826]は通常ブロードキャストされます。ただし、ディレクトリ支援のエッジTRILLスイッチは、ARPメッセージを傍受し、TRILLスイッチに関連情報がある場合に応答する可能性があります[ARPND]。
2. IPv6 ND [RFC4861] requests and replies are normally multicast. Except in the case of Secure Neighbor Discovery (SEND) [RFC3971], where possession of the right keying material might be required, a directory-assisted edge TRILL switch could intercept ND messages and reply if the TRILL switch has the relevant information [ARPND].
2. IPv6 ND [RFC4861]の要求と応答は通常マルチキャストです。 Secure Neighbor Discovery（SEND）[RFC3971]の場合を除いて、適切なキー情報の保持が必要になる場合があるため、ディレクトリ支援エッジTRILLスイッチはNDメッセージを傍受し、TRILLスイッチに関連情報がある場合は応答します[ARPND] 。
3. Unknown destination MAC addresses normally cause a native frame to be flooded. An edge TRILL switch ingressing a native frame necessarily has to determine if it knows the egress RBridge from which the destination MAC address of the frame (in the frame's VLAN or FGL) is reachable. It might have learned that information from the directory or could query the directory if it does not know it. Furthermore, if the edge TRILL switch has complete directory information, it can detect a forged source MAC or IP address in any native frame and discard the frame if it finds such a forged address.
3. 宛先MACアドレスが不明な場合、通常はネイティブフレームがフラッディングされます。ネイティブフレームに入るエッジTRILLスイッチは、必然的に、フレームの宛先MACアドレス（フレームのVLANまたはFGL内）に到達できる出口RBridgeを知っているかどうかを判断する必要があります。それはディレクトリからの情報を知っているかもしれません、またはそれがそれを知らないならディレクトリに問い合わせることができます。さらに、エッジTRILLスイッチが完全なディレクトリ情報を持っている場合、任意のネイティブフレームで偽造された送信元MACアドレスまたはIPアドレスを検出し、そのような偽造アドレスが見つかった場合はフレームを破棄できます。
4. RARP [RFC903] (Reverse ARP) is similar to ARP (item 1 above).
4. RARP [RFC903]（Reverse ARP）は、ARP（上記の項目1）に似ています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The terminology and abbreviations of [RFC6325] are used herein, along with the following:
[RFC6325]の用語と略語は、以下とともに使用されます。
AFN: Address Family Number (http://www.iana.org/assignments/address-family-numbers/).
AFN：アドレスファミリー番号（http://www.iana.org/assignments/address-family-numbers/）。
CSNP Time: Complete Sequence Number Protocol Data Unit (PDU) time. See ESADI [RFC7357] and Section 7.1 below.
CSNP時間：完全なシーケンス番号プロトコルデータユニット（PDU）時間。 ESADI [RFC7357]および以下のセクション7.1を参照してください。
Data Label: VLAN or FGL.
データラベル：VLANまたはFGL。
ESADI: End Station Address Distribution Information [RFC7357].
ESADI：端末アドレス配布情報[RFC7357]。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
FR: Flood Record flag bit. See Section 3.2.1.
FR：フラッドレコードフラグビット。セクション3.2.1を参照してください。
Host: A physical server or a virtual machine. A host must have a MAC address and usually has at least one IP address.
ホスト：物理サーバーまたは仮想マシン。ホストにはMACアドレスが必要で、通常は少なくとも1つのIPアドレスが必要です。
Interested Labels sub-TLV: Short for "Interested Labels and Spanning Tree Roots sub-TLV" [RFC7176].
興味のあるラベルのサブTLV：「興味のあるラベルとスパニングツリールートのサブTLV」の略[RFC7176]。
Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning Tree Roots sub-TLV" [RFC7176].
関心のあるVLANサブTLV：「関心のあるVLANとスパニングツリールートのサブTLV」の略[RFC7176]。
IP: Internet Protocol. In this document, IP includes both IPv4 and IPv6.
IP：インターネットプロトコル。このドキュメントでは、IPにはIPv4とIPv6の両方が含まれます。
MAC address: Media Access Control address [RFC7042].
MACアドレス：Media Access Controlアドレス[RFC7042]。
MacDA: Destination MAC address.
MacDA：宛先MACアドレス。
MacSA: Source MAC address.
MacSA：送信元MACアドレス。
OV: Overflow flag bit. See Section 3.2.2.1.
OV：オーバーフローフラグビット。セクション3.2.2.1を参照してください。
PDSS: Push Directory Server Status. See Sections 2 and 7.1.
PDSS：Directory Serverステータスをプッシュします。セクション2および7.1を参照してください。
Primary server: A directory server that obtains the information it is providing by a reliable mechanism designed to assure the freshness of that information. This mechanism is outside the scope of this document. (See "Secondary server" below.)
プライマリサーバー：提供する情報を、その情報の鮮度を保証するように設計された信頼できるメカニズムによって取得するディレクトリサーバー。このメカニズムは、このドキュメントの範囲外です。 （以下の「セカンダリサーバー」を参照してください。）
PUL: Pull Directory flag bit. See Sections 3 and 7.3.
PUL：プルディレクトリフラグビット。セクション3および7.3を参照してください。
RBridge: An alternative name for a TRILL switch.
RBridge：TRILLスイッチの別名。
Secondary server: A directory server that obtains the information it is providing from one or more primary servers.
セカンダリサーバー：1つ以上のプライマリサーバーから提供する情報を取得するディレクトリサーバー。
TLV: Type, Length, Value.
TLV：タイプ、長さ、値。
TRILL: Transparent Interconnection of Lots of Links or Tunneled Routing in the Link Layer.
TRILL：多くのリンクの透過的な相互接続またはリンク層のトンネルルーティング。
TRILL switch: A device that implements the TRILL protocol.
TRILLスイッチ：TRILLプロトコルを実装するデバイス。
In the Push Model [RFC7067], one or more Push Directory servers reside at TRILL switches and "push down" the address mapping information for the various addresses associated with end-station interfaces and the TRILL switches from which those interfaces are reachable [RFC7961]. This service is scoped by Data Label (VLAN or FGL [RFC7172]). A Push Directory advertises when, for a Data Label, it is configured to be a directory having complete information and also has actually pushed all the information it has. It might be pushing only a subset of the mapping and/or reachability information for a Data Label. The Push Model uses the ESADI [RFC7357] protocol as its distribution mechanism.
プッシュモデル[RFC7067]では、1つまたは複数のプッシュディレクトリサーバーがTRILLスイッチに常駐し、端末インターフェースに関連付けられたさまざまなアドレスのアドレスマッピング情報と、それらのインターフェースに到達できるTRILLスイッチを[プッシュダウン]します[RFC7961] 。このサービスのスコープはデータラベル（VLANまたはFGL [RFC7172]）です。プッシュディレクトリは、データラベルの場合、完全な情報を持つディレクトリになるように構成され、実際にすべての情報をプッシュしたときにアドバタイズします。データラベルのマッピングおよび/または到達可能性情報のサブセットのみをプッシュしている可能性があります。プッシュモデルは、配信メカニズムとしてESADI [RFC7357]プロトコルを使用します。
With the Push Model, if complete address mapping information for a Data Label is being pushed, a TRILL switch (RBridge) that has that complete information and is ingressing a native frame can simply drop the frame if the destination unicast MAC address can't be found in the mapping information available, instead of flooding the frame (ingressing it as an unknown MAC destination TRILL Data frame). But this will result in lost traffic if the ingress TRILL switch's directory information is incomplete.
プッシュモデルでは、データラベルの完全なアドレスマッピング情報がプッシュされている場合、その完全な情報を持ち、ネイティブフレームに進入しているTRILLスイッチ（RBridge）は、宛先ユニキャストMACアドレスを送信できない場合、単にフレームをドロップできます。フレームをフラッディングするのではなく、利用可能なマッピング情報で見つかります（不明なMAC宛先TRILLデータフレームとして入力されます）。ただし、入力TRILLスイッチのディレクトリ情報が不完全な場合は、トラフィックが失われます。
In the Push Model, it is necessary to have a way for a TRILL switch to subscribe to information from the directory server(s). TRILL switches simply use the ESADI [RFC7357] protocol mechanism to announce, in their core IS-IS Link State PDUs (LSPs), the Data Labels for which they are participating in ESADI by using the Interested VLANs sub-TLV [RFC7176] and/or the Interested Labels sub-TLV [RFC7176]. This will cause the directory information to be pushed to them for all such Data Labels that are being served by the one or more Push Directory servers.
プッシュモデルでは、TRILLスイッチがディレクトリサーバーからの情報をサブスクライブする方法が必要です。 TRILLスイッチは、ESADI [RFC7357]プロトコルメカニズムを単に使用して、コアIS-ISリンク状態PDU（LSP）で、関心のあるVLANサブTLV [RFC7176]を使用してESADIに参加しているデータラベルを通知します。またはInterest Labels sub-TLV [RFC7176]。これにより、1つまたは複数のプッシュディレクトリサーバーによって提供されているそのようなすべてのデータラベルのディレクトリ情報がプッシュされます。
Push Directory servers advertise, through ESADI, their availability to push the mapping information for a particular Data Label by setting the PDSS in their ESADI-Parameter APPsub-TLV for that ESADI instance (see [RFC7357] and Section 7.1) to a non-zero value. This PDSS field setting is visible to other ESADI participants, including other Push Directory servers, for that Data Label. Each Push Directory server MUST participate in ESADI for the Data Labels for which it will push mappings and set the PDSS field in its ESADI-Parameter APPsub-TLV for that Data Label. For increased robustness, increased bandwidth capability, and improved locality, it is useful to have multiple Push Directory servers for each Data Label. Each Push Directory server is configured with a number N, which is in the range 1 through 8 and defaults to 2, for each Data Label for which it can push directory information (see "PushDirServers" in Section 2.7). If the Push Directory servers for a Data Label are configured consistently with the same N and at least N servers are available, then N copies of that directory will be pushed.
プッシュディレクトリサーバーは、ESADIを介して、そのESADIインスタンスの[ESADIパラメータAPPsub-TLV（[RFC7357]およびセクション7.1を参照）でPDSSをゼロ以外に設定することにより、特定のデータラベルのマッピング情報をプッシュする可用性を通知します。値。このPDSSフィールド設定は、そのデータラベルの、他のプッシュディレクトリサーバーを含む他のESADI参加者に表示されます。各プッシュディレクトリサーバーは、マッピングをプッシュし、そのデータラベルのESADIパラメータAPPsub-TLVにPDSSフィールドを設定するデータラベルのESADIに参加する必要があります。堅牢性の向上、帯域幅機能の向上、および局所性の向上のために、データラベルごとに複数のプッシュディレクトリサーバーを用意すると便利です。各プッシュディレクトリサーバーは、ディレクトリ情報をプッシュできる各データラベルに対して、1〜8の範囲の数値Nで構成され、デフォルトは2です（2.7項の「PushDirServers」を参照）。データラベルのプッシュディレクトリサーバーが常に同じNで構成されていて、少なくともN個のサーバーが利用可能な場合、そのディレクトリのN個のコピーがプッシュされます。
Each Push Directory server also has a configurable 8-bit priority (PushDirPriority) to be Active, which defaults to 0x3F (see Section 2.7). This priority is treated as an unsigned integer, where the larger magnitude means higher priority. This priority appears in its ESADI-Parameter APPsub-TLV (see Section 7.1). In the case of a tie in this configurable priority, the System ID of the TRILL switch acting as the server is used as a tiebreaker and is treated as an unsigned 6-byte integer, where the larger magnitude indicates higher priority.
各プッシュディレクトリサーバーには、アクティブになるように構成可能な8ビットの優先度（PushDirPriority）もあり、デフォルトは0x3Fです（セクション2.7を参照）。この優先順位は、符号なし整数として扱われます。大きさが大きいほど、優先順位が高くなります。この優先順位は、ESADIパラメータAPPsub-TLVに表示されます（セクション7.1を参照）。この構成可能な優先順位のタイの場合、サーバーとして機能するTRILLスイッチのシステムIDはタイブレーカーとして使用され、符号なしの6バイト整数として扱われます。
For each Data Label it can serve, each Push Directory server checks to see if there appear to be enough higher-priority servers to push the desired number of copies. It does this by ordering, by priority, the Push Directory servers whose advertisements are present in the ESADI link-state database for that Data Label and that are data reachable [RFC7780] as indicated by its IS-IS link-state database. The Push Directory server then determines its own position in that order. If a Push Directory server's configuration indicates that N copies of the mappings for a Data Label should be pushed and the server finds that it is number K in the priority ordering (where number 1 in the ordered list is highest priority and the last is lowest priority), then if K is less than or equal to N, the Push Directory server is Active. If K is greater than N, it is Stand-By. Active and Stand-By behavior are specified below in Section 2.3.
提供できるデータラベルごとに、各プッシュディレクトリサーバーは、必要な数のコピーをプッシュするのに十分な優先度の高いサーバーがあるかどうかを確認します。これは、その広告がESADIリンク状態データベースに存在し、そのIS-ISリンク状態データベースによって示されるデータ到達可能[RFC7780]である広告ディレクトリを持つプッシュディレクトリサーバーを優先的に注文することによって行われます。プッシュディレクトリサーバーは、その順序で独自の位置を決定します。プッシュディレクトリサーバーの構成で、データラベルのマッピングのN個のコピーをプッシュする必要があることが示され、サーバーがそれが優先順位の番号K（番号付きリストの番号1が最も高く、最後が最も低い優先順位）であることを検出した場合）、KがN以下の場合、プッシュディレクトリサーバーはアクティブです。 KがNより大きい場合、それはスタンバイです。アクティブおよびスタンバイの動作は、セクション2.3で指定します。
For a Push Directory to reside on an end station, one or more TRILL switches locally connected to that end station must proxy for the Push Directory server and advertise themselves in ESADI as Push Directory servers. It appears to the rest of the TRILL campus that these TRILL switches (that are proxying for the end station) are the Push Directory server(s). The protocol between such a Push Directory end station and the one or more proxying TRILL switches acting as Push Directory servers is beyond the scope of this document.
プッシュディレクトリをエンドステーションに配置するには、そのエンドステーションにローカルに接続されている1つ以上のTRILLスイッチがプッシュディレクトリサーバーをプロキシし、ESADIでプッシュディレクトリサーバーとしてアドバタイズする必要があります。これらのTRILLスイッチ（エンドステーションのプロキシ）がプッシュディレクトリサーバーであるように、残りのTRILLキャンパスには見えます。このようなプッシュディレクトリエンドステーションと、プッシュディレクトリサーバーとして機能する1つ以上のプロキシTRILLスイッチ間のプロトコルは、このドキュメントの範囲外です。
The subsections below describe the states, events, and corresponding actions for Push Directory servers.
以下のサブセクションでは、プッシュディレクトリサーバーの状態、イベント、および対応するアクションについて説明します。
The meanings of possible values of the PDSS field in a Push Directory's ESADI-Parameter APPsub-TLV are summarized in the table below.
プッシュディレクトリのESADIパラメータAPPsub-TLVのPDSSフィールドの可能な値の意味を、以下の表にまとめます。
PDSS Meaning
---- ------------------------------------------------------
0 Not a Push Directory server
1 Push Directory server in Stand-By Mode
2 Push Directory server in Active Mode but not complete
3 Push Directory server in Active Mode that has pushed
complete data
A Push Directory server is in one of seven states, as listed below, for each Data Label it can serve. The name of each state is followed by a symbol that starts and ends with an angle bracket (for example, "<S1>") and represents the state. The value that the Push Directory server advertises in the PDSS is determined by the state. In addition, it has an internal State-Transition-Time variable for each Data Label it serves that is set at each state transition and that enables it to determine how long it has been in its current state for that Data Label.
プッシュディレクトリサーバーは、提供できる各データラベルについて、以下に示すように7つの状態のいずれかにあります。各状態の名前の後には、山かっこで始まり、山かっこで終わる記号が続き（たとえば、「<S1>」）、状態を表します。プッシュディレクトリサーバーがPDSSでアドバタイズする値は、状態によって決まります。さらに、各状態遷移で設定され、データラベルの現在の状態にある時間を判別できるようにする、各データラベルの内部State-Transition-Time変数があります。
Down <S1>: A completely shut down virtual state, defined for convenience in specifying state diagrams. A Push Directory server in this state does not advertise any Push Directory data. It may be participating in ESADI [RFC7357] with the PDSS field set to 0 in its ESADI-Parameter APPsub-TLV, or it might not be participating in ESADI at all. All states other than the Down state are considered to be Up states and imply a non-zero PDSS field.
ダウン<S1>：完全にシャットダウンされた仮想状態。状態図を指定するのに便利です。この状態のプッシュディレクトリサーバーは、プッシュディレクトリデータをアドバタイズしません。 ESADIパラメータAPPsub-TLVでPDSSフィールドが0に設定されたESADI [RFC7357]に参加しているか、ESADIにまったく参加していない可能性があります。ダウン状態以外のすべての状態はアップ状態と見なされ、ゼロ以外のPDSSフィールドを意味します。
Stand-By <S2>: No Push Directory data is advertised. Any outstanding ESADI-LSP fragments containing directory data are updated to remove that data, and if the result is an empty fragment (contains nothing except possibly an Authentication TLV), the fragment is purged. The Push Directory participates in ESADI [RFC7357] and advertises its ESADI fragment zero that includes an ESADI-Parameter APPsub-TLV with the PDSS field set to 1.
スタンバイ<S2>：プッシュディレクトリデータはアドバタイズされません。ディレクトリデータを含む未処理のESADI-LSPフラグメントは更新されてそのデータが削除され、結果が空のフラグメント（認証TLV以外のものが含まれていない）の場合、フラグメントはパージされます。プッシュディレクトリはESADI [RFC7357]に参加し、PDSSフィールドが1に設定されたESADIパラメータAPPsub-TLVを含むESADIフラグメントゼロをアドバタイズします。
Active <S3>: The Push Directory participates in ESADI [RFC7357] and advertises its ESADI fragment zero that includes an ESADI-Parameter APPsub-TLV with the PDSS field set to 2. It also advertises its directory data and any changes through ESADI [RFC7357] in its ESADI-LSPs, using the Interface Addresses APPsub-TLV [RFC7961], and updates that information as it changes.
アクティブ<S3>：プッシュディレクトリはESADI [RFC7357]に参加し、PDSSフィールドが2に設定されたESADIパラメータAPPsub-TLVを含むESADIフラグメントゼロをアドバタイズします。また、ディレクトリデータとESADIを介した変更もアドバタイズします[RFC7357 ] ESADI-LSP内で、インターフェイスアドレスAPPsub-TLV [RFC7961]を使用し、変更に応じてその情報を更新します。
Active Completing <S4>: The same behavior as the Active state, except that the server responds differently to events. The purpose of this state is to be sure that there has been enough time for directory information to propagate to subscribing edge TRILL switches (see "Time Condition", as defined in Section 2.3.2) before the directory server advertises that the information is complete.
アクティブ完了<S4>：サーバーがイベントに異なる応答をすることを除いて、アクティブ状態と同じ動作。この状態の目的は、ディレクトリサーバーが情報の完了を通知する前に、ディレクトリ情報がサブスクライブエッジTRILLスイッチ（セクション2.3.2で定義されている「時間条件」を参照）に伝播するのに十分な時間があることを確認することです。 。
Active Complete <S5>: The same behavior as Active, except that the PDSS field in the ESADI-Parameter APPsub-TLV is set to 3 and the server responds differently to events.
Active Complete <S5>：ESADI-Parameter APPsub-TLVのPDSSフィールドが3に設定され、サーバーがイベントに異なる応答をすることを除いて、Activeと同じ動作。
Going Stand-By Was Complete <S6>: The same behavior as Active, except that the server responds differently to events. The purpose of this state is to be sure that the information indicating that the directory will no longer be complete has enough time to propagate to edge TRILL switches (see "Time Condition" in Section 2.3.2) before the directory server stops advertising updates to the information. (See note below.)
スタンバイへの移行が完了しました<S6>：サーバーがイベントに異なる応答をすることを除いて、アクティブと同じ動作です。この状態の目的は、ディレクトリサーバーが更新の通知を停止する前に、ディレクトリが完成しないことを示す情報に、エッジTRILLスイッチ（セクション2.3.2の「時間条件」を参照）に伝播するのに十分な時間があることを確認することです。情報。 （下記の注を参照してください。）
Active Uncompleting <S7>: The same behavior as Active, except that it responds differently to events. The purpose of this state is to be sure that the information indicating that the directory will no longer be complete has enough time to propagate to edge TRILL switches (see "Time Condition" in Section 2.3.2) before the directory server might stop advertising updates to the information. (See note below.)
Active Uncompleting <S7>：イベントへの応答が異なることを除いて、Activeと同じ動作です。この状態の目的は、ディレクトリが完了しないことを示す情報に、ディレクトリサーバーが更新のアドバタイズを停止する前にエッジTRILLスイッチに伝播するのに十分な時間があることを確認することです（2.3.2項の「時間条件」を参照）。情報に。 （下記の注を参照してください。）
Note: It might appear that a Push Directory could transition directly from Active Complete to Active, since the Active state continues to advertise updates, eliminating the need for the Active Uncompleting transition state. But consider the case of the Push Directory that was complete being configured to be incomplete and then the Stand-By Condition (see Section 2.3.2) occurring shortly thereafter. If the first of these two events caused the server to transition directly to the Active state, then later, when the Stand-By Condition occurred, it would immediately transition to Stand-By and stop advertising updates even though there might not have been enough time for knowledge of its incompleteness to have propagated to all edge TRILL switches.
注：アクティブ状態が更新をアドバタイズし続けるため、プッシュディレクトリがアクティブ完了からアクティブに直接移行し、アクティブな未完了の移行状態の必要性がなくなるように見える場合があります。ただし、完全に構成されたプッシュディレクトリが不完全になるように構成され、その後すぐにスタンバイ条件（セクション2.3.2を参照）が発生する場合を考えます。これらの2つのイベントの最初のイベントによってサーバーが直接アクティブ状態に移行した場合、その後スタンバイ状態が発生すると、十分な時間がなかったとしても、すぐにスタンバイ状態に移行し、更新の通知を停止します。その不完全性の知識がすべてのエッジTRILLスイッチに伝播したため。
The following table lists each state and its corresponding PDSS value:
次の表に、各状態とそれに対応するPDSS値を示します。
State PDSS
-------------------------------- ------
Down <S1> 0
Stand-By <S2> 1
Active <S3> 2
Active Completing <S4> 2
Active Complete <S5> 3
Going Stand-By Was Complete <S6> 2
Active Uncompleting <S7> 2
Three auxiliary conditions, referenced later in this subsection, are defined as follows:
このサブセクションの後半で参照される3つの補助条件は、次のように定義されます。
The Activate Condition: In order to have the desired number of Push Directory servers pushing data for Data Label X, this Push Directory server should be active. This is determined by the server finding that (a) it is priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it is configured that there should be N copies pushed for Data Label X, and (c) K is less than or equal to N. For example, the Push Directory server is configured so that two copies should be pushed and finds that it is priority 1 or 2 among the Push Directory servers that are visible in its ESADI link-state database and that are data reachable, as indicated by its IS-IS link-state database.
アクティブ化条件：データラベルXのデータをプッシュする目的の数のプッシュディレクトリサーバーを使用するには、このプッシュディレクトリサーバーをアクティブにする必要があります。これは、サーバーがデータラベルXに対して（a）データ到達可能プッシュディレクトリサーバー（優先度が最も高いサーバーは1）の中で優先度Kであると判断したサーバーによって決定されます。（b）コピー数がNになるように構成されています。データラベルXに対してプッシュされ、（c）KがN以下である。たとえば、2つのコピーがプッシュされるようにプッシュディレクトリサーバーが構成され、それが次のプッシュディレクトリサーバーの中で優先度1または2であることがわかりますESADIリンク状態データベースに表示され、IS-ISリンク状態データベースで示されるように、データに到達可能です。
The Stand-By Condition: In order to have the desired number of Push Directory servers pushing data for Data Label X, this Push Directory server should be Stand-By (not Active). This is determined by the server finding that (a) it is priority K among the data-reachable Push Directory servers (where the highest-priority server is 1) for Data Label X, (b) it is configured that there should be N copies pushed for Data Label X, and (c) K is greater than N. For example, the Push Directory server is configured so that two copies should be pushed and finds that it is priority 3 or lower priority (higher number) among the available Push Directory servers.
スタンバイ条件：データラベルXのデータをプッシュする目的の数のプッシュディレクトリサーバーを使用するには、このプッシュディレクトリサーバーがスタンバイ（アクティブではない）である必要があります。これは、（a）データラベルXのデータ到達可能プッシュディレクトリサーバー（優先度が最も高いサーバーは1）の中で優先度Kであるとサーバーが判断することで決定されます。（b）Nコピーが存在するように構成されています。データラベルXに対してプッシュされ、（c）KがNより大きい。たとえば、プッシュディレクトリサーバーは、2つのコピーがプッシュされるように構成され、利用可能なプッシュの中で優先度3または低い優先度（高い数）であることがわかりますディレクトリサーバー。
The Time Condition: The Push Directory server has been in its current state for a configurable amount of time (PushDirTimer) that defaults to twice its CSNP (Complete Sequence Number PDU) time (see Sections 2.7 and 7.1).
時間条件：プッシュディレクトリサーバーは、CSNP（Complete Sequence Number PDU）時間の2倍にデフォルトで設定可能な時間（PushDirTimer）の間、現在の状態になっています（セクション2.7および7.1を参照）。
The events and conditions listed below cause state transitions in Push Directory servers.
以下にリストされているイベントと条件は、プッシュディレクトリサーバーの状態遷移を引き起こします。
1. The Push Directory server comes up.
1. プッシュディレクトリサーバーが起動します。
2. The Push Directory server or the TRILL switch on which it resides is being shut down. This is a persistent condition, unless the shutdown is canceled. So, for example, a Push Directory server in the Going Stand-By Was Complete state does not transition out of that state due to this condition but, after (1) the Time Condition is met and (2) the directory transitions to Stand-By and then performs the actions required there (such as purging LSPs), continues to the Down state if this condition is still true. Similar comments apply to events/conditions 3, 4, and 5.
2. プッシュディレクトリサーバーまたはそれが常駐するTRILLスイッチがシャットダウンされています。シャットダウンがキャンセルされない限り、これは永続的な状態です。そのため、たとえば、Going Stand-By Was Complete状態のプッシュディレクトリサーバーは、この状態が原因でその状態から移行しませんが、（1）時間条件が満たされ、（2）ディレクトリがStand-に移行します。そこで必要なアクション（LSPのパージなど）を実行し、この条件がまだ当てはまる場合は、ダウン状態を継続します。同様のコメントがイベント/条件3、4、および5に適用されます。
3. The Activate Condition is met, and the server's configuration indicates that it does not have complete data.
3. アクティベート条件が満たされ、サーバーの構成は、完全なデータがないことを示しています。
4. The Stand-By Condition is met.
4. スタンバイ条件が満たされています。
5. The Activate Condition is met, and the server's configuration indicates that it has complete data.
5. アクティベート条件が満たされ、サーバーの構成は完全なデータがあることを示しています。
6. The server's configuration is changed to indicate that it does not have complete data.
6. サーバーの構成が変更され、完全なデータがないことを示します。
7. The Time Condition is met.
7. 時間条件が満たされています。
The state transition table is as follows:
状態遷移表は次のとおりです。
| | | | Active | Active | Going | Active
State|Down|Stand-By|Active|Completing|Complete| Stand-By |Uncompleting
-----+ | | | | |Was Complete|
Event|<S1>| <S2> | <S3> | <S4> | <S5> | <S6> | <S7>
-----+----+--------+------+----------+--------+------------+------------
1 |<S2>| N/A | N/A | N/A | N/A | N/A | N/A
2 |<S1>| <S1> | <S2> | <S2> | <S6> | <S6> | <S7>
3 |<S1>| <S3> | <S3> | <S3> | <S7> | <S3> | <S7>
4 |<S1>| <S2> | <S2> | <S2> | <S6> | <S6> | <S6>
5 |<S1>| <S4> | <S4> | <S4> | <S5> | <S5> | <S5>
6 |<S1>| <S2> | <S3> | <S3> | <S7> | <S6> | <S7>
7 |<S1>| <S2> | <S3> | <S5> | <S5> | <S2> | <S3>
The above state table is equivalent to the following transition diagram:
上記の状態テーブルは、次の遷移図と同等です。
+-----------+
| Down <S1> |<---------+
+-----------+ |
|1 ^ | 3,4,5,6,7 |
| | +------------+
V |2
+---------------+
| Stand-By <S2> |<--------------------------------------+
+---------------+ ^ ^ ^ |
|5 |3 |1,4,6,7 | | | |
| | +---------+ | | |
| V |2,4 | |
| +---------------------+ | |
| | Active <S3> |<---------|-------------+ |
| +---------------------+ ^ | | |
| |5 ^ |1,3,6,7 ^ | | | |
| | | | | | | | |
| | | +---------+ | | | |
| | | | | | |
V V |3,6 | | | |
+------------------------+ | | | |
| Active Completing <S4> |------------+ | |
+------------------------+ 2,4 | | |
|7 |1,5 ^ | | |
| | | | | |
| +-------+ | | |
| | | |
| +------------------------------------+ | |
| | | | | |
V V |7 |5 |3 |7
+-------------+ 3,6 +----------------+ 4 +----------------+
| Active |------->| Active |--->| Going Stand-By |
| Complete | | Uncompleting | | Was Complete |
| <S5> |<-------| <S7> | | <S6> |
+-------------+ 5 +----------------+ +----------------+
|1,5,7 ^ |2,4 |1,2,3,6 ^ ^ |1,2,4,6 ^
| | | | | | | |
+-------+ | +------------+ | +--------+
| |
+----------------------------------+
Figure 1: Push Server State Diagram
図1：プッシュサーバーの状態図
End-station hosting and end-station use of Push Directories are outside the scope of this document. Push Directory information distribution is accomplished using ESADI [RFC7357], which does not operate to end stations. In the future, ESADI might be extended to operate to end stations, or some other method, such as BGP, might be specified as a way to support end-station hosting or end-station use of Push Directories.
端末のホスティングと端末のプッシュディレクトリの使用は、このドキュメントの範囲外です。プッシュディレクトリ情報の配信は、エンドステーションでは動作しないESADI [RFC7357]を使用して行われます。将来、ESADIはエンドステーションまで動作するように拡張されるか、またはBGPなどの他の方法が、エンドステーションのホスティングまたはエンドステーションでのプッシュディレクトリの使用をサポートする方法として指定される可能性があります。
Push Directory mappings can be distinguished from other data distributed through ESADI, because mappings are distributed only with the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that APPsub-TLV as being Push Directory data.
マッピングはインターフェイスアドレスAPPsub-TLV [RFC7961]でのみ配布され、そのAPPsub-TLVでプッシュディレクトリデータとしてフラグが付けられるため、プッシュディレクトリマッピングはESADIを通じて配布される他のデータと区別できます。
TRILL switches, whether or not they are Push Directory servers, MAY continue to advertise any locally learned MAC attachment information in ESADI [RFC7357] using the MAC-Reachability TLV [RFC6165]. However, if a Data Label is being served by complete Push Directory servers, advertising such a locally learned MAC attachment generally SHOULD NOT be done, as it would not add anything and would just waste bandwidth and ESADI link-state space. An exception might be when a TRILL switch learns local MAC connectivity and that information appears to be missing from the directory mapping.
TRILLスイッチは、それらがプッシュディレクトリサーバーであるかどうかに関係なく、MAC到達可能性TLV [RFC6165]を使用してESADI [RFC7357]でローカルに学習したMACアタッチメント情報を引き続きアドバタイズできます（MAY）。ただし、データラベルが完全なプッシュディレクトリサーバーによって提供されている場合、ローカルで学習されたMACアタッチメントのアドバタイズは、何も追加せず、帯域幅とESADIリンク状態スペースを浪費するだけなので、通常、行わないでください。例外は、TRILLスイッチがローカルMAC接続を学習し、その情報がディレクトリマッピングから欠落しているように見える場合です。
Because a Push Directory server needs to advertise interest in one or more Data Labels even though it might not want to receive multi-destination TRILL Data packets in those Data Labels, the "No Data" (NOD) flag bit is provided, as discussed in Section 3.8.
プッシュディレクトリサーバーは、1つまたは複数のデータラベルに関心があることをアドバタイズする必要があるため、これらのデータラベルで複数の宛先のTRILLデータパケットを受信したくない場合でも、「データなし」（NOD）フラグビットが提供されます。セクション3.8
When a Push Directory server is no longer data reachable [RFC7780], as indicated by the IS-IS link-state database, other TRILL switches MUST ignore any Push Directory data from that server, because it is no longer being updated and may be stale.
IS-ISリンク状態データベースによって示されるように、プッシュディレクトリサーバーがデータに到達できなくなった場合[RFC7780]、他のTRILLスイッチはそのサーバーからのプッシュディレクトリデータを無視する必要があります。更新されていないため、古くなっている可能性があるためです。
The nature of dynamic distributed asynchronous systems is such that it is impossible for a TRILL switch receiving Push Directory information to be absolutely certain that it has complete information. However, it can obtain a reasonable assurance of complete information by requiring that two conditions be met:
動的分散非同期システムの性質上、プッシュディレクトリ情報を受信するTRILLスイッチが完全な情報を持っていることを完全に確実にすることは不可能です。ただし、次の2つの条件を満たすことを要求することにより、完全な情報の合理的な保証を得ることができます。
1. The PDSS field is 3 in the ESADI fragment zero from the server for the relevant Data Label.
1. PDSSフィールドは、関連するデータラベルのサーバーからのESADIフラグメントゼロの3です。
2. As far as it can tell, it has had continuous data connectivity to the server for a configurable amount of time that defaults to twice the server's CSNP time (see "PushDirTimer" in Section 2.7).
2. 確認できる限り、デフォルトでサーバーのCSNP時間の2倍に設定可能な時間の間、サーバーへの継続的なデータ接続がありました（セクション2.7の「PushDirTimer」を参照）。
Condition 2 is necessary because a client TRILL switch might be just coming up and receive an ESADI-LSP meeting the requirement in condition 1 above but has not yet received all of the ESADI-LSP fragments from the Push Directory server.
クライアントTRILLスイッチが起動し、上記の条件1の要件を満たすESADI-LSPを受信しているが、まだプッシュディレクトリサーバーからすべてのESADI-LSPフラグメントを受信していないため、条件2が必要です。
Likewise, due to various delays, when an end station connects to or disconnects from the campus, there are timing differences between such a connection or disconnection, the update of directory information at the directory, and the update of directory information at any particular RBridge in the TRILL campus. Thus, there is commonly a small window during which an RBridge using directory information might either (1) drop or unnecessarily flood a frame as having an unknown unicast destination or (2) encapsulate a frame to an edge RBridge where the end station is no longer connected when the frame arrives at that edge RBridge.
同様に、さまざまな遅延により、エンドステーションがキャンパスに接続または切断すると、そのような接続または切断、ディレクトリでのディレクトリ情報の更新、および特定のRBridgeでのディレクトリ情報の更新の間にタイミングの違いがあります。 TRILLキャンパス。したがって、通常、小さなウィンドウがあり、その間、ディレクトリ情報を使用するRBridgeは、（1）不明なユニキャスト宛先を持つフレームをドロップするか不必要にフラッディングするか、（2）エンドステーションがもはや存在しないエッジRBridgeにフレームをカプセル化します。フレームがそのエッジRBridgeに到着すると接続されます。
There may be conflicts between mapping information from different Push Directory servers or conflicts between locally learned information and information received from a Push Directory server. In cases of such conflicts, information with a higher confidence value [RFC6325] [RFC7961] is preferred over information with a lower confidence value. In cases of equal confidence values, Push Directory information is preferred to locally learned information, and if information from Push Directory servers conflicts, the information from the higher-priority Push Directory server is preferred.
異なるプッシュディレクトリサーバーからのマッピング情報の競合、またはローカルで学習した情報とプッシュディレクトリサーバーから受信した情報の競合が発生する可能性があります。このような矛盾の場合、信頼値が高い情報[RFC6325] [RFC7961]が、信頼値が低い情報よりも優先されます。信頼値が等しい場合、ローカルで学習した情報よりもプッシュディレクトリ情報が優先され、プッシュディレクトリサーバーからの情報が競合する場合は、優先度の高いプッシュディレクトリサーバーからの情報が優先されます。
A secondary Push or Pull Directory server is one that obtains its data from a primary directory server. Such systems, where some directory servers can be populated from others, have been found useful for multiple-server directory applications -- for example, in the DNS, where it is the normal case that some authoritative servers (secondary servers) are populated with data from other authoritative servers (primary servers).
セカンダリプッシュまたはプルディレクトリサーバーは、プライマリディレクトリサーバーからデータを取得するサーバーです。一部のディレクトリサーバーに他のサーバーを追加できるこのようなシステムは、複数サーバーのディレクトリアプリケーションに役立つことがわかっています。たとえば、DNSでは、一部の権限のあるサーバー（セカンダリサーバー）にデータが入力されるのが通常です。他の権限のあるサーバー（プライマリサーバー）から。
Other techniques MAY be used, but by default, this data transfer occurs through the primary server acting as a Push Directory server for the Data Labels involved, while the secondary directory server takes the pushed data it receives from the highest-priority Push Directory server and re-originates it. Such a secondary server may be a Push Directory server, a Pull Directory server, or both for any particular Data Label. Because the data from a secondary server will necessarily be at least a little less fresh than that from a primary server, it is RECOMMENDED that the re-originated secondary server's data be given a confidence level at least one less than that of the data as received from the primary server (or unchanged if it is already of minimum confidence).
他の手法を使用することもできますが、デフォルトでは、このデータ転送は、関係するデータラベルのプッシュディレクトリサーバーとして機能するプライマリサーバーを介して行われ、セカンダリディレクトリサーバーは、最も優先度の高いプッシュディレクトリサーバーから受信したプッシュデータを受け取り、元に戻します。このようなセカンダリサーバーは、特定のデータラベルのプッシュディレクトリサーバー、プルディレクトリサーバー、またはその両方です。セカンダリサーバーからのデータは、少なくともプライマリサーバーからのデータよりも少し新しいため、再生成されたセカンダリサーバーのデータには、受信時のデータよりも少なくとも1低い信頼レベルを与えることをお勧めします。プライマリサーバーから（または、信頼性が既に低い場合は変更なし）。
The following configuration parameters, per Data Label, are available for controlling Push Directory behavior:
プッシュディレクトリの動作を制御するために、データラベルごとに次の構成パラメーターを使用できます。
Name Range/Setting Default Section
--------------- ------------- --------- ------------
PushDirService true/false false 2.2
PushDirServers 1-8 2 2.2
PushDirPriority 0-255 0x3F 2.2
PushDirComplete true/false false 2.3.1, 2.3.2
PushDirTimer 1-511 2 * CSNP 2.3.2, 2.5
PushDirService is a boolean. When false, Push Directory service is not provided; when true, it is.
PushDirServiceはブール値です。 falseの場合、プッシュディレクトリサービスは提供されません。真の場合はそうです。
PushDirComplete is a boolean. When false, the server never indicates that the information it has pushed is complete; when true, it does so indicate after pushing all the information it knows.
PushDirCompleteはブール値です。 falseの場合、サーバーはプッシュした情報が完全であることを決して示しません。 trueの場合、知っているすべての情報をプッシュした後、それを示します。
PushDirTimer defaults to two times the ESADI-CSNP configuration value but not less than 1 second.
PushDirTimerのデフォルトは、ESADI-CSNP構成値の2倍ですが、1秒以上です。
In the Pull Model [RFC7067], a TRILL switch (RBridge) pulls directory information from an appropriate directory server when needed.
プルモデル[RFC7067]では、TRILLスイッチ（RBridge）が、必要に応じて適切なディレクトリサーバーからディレクトリ情報をプルします。
A TRILL switch that makes use of Pull Directory services must implement appropriate connections between its directory utilization and its link-state database and link-state updating. For example, Pull Directory servers for a particular Data Label X are found by looking in the core TRILL IS-IS link-state database for data-reachable [RFC7780] TRILL switches that advertise themselves by setting the Pull Directory flag (PUL) to 1 in their Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label. The set of such switches can change with configuration changes by network management, such as the following:
プルディレクトリサービスを利用するTRILLスイッチは、そのディレクトリ使用率とそのリンク状態データベースおよびリンク状態更新との間に適切な接続を実装する必要があります。たとえば、特定のデータラベルXのプルディレクトリサーバーは、コアのTRILL IS-ISリンク状態データベースで、プルディレクトリフラグ（PUL）を1に設定することでアドバタイズするデータ到達可能[RFC7780] TRILLスイッチを探して見つかります。そのデータラベルの利害関係VLANサブTLVまたは利害関係ラベルサブTLV（セクション7.3を参照）。このようなスイッチのセットは、次のようなネットワーク管理による構成変更に伴って変化する可能性があります。
o the startup or shutdown of Pull Directory servers o changes in network topology, such as the connection or disconnection of TRILL switches that are Pull Directory servers
oプルディレクトリサーバーの起動またはシャットダウンoプルディレクトリサーバーであるTRILLスイッチの接続または切断などのネットワークトポロジの変更
o network partition or merger
o ネットワーク分割または合併
As described in Section 3.7, a TRILL switch MUST be able to detect that a Pull Directory from which it has cached data is no longer data reachable so that it can discard such cached data.
セクション3.7で説明したように、TRILLスイッチは、データをキャッシュしたプルディレクトリがデータにアクセスできなくなったことを検出して、そのようなキャッシュデータを破棄できるようにする必要があります。
If multiple data-reachable TRILL switches indicate in the link-state database that they are Pull Directory servers for a particular Data Label, pull requests can be sent to any one or more of them, but it is RECOMMENDED that pull requests be preferentially sent to the server or servers that are lowest cost from the requesting TRILL switch.
複数のデータ到達可能TRILLスイッチが特定のデータラベルのプルディレクトリサーバーであることをリンクステートデータベースで示している場合、プル要求はそれらの1つ以上に送信できますが、プル要求が優先的に送信されることをお勧めします要求しているTRILLスイッチからのコストが最も低いサーバー。
Pull Directory requests are sent by encapsulating them in an RBridge Channel [RFC7178] message using the Pull Directory channel protocol number (see Section 7.2). Responses are returned in an RBridge Channel message using the same channel protocol number. See Section 3.2 for Query and Response Message formats. For cache consistency or notification purposes, Pull Directory servers, under certain conditions, MUST send unsolicited Update Messages to client TRILL switches they believe may be holding old data. Those clients can acknowledge such updates, as described in Section 3.3. All these messages have a common header, as described in Section 3.1. Errors are returned as described in Section 3.6.
プルディレクトリ要求は、プルディレクトリチャネルプロトコル番号を使用してRBridgeチャネル[RFC7178]メッセージにカプセル化することにより送信されます（セクション7.2を参照）。応答は、同じチャネルプロトコル番号を使用してRBridge Channelメッセージで返されます。クエリおよび応答メッセージのフォーマットについては、セクション3.2を参照してください。キャッシュの一貫性または通知の目的で、プルディレクトリサーバーは、特定の条件下で、古いデータを保持していると思われるクライアントTRILLスイッチに非請求更新メッセージを送信する必要があります。セクション3.3で説明するように、これらのクライアントはこのような更新を確認できます。セクション3.1で説明するように、これらのメッセージにはすべて共通のヘッダーがあります。セクション3.6で説明されているように、エラーが返されます。
The requests to Pull Directory servers are typically derived from ingressed ARP [RFC826], ND [RFC4861], RARP [RFC903], or SEND [RFC3971] messages, or data frames with unknown unicast destination MAC addresses, intercepted by an ingress TRILL switch, as described in Section 1.1.
プルディレクトリサーバーへのリクエストは、通常、入力ARP [RFC826]、ND [RFC4861]、RARP [RFC903]、またはSEND [RFC3971]メッセージ、または入力TRILLスイッチによってインターセプトされた不明なユニキャスト宛先MACアドレスを持つデータフレームから派生します。セクション1.1で説明されています。
Pull Directory responses include an amount of time for which the response should be considered valid. This includes negative responses that indicate that no data is available. It is RECOMMENDED that both positive responses with data and negative responses be cached and used to locally handle ARP, ND, RARP, unknown destination MAC frames, or the like [ARPND], until the responses expire. If information previously pulled is about to expire, a TRILL switch MAY try to refresh it by issuing a new pull request but, to avoid unnecessary requests, SHOULD NOT do so unless it has been recently used. The validity timer of cached Pull Directory responses is NOT reset or extended merely because that cache entry is used.
プルディレクトリの応答には、応答が有効であると見なされる必要がある時間が含まれます。これには、利用可能なデータがないことを示す否定応答が含まれます。データのある肯定応答と否定応答の両方をキャッシュし、応答が期限切れになるまでローカルでARP、ND、RARP、不明な宛先MACフレームなどを処理するために使用することをお勧めします[ARPND]。以前にプルされた情報の有効期限が近づいている場合、TRILLスイッチは新しいプルリクエストを発行してそれを更新しようとしますが、不要なリクエストを回避するために、最近使用されていない限り、そうしないでください。キャッシュされたプルディレクトリの応答の有効性タイマーは、そのキャッシュエントリが使用されているという理由だけでリセットまたは拡張されません。
All Pull Directory messages are transmitted as the Channel Protocol-specific payload of RBridge Channel messages [RFC7178]. Pull Directory messages are formatted as described herein, starting with the following common 8-byte header:
すべてのプルディレクトリメッセージは、RBridgeチャネルメッセージのチャネルプロトコル固有のペイロードとして送信されます[RFC7178]。プルディレクトリメッセージは、次の一般的な8バイトヘッダーで始まる、ここで説明するようにフォーマットされます。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Specific Payload - variable length
+-+-+- ...
Ver: Version of the Pull Directory protocol. An unsigned integer. Version 0 (zero) is specified in this document. See Section 3.1.1 for a discussion of version negotiation.
Ver：プルディレクトリプロトコルのバージョン。符号なし整数。このドキュメントでは、バージョン0（ゼロ）が指定されています。バージョンネゴシエーションの説明については、セクション3.1.1を参照してください。
Type: The Pull Directory message type, as follows:
タイプ：プルディレクトリのメッセージタイプ。
Type Section Name
---- ------- ------------
0 - Reserved
1 3.2.1 Query
2 3.2.2 Response
3 3.3.1 Update
4 3.3.2 Acknowledge
5-14 - Unassigned
15 - Reserved
Flags: Four flag bits whose meaning depends on the Pull Directory message type. Flags whose meanings are not specified are reserved, MUST be sent as zero, and MUST be ignored on receipt.
フラグ：プルディレクトリのメッセージタイプによって意味が異なる4つのフラグビット。意味が指定されていないフラグは予約されており、ゼロとして送信する必要があり、受信時には無視する必要があります。
Count: Some Pull Directory message types specified herein have zero or more occurrences of a Record as part of the type-specific payload. The Count field is the number of occurrences of that Record and is expressed as an unsigned integer. For any Pull Directory messages not structured with such occurrences, this field MUST be sent as zero and ignored on receipt.
カウント：ここで指定されているいくつかのプルディレクトリメッセージタイプには、タイプ固有のペイロードの一部として、レコードが0回以上出現します。 Countフィールドは、そのRecordの出現回数であり、符号なし整数として表されます。このような発生で構成されていないプルディレクトリメッセージの場合、このフィールドはゼロとして送信され、受信時に無視される必要があります。
Err, SubErr: A two-part error code. These fields are only used in Reply Messages. In messages that are requests or updates, these fields MUST be sent as zero and ignored on receipt. An Err field containing the value zero means no error. The meaning of values in the SubErr field depends on the value of the Err field, but in all cases, a zero SubErr field is allowed and provides no additional information beyond the value of the Err field.
Err、SubErr：2つの部分からなるエラーコード。これらのフィールドは、返信メッセージでのみ使用されます。要求または更新であるメッセージでは、これらのフィールドをゼロとして送信し、受信時に無視する必要があります。値がゼロのErrフィールドは、エラーがないことを意味します。 SubErrフィールドの値の意味はErrフィールドの値によって異なりますが、すべての場合において、ゼロのSubErrフィールドが許可され、Errフィールドの値以外の追加情報は提供されません。
Sequence Number: An identifying 32-bit quantity set by the TRILL switch sending a request or other unsolicited message and returned in every corresponding reply or acknowledgment. It is used to match up responses with the message to which they respond.
シーケンス番号：リクエストまたはその他の非請求メッセージを送信するTRILLスイッチによって設定され、対応するすべての応答または確認で返される32ビットの識別番号。これは、応答と応答先のメッセージを一致させるために使用されます。
Type Specific Payload: Format depends on the Pull Directory message type.
タイプ固有のペイロード：形式は、プルディレクトリのメッセージタイプによって異なります。
The version number (Ver) in the Pull Directory message header is incremented for a future version with changes such that TRILL directory messages cannot be parsed correctly by an earlier version. Ver is not incremented for minor changes such as defining a new field value for an existing field.
プルディレクトリメッセージヘッダーのバージョン番号（Ver）は、TRILLディレクトリメッセージが以前のバージョンで正しく解析されないように変更されて、将来のバージョンで増加します。 Verは、既存のフィールドに新しいフィールド値を定義するなどの小さな変更では増分されません。
Pull Directory messages come in pairs (Request-Response, Update-Acknowledgment). The version number in the Request/Update (Ver1) indicates the format of that message and the format of the corresponding returned Response/Acknowledgment. The version number in the returned Response/Acknowledgment (Ver2) indicates the highest version number that the sender of that Response/Acknowledgment understands.
プルディレクトリのメッセージはペアで送信されます（要求-応答、更新-確認）。要求/更新（Ver1）のバージョン番号は、そのメッセージの形式と、対応する返された応答/確認の形式を示します。返された応答/確認応答（Ver2）のバージョン番号は、その応答/確認応答の送信者が理解できる最も高いバージョン番号を示します。
In the most common case -- a well-configured network -- Ver1 and Ver2 will be equal.
最も一般的なケース-適切に構成されたネットワーク-Ver1とVer2は同等です。
If Ver2 is less than Ver1, the returned Response/Acknowledgment will be an error message saying that the version is not understood.
Ver2がVer1より小さい場合、返されるResponse / Acknowledgementは、バージョンが理解されていないことを示すエラーメッセージになります。
If Ver2 is greater than Ver1 and the responder understands Ver1, it responds normally in Ver1 format. However, if the responder does not understand Ver1, it MUST send a "Version not understood" error message (Section 3.6.2) correctly formatted for Ver1. Thus, all implementations that support some version X MUST be able to send a Version not understood error message correctly formatted for all lower versions down to version 0.
Ver2がVer1より大きく、レスポンダがVer1を理解している場合は、Ver1形式で正常に応答します。ただし、レスポンダがVer1を理解していない場合は、Ver1用に正しくフォーマットされた「Version not理解」エラーメッセージ（セクション3.6.2）を送信する必要があります。したがって、一部のバージョンXをサポートするすべての実装は、バージョン0までのすべての下位バージョン用に正しくフォーマットされたバージョン不明のエラーメッセージを送信できる必要があります。
The formats of Pull Directory Query Messages and Pull Directory Response Messages are specified in Sections 3.2.1 and 3.2.2.1, respectively.
プルディレクトリクエリメッセージとプルディレクトリレスポンスメッセージの形式は、それぞれセクション3.2.1および3.2.2.1で指定されています。
A Pull Directory Query Message is sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). The Data Label of the packet is the Data Label in which the query is being made. The priority of the RBridge Channel message is a mapping of the priority of the ingressed frame that caused the query. The default mapping depends, per Data Label, on the strategy (see Section 4) or a configured priority (see "DirGenQPriority" in Section 3.9) for generated queries. (Generated queries are those queries that are not the result of a mapping -- for example, a query to refresh a cache entry.) The Channel Protocol-specific data is formatted as a header and a sequence of zero or more QUERY Records as follows:
プルディレクトリクエリメッセージは、RBridgeチャネルメッセージ[RFC7178] TRILLデータパケットのチャネルプロトコル固有のコンテンツとして、またはネイティブのRBridgeチャネルデータフレームとして送信されます（セクション3.5を参照）。パケットのデータラベルは、クエリが作成されるデータラベルです。 RBridge Channelメッセージの優先度は、クエリの原因となった入力フレームの優先度のマッピングです。デフォルトのマッピングは、データラベルごとに、生成されたクエリの戦略（セクション4を参照）または構成された優先度（セクション3.9の「DirGenQPriority」を参照）によって異なります。 （生成されたクエリは、マッピングの結果ではないクエリです（たとえば、キャッシュエントリを更新するクエリなど）。チャネルプロトコル固有のデータは、ヘッダーおよび次のように0個以上のQUERYレコードのシーケンスとしてフォーマットされます。 ：
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QUERY 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| QUERY K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Ver, Sequence Number: See Section 3.1.
バージョン、シーケンス番号：セクション3.1を参照してください。
Type: 1 for Query. Queries received by a TRILL switch that is not a Pull Directory for the relevant Data Label result in an error response (see Section 3.6) unless inhibited by rate limiting. (See [RFC7178] for information on the Response Message that is generated if the recipient implements the RBridge Channel features but does not implement the Pull Directory RBridge Channel Protocol.)
クエリの場合は1と入力します。関連するデータラベルのプルディレクトリではないTRILLスイッチによって受信されたクエリは、レート制限によって抑制されない限り、エラー応答（セクション3.6を参照）になります。 （受信者がRBridge Channel機能を実装しているが、Pull Directory RBridge Channel Protocolを実装していない場合に生成される応答メッセージについては、[RFC7178]を参照してください。）
Flags, Err, and SubErr: MUST be sent as zero and ignored on receipt.
Flags、Err、およびSubErr：ゼロとして送信し、受信時に無視する必要があります。
Count: Count is the number of QUERY Records present. A Query Message Count of 0 is explicitly allowed, for the purpose of pinging a Pull Directory server to see if it is responding. On receipt of such an empty Query Message, a Response Message that also has a Count of 0 is returned unless inhibited by rate limiting.
カウント：カウントは、存在するQUERYレコードの数です。プルディレクトリサーバーにpingして応答しているかどうかを確認するために、クエリメッセージ数0を明示的に許可します。このような空のクエリメッセージを受信すると、レート制限によって抑制されない限り、カウントが0の応答メッセージが返されます。
QUERY: Each QUERY Record within a Pull Directory Query Message is formatted as follows:
クエリ：プルディレクトリクエリメッセージ内の各クエリレコードは、次のようにフォーマットされます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |FR| RESV | QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
If QTYPE = 1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| AFN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Address ...
+--+--+--+--+--+--+--+--+--+--+--...
If QTYPE = 2 or 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Query Frame ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: Size of the QUERY Record in bytes, expressed as an unsigned integer and not including the SIZE field and following byte. A value of SIZE so large that the material doesn't fit in the Query Message indicates a malformed QUERY Record. A QUERY Record with such an illegal SIZE value, and any subsequent QUERY Records, MUST be ignored, and the entire Query Message MAY be ignored.
SIZE：バイト単位のQUERYレコードのサイズ。符号なし整数として表され、SIZEフィールドと後続のバイトは含まれません。マテリアルがクエリメッセージに収まらないほど大きいサイズの値は、不正なクエリレコードを示します。このような不正なSIZE値を持つQUERYレコード、および後続のQUERYレコードはすべて無視する必要があり、クエリメッセージ全体を無視する必要があります。
FR: The Flood Record flag. Ignored if QTYPE is 1. If QTYPE is 2 or 5 and the directory information sought is not found, the frame provided is flooded; otherwise, it is not forwarded. See Section 3.2.2.2. For QTYPEs other than 2 or 5, the FR flag has no effect.
FR：洪水記録フラグ。 QTYPEが1の場合は無視されます。QTYPEが2または5で、目的のディレクトリ情報が見つからない場合、提供されたフレームはフラッディングされます。それ以外の場合は転送されません。セクション3.2.2.2を参照してください。 2または5以外のQTYPEの場合、FRフラグは効果がありません。
RESV: A block of three reserved bits. MUST be sent as zero and ignored on receipt.
RESV：3つの予約済みビットのブロック。ゼロとして送信し、受信時に無視する必要があります。
QTYPE: There are several types of QUERY Records currently defined in two classes, as follows: (1) a QUERY Record that provides an explicit address and asks for all addresses for the interface specified by the Query Address and (2) a QUERY Record that includes a frame. The fields of each are specified below. Values of QTYPE are as follows:
QTYPE：次のように、現在2つのクラスで定義されているQUERYレコードにはいくつかのタイプがあります。フレームを含みます。それぞれのフィールドを以下に示します。 QTYPEの値は次のとおりです。
QTYPE Description
----- -------------------------------
0 Reserved
1 Address query
2 Frame query
3-4 Unassigned
5 Unknown unicast MAC Query Frame
6-14 Unassigned
15 Reserved
AFN: Address Family Number of the Query Address.
AFN：クエリアドレスのアドレスファミリ番号。
Query Address: The query is asking for any other addresses, and the nickname of the TRILL switch from which they are reachable, that correspond to the same interface as this address, within the Data Label of the query of the address provided. A typical Query Address would be something like the following:
クエリアドレス：クエリは、提供されたアドレスのクエリのデータラベル内で、このアドレスと同じインターフェースに対応する、他のアドレスと、それらのアドレスに到達できるTRILLスイッチのニックネームを求めています。一般的なクエリアドレスは次のようになります。
1. A 48-bit MAC address, with the querying TRILL switch primarily interested in either
1. 48ビットのMACアドレス。クエリのTRILLスイッチは、主に次のいずれかに関心があります。
a. the RBridge by which that MAC address is reachable, so that the querying RBridge can forward an unknown (before the query) destination MAC address native frame as a unicast TRILL Data packet rather than flooding it, or
a. そのMACアドレスに到達できるRBridge。クエリを実行するRBridgeは、不明な（クエリの前に）宛先MACアドレスのネイティブフレームを、フラッディングするのではなく、ユニキャストTRILLデータパケットとして転送できます。
b. the IP address corresponding to the MAC address, so that the RBridge can locally respond to a RARP [RFC903] native frame.
b. MACアドレスに対応するIPアドレス。これにより、RBridgeはRARP [RFC903]ネイティブフレームにローカルに応答できます。
2. An IPv4 or IPv6 address, with the querying RBridge interested in the corresponding MAC address so it can locally respond to an ARP [RFC826] or ND [RFC4861] native frame [ARPND].
2. IPv4またはIPv6アドレス。対応するMACアドレスに関心のあるRBridgeに問い合わせて、ローカルでARP [RFC826]またはND [RFC4861]ネイティブフレーム[ARPND]に応答できるようにします。
But the Query Address could be some other address type for which an AFN has been assigned, such as a 64-bit MAC address [RFC7042] or a CLNS (connectionless-mode network service) [X.233] address.
ただし、クエリアドレスは、64ビットMACアドレス[RFC7042]またはCLNS（コネクションレスモードネットワークサービス）[X.233]アドレスなど、AFNが割り当てられている他のアドレスタイプである可能性があります。
Query Frame: Where a QUERY Record is the result of an ARP, ND, RARP, SEND, or unknown unicast MAC destination address, the ingress TRILL switch MAY send the frame to a Pull Directory server if the frame is small enough that the resulting Query Message fits into a TRILL Data packet within the campus MTU. The full frame is included, starting with the destination and source MAC addresses, but does not include the Frame Check Sequence (FCS).
クエリフレーム：クエリレコードがARP、ND、RARP、SEND、または不明なユニキャストMAC宛先アドレスの結果である場合、フレームが結果のクエリよりも小さい場合、入力TRILLスイッチはフレームをプルディレクトリサーバーに送信できます（MAY）。メッセージは、キャンパスMTU内のTRILLデータパケットに収まります。宛先および送信元MACアドレスで始まる完全なフレームが含まれますが、フレームチェックシーケンス（FCS）は含まれません。
If no response to a Pull Directory Query Message is received within a configurable timeout (see "DirQueryTimeout" in Section 3.9), then the Query Message should be retransmitted with the same Sequence Number (up to a configurable number of times (see "DirQueryRetries" in Section 3.9)). If there are multiple QUERY Records in a Query Message, responses to various subsets of these QUERY Records can be received before the timeout. In that case, the remaining unanswered QUERY Records should be resent in a new Query Message with a new Sequence Number. If a TRILL switch is not capable of handling partial responses to queries with multiple QUERY Records, it MUST NOT send a Request Message with more than one QUERY Record in it.
構成可能なタイムアウト（3.9項の「DirQueryTimeout」を参照）内にプルディレクトリクエリメッセージへの応答がない場合、クエリメッセージは同じシーケンス番号（構成可能な回数まで（「DirQueryRetries」を参照）で再送信する必要があります。セクション3.9）で）。クエリメッセージに複数のQUERYレコードがある場合、タイムアウト前に、これらのQUERYレコードのさまざまなサブセットへの応答を受信できます。その場合、残りの未応答のQUERYレコードは、新しいシーケンス番号の新しいクエリメッセージで再送信する必要があります。 TRILLスイッチが複数のQUERYレコードを持つクエリへの部分的な応答を処理できない場合、複数のQUERYレコードを含むリクエストメッセージを送信してはなりません（MUST NOT）。
See Section 3.6 for a discussion of how Query Message errors are handled.
クエリメッセージエラーの処理方法については、3.6項を参照してください。
A Pull Directory Query Message results in a Pull Directory Response Message as described in Section 3.2.2.1.
プルディレクトリクエリメッセージは、セクション3.2.2.1で説明されているように、プルディレクトリレスポンスメッセージになります。
In addition, if the QUERY Record QTYPE was 2 or 5, the frame included in the Query may be modified and forwarded by the Pull Directory server as described in Section 3.2.2.2.
さらに、クエリレコードQTYPEが2または5の場合、セクション3.2.2.2で説明されているように、クエリに含まれるフレームがプルディレクトリサーバーによって変更および転送されることがあります。
Pull Directory Response Messages are sent as the Channel Protocol-specific content of an RBridge Channel message [RFC7178] TRILL Data packet or as a native RBridge Channel data frame (see Section 3.5). Responses are sent with the same Data Label and priority as the Query Message to which they correspond, except that the Response Message priority is limited to be no more than the configured value DirRespMaxPriority (Section 3.9).
プルディレクトリ応答メッセージは、RBridgeチャネルメッセージのチャネルプロトコル固有のコンテンツとして送信されます[RFC7178] TRILLデータパケットまたはネイティブのRBridgeチャネルデータフレーム（セクション3.5を参照）。応答メッセージは、対応するクエリメッセージと同じデータラベルと優先度で送信されます。ただし、応答メッセージの優先度は、構成された値DirRespMaxPriority（3.9節）以下に制限されます。
The RBridge Channel Protocol-specific data format is as follows:
RBridge Channel Protocol固有のデータ形式は次のとおりです。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESPONSE 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| RESPONSE K
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Ver, Sequence Number: As specified in Section 3.1.
バージョン、シーケンス番号：セクション3.1で指定されたとおり。
Type: 2 = Response.
タイプ：2 =応答。
Flags: MUST be sent as zero and ignored on receipt.
フラグ：ゼロとして送信し、受信時に無視する必要があります。
Count: Count is the number of RESPONSE Records present in the Response Message.
カウント：カウントは、応答メッセージに存在するRESPONSEレコードの数です。
Err, SubErr: A two-part error code. Zero, unless there was an error in the Query Message (in which case, see Section 3.6).
Err、SubErr：2つの部分からなるエラーコード。クエリメッセージにエラーがなかった場合を除き、ゼロ（この場合、セクション3.6を参照）。
RESPONSE: Each RESPONSE Record within a Pull Directory Response Message is formatted as follows:
応答：プルディレクトリの応答メッセージ内の各応答レコードは、次のようにフォーマットされます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| SIZE |OV| RESV | Index |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Lifetime |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Response Data ...
+--+--+--+--+--+--+--+--+--+--+--...
SIZE: The size of the RESPONSE Record is an unsigned integer number of bytes, not including the SIZE field and following byte. A value of SIZE so large that the material doesn't fit in the Query Message indicates a malformed RESPONSE Record. A RESPONSE Record with such an excessive SIZE value, and any subsequent RESPONSE Records, MUST be ignored, and the entire Response Message MAY be ignored.
SIZE：RESPONSEレコードのサイズは、SIZEフィールドとそれに続くバイトを含まない、符号なし整数バイト数です。マテリアルがクエリメッセージに収まらないほどのSIZEの値は、不正なRESPONSEレコードを示します。このような過度のSIZE値を持つRESPONSEレコード、および後続のRESPONSEレコードは無視する必要があり、応答メッセージ全体を無視する必要があります（MAY）。
OV: The overflow flag. Indicates, as described below, that there was too much Response Data to include in one Response Message.
OV：オーバーフローフラグ。以下で説明するように、1つの応答メッセージに含めるには応答データが多すぎることを示します。
RESV: Three reserved bits that MUST be sent as zero and ignored on receipt.
RESV：ゼロとして送信し、受信時に無視する必要がある3つの予約済みビット。
Index: The relative index of the QUERY Record in the Query Message to which this RESPONSE Record corresponds. The Index will always be 1 for Query Messages containing a single QUERY Record. If the Index is larger than the Count was in the corresponding Query, that RESPONSE Record MUST be ignored, and subsequent RESPONSE Records or the entire Response Message MAY be ignored.
インデックス：このRESPONSEレコードが対応するクエリメッセージ内のクエリレコードの相対インデックス。単一のQUERYレコードを含むクエリメッセージの場合、インデックスは常に1になります。インデックスが対応するクエリにあるカウントよりも大きい場合、そのRESPONSEレコードは無視されなければならず（MUST）、後続のRESPONSEレコードまたは応答メッセージ全体が無視されてもよい（MAY）。
Lifetime: The length of time, in units of 100 milliseconds, for which the response should be considered valid, except that the values zero and 2**16 - 1 are special. If zero, the response can only be used for the particular query from which it resulted and MUST NOT be cached. If 2**16 - 1, the response MAY be kept indefinitely but not after the Pull Directory server goes down or becomes unreachable. (The maximum definite time that can be expressed is a little over 1.8 hours.)
存続期間：100ミリ秒単位の時間の長さ。応答は有効と見なされます。ただし、値0および2 ** 16-1は特別です。ゼロの場合、応答は、その応答が発生した特定のクエリにのみ使用でき、キャッシュしてはなりません（MUST NOT）。 2 ** 16-1の場合、応答は無期限に保持される可能性がありますが、プルディレクトリサーバーがダウンまたは到達不能になった後は保持されません。 （表現できる最大の確定時間は1.8時間強です。）
Response Data: There are three types of RESPONSE Records:
応答データ：RESPONSEレコードには3つのタイプがあります。
- If the Err field of the encapsulating Response Message has a message-level error code in it, then the RESPONSE Records are omitted and Count will be 0. See Section 3.6 for additional information on errors.
- カプセル化応答メッセージのErrフィールドにメッセージレベルのエラーコードが含まれている場合、RESPONSEレコードは省略され、Countは0になります。エラーの詳細については、セクション3.6を参照してください。
- If the Err field of the encapsulating Response Message has a record-level error code in it, then the RESPONSE Records are those having that error, as further described in Section 3.6.
- カプセル化する応答メッセージのErrフィールドにレコードレベルのエラーコードが含まれている場合、セクション3.6で詳しく説明するように、RESPONSEレコードはそのエラーが発生したレコードです。
- If the Err field of the encapsulating Response Message is 0, then the Response Data in each RESPONSE Record is formatted as the value part of an Interface Addresses APPsub-TLV [RFC7961]. The maximum size of such contents is 255 bytes, in which case the RESPONSE Record SIZE field is 255.
- カプセル化する応答メッセージのErrフィールドが0の場合、各RESPONSEレコードの応答データは、インターフェイスアドレスAPPsub-TLV [RFC7961]の値の一部としてフォーマットされます。そのようなコンテンツの最大サイズは255バイトです。この場合、RESPONSE Record SIZEフィールドは255です。
Multiple RESPONSE Records can appear in a Response Message with the same Index if an answer to the QUERY Record consists of multiple Interface Addresses APPsub-TLV values. This would be necessary if, for example, a MAC address within a Data Label appears to be reachable by multiple TRILL switches. However, all RESPONSE Records to any particular QUERY Record MUST occur in the same Response Message. If a Pull Directory holds more mappings for a queried address than will fit into one Response Message, it selects which mappings to include, by some method outside the scope of this document, and sets the overflow flag (OV) in all of the RESPONSE Records responding to that Query Address.
QUERYレコードへの応答が複数のインターフェイスアドレスAPPsub-TLV値で構成されている場合、同じインデックスを持つ複数のRESPONSEレコードが応答メッセージに表示される可能性があります。これは、たとえば、データラベル内のMACアドレスが複数のTRILLスイッチから到達可能であるように見える場合に必要です。ただし、特定のQUERYレコードに対するすべてのRESPONSEレコードは、同じ応答メッセージで発生する必要があります。プルディレクトリが1つの応答メッセージに収まらないほどクエリアドレスのマッピングを保持している場合、このドキュメントの範囲外の何らかの方法で含めるマッピングを選択し、すべてのRESPONSEレコードにオーバーフローフラグ（OV）を設定しますそのクエリアドレスに応答します。
See Section 3.6 for a discussion of how errors are handled.
エラーの処理方法については、3.6項を参照してください。
Query Messages with QTYPEs 2 and 5 are interpreted and handled as described below. In these cases, if the information implicitly sought is not in the directory and the FR flag in the Query Message was 1 (one), the provided frame is forwarded by the Pull Directory server as a multi-destination TRILL Data packet with the ingress nickname of the Pull Directory server (or proxy, if it is hosted on an end station) in the TRILL Header. If the FR flag is 0, the frame is not forwarded in this case.
QTYPE 2および5のクエリメッセージは、以下のように解釈および処理されます。これらのケースでは、暗黙的に求められた情報がディレクトリになく、クエリメッセージのFRフラグが1の場合、提供されたフレームは、プルニックネームサーバーによって、入力ニックネームを持つ複数の宛先TRILLデータパケットとして転送されます。 TRILLヘッダーのプルディレクトリサーバー（エンドステーションでホストされている場合はプロキシ）の。 FRフラグが0の場合、フレームはこの場合転送されません。
If there was no error in the handling of the encapsulating Query Message, the Pull Directory server forwards the frame inside that QUERY Record, after modifying it in some cases, as described below:
カプセル化クエリメッセージの処理にエラーがなかった場合、プルディレクトリサーバーは、以下で説明するように、場合によってはフレームを変更した後、そのQUERYレコード内のフレームを転送します。
ARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an ARP [RFC826] frame is included in the Record: The ar$op field MUST be ares_op$REQUEST, and for the response described in Section 3.2.2.1, this is treated as a query for the target protocol address, where the AFN of that address is given by ar$pro. (ARP fields and value names with embedded dollar signs ("$") are specified in [RFC826].) If (1) ar$op is not ares_op$REQUEST, (2) the ARP is malformed, or (3) the query fails, an error is returned. Otherwise, the ARP is modified into the appropriate ARP response, which is then sent by the Pull Directory server as a TRILL Data packet.
ARP：QTYPEが2で、QUERYレコードのEthertypeがARP [RFC826]フレームがレコードに含まれていることを示している場合：ar $ opフィールドはares_op $ REQUESTである必要があり、セクション3.2.2.1で説明されている応答の場合、これはターゲットプロトコルアドレスのクエリとして扱われ、そのアドレスのAFNはar $ proによって指定されます。 （ドル記号（ "$"）が埋め込まれたARPフィールドと値の名前は[RFC826]で指定されています。）（1）ar $ opがares_op $ REQUESTでない場合、（2）ARPの形式が正しくない、または（3）クエリ失敗すると、エラーが返されます。それ以外の場合、ARPは適切なARP応答に変更され、プルディレクトリサーバーによってTRILLデータパケットとして送信されます。
ND/SEND: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that an IPv6 ND [RFC4861] or SEND [RFC3971] frame is included in the Record: Only Neighbor Solicitation ND frames (corresponding to an ARP query) are allowed. An error is returned for other ND frames or if the target address is not found. Otherwise, if the ND is not a SEND, an ND Neighbor Advertisement response is returned by the Pull Directory server as a TRILL Data packet. In the case of SEND, an error is returned indicating that a SEND frame was received by the Pull Directory, and the Pull Directory then either (1) forwards the SEND frame to the holder of the IPv6 address if that information is in the directory or (2) multicasts the SEND frame.
ND / SEND：QTYPEが2で、QUERYレコードのEthertypeがIPv6 ND [RFC4861]またはSEND [RFC3971]フレームがレコードに含まれていることを示している場合：（ARPクエリに対応する）近隣要請NDフレームのみが許可されます。他のNDフレームの場合、またはターゲットアドレスが見つからない場合は、エラーが返されます。それ以外の場合、NDがSENDではない場合、プルディレクトリサーバーからNDネイバーアドバタイズメント応答がTRILLデータパケットとして返されます。 SENDの場合、SENDフレームがプルディレクトリによって受信されたことを示すエラーが返されます。プルディレクトリは、その情報がディレクトリにある場合は、（1）SENDフレームをIPv6アドレスの所有者に転送するか、 （2）SENDフレームをマルチキャストします。
RARP: When QTYPE is 2 and the Ethertype in the QUERY Record indicates that a RARP [RFC903] frame is included in the Record: If the ar$op field is ares_op$REQUEST, the frame is handled as an ARP, as described above. Otherwise, the ar$op field MUST be "reverse request", and for the response described in Section 3.2.2.1, this is treated as a query for the target hardware address, where the AFN of that address is given by ar$hrd. (See [RFC826] for RARP fields.) If (1) ar$op is not one of these values, (2) the RARP is malformed, or (3) the query fails, an error is returned. Otherwise, the RARP is modified into the appropriate RARP response, which is then unicast by the Pull Directory server as a TRILL Data packet to the source hardware MAC address.
RARP：QTYPEが2で、QUERYレコードのEthertypeがRARP [RFC903]フレームがレコードに含まれていることを示している場合：ar $ opフィールドがares_op $ REQUESTの場合、フレームは上記のようにARPとして処理されます。それ以外の場合、ar $ opフィールドは「リバースリクエスト」である必要があり、セクション3.2.2.1で説明されている応答の場合、これはターゲットハードウェアアドレスのクエリとして扱われ、そのアドレスのAFNはar $ hrdによって指定されます。 （RARPフィールドについては、[RFC826]を参照してください。）（1）ar $ opがこれらの値のいずれでもない場合、（2）RARPの形式が正しくない、または（3）クエリが失敗した場合、エラーが返されます。それ以外の場合、RARPは適切なRARP応答に変更され、プルディレクトリサーバーによって送信元ハードウェアMACアドレスへのTRILLデータパケットとしてユニキャストされます。
MacDA: When QTYPE is 5, indicating that a frame is provided in the QUERY Record whose destination MAC address TRILL switch attachment is unknown, the only requirement is that this MAC address has to be unicast. The Ethertype in the QUERY Record is ignored. If this MAC address is a group address, an error is returned. In the case of Pull Directory Response Messages (Section 3.2.2.1), this MAC address is treated as a query for the MacDA. In the creation of the response described in Section 3.2.2.1, the query is treated as a query for this MAC address. If the Pull Directory contains TRILL switch attachment information for the MAC address in the Data Label of the Query Message, it forwards the frame to that switch in a unicast TRILL Data packet.
MacDA：QTYPEが5の場合、宛先MACアドレスTRILLスイッチの接続が不明なQUERYレコードにフレームが提供されていることを示し、唯一の要件は、このMACアドレスがユニキャストでなければならないことです。 QUERYレコードのEthertypeは無視されます。このMACアドレスがグループアドレスの場合、エラーが返されます。プルディレクトリの応答メッセージ（セクション3.2.2.1）の場合、このMACアドレスはMacDAのクエリとして扱われます。セクション3.2.2.1で説明されている応答の作成では、クエリはこのMACアドレスのクエリとして扱われます。プルディレクトリにクエリメッセージのデータラベルのMACアドレスのTRILLスイッチアタッチメント情報が含まれている場合、フレームはそのスイッチにユニキャストTRILLデータパケットで転送されます。
Unless it sends all responses with a Lifetime of 0, a Pull Directory MUST take action, by sending Update Messages, to minimize the amount of time that a TRILL switch will continue to use stale information from that Pull Directory. The formats of Update Messages and the Acknowledge Messages used to respond to Update Messages are given in Sections 3.3.1 and 3.3.2, respectively.
Lifetimeが0のすべての応答を送信しない限り、プルディレクトリは更新メッセージを送信して、TRILLスイッチがそのプルディレクトリからの古い情報を使用し続ける時間を最小限に抑えるためのアクションを実行する必要があります。更新メッセージおよび更新メッセージに応答するために使用される確認メッセージのフォーマットは、それぞれセクション3.3.1および3.3.2に記載されています。
A Pull Directory server MUST maintain one of three sets of records concerning possible cached data at clients of that server. These are numbered and listed below in order of increasing specificity:
プルディレクトリサーバーは、そのサーバーのクライアントでキャッシュされる可能性のあるデータに関する3つのレコードセットの1つを維持する必要があります。これらには番号が付けられ、具体性の高い順に以下にリストされています。
Method 1, Least Specific. An overall record, per Data Label, of when the last positive Response Data sent will expire and when the last negative response sent will expire; the records are retained until such expiration.
方法1、最も限定的。送信された最後の肯定応答データが期限切れになるとき、および送信された最後の否定応答が期限切れになるときの、データラベルごとの全体的なレコード。記録はそのような満了まで保持されます。
Pro: Minimizes the record-keeping burden on the Pull Directory server.
長所：プルディレクトリサーバーの記録保持の負担を最小限に抑えます。
Con: Increases the volume of and overhead due to (1) spontaneous Update Messages and (2) unnecessarily invalidating cached information.
欠点：（1）自発的な更新メッセージと（2）キャッシュされた情報を不必要に無効化することにより、ボリュームとオーバーヘッドが増加します。
Method 2, Medium Specificity. For each unit of data (Interface Addresses APPsub-TLV (IA APPsub-TLV) Address Set [RFC7961]) held by the server, record when the last response sent with that positive Response Data will expire. In addition, record each address about which a negative response was sent by the server and when the last such negative response will expire. Each such record of a positive or negative response is discarded upon expiration.
方法2、中程度の特異性。サーバーが保持するデータの各ユニット（インターフェースアドレスAPPsub-TLV（IA APPsub-TLV）アドレスセット[RFC7961]）について、その正の応答データで送信された最後の応答がいつ期限切れになるかを記録します。さらに、サーバーから否定応答が送信された各アドレスと、そのような最後の否定応答がいつ期限切れになるかを記録します。肯定応答または否定応答のそのような各レコードは、有効期限が切れると破棄されます。
Pros/Cons: An intermediate level of detail in server record-keeping; also, an intermediate volume of, and overhead due to, spontaneous Update Messages with some unnecessary invalidation of cached information.
長所/短所：サーバーの記録管理の中間レベルの詳細。また、キャッシュされた情報の不要な無効化を伴う自発的な更新メッセージの中間的な量とそれに起因するオーバーヘッド。
Method 3, Most Specific. For each unit of data held by the server (IA APPsub-TLV Address Set [RFC7961]) and each address about which a negative response was sent, a list of TRILL switches that were sent that data as a positive response or sent a negative response for the address, and the expected time to expiration for that data or address at each such TRILL switch, assuming that the requester cached the response. Each list entry is retained until such expiration time.
方法3、最も具体的。サーバーが保持するデータの各ユニット（IA APPsub-TLVアドレスセット[RFC7961]）および否定応答が送信された各アドレスについて、そのデータを肯定応答として送信した、または否定応答を送信したTRILLスイッチのリストリクエスタが応答をキャッシュしたと仮定して、アドレスおよびそのような各TRILLスイッチでのそのデータまたはアドレスの有効期限までの予想時間各リストエントリは、そのような有効期限まで保持されます。
Pros: Minimizes spontaneous Update Messages sent to update pull client TRILL switch caches, and minimizes unnecessary invalidation of cached information.
長所：プルクライアントの更新TRILLスイッチキャッシュに送信される自発的な更新メッセージを最小限に抑え、キャッシュされた情報の不要な無効化を最小限に抑えます。
Con: Increased record-keeping burden on the Pull Directory server.
欠点：プルディレクトリサーバーの記録保持の負荷が増加しました。
RESPONSE Records sent with a zero Lifetime are considered to have already expired and so do not need to be tracked. In all cases, there may still be brief periods of time when directory information has changed, but information that a pull client has cached has not yet been updated or expunged.
応答期間がゼロで送信されたRESPONSEレコードは、すでに有効期限が切れていると見なされるため、追跡する必要はありません。すべての場合において、ディレクトリ情報が変更されても、プルクライアントがキャッシュした情報がまだ更新または消去されていない場合があります。
A Pull Directory server might have a limit as to (1) how many TRILL switches for which it can maintain detailed expiry information using method 3 or (2) how many data units or addresses for which it can maintain expiry information using method 2 or the like. If such limits are exceeded, it MUST transition to a lower-numbered method but, in all cases, MUST support, at a minimum, method 1 and SHOULD support methods 2 and 3. The use of method 1 may be quite inefficient, due to large amounts of cached positive and negative information being unnecessarily discarded.
プルディレクトリサーバーには、（1）方法3を使用して詳細な有効期限情報を維持できるTRILLスイッチの数、または（2）方法2を使用して有効期限情報を維持できるデータユニットまたはアドレスの数、またはお気に入り。そのような制限を超えた場合、それはより低い番号のメソッドに移行する必要がありますが、すべての場合において、少なくともメソッド1をサポートする必要があり、メソッド2および3をサポートする必要があります（SHOULD）。メソッド1の使用は、キャッシュされた大量のポジティブおよびネガティブ情報が不必要に破棄されます。
When data at a Pull Directory is changed, deleted, or added and there may be unexpired stale information at a requesting TRILL switch, the Pull Directory MUST send an Update Message as discussed below. The sending of such an Update Message MAY be delayed by a configurable number of milliseconds (see "DirUpdateDelay" in Section 3.9) to await other possible changes that could be included in the same Update Message.
プルディレクトリのデータが変更、削除、または追加され、要求しているTRILLスイッチに期限切れの古い情報がある場合、プルディレクトリは、以下で説明するように更新メッセージを送信する必要があります。そのような更新メッセージの送信は、同じ更新メッセージに含まれる可能性のある他の可能な変更を待つために、構成可能なミリ秒数（3.9節の「DirUpdateDelay」を参照）だけ遅延する場合があります。
1. If method 1, the least detailed method, is being followed, then when any Pull Directory information in a Data Label is changed or deleted and there are outstanding cached positive data response(s), an all-addresses flush positive data Update Message is flooded within that Data Label as an RBridge Channel message. If data is added and there are outstanding cached negative responses, an all-addresses flush negative message is similarly flooded. A Count field value of 0 in an Update Message indicates "all-addresses". On receiving an all-addresses flooded flush positive Update from a Pull Directory server it has used, indicated by the F (Flood) and P (Positive) bits being 1 and the Count being 0, a TRILL switch discards the cached data responses it has for that Data Label. Similarly, on receiving an all-addresses flush negative Update, indicated by the F and N (Negative) bits being 1 and the Count being 0, it discards all cached negative replies for that Data Label. A combined flush positive and negative can be flooded by having all of the F, P, and N bits (see Section 3.3.1) set to 1 and the Count field 0, resulting in the discard of all positive and negative cached information for the Data Label.
1. 方法1（最も詳細な方法ではない）に従っている場合、データラベルのプルディレクトリ情報が変更または削除され、未処理のキャッシュされたポジティブデータレスポンスがあると、すべてのアドレスがポジティブデータをフラッシュし、更新メッセージがフラッディングされます。そのデータラベル内でRBridge Channelメッセージとして。データが追加され、キャッシュされた未処理の否定応答がある場合、すべてのアドレスのフラッシュ否定メッセージが同様にフラッディングされます。更新メッセージのカウントフィールド値が0の場合は、「すべてのアドレス」を示します。 TRILLスイッチは、F（Flood）およびP（Positive）ビットが1で、Countが0であることを示す、使用したPull Directoryサーバーからフラッディングされたすべてのアドレスのフラッディングフラッシュポジティブアップデートを受信すると、キャッシュされたデータ応答を破棄します。そのデータラベル。同様に、FおよびN（ネガティブ）ビットが1で、カウントが0であることを示す、すべてのアドレスフラッシュのネガティブ更新を受信すると、そのデータラベルに対するキャッシュされたすべてのネガティブ応答を破棄します。フラッシュの正と負の組み合わせは、すべてのF、P、およびNビット（セクション3.3.1を参照）を1に設定し、カウントフィールドを0にすることでフラッディングでき、その結果、キャッシュされたすべての正および負のキャッシュ情報が破棄されます。データラベル。
2. If method 2 is being followed, then a TRILL switch floods address-specific positive Update Messages when data that might be cached by a querying TRILL switch is changed or deleted and floods address-specific negative Update Messages when data that might be cached by a querying TRILL switch is added. Such messages are sent as RBridge Channel messages. The F bit will be 1; however, the Count field will be non-zero, and either the P bit or the N bit, but not both, will be 1. There are actually four possible message types that can be flooded:
2.方法2が実行されている場合、クエリTRILLスイッチによってキャッシュされる可能性のあるデータが変更または削除されると、TRILLスイッチはアドレス固有のポジティブ更新メッセージをフラッディングし、データがキャッシュされる可能性がある場合は、アドレス固有のネガティブ更新メッセージをフラッディングします。クエリTRILLスイッチが追加されました。このようなメッセージは、RBridge Channelメッセージとして送信されます。 Fビットは1になります。ただし、Countフィールドはゼロではなく、PビットまたはNビットのいずれか（両方ではない）は1になります。実際にフラッディングされる可能性のあるメッセージタイプは4つあります。
a. If data that might still be cached is updated: An unsolicited Update Message is sent with the P flag set and the Err field 0. On receipt, the addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached positive information from that server. If they match, the cached information is updated.
a. まだキャッシュされている可能性のあるデータが更新された場合：Pフラグが設定され、Errフィールドが0の未承諾更新メッセージが送信されます。受信時に、RESPONSEレコードのアドレスは、受信TRILLスイッチがキャッシュを保持しているアドレスと比較されます。そのサーバーからの肯定的な情報。それらが一致する場合、キャッシュされた情報が更新されます。
b. If data that might still be cached is deleted: An unsolicited Update Message is sent with the P flag set and the Err field non-zero, giving the error that would now be encountered in attempting to pull information for the relevant address from the Pull Directory server. In this non-zero Err field case, the RESPONSE Record(s) differs from non-zero Err Reply Message RESPONSE Records in that they do include an interface address set. Any cached positive information for the addresses given is deleted, and the negative response is cached as per the Lifetime given.
b. まだキャッシュされている可能性のあるデータが削除された場合：Pフラグが設定され、Errフィールドがゼロ以外の未承諾更新メッセージが送信され、プルディレクトリから関連アドレスの情報をプルしようとしたときに発生するエラーが発生します。サーバ。このゼロ以外のErrフィールドの場合、RESPONSEレコードは、インターフェースアドレスセットが含まれているという点で、ゼロ以外のErr応答メッセージRESPONSEレコードとは異なります。指定されたアドレスのキャッシュされた肯定的な情報はすべて削除され、否定的な応答は指定された有効期間に従ってキャッシュされます。
c. If data for an address for which a negative response was sent is added, so that negative response that might still be cached is now incorrect: An unsolicited Update Message is sent with the N flag set to 1 and the Err field 0. The addresses in the RESPONSE Records are compared to the addresses for which the receiving TRILL switch is holding cached negative information from that server; if they match, the cached negative information is deleted, and the positive information provided is cached as per the Lifetime given.
c. 否定応答が送信されたアドレスのデータが追加されたため、まだキャッシュされている可能性がある否定応答が正しくない場合：非送信請求更新メッセージは、Nフラグが1に設定され、Errフィールドが0で送信されます。 RESPONSEレコードは、受信TRILLスイッチがそのサーバーからのキャッシュされた否定情報を保持しているアドレスと比較されます。それらが一致する場合、キャッシュされた否定的な情報は削除され、提供された肯定的な情報は、指定されたライフタイムに従ってキャッシュされます。
d. In the rare case where it is desired to change the Lifetime or error associated with negative information that might still be cached: An unsolicited Update Message is sent with the N flag set to 1 and the Err field non-zero. As in case b above, the RESPONSE Record(s) gives the relevant addresses. Any cached negative information for the addresses is updated.
d. キャッシュされている可能性がある否定的な情報に関連するライフタイムまたはエラーを変更することが望まれるまれなケースでは、Nフラグを1に設定し、Errフィールドをゼロ以外にして、非送信請求更新メッセージが送信されます。上記のケースbと同様に、RESPONSEレコードは関連するアドレスを提供します。アドレスのキャッシュされた負の情報はすべて更新されます。
3. If method 3 is being followed, unsolicited Update Messages of the same sort are sent as with method 2 above, except that they are not normally flooded but unicast only to the specific TRILL switches the directory server believes may be holding the cached positive or negative information that needs deletion or updating. However, a Pull Directory server MAY flood unsolicited updates using method 3 -- for example, if it determines that a sufficiently large fraction of the TRILL switches in some Data Label are requesters that need to be updated so that flooding is more efficient than unicast.
3.方法3が実行されている場合、通常はフラッディングされず、特定のTRILLスイッチにのみユニキャストされることを除いて、上記の方法2と同じ種類の非送信請求更新メッセージが送信されます。削除または更新が必要な否定的な情報。ただし、プルディレクトリサーバーは、方法3を使用して非送信請求更新をフラッディングする可能性があります（たとえば、一部のデータラベルのTRILLスイッチの十分に大きい部分がリクエスターであり、ユニキャストよりもフラッディングが効率的になるように更新する必要があると判断した場合）。
A Pull Directory server tracking cached information with method 3 MUST NOT clear the indication that it needs to update cached information at a querying TRILL switch until it has either (a) sent an Update Message and received a corresponding Acknowledge Message or (b) sent a configurable number of updates at a configurable interval where these parameters default to three updates 100 milliseconds apart (see Section 3.9).
方法3でキャッシュ情報を追跡するプルディレクトリサーバーは、（a）更新メッセージを送信して対応する確認メッセージを受信するか、または（b）送信するまで、クエリTRILLスイッチでキャッシュ情報を更新する必要があるという指示をクリアしてはなりません（MUST NOT）。構成可能な間隔で構成可能な更新の数。これらのパラメーターは、デフォルトで100ミリ秒間隔で3つの更新に設定されます（セクション3.9を参照）。
A Pull Directory server tracking cached information with method 1 or method 2 SHOULD NOT clear the indication that it needs to update cached information until it has sent an Update Message and received a corresponding Acknowledge Message from all of its ESADI neighbors or it has sent a number of updates at a configurable interval, as specified in the paragraph above.
方法1または方法2でキャッシュされた情報を追跡するプルディレクトリサーバーは、更新メッセージを送信し、すべてのESADIネイバーから対応する確認メッセージを受信するか、番号を送信するまで、キャッシュ情報を更新する必要があるという指示をクリアしてはなりません（SHOULD NOT）。上記の段落で指定されているように、構成可能な間隔で更新を実行します。
An Update Message is formatted as a Response Message, with the differences described in Section 3.3 above and the following:
更新メッセージは応答メッセージとしてフォーマットされますが、上記のセクション3.3で説明した違いと以下の違いがあります。
o The Type field in the message header is set to 3.
o メッセージヘッダーのTypeフィールドは3に設定されます。
o The Index field in the RESPONSE Record(s) is set to 0 on transmission and ignored on receipt (but the Count field in the Update Message header MUST still correctly indicate the number of RESPONSE Records present).
o RESPONSEレコードのIndexフィールドは送信時に0に設定され、受信時に無視されます（ただし、Update MessageヘッダーのCountフィールドは、存在するRESPONSEレコードの数を正しく示す必要があります）。
o The priority with which the message is sent, DirUpdatePriority, is configurable and defaults to 5 (see Section 3.9).
o メッセージの送信に使用される優先度、DirUpdatePriorityは設定可能であり、デフォルトは5です（セクション3.9を参照）。
Update Messages are initiated by a Pull Directory server. The Sequence Number space used is controlled by the originating Pull Directory server. This Sequence Number space for Update Messages is different from the Sequence Number space used in a Query and the corresponding Response that are controlled by the querying TRILL switch.
更新メッセージは、プルディレクトリサーバーによって開始されます。使用されるシーケンス番号スペースは、元のプルディレクトリサーバーによって制御されます。更新メッセージのこのシーケンス番号スペースは、クエリで使用されるシーケンス番号スペースと、クエリのTRILLスイッチによって制御される対応する応答とは異なります。
The 4-bit Flags field of the message header for an Update Message is as follows:
更新メッセージのメッセージヘッダーの4ビットフラグフィールドは次のとおりです。
+---+---+---+---+
| F | P | N | R |
+---+---+---+---+
F: The Flood bit. If F = 0, the Update Message is unicast. If F = 1, it is multicast to All-Egress-RBridges.
F：フラッドビット。 F = 0の場合、更新メッセージはユニキャストです。 F = 1の場合、All-Egress-RBridgesにマルチキャストされます。
P, N: Flags used to indicate positive or negative Update Messages. P = 1 indicates "positive". N = 1 indicates "negative". Both may be 1 for a flooded all-addresses Update.
P、N：肯定または否定の更新メッセージを示すために使用されるフラグ。 P = 1は「正」を示します。 N = 1は「負」を示します。フラッディングされたすべてのアドレスの更新の場合、どちらも1になることがあります。
R: Reserved. MUST be sent as zero and ignored on receipt.
R：予約済み。ゼロとして送信し、受信時に無視する必要があります。
For tracking methods 2 and 3 in Section 3.3, a particular Update Message MUST have either the P flag or the N flag set, but not both. If both are set, the Update Message MUST be ignored, as this combination is only valid for method 1.
セクション3.3のメソッド2と3を追跡するには、特定の更新メッセージにPフラグまたはNフラグのいずれかを設定する必要がありますが、両方を設定する必要はありません。両方が設定されている場合、この組み合わせはメソッド1に対してのみ有効であるため、更新メッセージを無視する必要があります。
An Acknowledge Message is sent in response to an Update Message to confirm receipt or indicate an error, unless response is inhibited by rate limiting. It is formatted as a Response Message, but the Type is set to 4.
レート制限によって応答が禁止されていない限り、受信を確認するか、エラーを示すために、更新メッセージに応答して確認メッセージが送信されます。応答メッセージとしてフォーマットされますが、タイプは4に設定されます。
If there are no errors in the processing of an Update Message or if there is an overall message-level error or a header error in an Update Message, the message is echoed back with the Err and SubErr fields set appropriately, the Type changed to Acknowledge, and a null Records section with the Count field set to 0.
更新メッセージの処理にエラーがない場合、または更新メッセージに全体的なメッセージレベルのエラーまたはヘッダーエラーがある場合、メッセージはErrおよびSubErrフィールドが適切に設定されてエコーバックされ、TypeがAcknowledgeに変更されます。 、およびCountフィールドが0に設定されたnullレコードセクション。
If there is a record-level error in an Update Message, one or more Acknowledge Messages may be returned with the erroneous record(s) indicated as discussed in Section 3.6.
更新メッセージにレコードレベルのエラーがある場合、セクション3.6で説明されているように、1つ以上の確認応答メッセージが誤ったレコードとともに返されることがあります。
An Acknowledge Message is sent with the same priority as the Update Message it acknowledges but not more than a configured priority called "DirAckMaxPriority", which defaults to 5 (see Section 3.9).
確認応答メッセージは、確認応答する更新メッセージと同じ優先順位で送信されますが、「DirAckMaxPriority」と呼ばれる設定された優先順位を超えません。デフォルトは5です（セクション3.9を参照）。
As specified in Sections 3.2 and 3.3, the Query, Response, Update, and Acknowledge Messages can have zero or more repeating Record structures under different circumstances, as summarized below. The "Err" column abbreviations in this table have the meanings listed below. "IA APPsub-TLV value" means the value part of the IA APPsub-TLV specified in [RFC7961].
セクション3.2および3.3で指定されているように、クエリ、応答、更新、および確認応答メッセージは、以下に要約するように、さまざまな状況下で0個以上の繰り返しレコード構造を持つことができます。この表の「Err」列の略語には、以下の意味があります。 「IA APPsub-TLV値」とは、[RFC7961]で指定されているIA APPsub-TLVの値の部分を意味します。
MBZ = MUST be zero Z = zero NZ = non-zero NZM = non-zero message-level error NZR = non-zero record-level error
MBZ =ゼロでなければならないZ =ゼロNZ =ゼロ以外のNZM =ゼロ以外のメッセージレベルのエラーNZR =ゼロ以外のレコードレベルのエラー
Message Err Section Record Structure Response Data
----------- --- ------- ---------------- -------------------
Query MBZ 3.2.1 QUERY Record -
Response Z 3.2.2.1 RESPONSE Record IA APPsub-TLV value
Response NZM 3.2.2.1 null -
Response NZR 3.2.2.1 RESPONSE Record Records with error
Update MBZ 3.3.1 RESPONSE Record IA APPsub-TLV value
Acknowledge Z 3.3.2 null -
Acknowledge NZM 3.3.2 null -
Acknowledge NZR 3.3.2 RESPONSE Record Records with error
See Section 3.6 for further details on errors.
エラーの詳細については、セクション3.6を参照してください。
A Pull Directory can be hosted on an end station as specified in Section 3.5.1.
プルディレクトリは、セクション3.5.1で指定されているエンドステーションでホストできます。
An end station can use a Pull Directory as specified in Section 3.5.2. This capability would be useful in supporting an end station that performs directory-assisted encapsulation [DirAsstEncap] or that is a "Smart Endnode" [SmartEN].
端末は、セクション3.5.2で指定されているプルディレクトリを使用できます。この機能は、ディレクトリアシストカプセル化を実行するエンドステーション、または「スマートエンドノード」[SmartEN]をサポートするエンドステーションのサポートに役立ちます。
The native Pull Directory messages used in these cases are as specified in Section 3.5.3. In these cases, the edge RBridge(s) and end station(s) involved need to detect each other and exchange some control information. This is accomplished with the TRILL End System to Intermediate System (ES-IS) mechanism specified in Section 5.
これらのケースで使用されるネイティブプルディレクトリメッセージは、セクション3.5.3で指定されています。これらの場合、関係するエッジRBridgeとエンドステーションは、お互いを検出し、いくつかの制御情報を交換する必要があります。これは、セクション5で指定されているTRILL End System to Intermediate System（ES-IS）メカニズムによって実現されます。
Optionally, a Pull Directory actually hosted on an end station MAY be supported. In that case, one or more TRILL switches must act as indirect Pull Directory servers. That is, they host a Pull Directory server, which is seen by other TRILL switches in the campus, and a Pull Directory client, which fetches directory information from one or more end-station Pull Directory servers, where at least some of the information provided by the Pull Directory server may be information fetched from an end station to which it is directly connected by the co-located Pull Directory client. ("Direct connection" means a connection not involving any intermediate TRILL switches.)
オプションで、実際にエンドステーションでホストされているプルディレクトリがサポートされる場合があります。その場合、1つ以上のTRILLスイッチが間接プルディレクトリサーバーとして機能する必要があります。つまり、キャンパス内の他のTRILLスイッチから見えるプルディレクトリサーバーと、少なくともいくつかの情報が提供される1つ以上のエンドステーションプルディレクトリサーバーからディレクトリ情報をフェッチするプルディレクトリクライアントをホストします。プルディレクトリサーバーは、同じ場所にあるプルディレクトリクライアントによって直接接続されているエンドステーションからフェッチされた情報である可能性があります。 （「直接接続」とは、中間のTRILLスイッチを含まない接続を意味します。）
End stations hosting a Pull Directory server MUST support TRILL ES-IS (see Section 5) and advertise the Data Labels for which they are providing service in one or more Interested VLANs sub-TLVs or Interested Labels sub-TLVs by setting the PUL flag (see Section 7.3).
プルディレクトリサーバーをホストしているエンドステーションは、TRILL ES-ISをサポートし（セクション5を参照）、PULフラグを設定して、1つ以上の対象VLANサブTLVまたは対象ラベルサブTLVでサービスを提供しているデータラベルをアドバタイズする必要があります（セクション7.3を参照してください）。
* * * * * * *
+---------------+ * *
| End Station 1 | +---------------+ *
| Pull Directory+--------------+ RB1, Pull | *
| Server | | Directory| *
+---------------+ +-------+ Client|Server | +----+
| +---------------+ |RB99|
+---------------+ | * +----+
| End Station 2 | +--+---+ +---------------+ *
| Pull Directory+---+Bridge+---+ RB2, Pull | *
| Server | +--+---+ | Directory| *
+---------------+ | | Client|Server | *
| +---------------+ *
| * TRILL *
. * Campus *
. * *
. * * * * * * *
Figure 2: End-Station Pull Directory Example
図2：端末のプルディレクトリの例
Figure 2 gives an example where RB1 and RB2 advertise themselves to the rest of the TRILL campus, such as RB99, as Pull Directory servers and obtain at least some of the information they are providing by issuing Pull Directory queries to End Stations 1 and/or 2. This example is specific, but many variations are possible. The box labeled "Bridge" in Figure 2 could be replaced by a complex bridged LAN or could be a bridgeless LAN through the use of a hub or repeater. Or, end stations might be connected via point-to-point links (as shown for End Station 1), including multi-ported end stations connected by point-to-point links to multiple RBridges. Although Figure 2 shows two end stations and two RBridges, there could be one or more than two RBridges having such indirect Pull Directory servers. Furthermore, there could be one or more than two end stations with Pull Directory servers on them. Each TRILL switch acting as an indirect Pull Directory server could then be differently configured as to the Data Labels for which it is providing indirect service selected from the union of the Data Labels supported by the end-station hosted servers and could select from among those end-station hosted servers supporting each Data Label the indirect server is configured to provide.
図2は、RB1とRB2がプルディレクトリサーバーとしてRB99などのTRILLキャンパスの残りの部分にアドバタイズし、エンドステーション1やプルステーションにプルディレクトリクエリを発行することで、提供する情報の少なくとも一部を取得する例を示しています。 2.この例は特定のものですが、多くのバリエーションが可能です。図2の「ブリッジ」というラベルの付いたボックスは、複雑なブリッジLANに置き換えることも、ハブまたはリピーターを使用してブリッジレスLANにすることもできます。または、エンドステーションは、ポイントツーポイントリンクによって複数のRBridgeに接続されたマルチポートエンドステーションを含め、ポイントツーポイントリンク（エンドステーション1で示されている）を介して接続される場合があります。図2は2つのエンドステーションと2つのRBridgeを示していますが、このような間接的なプルディレクトリサーバーを持つ1つまたは2つ以上のRBridgeが存在する場合があります。さらに、プルディレクトリサーバーを備えた1つまたは2つ以上のエンドステーションが存在する可能性があります。間接プルディレクトリサーバーとして機能する各TRILLスイッチは、エンドステーションのホストサーバーによってサポートされるデータラベルのユニオンから選択された間接サービスを提供するデータラベルに対して異なる構成が可能で、これらのエンドから選択できます。 -ステーションがホストするサーバーは、間接サーバーが提供するように構成されている各データラベルをサポートします。
When an indirect Pull Directory server receives Query Messages from other TRILL switches, it answers from information it has cached or issues Pull Directory requests to end-station Pull Directory servers with which it has TRILL ES-IS adjacency to obtain the information. Any Response sent by an indirect Pull Directory server MUST NOT have a validity time longer than the validity period of the data on which it is based. When an indirect Pull Directory server receives Update Messages, it updates its cached information and MUST originate Update Messages to any clients that may have mirrors of the cached information so updated.
間接プルディレクトリサーバーは、他のTRILLスイッチからクエリメッセージを受信すると、キャッシュした情報から応答するか、TRILL ES-IS隣接関係があるエンドステーションのプルディレクトリサーバーにプルディレクトリ要求を発行して、情報を取得します。間接プルディレクトリサーバーによって送信された応答の有効期間は、それが基づいているデータの有効期間よりも長くてはなりません。間接プルディレクトリサーバーは更新メッセージを受信すると、キャッシュされた情報を更新し、更新されたキャッシュ情報のミラーを持つすべてのクライアントに対して更新メッセージを生成する必要があります。
Since an indirect Pull Directory server discards information it has cached from queries to an end-station Pull Directory server if it loses adjacency to the server (Section 3.7), if it detects that such information may be cached at RBridge clients and has no other source for the information, it MUST send Update Messages to those clients withdrawing the information. For this reason, indirect Pull Directory servers may wish to query multiple sources, if available, and cache multiple copies of returned information from those multiple sources. Then, if one end-station source becomes inaccessible or withdraws the information but the indirect Pull Directory server has the information from another source, it need not originate Update Messages.
間接プルディレクトリサーバーは、サーバーへの隣接性を失うと（セクション3.7）、その情報がRBridgeクライアントでキャッシュされ、他のソースがないことを検出すると、クエリからエンドステーションプルディレクトリサーバーへのキャッシュ情報を破棄します。情報については、情報を引き出すクライアントに更新メッセージを送信する必要があります。このため、間接プルディレクトリサーバーは、利用可能な場合、複数のソースにクエリを実行し、それらの複数のソースから返された情報の複数のコピーをキャッシュしたい場合があります。次に、1つのエンドステーションソースにアクセスできなくなったり、情報が取り消されたりしても、間接プルディレクトリサーバーが別のソースからの情報を持っている場合、更新メッセージを発信する必要はありません。
Some special end stations, such as those discussed in [DirAsstEncap] and [SmartEN], may need to access directory information. How edge RBridges provide this optional service is specified below.
[DirAsstEncap]や[SmartEN]で説明されているようないくつかの特別な端末は、ディレクトリ情報にアクセスする必要があるかもしれません。エッジRBridgesがこのオプションサービスを提供する方法を以下に示します。
When Pull Directory support is provided by an edge RBridge to end stations, the messages used are as specified in Section 3.5.3 below. The edge RBridge MUST support TRILL ES-IS (Section 5) and advertises the Data Labels for which it offers this service to end stations by setting the Pull Directory flag (PUL) to 1 in its Interested VLANs sub-TLV or Interested Labels sub-TLV (see Section 7.3) for that Data Label advertised through TRILL ES-IS.
プルブリッジのサポートがエッジRBridgeによってエンドステーションに提供されている場合、使用されるメッセージは、以下のセクション3.5.3で指定されています。エッジRBridgeはTRILL ES-IS（セクション5）をサポートする必要があり、関係するVLANサブTLVまたはInterest Labelsサブでプルディレクトリフラグ（PUL）を1に設定することにより、このサービスをエンドステーションに提供するデータラベルをアドバタイズします。 TRILL ES-ISを通じてアドバタイズされるそのデータラベルのTLV（セクション7.3を参照）。
The Pull Directory messages used between TRILL switches and end stations are native RBridge Channel messages [RFC7178]. These RBridge Channel messages use the same Channel Protocol number as the inter-RBridge Pull Directory RBridge Channel messages. The Outer.VLAN ID used is the TRILL ES-IS Designated VLAN (see Section 5) on the link to the end station. Since there is no TRILL Header or inner Data Label for native RBridge Channel messages, that information is added to the Pull Directory message header as specified below.
TRILLスイッチと端末の間で使用されるプルディレクトリメッセージは、ネイティブのRBridgeチャネルメッセージです[RFC7178]。これらのRBridgeチャネルメッセージは、RBridge間プルディレクトリRBridgeチャネルメッセージと同じチャネルプロトコル番号を使用します。使用されるOuter.VLAN IDは、エンドステーションへのリンク上のTRILL ES-IS Designated VLAN（セクション5を参照）です。ネイティブRBridgeチャネルメッセージにはTRILLヘッダーまたは内部データラベルがないため、その情報は、以下に示すようにプルディレクトリメッセージヘッダーに追加されます。
The protocol-dependent data part of the native RBridge Channel message is the same as for inter-RBridge Channel messages, except that the 8-byte header described in Section 3.1 is expanded to 12 or 16 bytes, as follows:
ネイティブRBridgeチャネルメッセージのプロトコル依存データ部分は、セクション3.1で説明した8バイトのヘッダーが次のように12または16バイトに拡張されていることを除いて、RBridgeチャネル間メッセージの場合と同じです。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Flags | Count | Err | SubErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Label ... (4 or 8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| Type Specific Payload - variable length
+-+-+- ...
Fields other than the Data Label field are as defined in Section 3.1. The Data Label that normally appears right after the Inner.MacSA of the RBridge Channel Pull Directory message appears in the Data Label field of the Pull Directory message header in the native RBridge Channel message version. This Data Label appears in a native Query Message, to be reflected in a Response Message, or it might appear in a native Update to be reflected in an Acknowledge Message. Since the appropriate VLAN or FGL [RFC7172] Ethertype is included, the length of the Data Label can be determined from the first 2 bytes.
データラベルフィールド以外のフィールドは、セクション3.1で定義されています。 RBridgeチャネルプルディレクトリメッセージのInner.MacSAの直後に通常表示されるデータラベルは、ネイティブのRBridgeチャネルメッセージバージョンのプルディレクトリメッセージヘッダーのデータラベルフィールドに表示されます。このデータラベルは、ネイティブクエリメッセージに表示されて応答メッセージに反映されるか、ネイティブアップデートに表示されて確認応答メッセージに反映される場合があります。適切なVLANまたはFGL [RFC7172] Ethertypeが含まれているため、データラベルの長さは最初の2バイトから決定できます。
A non-zero Err field in the Pull Directory Response or Acknowledge Message header indicates an error message.
Pull Directory ResponseまたはAcknowledge Messageヘッダーのゼロ以外のErrフィールドは、エラーメッセージを示します。
If there is an error that applies to an entire Query or Update Message or its header, as indicated by the range of the value of the Err field, then the QUERY Records probably were not even looked at by the Pull Directory server and would provide no additional information in the Response or Acknowledge Message. Therefore, the Records section of the response to a Query Message or Update Message is omitted, and the Count field is set to 0 in the Response or Acknowledge Message.
Errフィールドの値の範囲によって示されるように、クエリまたは更新メッセージまたはそのヘッダー全体に適用されるエラーがある場合、クエリレコードはおそらくプルディレクトリサーバーによっても参照されず、何も提供しません。応答または確認メッセージの追加情報。したがって、クエリメッセージまたは更新メッセージへの応答のレコードセクションは省略され、応答または確認メッセージのカウントフィールドは0に設定されます。
If errors occur at the QUERY Record level for a Query Message, they MUST be reported in a Response Message separate from the results of any successful non-erroneous QUERY Records. If multiple QUERY Records in a Query Message have different errors, they MUST be reported in separate Response Messages. If multiple QUERY Records in a Query Message have the same error, this error response MAY be reported in one or multiple Response Messages. In an error Response Message, the QUERY Record or Records being responded to appear, expanded by the Lifetime for which the server thinks the error might persist (usually 2**16 - 1, which indicates "indefinitely") and with their Index inserted, as the RESPONSE Record or Records.
クエリメッセージのクエリレコードレベルでエラーが発生した場合は、エラーのないクエリレコードの結果とは別に、応答メッセージでエラーを報告する必要があります。クエリメッセージ内の複数のクエリレコードに異なるエラーがある場合、それらは別々の応答メッセージで報告する必要があります。クエリメッセージ内の複数のQUERYレコードに同じエラーがある場合、このエラー応答は1つまたは複数の応答メッセージで報告される場合があります。エラーレスポンスメッセージでは、応答するQUERYレコードが表示され、サーバーがエラーが持続する可能性があると考えるライフタイム（通常は2 ** 16-1で「無期限」を示す）と、インデックスが挿入された状態で展開されます。 RESPONSEレコードとして。
If errors occur at the RESPONSE Record level for an Update Message, they MUST be reported in an Acknowledge Message separate from the acknowledgment of any non-erroneous RESPONSE Records. If multiple RESPONSE Records in an Update have different errors, they MUST be reported in separate Acknowledge Messages. If multiple RESPONSE Records in an Update Message have the same error, this error response MAY be reported in one or multiple Acknowledge Messages. In an error Acknowledge Message, the RESPONSE Record or Records being responded to appear, expanded by the time for which the server thinks the error might persist and with their Index inserted, as a RESPONSE Record or Records.
更新メッセージのRESPONSEレコードレベルでエラーが発生した場合、エラーのないRESPONSEレコードの確認とは別に、確認メッセージでエラーを報告する必要があります。 Update内の複数のRESPONSEレコードに異なるエラーがある場合、それらは個別の確認メッセージで報告する必要があります。更新メッセージの複数のRESPONSEレコードに同じエラーがある場合、このエラー応答は1つまたは複数の確認応答メッセージで報告される場合があります。エラー確認メッセージでは、応答する1つまたは複数のRESPONSEレコードが表示され、サーバーがエラーが持続する可能性があると考える時間までに拡張され、インデックスが挿入された状態で、RESPONSEレコードとして表示されます。
Err values 1 through 126 are available for encoding errors at the Request Message or Update Message level. Err values 128 through 254 are available for encoding errors at the QUERY Record or RESPONSE Record level. The SubErr field is available for providing more detail on errors. The meaning of a SubErr field value depends on the value of the Err field.
エラー値1〜126は、要求メッセージまたは更新メッセージレベルでのエンコーディングエラーに使用できます。 128から254までのErr値は、QUERYレコードまたはRESPONSEレコードレベルでのエンコーディングエラーに使用できます。 SubErrフィールドは、エラーの詳細を提供するために使用できます。 SubErrフィールド値の意味は、Errフィールドの値によって異なります。
The following table lists error code values for the Err field, their meanings, and whether they apply at the message level or the record level.
次の表は、Errフィールドのエラーコード値とその意味、およびそれらがメッセージレベルで適用されるかレコードレベルで適用されるかを示しています。
Err Level Meaning
------- ------- -----------------------------------------------
0 - No Error
1 Message Unknown or reserved Query Message field value 2 Message Request Message/data too short 3 Message Unknown or reserved Update Message field value 4 Message Update Message/data too short 5-126 Message Unassigned 127 - Reserved
1メッセージ不明または予約済みクエリメッセージフィールド値2メッセージ要求メッセージ/データが短すぎる3メッセージ不明または予約済み更新メッセージフィールド値4メッセージ更新メッセージ/データが短すぎる5-126メッセージ未割り当て127-予約済み
128 Record Unknown or reserved QUERY Record field value 129 Record QUERY Record truncated 130 Record Address not found 131 Record Unknown or reserved RESPONSE Record field value 132 Record RESPONSE Record truncated 133-254 Record Unassigned 255 - Reserved
128レコード不明または予約済みQUERYレコードフィールド値129レコードQUERYレコードが切り捨てられました130レコードアドレスが見つかりません131レコード不明または予約済みRESPONSEレコードフィールド値132レコードRESPONSEレコードが切り捨てられました133-254レコード未割り当て255-予約済み
Note that some error codes are for overall message-level errors, while some are for errors in the repeating records that occur in messages.
一部のエラーコードはメッセージレベルのエラー全体に対するものであり、一部はメッセージで発生する繰り返しレコードのエラーに対するものです。
The following sub-errors are specified under error codes 1 and 3:
次のサブエラーは、エラーコード1および3で指定されています。
SubErr Field with Error
------ -------------------------------------------
0 Unspecified
1 Version not understood (see Section 3.1.1)
2 Unknown Type field value
3 Specified Data Label not being served
4-254 Unassigned
255 Reserved
The following sub-errors are specified under error codes 128 and 131:
次のサブエラーは、エラーコード128および131で指定されています。
SubErr Field with Error
------ ----------------------------------------------------
0 Unspecified
1 Unknown AFN field value
2 Unknown or Reserved QTYPE field value
3 Invalid or inconsistent SIZE field value
4 Invalid frame for QTYPE 2 (other than SEND)
5 SEND frame sent as QTYPE 2
6 Invalid frame for QTYPE 5 (such as multicast MacDA)
7-254 Unassigned
255 Reserved
A Pull Directory client MUST be able to detect, by tracking link-state changes, when a Pull Directory server is no longer accessible (data reachable [RFC7780] for the inter-RBridge case or TRILL ES-IS (Section 5) adjacent for the end-station-to-RBridge case) and MUST promptly discard all pull responses it is retaining from that server, as it can no longer receive cache consistency Update Messages from the server.
プルディレクトリクライアントは、リンク状態の変化を追跡することにより、プルディレクトリサーバーにアクセスできなくなった場合（RBridge間ケースの場合はデータ到達可能[RFC7780]またはTRILL ES-IS（セクション5）に隣接する場合）を検出できなければなりません（MUST）。 end-station-to-RBridgeの場合）、サーバーからキャッシュ整合性更新メッセージを受信できなくなるため、サーバーから保持しているすべてのプル応答を直ちに破棄する必要があります。
A secondary Pull Directory server is one that obtains its data from a primary directory server. See the discussion in Section 2.6 regarding the transfer of directory information from the primary server to the secondary server.
セカンダリプルディレクトリサーバーは、プライマリディレクトリサーバーからデータを取得するサーバーです。プライマリサーバーからセカンダリサーバーへのディレクトリ情報の転送については、2.6項の説明を参照してください。
In the TRILL base protocol [RFC6325] as extended for FGL [RFC7172], the mere presence of any Interested VLANs sub-TLVs or Interested Labels sub-TLVs in the LSP of a TRILL switch indicates connection to end stations in the VLAN(s) or FGL(s) listed and thus a need to receive multi-destination traffic in those Data Labels. However, with Pull Directories, advertising that you are a directory server requires using these sub-TLVs to indicate the Data Label(s) you are serving.
FGL [RFC7172]に拡張されたTRILLベースプロトコル[RFC6325]では、TRILLスイッチのLSPに関係するVLANサブTLVまたは関係するラベルサブTLVが存在するだけで、VLANのエンドステーションへの接続が示されます。またはFGLがリストされているため、これらのデータラベルで複数の宛先のトラフィックを受信する必要があります。ただし、プルディレクトリでは、ディレクトリサーバーであることを宣伝するには、これらのサブTLVを使用して、提供するデータラベルを示す必要があります。
If a directory server does not wish to receive multi-destination TRILL Data packets for the Data Labels it lists in one of the Interested VLANs or Interested Labels (FGLs) sub-TLVs (see Section 1.2), it sets the No Data (NOD) bit to 1 (see Section 7.3). This means that data on a distribution tree may be pruned so as not to reach the "No Data" TRILL switch as long as there are no TRILL switches interested in the Data Label that are beyond the No Data TRILL switch on that distribution tree. The NOD bit is backward compatible, as TRILL switches ignorant of it will simply not prune when they could; this is safe, although it may cause increased link utilization by some TRILL switches sending multi-destination traffic where it is not needed.
ディレクトリサーバーが、関係するVLANまたは関係するラベル（FGL）サブTLV（セクション1.2を参照）の1つにリストするデータラベルのマルチ宛先TRILLデータパケットを受信したくない場合は、データなし（NOD）を設定します。ビットを1に設定します（7.3項を参照）。これは、その配布ツリーのNo Data TRILLスイッチを超えているData Labelに関係するTRILLスイッチがない限り、「No Data」TRILLスイッチに到達しないように、配布ツリーのデータが剪定される可能性があることを意味します。 NODビットは下位互換性があります。TRILLスイッチはそれを知らないので、可能な場合はプルーニングしません。これは安全ですが、複数の宛先トラフィックを送信するTRILLスイッチによっては、リンクの使用率が増加する可能性があります。
Push Directories advertise themselves inside ESADI, which normally requires the ability to send and receive multi-destination TRILL Data packets but can be implemented with serial unicast.
プッシュディレクトリはESADI内で自身をアドバタイズします。これは通常、マルチ宛先TRILLデータパケットを送受信する機能を必要としますが、シリアルユニキャストで実装できます。
An example of a TRILL switch serving as a directory that might not want multi-destination traffic in some Data Labels would be a TRILL switch that does not offer end-station service for any of the Data Labels for which it is serving as a directory and is
一部のデータラベルで複数の宛先のトラフィックを必要としない可能性があるディレクトリとして機能するTRILLスイッチの例は、ディレクトリとして機能しているデータラベルのエンドステーションサービスを提供しないTRILLスイッチです。です
- a Pull Directory and/or
- プルディレクトリおよび/または
- a Push Directory for one or more Data Labels, where all of the ESADI traffic for those Data Labels will be handled by unicast ESADI [RFC7357].
- a 1つ以上のデータラベルのプッシュディレクトリ。これらのデータラベルのすべてのESADIトラフィックは、ユニキャストESADI [RFC7357]によって処理されます。
A Push Directory MUST NOT set the NOD bit for a Data Label if it needs to communicate via multi-destination ESADI or RBridge Channel PDUs in that Data Label, since such PDUs look like TRILL Data packets to transit TRILL switches and are likely to be incorrectly pruned if the NOD bit was set.
そのようなPDUはTRILLスイッチを通過するTRILLデータパケットのように見え、誤っている可能性が高いため、そのデータラベル内の複数の宛先ESADIまたはRBridgeチャネルPDUを介して通信する必要がある場合、プッシュディレクトリはデータラベルのNODビットを設定してはなりません（MUST NOT）。 NODビットが設定されている場合は、除去されます。
The following per-RBridge scalar configuration parameters are available for controlling Pull Directory service behavior. In addition, there is a configurable mapping, per Data Label, from the priority of a native frame being ingressed to the priority of any Pull Directory query it causes. The default mapping depends on the client strategy, as described in Section 4.
次のRBridgeごとのスカラー構成パラメーターは、プルディレクトリサービスの動作を制御するために使用できます。さらに、データラベルごとに、入力されるネイティブフレームの優先度から、それが引き起こすプルディレクトリクエリの優先度まで、構成可能なマッピングがあります。セクション4で説明されているように、デフォルトのマッピングはクライアント戦略に依存します。
Name Default Section Note Below
------------------ ---------------- ------- ----------
DirQueryTimeout 100 milliseconds 3.2.1 1 DirQueryRetries 3 3.2.1 1 DirGenQPriority 5 3.2.1 2
DirQueryTimeout 100ミリ秒3.2.1 1 DirQueryRetries 3 3.2.1 1 DirGenQPriority 5 3.2.1 2
DirRespMaxPriority 6 3.2.2.1 3
DirRespMaxPriority 6 3.2.2.1 3
DirUpdateDelay 50 milliseconds 3.3 DirUpdatePriority 5 3.3.1 DirUpdateTimeout 100 milliseconds 3.3.3 DirUpdateRetries 3 3.3.3
DirUpdateDelay 50ミリ秒3.3 DirUpdatePriority 5 3.3.1 DirUpdateTimeout 100ミリ秒3.3.3 DirUpdateRetries 3 3.3.3
DirAckMaxPriority 5 3.3.2 4
DirAckMaxPriority 5 3.3.2 4
Note 1: Pull Directory Query client timeout waiting for response and maximum number of retries.
注1：応答を待機するプルディレクトリクエリクライアントのタイムアウトと最大再試行回数。
Note 2: Priority for client-generated requests (such as a query to refresh cached information).
注2：クライアントが生成した要求の優先順位（キャッシュされた情報を更新するクエリなど）。
Note 3: Pull Directory Response Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity.
注3：プルディレクトリの応答メッセージは、ネットワーク接続に重要なメッセージ用に予約する必要があるため、優先度7で送信すべきではありません（SHOULD NOT）。
Note 4: Pull Directory Acknowledge Messages SHOULD NOT be sent with priority 7, as that priority SHOULD be reserved for messages critical to network connectivity.
注4：プルディレクトリ確認メッセージは、ネットワーク接続に重要なメッセージ用に予約する必要があるため、優先度7で送信してはなりません（SHOULD NOT）。
For some edge nodes that have a great number of Data Labels enabled, managing the MAC and Data Label <-> Edge RBridge mapping for hosts under all those Data Labels can be a challenge. This is especially true for data-center gateway nodes, which need to communicate with many, if not all, Data Labels.
多数のデータラベルが有効になっている一部のエッジノードでは、これらすべてのデータラベルの下でホストのMACおよびデータラベル<->エッジRBridgeマッピングを管理することが困難な場合があります。これは、すべてではないにしても多くのデータラベルと通信する必要があるデータセンターゲートウェイノードに特に当てはまります。
For those edge TRILL switch nodes, a hybrid model should be considered. That is, the Push Model is used for some Data Labels or addresses within a Data Label, while the Pull Model is used for other Data Labels or addresses within a Data Label. The network operator decides, via configuration, which Data Labels' mapping entries are pushed down from directories and which Data Labels' mapping entries are pulled.
それらのエッジTRILLスイッチノードについては、ハイブリッドモデルを検討する必要があります。つまり、プッシュモデルは一部のデータラベルまたはデータラベル内のアドレスに使用され、プルモデルは他のデータラベルまたはデータラベル内のアドレスに使用されます。ネットワークオペレーターは、構成を介して、どのデータラベルのマッピングエントリをディレクトリからプッシュダウンするか、どのデータラベルのマッピングエントリをプルするかを決定します。
For example, assume a data center where hosts in specific Data Labels, say VLANs 1 through 100, communicate regularly with external peers. The mapping entries for those 100 VLANs should probably be pushed down to the data-center gateway routers. For hosts in other Data Labels that only communicate with external peers occasionally for management interfacing, the mapping entries for those VLANs should be pulled down from the directory when needed.
たとえば、特定のデータラベルのホスト（VLAN 1〜100など）が外部ピアと定期的に通信するデータセンターを想定します。これらの100個のVLANのマッピングエントリは、おそらくデータセンターゲートウェイルーターにプッシュされるはずです。管理インターフェイスのために時々外部ピアとのみ通信する他のデータラベルのホストの場合、それらのVLANのマッピングエントリは、必要に応じてディレクトリからプルダウンする必要があります。
Similarly, within a Data Label, it could be that some addresses, such as the addresses of gateways, files, DNS, or database server hosts are commonly referenced by most other hosts but those other hosts, perhaps compute engines, are typically only referenced by a few hosts in that Data Label. In that case, the address information for the commonly referenced hosts could be pushed as an incomplete directory, while the addresses of the others are pulled when needed.
同様に、データラベル内では、ゲートウェイ、ファイル、DNS、またはデータベースサーバーホストのアドレスなど、一部のアドレスは他のほとんどのホストによって一般的に参照されますが、他のホスト、おそらく計算エンジンは、通常、そのデータラベルのいくつかのホスト。その場合、一般的に参照されるホストのアドレス情報は不完全なディレクトリとしてプッシュされ、他のホストのアドレスは必要に応じてプルされます。
The mechanisms described in this document for Push and Pull Directory services make it easy to use Push for some Data Labels or addresses and Pull for others. In fact, different TRILL switches can even be configured so that some use Push Directory services and some use Pull Directory services for the same Data Label if both Push and Pull Directory services are available for that Data Label. Also, there can be Data Labels for which directory services are not used at all.
このドキュメントで説明されているプッシュおよびプルディレクトリサービスのメカニズムにより、一部のデータラベルまたはアドレスにプッシュを使用し、他のアドレスにプルを使用することが容易になります。実際、プッシュとプルディレクトリの両方のサービスがそのデータラベルで利用可能であれば、同じデータラベルに対してプッシュディレクトリサービスとプルディレクトリサービスを使用するように、別のTRILLスイッチを構成することもできます。また、ディレクトリサービスがまったく使用されていないデータラベルが存在する場合もあります。
There are a wide variety of strategies that a TRILL switch can adopt for making use of directory assistance. A few suggestions are given below.
ディレクトリアシスタンスを利用するためにTRILLスイッチが採用できるさまざまな戦略があります。いくつかの提案を以下に示します。
- Even if a TRILL switch will normally be operating with information from a complete Push Directory server, there will be a period of time when it first comes up before the information it holds is complete. Or, it could be that the only Push Directories that can push information to it are incomplete or that they are just starting and may not yet have pushed the entire directory. Thus, it is RECOMMENDED that all TRILL switches have a strategy for dealing with the situation where they do not have complete directory information. Examples are to send a Pull Directory query or to revert to the behavior described in [RFC6325].
- TRILLスイッチが通常、完全なプッシュディレクトリサーバーからの情報で動作している場合でも、保持されている情報が完了する前に最初に起動する期間があります。または、情報をそこにプッシュできる唯一のプッシュディレクトリが不完全であるか、開始したばかりでディレクトリ全体をまだプッシュしていない可能性があります。したがって、すべてのTRILLスイッチが完全なディレクトリ情報を持たない状況に対処するための戦略を持つことが推奨されます。例としては、プルディレクトリクエリを送信したり、[RFC6325]で説明されている動作に戻したりします。
- If a TRILL switch receives a native frame X resulting in seeking directory information, a choice needs to be made as to what to do if it does not already have the directory information it needs. In particular, it could (1) immediately flood the TRILL Data packet resulting from ingressing X in parallel with seeking the directory information, (2) flood that TRILL Data packet after a delay, if it fails to obtain the directory information, or (3) discard X if it fails to obtain the information. The choice might depend on the priority of frame X, since the higher that priority the more urgent the frame typically is, and the greater the probability of harm in delaying it. If a Pull Directory request is sent, it is RECOMMENDED that its priority be derived from the priority of frame X according to the table below; however, it SHOULD be possible, on a per-TRILL-switch basis, to configure the second two columns of this table.
- TRILLスイッチがネイティブフレームXを受信し、その結果ディレクトリ情報が検索される場合、必要なディレクトリ情報がまだない場合はどうするかを選択する必要があります。特に、（1）ディレクトリ情報のシークと並行してXの進入によって生じたTRILLデータパケットを即座にフラッディングする、（2）ディレクトリ情報の取得に失敗した場合、遅延後にTRILLデータパケットをフラッディングする、または（3 ）情報の取得に失敗した場合、Xを破棄します。優先度が高いほどフレームの緊急性が高く、通常、フレームXの優先度に依存する可能性があります。これは、フレームXの遅延による害の可能性が高くなります。プルディレクトリ要求が送信された場合、その優先順位は、以下の表に従ってフレームXの優先順位から派生することが推奨されます。ただし、この表の2番目の2列を構成することは、TRILLスイッチごとに可能である必要があります（SHOULD）。
Ingressed If Flooded If Flooded
Priority Immediately After Delay
-------- ----------- -----------
7 5 6
6 5 6
5 4 5
4 3 4
3 2 3
2 0 2
0 1 0
1 1 1
Note: The odd-looking ordering of numbers towards the bottom of the columns above is because priority 1 is lower than priority zero. That is to say, the values in the first column are in priority order. They will look more logical if you think of "0" as being "1.5".
注：上の列の下部に向かって奇数に見える数字の順序は、優先度1が優先度0よりも低いためです。つまり、最初の列の値は優先順です。 「0」を「1.5」と考えると、より論理的に見えます。
Priority 7 is normally only used for urgent messages critical to adjacency and so SHOULD NOT be the default for directory traffic. Unsolicited updates are sent with a priority that is configured per Data Label and that defaults to priority 5.
優先度7は通常、隣接性にとって重要な緊急メッセージにのみ使用されるため、ディレクトリトラフィックのデフォルトにするべきではありません。非送信請求更新は、データラベルごとに構成された優先度で送信され、デフォルトで優先度5に設定されます。
TRILL ES-IS (End System to Intermediate System) is a variation of TRILL IS-IS [RFC7176] [RFC7177] [RFC7780] designed to operate on a TRILL link among and between one or more TRILL switches and end stations on that link. TRILL ES-IS is analogous to the ISO/IEC ES-IS standard [ISO9542] but is implemented in a significantly different way as a variation of TRILL IS-IS, as specified in this section. Support of TRILL ES-IS is generally optional for both the TRILL switches and the end stations on a link but may be required to support certain features. At the time of this writing, the only features requiring TRILL ES-IS are those listed in this section.
TRILL ES-IS（エンドシステムから中間システム）は、TRILL IS-IS [RFC7176] [RFC7177] [RFC7780]のバリエーションであり、1つ以上のTRILLスイッチ間およびエンドステーション間のTRILLリンク上で動作するように設計されています。 TRILL ES-ISはISO / IEC ES-IS標準[ISO9542]に類似していますが、このセクションで指定されているように、TRILL IS-ISのバリエーションとして大幅に異なる方法で実装されています。 TRILL ES-ISのサポートは、通常、リンク上のTRILLスイッチと端末の両方でオプションですが、特定の機能をサポートするために必要な場合があります。この記事の執筆時点では、TRILL ES-ISが必要な機能は、このセクションに記載されている機能のみです。
TRILL ES-IS
TRILL IT-IS
o is useful for supporting Pull Directory hosting on, or use from, end stations (see Section 3.5),
o 端末でのプルディレクトリのホスティングまたはエンドステーションからの使用をサポートするのに役立ちます（セクション3.5を参照）。
o is useful for supporting specialized end stations [DirAsstEncap] [SmartEN], and
o 特殊なエンドステーション[DirAsstEncap] [SmartEN]のサポートに役立ちます。
o may have additional future uses.
o 追加の将来の用途があるかもしれません。
The advantages of TRILL ES-IS over simply making an "end station" be a TRILL switch include relieving the end station of having to maintain a copy of the core link-state database (LSPs) and of having to perform routing calculations or having the ability to forward traffic.
「エンドステーション」を単にTRILLスイッチにすることに対するTRILL ES-ISの利点には、コアリンクステートデータベース（LSP）のコピーを維持する必要、およびルーティング計算を実行する必要がある、またはトラフィックを転送する機能。
Except as provided below in this section, TRILL ES-IS PDUs and TLVs are the same as TRILL IS-IS PDUs and TLVs.
このセクションで以下に示す場合を除き、TRILL ES-IS PDUおよびTLVはTRILL IS-IS PDUおよびTLVと同じです。
All TRILL ES-IS PDUs (except some MTU-probe and MTU-ack PDUs, which may be unicast) are multicast using the TRILL-ES-IS multicast MAC address (see Section 7.6). This use of a different multicast address assures that TRILL ES-IS and TRILL IS-IS PDUs will not be confused for one another.
すべてのTRILL ES-IS PDU（ユニキャストの場合がある一部のMTUプローブおよびMTU-ack PDUを除く）は、TRILL-ES-ISマルチキャストMACアドレスを使用してマルチキャストされます（セクション7.6を参照）。この異なるマルチキャストアドレスの使用により、TRILL ES-ISとTRILL IS-IS PDUが互いに混同されないことが保証されます。
Because end stations do not have IS-IS System IDs, TRILL ES-IS uses port MAC addresses in their place. This is convenient, since MAC addresses are 48-bit and almost all IS-IS implementations use 48-bit System IDs. Logically, TRILL IS-IS operates between the TRILL switches in a TRILL campus as identified by the System ID, while TRILL ES-IS operates between Ethernet ports on an Ethernet link (which may be a bridged LAN) as identified by the MAC address [RFC6325].
端末にはIS-ISシステムIDがないため、TRILL ES-ISは代わりにポートMACアドレスを使用します。 MACアドレスは48ビットであり、ほとんどすべてのIS-IS実装は48ビットのシステムIDを使用するため、これは便利です。論理的には、TRILL IS-ISはシステムIDで識別されるTRILLキャンパス内のTRILLスイッチ間で動作し、TRILL ES-ISはMACアドレスで識別されるイーサネットリンク（ブリッジLANの場合もある）のイーサネットポート間で動作します[ RFC6325]。
As System IDs of TRILL switches in a campus are required to be unique, so the MAC addresses of TRILL ES-IS ports on a link MUST be unique.
キャンパス内のTRILLスイッチのシステムIDは一意である必要があるため、リンク上のTRILL ES-ISポートのMACアドレスは一意である必要があります。
TRILL ES-IS adjacency formation and Designated RBridge (DRB) election operate between the ports on the link as specified in [RFC7177] for a broadcast link. The DRB specifies an ES-IS Designated VLAN for the link. Adjacency determination, DRB election, and Designated VLANs as described in this section are distinct from TRILL IS-IS adjacency, DRB election, and Designated VLANs.
TRILL ES-IS隣接関係形成と指定RBridge（DRB）選択は、ブロードキャストリンクの[RFC7177]で指定されているように、リンク上のポート間で動作します。 DRBは、リンクのES-IS指定VLANを指定します。このセクションで説明する隣接関係の決定、DRBの選択、および指定VLANは、TRILL IS-ISの隣接関係、DRBの選択、および指定VLANとは異なります。
Although the "Report state" [RFC7177] exists for TRILL ES-IS adjacencies, such adjacencies are only reported in TRILL ES-IS LSPs, not in any TRILL IS-IS LSPs.
「レポート状態」[RFC7177]はTRILL ES-IS隣接に存在しますが、そのような隣接はTRILL ES-IS LSPでのみ報告され、どのTRILL IS-IS LSPでも報告されません。
End stations supporting TRILL ES-IS MUST assign a unique Port ID to each of their TRILL ES-IS ports; the Port ID appears in the TRILL ES-IS Hellos they send.
TRILL ES-ISをサポートする端末は、TRILL ES-ISポートのそれぞれに一意のポートIDを割り当てる必要があります。ポートIDは、彼らが送信するTRILL ES-IS Hellosに表示されます。
TRILL ES-IS has nothing to do with Appointed Forwarders. The Appointed Forwarders sub-TLV and the VLANs Appointed sub-TLV [RFC7176] are not used and SHOULD NOT be sent in TRILL ES-IS; if such a sub-TLV is received in TRILL ES-IS, it is ignored. (The Appointed Forwarders on a link are determined as specified in [RFC8139], using TRILL IS-IS.)
TRILL ES-ISはAppointed Forwardersとは関係ありません。 Appointed Forwarders sub-TLVとVLANs Appointed sub-TLV [RFC7176]は使用されず、TRILL ES-ISで送信してはなりません（SHOULD NOT）。そのようなサブTLVがTRILL ES-ISで受信されても、無視されます。 （リンク上のAppointed Forwardersは、[RFC8139]で指定されているように、TRILL IS-ISを使用して決定されます。）
Although some of the ports sending TRILL ES-IS PDUs are on end stations and thus not on routers (TRILL switches), they nevertheless may make use of the Router CAPABILITY (#242) [RFC7981] and MT-Capability (#144) [RFC6329] IS-IS TLVs to indicate capabilities as specified in [RFC7176].
TRILL ES-IS PDUを送信するポートの一部はエンドステーションにあり、ルーター（TRILLスイッチ）にはありませんが、ルーターの機能（＃242）[RFC7981]とMT-Capability（＃144）[ RFC6329] [RFC7176]で指定されている機能を示すIS-IS TLV。
TRILL ES-IS Hellos are like TRILL IS-IS Hellos, but note the following: in the Special VLANs and Flags sub-TLV [RFC7176], any TRILL switches advertise a nickname they own, but for end stations, that field MUST be sent as zero and ignored on receipt. In addition, in the Special VLANs and Flags sub-TLV (Section 2.2.1 of [RFC7176]) in a TRILL ES-IS Hello, the AF and TR flag bits MUST be sent as zero, the AC flag bit MUST be sent as one (1), and all three are ignored on receipt.
TRILL ES-IS HellosはTRILL IS-IS Hellosに似ていますが、次の点に注意してください。特別なVLANおよびフラグサブTLV [RFC7176]では、TRILLスイッチは所有するニックネームをアドバタイズしますが、エンドステーションの場合、そのフィールドを送信する必要がありますゼロとして受け取り、無視されます。さらに、TRILL ES-IS Helloの特別なVLANおよびフラグサブTLV（[RFC7176]のセクション2.2.1）では、AFおよびTRフラグビットをゼロとして送信する必要があり、ACフラグビットを次のように送信する必要があります。 1つ、および3つすべてが受信時に無視されます。
The only link-state transmission and synchronization that occur in TRILL ES-IS are for E-L1CS (Extended Level 1 Circuit Scope) PDUs [RFC7356]. In particular, the end-station Ethernet ports supporting TRILL ES-IS do not support the core TRILL IS-IS LSPs and do not support E-L1FS (Extended Level 1 Flooding Scope) LSPs [RFC7780] (or the CSNPs or PSNPs (Partial Sequence Number PDUs) [RFC7356] corresponding to either of them). TLVs and sub-TLVs that would otherwise be sent in TRILL IS-IS LSPs or E-L1FS LSPs are instead sent in E-L1CS LSPs.
TRILL ES-ISで発生する唯一のリンクステート送信と同期は、E-L1CS（拡張レベル1サーキットスコープ）PDU [RFC7356]に対するものです。特に、TRILL ES-ISをサポートする端末のイーサネットポートは、コアTRILL IS-IS LSPをサポートせず、E-L1FS（拡張レベル1フラッディングスコープ）LSP [RFC7780]（またはCSNPまたはPSNP（部分的）シーケンス番号PDU）[RFC7356]のいずれかに対応）。代わりにTRILL IS-IS LSPまたはE-L1FS LSPで送信されるTLVおよびサブTLVは、代わりにE-L1CS LSPで送信されます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
Incorrect directory information can result in a variety of security threats, including those listed below. Directory servers therefore need to take care to implement and enforce access control policies that are not overly permissive.
不正なディレクトリ情報は、以下にリストされているものを含む、さまざまなセキュリティ上の脅威をもたらす可能性があります。したがって、ディレクトリサーバーは、過度に許容されないアクセス制御ポリシーを実装および適用するよう注意する必要があります。
o Incorrect directory mappings can result in data being delivered to the wrong end stations, or set of end stations in the case of multi-destination packets, violating security policy.
o ディレクトリマッピングが正しくないと、データが間違ったエンドステーションに配信されたり、マルチ宛先パケットの場合はエンドステーションのセットに配信されたりして、セキュリティポリシーに違反する可能性があります。
o Missing, incorrect, or inaccessible directory data can result in denial of service due to sending data packets to black holes or discarding data on ingress due to incorrect information that their destinations are not reachable or that their source addresses are forged.
o ディレクトリデータが欠落している、正しくない、またはアクセスできない場合、ブラックホールにデータパケットを送信したり、宛先に到達できない、または送信元アドレスが偽造されているという誤った情報が原因で入力時にデータを破棄したりして、サービス拒否が発生する可能性があります。
For these reasons, whatever server or end station the directory information resides on, it needs to be protected from unauthorized modification. Parties authorized to modify directory data can violate availability and integrity policies.
これらの理由により、ディレクトリ情報が存在するサーバーまたはエンドステーションが何であれ、不正な変更から保護する必要があります。ディレクトリデータの変更を許可された当事者は、可用性と整合性のポリシーに違反する可能性があります。
In implementations of the base TRILL protocol [RFC6325] [RFC7780], RBridges deal almost exclusively with MAC addresses. The use of directories to map to/from IP addresses means that RBridges deal more actively with IP addresses as well. But RBridges in any case would be exposed to plain-text ARP/ND/SEND/IP traffic and so can see all this addressing metadata. So, this more-explicit dealing with IP addresses has little effect on the privacy of end-station traffic.
基本のTRILLプロトコル[RFC6325] [RFC7780]の実装では、RBridgeはほぼ排他的にMACアドレスを扱います。ディレクトリを使用してIPアドレスとの間でマップすることは、RBridgeがIPアドレスをより積極的に処理することも意味します。ただし、いずれの場合もRBridgeはプレーンテキストのARP / ND / SEND / IPトラフィックに公開されるため、このすべてのアドレス指定メタデータを確認できます。したがって、このIPアドレスのより明示的な処理は、端末トラフィックのプライバシーにほとんど影響を与えません。
Parties authorized to read directory data can violate privacy policies for such data.
ディレクトリデータの読み取りを許可された当事者は、そのようなデータのプライバシーポリシーに違反する可能性があります。
Push Directory data is distributed through ESADI-LSPs [RFC7357]. ESADI is built on IS-IS, and such data can thus be authenticated with the widely implemented and deployed IS-IS PDU security. This mechanism provides authentication and integrity protection. See [RFC5304], [RFC5310], and the Security Considerations section of [RFC7357].
プッシュディレクトリデータはESADI-LSP [RFC7357]を介して配布されます。 ESADIはIS-ISに基づいて構築されているため、このようなデータは、広く実装および展開されているIS-IS PDUセキュリティで認証できます。このメカニズムは、認証と整合性保護を提供します。 [RFC5304]、[RFC5310]、および[RFC7357]のセキュリティに関する考慮事項のセクションを参照してください。
Pull Directory queries and responses are transmitted as RBridge-to-RBridge or native RBridge Channel messages [RFC7178]. Such messages can be secured by the mechanisms specified in [RFC7978]. These mechanisms can provide authentication and confidentiality protection. At the time of this writing, these security mechanisms are believed to be less widely implemented than IS-IS security.
プルディレクトリのクエリと応答は、RBridge-to-RBridgeまたはネイティブのRBridge Channelメッセージ[RFC7178]として送信されます。このようなメッセージは、[RFC7978]で指定されたメカニズムによって保護できます。これらのメカニズムは、認証と機密保護を提供できます。この記事の執筆時点では、これらのセキュリティメカニズムはIS-ISセキュリティほど実装されていないと考えられています。
IANA has created a subregistry in the "TRILL Parameters" registry as follows:
IANAは、「TRILL Parameters」レジストリに次のサブレジストリを作成しました。
Subregistry: ESADI-Parameter APPsub-TLV Flag Bits Registration Procedure(s): Standards Action References: [RFC7357] [RFC8171]
サブレジストリ：ESADIパラメータAPPsub-TLVフラグビット登録手順：標準アクションリファレンス：[RFC7357] [RFC8171]
Bit Mnemonic Description Reference
--- -------- ---------------------------- ---------------
0 UN Supports Unicast ESADI ESADI [RFC7357]
1-2 PDSS Push Directory Server Status [RFC8171]
3-7 - Unassigned
In addition, the ESADI-Parameter APPsub-TLV is optionally extended, as provided in its original specification in ESADI [RFC7357], by 1 byte as shown below. Therefore, [RFC8171] has also been added as a second reference to the ESADI-Parameter APPsub-TLV in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry.
さらに、ESADIパラメータAPPsub-TLVは、ESADI [RFC7357]の元の仕様で提供されているように、オプションで以下に示すように1バイト拡張されます。したがって、[RFC8171]も「IS-IS TLV 251アプリケーションID 1のTRILL APPsub-TLVタイプ」レジストリのESADIパラメータAPPsub-TLVへの2番目の参照として追加されました。
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|R| Priority | (1 byte)
+-+-+-+-+-+-+-+-+
| CSNP Time | (1 byte)
+-+-+-+-+-+-+-+-+
| Flags | (1 byte)
+---------------+
|PushDirPriority| (optional, 1 byte)
+---------------+
| Reserved for (variable)
| expansion
+-+-+-+-...
The meanings of all the fields are as specified in ESADI [RFC7357], except that the added PushDirPriority is the priority of the advertising ESADI instance to be a Push Directory as described in Section 2.3. If the PushDirPriority field is not present (Length = 3), it is treated as if it were 0x3F. 0x3F is also the value used and placed here by a TRILL switch whose priority to be a Push Directory has not been configured.
すべてのフィールドの意味はESADI [RFC7357]で指定されているとおりです。ただし、追加されたPushDirPriorityは、セクション2.3で説明されているように、アドバタイズするESADIインスタンスがプッシュディレクトリになる優先度です。 PushDirPriorityフィールドが存在しない場合（長さ= 3）、0x3Fであるかのように扱われます。 0x3Fは、プッシュディレクトリとなる優先度が設定されていないTRILLスイッチによって使用および配置される値でもあります。
IANA has assigned a new RBridge Channel Protocol number (0x005) from the range assignable by Standards Action [RFC5226] and updated the subregistry accordingly in the "TRILL Parameters" registry. The description is "Pull Directory Services". The reference is [RFC8171].
IANAは、標準アクション[RFC5226]によって割り当て可能な範囲から新しいRBridgeチャネルプロトコル番号（0x005）を割り当て、それに応じて「TRILLパラメータ」レジストリのサブレジストリを更新しました。説明は「プルディレクトリサービス」です。参照は[RFC8171]です。
IANA has assigned a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV and the Interested Labels field of the Interested Labels sub-TLV [RFC7176] to indicate a Pull Directory server (PUL). This bit has been added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below.
IANAは、以前に予約されたビットをInterest VLANsサブTLVのInterest VLANsフィールドとInterest LabelsサブTLV [RFC7176]のInterest Labelsフィールドに割り当てて、プルディレクトリサーバー（PUL）を示しています。このビットは、このドキュメントを参照として、[RFC7357]によって作成された「Interested VLANs Flag Bits」および「Interested Labels Flag Bits」サブレジストリに、以下に示すように追加されました。
IANA has assigned a previously reserved bit in the Interested VLANs field of the Interested VLANs sub-TLV and the Interested Labels field of the Interested Labels sub-TLV [RFC7176] to indicate No Data (NOD) (see Section 3.8). This bit has been added, with this document as a reference, to the "Interested VLANs Flag Bits" and "Interested Labels Flag Bits" subregistries created by [RFC7357], as shown below.
IANAは、以前に予約されたビットを対象VLANサブTLVの対象VLANフィールドと対象ラベルサブTLV [RFC7176]の対象ラベルフィールドに割り当てて、データなし（NOD）を示しています（セクション3.8を参照）。このビットは、このドキュメントを参照として、[RFC7357]によって作成された「Interested VLANs Flag Bits」および「Interested Labels Flag Bits」サブレジストリに、以下に示すように追加されました。
The bits are as follows:
ビットは次のとおりです。
Registry: Interested VLANs Flag Bits
レジストリ：関心のあるVLANフラグビット
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
18 PUL Pull Directory [RFC8171]
19 NOD No Data [RFC8171]
Registry: Interested Labels Flag Bits
レジストリ：興味のあるラベルフラグビット
Bit Mnemonic Description Reference
--- -------- -------------- ---------------
6 PUL Pull Directory [RFC8171]
7 NOD No Data [RFC8171]
IANA has created a new registry as follows:
IANAは、次のように新しいレジストリを作成しました。
Name: TRILL Pull Directory Query Types (QTYPEs) Registration Procedure(s): IETF Review Reference: [RFC8171] Initial contents as in Section 3.2.1.
名前：TRILLプルディレクトリクエリタイプ（QTYPE）登録手順：IETFレビューリファレンス：[RFC8171]セクション3.2.1と同じ初期コンテンツ。
IANA has created a new registry and two new indented subregistries as follows:
IANAは、次のように新しいレジストリと2つのインデントされたサブレジストリを作成しました。
Registry Name: TRILL Pull Directory Errors Registration Procedure(s): IETF Review Reference: [RFC8171]
レジストリ名：TRILL Pullディレクトリエラー登録手順：IETFレビューリファレンス：[RFC8171]
Initial contents as in Section 3.6.1.
セクション3.6.1と同じ初期コンテンツ。
Subregistry Name: Sub-codes for TRILL Pull Directory Errors 1 and 3 Registration Procedure(s): Expert Review Reference: [RFC8171]
サブレジストリ名：TRILLプルディレクトリエラー1および3のサブコード登録手順：専門家レビューリファレンス：[RFC8171]
Initial contents as in Section 3.6.2.
セクション3.6.2と同じ初期コンテンツ。
Subregistry Name: Sub-codes for TRILL Pull Directory Errors 128 and 131 Registration Procedure(s): Expert Review Reference: [RFC8171]
サブレジストリ名：TRILLプルディレクトリエラー128および131のサブコード登録手順：専門家レビューリファレンス：[RFC8171]
Initial contents as in Section 3.6.3.
セクション3.6.3と同じ初期コンテンツ。
IANA has assigned a TRILL multicast MAC address (01-80-C2-00-00-47) from the "TRILL Multicast Addresses" registry. The description is "TRILL-ES-IS". The reference is [RFC8171].
IANAは、「TRILL Multicast Addresses」レジストリからTRILLマルチキャストMACアドレス（01-80-C2-00-00-47）を割り当てました。説明は「TRILL-ES-IS」です。参照は[RFC8171]です。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, DOI 10.17487/RFC0903, June 1984, <http://www.rfc-editor.org/info/rfc903>.
[RFC903] Finlayson、R.、Mann、T.、Mogul、J.、and M. Theimer、 "A Reverse Address Resolution Protocol"、STD 38、RFC 903、DOI 10.17487 / RFC0903、June 1984、<http：// www.rfc-editor.org/info/rfc903>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、DOI 10.17487 / RFC3971、March 2005、<http：/ /www.rfc-editor.org/info/rfc3971>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、DOI 10.17487 / RFC6165、2011年4月、<http://www.rfc-editor.org/info / rfc6165>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>.
[RFC6329] Fedyk、D。、編、Ashwood-Smith、P。、編、Allan、D.、Bragg、A。、およびP. Unbehagen、「IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging」、 RFC 6329、DOI 10.17487 / RFC6329、2012年4月、<http://www.rfc-editor.org/info/rfc6329>。
[RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <http://www.rfc-editor.org/info/rfc7042>.
[RFC7042] Eastlake 3rd、D。およびJ. Abley、「IANAの考慮事項およびIEEE 802パラメータのIETFプロトコルおよびドキュメントの使用法」、BCP 141、RFC 7042、DOI 10.17487 / RFC7042、2013年10月、<http：//www.rfc -editor.org/info/rfc7042>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <http://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<http://www.rfc-editor.org/info/rfc7177>。
[RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. Ward, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7178] Eastlake 3rd、D.、Manral、V.、Li、Y.、Aldrin、S.、and D. Ward、 "Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Support"、RFC 7178、DOI 10.17487 / RFC7178、2014年5月、<http://www.rfc-editor.org/info/rfc7178>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-IS Flooding Scope Link State PDU（LSPs）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// www。 rfc-editor.org/info/rfc7356>。
[RFC7357] Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O. Stokes, "Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol", RFC 7357, DOI 10.17487/RFC7357, September 2014, <http://www.rfc-editor.org/info/rfc7357>.
[RFC7357] Zhai、H.、Hu、F.、Perlman、R.、Eastlake 3rd、D。、およびO. Stokes、「多数のリンクの透過的な相互接続（TRILL）：端末アドレス配布情報（ESADI）プロトコル」 、RFC 7357、DOI 10.17487 / RFC7357、2014年9月、<http://www.rfc-editor.org/info/rfc7357>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[RFC7961] Eastlake 3rd, D. and L. Yizhou, "Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV", RFC 7961, DOI 10.17487/RFC7961, August 2016, <http://www.rfc-editor.org/info/rfc7961>.
[RFC7961] Eastlake 3rd、D。およびL. Yizhou、「多数のリンクの透過的な相互接続（TRILL）：インターフェースアドレスAPPsub-TLV」、RFC 7961、DOI 10.17487 / RFC7961、2016年8月、<http：//www.rfc -editor.org/info/rfc7961>。
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, <http://www.rfc-editor.org/info/rfc7981>.
[RFC7981] Ginsberg、L.、Previdi、S。、およびM. Chen、「IS-IS Extensions for Advertising Router Information」、RFC 7981、DOI 10.17487 / RFC7981、2016年10月、<http：//www.rfc-editor .org / info / rfc7981>。
[RFC8139] Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F. Hu, "Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders", RFC 8139, DOI 10.17487/RFC7961, June 2017, <http://www.rfc-editor.org/info/rfc8139>.
[RFC8139] Eastlake 3rd、D.、Li、Y.、Umair、M.、Banerjee、A.、and F. Hu、 "Transparent Interconnection of Lots of Links（TRILL）：Appointed Forwarders"、RFC 8139、DOI 10.17487 / RFC7961、2017年6月、<http://www.rfc-editor.org/info/rfc8139>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.
[RFC7067] Dunbar、L.、Eastlake 3rd、D.、Perlman、R。、およびI. Gashinsky、「Directory Assistance Problem and High-Level Design Proposal」、RFC 7067、DOI 10.17487 / RFC7067、2013年11月、<http： //www.rfc-editor.org/info/rfc7067>。
[RFC7978] Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension", RFC 7978, DOI 10.17487/RFC7978, September 2016, <http://www.rfc-editor.org/info/rfc7978>.
[RFC7978] Eastlake 3rd、D.、Umair、M。、およびY. Li、「Transparent Interconnection of Lots of Links（TRILL）：RBridge Channel Header Extension」、RFC 7978、DOI 10.17487 / RFC7978、2016年9月、<http： //www.rfc-editor.org/info/rfc7978>。
[ARPND] Li, Y., Eastlake 3rd, D., Dunbar, L., Perlman, R., and M. Umair, "TRILL: ARP/ND Optimization", Work in Progress, draft-ietf-trill-arp-optimization-08, April 2017.
[ARPND] Li、Y.、Eastlake 3rd、D.、Dunbar、L.、Perlman、R。、およびM. Umair、「TRILL：ARP / ND Optimization」、Work in Progress、draft-ietf-trill-arp-最適化-08、2017年4月。
[DirAsstEncap] Dunbar, L., Eastlake 3rd, D., and R. Perlman, "Directory Assisted TRILL Encapsulation", Work in Progress, draft-ietf-trill-directory-assisted-encap-05, May 2017.
[DirAsstEncap] Dunbar、L.、Eastlake 3rd、D。、およびR. Perlman、「Directory Assisted TRILL Encapsulation」、作業中、draft-ietf-trill-directory-assisted-encap-05、2017年5月。
[ISO9542] ISO 9542:1988, "Information processing systems -- Telecommunications and information exchange between systems -- End system to Intermediate system routeing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service (ISO 8473)", August 1988.
[ISO9542] ISO 9542：1988、「情報処理システム-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するためのエンドシステムから中間システムへのルーティング交換プロトコル、1988年8月。
[SmartEN] Perlman, R., Hu, F., Eastlake 3rd, D., Krupakaran, K., and T. Liao, "TRILL Smart Endnodes", Work in Progress, draft-ietf-trill-smart-endnodes-05, February 2017.
[SmartEN] Perlman、R.、Hu、F.、Eastlake 3rd、D.、Krupakaran、K。、およびT. Liao、「TRILL Smart Endnodes」、Work in Progress、draft-ietf-trill-smart-endnodes-05 、2017年2月。
[X.233] International Telecommunication Union, ITU-T Recommendation X.233: "Information technology - Protocol for providing the connectionless-mode network service: Protocol specification", August 1997, <https://www.itu.int/rec/T-REC-X.233/en>.
[X.233]国際電気通信連合、ITU-T勧告X.233：「情報技術-コネクションレスモードのネットワークサービスを提供するためのプロトコル：プロトコル仕様」、1997年8月、<https://www.itu.int/rec /T-REC-X.233/en>。
Acknowledgments
謝辞
The contributions of the following persons are gratefully acknowledged:
以下の方々の貢献に感謝いたします。
Amanda Baber, Matthew Bocci, Alissa Cooper, Stephen Farrell, Daniel Franke, Igor Gashinsky, Joel Halpern, Susan Hares, Alexey Melnikov, Gayle Noble, and Tianran Zhou.
アマンダ・バーバー、マシュー・ボッチ、アリッサ・クーパー、スティーブン・ファレル、ダニエル・フランケ、イゴール・ガシンスキー、ジョエル・ハルパーン、スーザン・ヘアズ、アレクセイ・メルニコフ、ゲイル・ノーブル、ティアンラン・ジョウ。
Authors' Addresses
著者のアドレス
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America Phone: +1-508-333-2270 Email: d3e3e3@gmail.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford、MA 01757 United States電話：+ 1-508-333-2270メール：d3e3e3@gmail.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive, Suite #175 Plano, TX 75024 United States of America Phone: +1-469-277-5840 Email: ldunbar@huawei.com
Linda Dunbar Huawei Technologies 5430 Legacy Drive、Suite＃175 Plano、TX 75024 United States電話：+ 1-469-277-5840メール：ldunbar@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States of America Email: Radia@alum.mit.edu
Radia Perlman EMC 2010 256th Avenue NE、＃200 Bellevue、WA 98007アメリカ合衆国メール：Radia@alum.mit.edu
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China Phone: +86-25-56622310 Email: liyizhou@huawei.com
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国電話：+ 86-25-56622310電子メール：Li Yizhou@Huawei.com