[要約] RFC 8384は、TRILLスマートエンドノードの透過的な相互接続に関するものであり、TRILLネットワーク内のエンドノードの動作と相互接続の仕組みを定義しています。このRFCの目的は、TRILLネットワーク内のスマートエンドノードの効果的な利用と、ネットワークのパフォーマンスとスケーラビリティの向上です。
Internet Engineering Task Force (IETF) R. Perlman
Request for Comments: 8384 Dell EMC
Category: Standards Track F. Hu
ISSN: 2070-1721 ZTE Corporation
D. Eastlake 3rd
T. Liao
Huawei Technologies
July 2018
Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes
多数のリンクの透過的な相互接続（TRILL）スマートエンドノード
Abstract
概要
This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "Smart Endnode". Only the attached edge RBridge can distinguish a "Smart Endnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that are Fine-Grained Label (FGL) aware.
このドキュメントでは、エンドノードがエンドノード学習とカプセル化/カプセル化解除を志願できるようにすることで、エッジルーティングブリッジ（RBridges）のエンドノード学習テーブルのサイズと鮮度の問題に対処します。このようなエンドノードは、「スマートエンドノード」として知られています。アタッチされたエッジRBridgeのみが、「スマートエンドノード」と「通常のエンドノード」を区別できます。スマートエンドノードは、接続されたエッジRBridgeのニックネームを使用するため、このソリューションは余分なニックネームを消費しません。このソリューションでは、ファイングレインラベル（FGL）対応のエンドノードも有効になります。
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 https://www.rfc-editor.org/info/rfc8384.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8384で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Smart-Hello Mechanism between Smart Endnode and RBridge . . . 6
4.1. Smart-Hello Encapsulation . . . . . . . . . . . . . . . . 6
4.2. Edge RBridge's Smart-Hello . . . . . . . . . . . . . . . 8
4.3. Smart Endnode's Smart-Hello . . . . . . . . . . . . . . . 8
5. Processing Data Packets . . . . . . . . . . . . . . . . . . . 10
5.1. Data-Packet Processing for Smart Endnodes . . . . . . . . 10
5.2. Data-Packet Processing for Edge RBridge . . . . . . . . . 11
6. Multihoming Scenario . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS [IS-IS] [RFC7176] link state routing and encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges) or "TRILL Switches".
IETF TRILL（多数のリンクの透過的相互接続）プロトコル[RFC6325] [RFC7780]は、構成なしの最適なペアワイズデータフレーム転送、一時ループの期間中も安全な転送、およびユニキャストとマルチキャストの両方のトラフィックのマルチパスのサポートを提供します。 TRILLは、IS-IS [IS-IS] [RFC7176]リンクステートルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを実現します。 TRILLを実装するデバイスは、「RBridges」（ルーティングブリッジ）または「TRILLスイッチ」と呼ばれます。
An RBridge that attaches to endnodes is called an "edge RBridge" or "edge TRILL Switch", whereas one that exclusively forwards encapsulated frames is known as a "transit RBridge" or "transit TRILL Switch". An edge RBridge traditionally is the one that encapsulates a native Ethernet frame with a TRILL header or that receives a TRILL-encapsulated packet and decapsulates the TRILL header. To encapsulate efficiently, the edge RBridge must keep an "endnode table" consisting of (Media Access Control (MAC), Data Label, TRILL egress switch nickname) sets, for those remote MAC addresses in Data Labels currently communicating with endnodes to which the edge RBridge is attached.
エンドノードに接続するRBridgeは「エッジRBridge」または「エッジTRILLスイッチ」と呼ばれますが、カプセル化されたフレームのみを転送するものは「トランジットRBridge」または「トランジットTRILLスイッチ」と呼ばれます。従来、エッジRBridgeは、ネイティブイーサネットフレームをTRILLヘッダーでカプセル化するもの、またはTRILLカプセル化されたパケットを受信してTRILLヘッダーをカプセル化解除するものです。効率的にカプセル化するために、エッジRBridgeは、（メディアアクセスコントロール（MAC）、データラベル、TRILL出力スイッチニックネーム）セットで構成される「エンドノードテーブル」を維持する必要があります。 RBridgeが付属しています。
These table entries might be configured, received from End Station Address Distribution Information (ESADI) [RFC7357], looked up in a directory [RFC7067], or learned from decapsulating received traffic. If the edge RBridge has attached endnodes communicating with many remote endnodes, this table could become very large. Also, if a MAC address / Data Label pair in the table have moved to a different remote TRILL switch, it might be difficult for the edge RBridge to notice this quickly; and because the edge RBridge is encapsulating to the incorrect egress RBridge, the traffic will get lost.
これらのテーブルエントリは、構成するか、エンドステーションアドレス配布情報（ESADI）[RFC7357]から受信するか、ディレクトリ[RFC7067]で検索するか、受信トラフィックのカプセル化を解除して学習します。エッジRBridgeに、多くのリモートエンドノードと通信するエンドノードが接続されている場合、このテーブルは非常に大きくなる可能性があります。また、テーブル内のMACアドレスとデータラベルのペアが別のリモートTRILLスイッチに移動した場合、エッジRBridgeがこれにすぐに気付くのが難しい場合があります。また、エッジRBridgeが不正な出力RBridgeにカプセル化しているため、トラフィックが失われます。
BUM: Broadcast, Unknown unicast, and Multicast.
BUM：ブロードキャスト、不明なユニキャスト、およびマルチキャスト。
Edge RBridge: An RBridge providing endnode service on at least one of its ports. It is also called an edge TRILL Switch.
エッジRBridge：少なくとも1つのポートでエンドノードサービスを提供するRBridge。エッジTRILLスイッチとも呼ばれます。
Data Label: VLAN or FGL.
データラベル：VLANまたはFGL。
DRB: Designated RBridge [RFC6325].
DRB：指定RBridge [RFC6325]。
ESADI: End Station Address Distribution Information [RFC7357].
ESADI：端末アドレス配布情報[RFC7357]。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
IS-IS: Intermediate System to Intermediate System [IS-IS].
IS-IS：Intermediate System to Intermediate System [IS-IS]。
LSP: Link State PDU.
LSP：リンク状態PDU。
PDU: Protocol Data Unit.
PDU：プロトコルデータユニット。
RBridge: Routing Bridge, an alternative name for a TRILL switch.
RBridge：TRILLスイッチの別名であるルーティングブリッジ。
Smart Endnode: An endnode that has the capability specified in this document including learning and maintaining (MAC, Data Label, nickname) entries and encapsulating/decapsulating TRILL frame.
スマートエンドノード：（MAC、データラベル、ニックネーム）エントリの学習と保守、TRILLフレームのカプセル化/カプセル化解除など、このドキュメントで指定されている機能を持つエンドノード。
Transit RBridge: An RBridge that exclusively forwards encapsulated frames. It is also called a transit TRILL Switch.
Transit RBridge：カプセル化されたフレームのみを転送するRBridge。トランジットTRILLスイッチとも呼ばれます。
TRILL: Transparent Interconnection of Lots of Links [RFC6325][RFC7780].
TRILL：多くのリンクの透過的な相互接続[RFC6325] [RFC7780]。
TRILL ES-IS: TRILL End System to Intermediate System, is a variation of TRILL IS-IS designed to operate on a TRILL link among and between one or more TRILL switches and end stations on that link [RFC8171].
TRILL ES-IS：TRILL End System to Intermediate Systemは、1つ以上のTRILLスイッチ間およびそのリンク上のエンドステーション間のTRILLリンクで動作するように設計されたTRILL IS-ISのバリエーションです[RFC8171]。
TRILL Switch: a device that implements the TRILL protocol; an alternative term for an RBridge.
TRILLスイッチ：TRILLプロトコルを実装するデバイス。 RBridgeの別名。
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 Smart Endnode solution defined in this document addresses the problem of the size and freshness of the endnode learning table in edge RBridges. An endnode E, attached to an edge RBridge R, tells R that E would like to be a "Smart Endnode", which means that E will encapsulate and decapsulate the TRILL frame, using R's nickname. Because E uses R's nickname, this solution does not consume extra nicknames.
このドキュメントで定義されているスマートエンドノードソリューションは、エッジRBridgeのエンドノード学習テーブルのサイズと鮮度の問題に対処します。エッジRBridge Rに接続されたエンドノードEは、Eが「スマートエンドノード」になりたいことをRに伝えます。つまり、EはRのニックネームを使用してTRILLフレームをカプセル化およびカプセル化解除します。 EはRのニックネームを使用するため、このソリューションは余分なニックネームを消費しません。
Take Figure 1 as the example Smart Endnode scenario: RB1, RB2, and RB3 are the RBridges in the TRILL domain and SE1 and SE2 are the Smart Endnodes that can encapsulate and decapsulate the TRILL packets. RB1 is the edge RB to which SE1 and SE2 have attached. RB1 assigns one of its nicknames to be used by SE1 and SE2.
スマートエンドノードシナリオの例として図1を取り上げます。RB1、RB2、およびRB3はTRILLドメインのRBridgeであり、SE1およびSE2はTRILLパケットをカプセル化およびカプセル化解除できるスマートエンドノードです。 RB1は、SE1およびSE2が接続されているエッジRBです。 RB1は、SE1およびSE2が使用するニックネームの1つを割り当てます。
Each Smart Endnode, SE1 and SE2, uses RB1's nickname when encapsulating and maintains an endnode table of (MAC, Data Label, TRILL egress switch nickname) for remote endnodes that it (SE1 or SE2) is corresponding with. RB1 does not decapsulate packets destined for SE1 or SE2 and does not learn (MAC, Data Label, TRILL egress switch nickname) for endnodes corresponding with SE1 or SE2, but RB1 does decapsulate and does learn (MAC, Data Label, TRILL egress switch nickname) for any endnodes attached to RB1 that have not declared themselves to be Smart Endnodes.
各スマートエンドノード（SE1およびSE2）は、カプセル化時にRB1のニックネームを使用し、それ（SE1またはSE2）が対応するリモートエンドノードの（MAC、データラベル、TRILL出力スイッチニックネーム）のエンドノードテーブルを維持します。 RB1は、SE1またはSE2宛てのパケットをカプセル化解除せず、SE1またはSE2に対応するエンドノードについては学習しません（MAC、データラベル、TRILL出力スイッチニックネーム）が、RB1はカプセル化を解除して学習します（MAC、データラベル、TRILL出力スイッチニックネーム） ）RB1に接続され、自分自身がスマートエンドノードであると宣言していないエンドノードの場合。
Just as an RBridge learns and times out (MAC, Data Label, TRILL egress switch nickname), Smart Endnodes SE1 and SE2 also learn and time out endnode entries. However, SE1 and SE2 might also determine, through ICMP messages or other techniques that an endnode entry is not successfully reaching the destination endnode, and it can be deleted, even if the entry has not timed out.
RBridgeが学習してタイムアウト（MAC、データラベル、TRILL出力スイッチニックネーム）するように、スマートエンドノードSE1およびSE2もエンドノードエントリを学習してタイムアウトします。ただし、SE1とSE2は、ICMPメッセージまたは他の手法を介して、エンドノードエントリが宛先エンドノードに正常に到達していないことも判断し、エントリがタイムアウトしていなくても削除できる場合があります。
If SE1 wishes to correspond with destination MAC D, and no endnode entry exists, SE1 will encapsulate the packet as an unknown destination, or consult a directory [RFC7067] (just as an RBridge would do if there was no endnode entry).
SE1が宛先MAC Dとの対応を希望し、エンドノードエントリが存在しない場合、SE1はパケットを不明な宛先としてカプセル化するか、ディレクトリ[RFC7067]を参照します（エンドノードエントリがない場合と同様にRBridgeが行うように）。
+----------+
|SE1(Smart |
|Endnode1) | \ +------------------------------+
+----------+ \ / \
\ /+------+ +------+ +-----+ \ +-----------+
/-+-| RB 1 |---| RB2 |----| RB3 |-----+--|Endnode3 |
/ | +------+ +------+ +-----+ | |MAC=D |
+----------+ / \ / +-----------+
|SE2(Smart | \ /
| Endnode2)| +------------------------------+
+----------+
Figure 1: Smart Endnode Scenario
図1：スマートエンドノードシナリオ
The mechanism in this document is that the Smart Endnode SE1 issues a Smart-Hello, indicating SE1's desire to act as a Smart Endnode, together with the set of MAC addresses and Data Labels that SE1 owns. The Smart-Hello is used to announce the Smart Endnode capability and parameters (such as MAC address, Data Label, etc.). The Smart-Hello is a type of TRILL ES-IS PDU, which is specified in Section 5 of [RFC8171]. The detailed content for a Smart Endnode's Smart-Hello is defined in Section 4.
このドキュメントのメカニズムは、スマートエンドノードSE1がSmart-Helloを発行し、SE1が所有するMACアドレスとデータラベルのセットとともに、スマートエンドノードとして機能したいというSE1の要望を示します。 Smart-Helloは、スマートエンドノードの機能とパラメータ（MACアドレス、データラベルなど）を通知するために使用されます。 Smart-HelloはTRILL ES-IS PDUの一種であり、[RFC8171]のセクション5で指定されています。スマートエンドノードのSmart-Helloの詳細な内容は、セクション4で定義されています。
If RB1 supports having a Smart Endnode neighbor, it also sends Smart-Hellos. The Smart Endnode learns from RB1's Smart-Hellos what RB1's nickname is and which trees RB1 can use when RB1 ingresses multi-destination frames. Although Smart Endnode SE1 transmits Smart-Hellos, it does not transmit or receive Link State PDUs (LSPs) or Extended Level 1 Flooding Scope (E-L1FS) FS LSPs [RFC7780].
RB1がスマートエンドノードネイバーのサポートをサポートしている場合、RB1はSmart-Helloも送信します。スマートエンドノードは、RB1のSmart-Helloから、RB1のニックネームと、RB1が複数の宛先フレームに入るときにRB1が使用できるツリーを学習します。スマートエンドノードSE1はSmart-Helloを送信しますが、リンクステートPDU（LSP）または拡張レベル1フラッディングスコープ（E-L1FS）FS LSP [RFC7780]を送受信しません。
Since a Smart Endnode can encapsulate TRILL Data packets, it can cause the Inner.Label to be a Fine-Grained Label [RFC7172]; thus, this method supports FGL-aware endnodes. When and how a Smart Endnode decides to use the FGL instead of VLANs to encapsulate the TRILL Data packet is out of scope in this document.
スマートエンドノードはTRILLデータパケットをカプセル化できるため、Inner.Labelを細かいラベルにすることができます[RFC7172]。したがって、このメソッドはFGL対応のエンドノードをサポートします。スマートエンドノードがVLANではなくFGLを使用してTRILLデータパケットをカプセル化する場合とその方法は、このドキュメントの範囲外です。
The subsections below describe Smart-Hello messages.
以下のサブセクションでは、Smart-Helloメッセージについて説明します。
Although a Smart Endnode is not an RBridge, does not send LSPs or maintain a copy of the link state database, and does not perform routing calculations, it is required to have a "Hello" mechanism (1) to announce to edge RBridges that it is a Smart Endnode and (2) to tell them what MAC addresses it is handling in what Data Labels. Similarly, an edge RBridge that supports Smart Endnodes needs a message (1) to announce that support, (2) to inform Smart Endnodes what nickname to use for ingress and what nickname(s) can be used as egress nickname in a multi-destination TRILL Data packet, and (3) the list of Smart Endnodes it knows about on that link.
スマートエンドノードはRBridgeではなく、LSPを送信したり、リンク状態データベースのコピーを維持したりせず、ルーティング計算を実行しませんが、エッジRBridgeにそれを通知する「Hello」メカニズム（1）が必要です。はスマートエンドノードであり、（2）どのMACアドレスがどのデータラベルで処理されているかを通知します。同様に、スマートエンドノードをサポートするエッジRBridgeには、（1）そのサポートを通知するメッセージ、（2）スマートエンドノードに、入力に使用するニックネーム、および複数の宛先で出力ニックネームとして使用できるニックネームを通知するメッセージが必要です。 TRILLデータパケット、および（3）そのリンク上で認識されているスマートエンドノードのリスト。
The messages sent by Smart Endnodes and by edge RBridges that support Smart Endnodes are called "Smart-Hellos". The Smart-Hello is a type of TRILL ES-IS PDU, which is specified in [RFC8171].
スマートエンドノードおよびスマートエンドノードをサポートするエッジRBridgeによって送信されるメッセージは、「Smart-Hello」と呼ばれます。 Smart-Helloは、[RFC8171]で指定されているTRILL ES-IS PDUの一種です。
The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes and for Smart-Hellos sent by edge RBridges, consists of TRILL IS-IS TLVs as described in the following two subsections. The non-extended format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 8-bit size and type field. Both types of Smart-Hellos MUST include a Smart-Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
スマートエンドノードによって送信されるスマートHelloと、エッジRBridgeによって送信されるスマートHelloの両方のSmart-Helloペイロードは、次の2つのサブセクションで説明するように、TRILL IS-IS TLVで構成されます。非拡張フォーマットが使用されるため、TLV、サブTLV、およびAPPサブTLVには、8ビットのサイズとタイプのフィールドがあります。両方のタイプのSmart-Helloには、TRILL GENINFO TLV内に次のようにSmart-Parameters APPsub-TLVを含める必要があります。
+-+-+-+-+-+-+-+-+-
|Smart-Parameters| (1 byte)
+-+-+-+-+-+-+-+-+-
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Holding Time | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Smart-Parameters APPsub-TLV
図2：スマートパラメータAPPsub-TLV
o Type: APPsub-TLV type Smart-Parameters, value is 22.
o タイプ：APPsub-TLVタイプSmart-Parameters、値は22です。
o Length: 4.
o 長さ：4。
o Holding Time: A time in seconds as an unsigned integer. It has the same meaning as the Holding Time field in IS-IS Hellos [IS-IS]. A Smart Endnode and an edge RBridge supporting Smart Endnodes MUST send a Smart-Hello at least three times during their Holding Time. If no Smart-Hellos are received from a Smart Endnode or edge RBridge within the most recent Holding Time it sent, it is assumed that it is no longer available.
o 保持時間：符号なし整数としての秒単位の時間。 IS-IS Hellos [IS-IS]の[Holding Time]フィールドと同じ意味です。スマートエンドノードとスマートエンドノードをサポートするエッジRBridgeは、保持時間中に少なくとも3回Smart-Helloを送信する必要があります。送信した最新の保持時間内にスマートエンドノードまたはエッジRBridgeからSmart-Helloが受信されない場合、それはもう使用できないと見なされます。
o Flags: At this time, all of the Flags are reserved and MUST be sent as zero and ignored on receipt.
o フラグ：現時点では、すべてのフラグが予約されており、ゼロとして送信し、受信時に無視する必要があります。
o If more than one Smart-Parameters APPsub-TLV appears in a Smart-Hello, the first one is used and any following ones are ignored. If no Smart-Parameters APPsub-TLVs appear in a Smart-Hello, that Smart-Hello is ignored.
o Smart-Helloに複数のSmart-Parameters APPsub-TLVが表示された場合、最初のものが使用され、後続のものはすべて無視されます。 Smart-HelloにSmart-Parameters APPsub-TLVが表示されない場合、そのSmart-Helloは無視されます。
The edge RBridge's Smart-Hello contains the following information in addition to the Smart-Parameters APPsub-TLV:
エッジRBridgeのSmart-Helloには、Smart-Parameters APPsub-TLVに加えて、次の情報が含まれています。
o RBridge's nickname. The nickname sub-TLV, specified in Section 2.3.2 in [RFC7176], is reused here carried inside a TLV 242 (IS-IS router capability) in a Smart-Hello frame. If more than one nickname appears in the Smart-Hello, the first one is used and the following ones are ignored.
o RBridgeのニックネーム。 [RFC7176]のセクション2.3.2で指定されているニックネームサブTLVは、Smart-HelloフレームのTLV 242（IS-ISルーター機能）内で運ばれて再利用されます。 Smart-Helloに複数のニックネームがある場合、最初のニックネームが使用され、次のニックネームは無視されます。
o Trees that RB1 can use when ingressing multi-destination frames. The Tree Identifiers sub-TLV, specified in Section 2.3.4 in [RFC7176], is reused here.
o RB1が複数の宛先フレームに入るときに使用できるツリー。 [RFC7176]のセクション2.3.4で指定されているツリー識別子サブTLVは、ここで再利用されます。
o Smart Endnode neighbor list. The TRILL Neighbor TLV, specified in section 2.5 in [RFC7176], is reused for this purpose.
o スマートエンドノードネイバーリスト。 [RFC7176]のセクション2.5で指定されているTRILLネイバーTLVは、この目的で再利用されます。
o An Authentication TLV MAY also be included.
o 認証TLVも含めることができます。
A new APPsub-TLV (Smart-MAC TLV) for use by Smart Endnodes is as defined below. In addition, there will be a Smart-Parameters APPsub-TLV and there MAY be an Authentication TLV in a Smart Endnode Smart-Hello.
スマートエンドノードで使用する新しいAPPsub-TLV（Smart-MAC TLV）は、次のように定義されています。さらに、Smart-Parameters APPsub-TLVがあり、Smart Endnode Smart-Helloに認証TLVがある場合があります。
If there are several VLANs/FGL Data Labels for that Smart Endnode, the Smart-MAC APPsub-TLV is included several times in the Smart Endnode's Smart-Hello. This APPsub-TLV appears inside a TRILL GENINFO TLV.
そのスマートエンドノードに複数のVLAN / FGLデータラベルがある場合、Smart-MAC APPsub-TLVはスマートエンドノードのSmart-Helloに数回含まれます。このAPPsub-TLVはTRILL GENINFO TLV内に表示されます。
+-+-+-+-+-+-+-+-+
|Type=Smart-MAC | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|M| RSV | VLAN/FGL Data Label | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Smart-MAC APPsub-TLV
図3：Smart-MAC APPsub-TLV
o Type: TRILL APPsub-TLV Type Smart-MAC, value is 23.
o タイプ：TRILL APPsub-TLVタイプSmart-MAC、値は23。
o Length: Total number of bytes contained in the value field of the TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label fields and six times the number of MAC addresses present. So, if there are n MAC addresses, this is 4+6*n.
o 長さ：TLVの値フィールドに含まれる合計バイト数、つまりF / M / RSV / FGLデータラベルフィールドの長さと、存在するMACアドレスの数の6倍の合計。したがって、n個のMACアドレスがある場合、これは4 + 6 * nです。
o F: 1 bit. If it is set to 1, it indicates that the endnode supports FGL Data Labels [RFC7172], and that this Smart-MAC APPsub-TLV has an FGL in the following VLAN/FGL field. Otherwise, the VLAN/FGL Data Label field is a VLAN ID. (See below for the format of the VLAN/FGL Data Label field).
o F：1ビット。 1に設定されている場合、これはエンドノードがFGLデータラベル[RFC7172]をサポートし、このSmart-MAC APPsub-TLVが次のVLAN / FGLフィールドにFGLを持っていることを示します。それ以外の場合、VLAN / FGLデータラベルフィールドはVLAN IDです。 （VLAN / FGLデータラベルフィールドの形式については、以下を参照してください）。
o M: 1 bit. If it is set to 1, it indicates multihoming (see Section 6). If it is set to 0, it indicates that the Smart Endnodes are not using multihoming.
o M：1ビット。 1に設定されている場合、マルチホーミングを示します（セクション6を参照）。 0に設定されている場合は、スマートエンドノードがマルチホーミングを使用していないことを示しています。
o RSV: 6 bits; reserved for the future use.
o RSV：6ビット;将来の使用のために予約されています。
o VLAN/FGL Data Label: 24 bits. If F is 1, this field is a 24-bit FGL Data Label for all subsequent MAC addresses in this APPsub-TLV. Otherwise, if F is 0, the lower 12 bits are the VLAN of all subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits are not used (sent as zero and ignored on receipt). If there is no VLAN/FGL Data Label specified, the VLAN/FGL Data Label is zero.
o VLAN / FGLデータラベル：24ビット。 Fが1の場合、このフィールドは、このAPPsub-TLVの後続のすべてのMACアドレスの24ビットFGLデータラベルです。それ以外の場合、Fが0の場合、下位12ビットはこのAPPsub-TLVの後続のすべてのMACアドレスのVLANであり、上位12ビットは使用されません（ゼロとして送信され、受信時に無視されます）。 VLAN / FGLデータラベルが指定されていない場合、VLAN / FGLデータラベルはゼロです。
o MAC(i): This is a 48-bit MAC address reachable in the Data Label sent by the Smart Endnode that is announcing this APPsub-TLV.
o MAC（i）：これは、このAPPsub-TLVを通知するスマートエンドノードによって送信されたデータラベルで到達可能な48ビットMACアドレスです。
The subsections below specify the processing of Smart Endnode data packets. All TRILL Data packets sent to or from Smart Endnodes are sent in the Designated VLAN [RFC6325] of the local link but do not necessarily have to be VLAN tagged.
以下のサブセクションでは、スマートエンドノードデータパケットの処理を指定します。スマートエンドノードとの間で送受信されるすべてのTRILLデータパケットは、ローカルリンクの指定VLAN [RFC6325]で送信されますが、必ずしもVLANタグを付ける必要はありません。
A Smart Endnode does not issue or receive LSPs or E-L1FS FS LSPs or calculate topology. It does the following:
スマートエンドノードは、LSPまたはE-L1FS FS LSPを発行または受信したり、トポロジを計算したりしません。次のことを行います。
o A Smart Endnode maintains an endnode table of (the MAC address of remote endnode, Data Label, the nickname of the edge RBridge's attached) entries of end nodes with which the Smart Endnode is communicating. Entries in this table are populated the same way that an edge RBridge populates the entries in its table:
o スマートエンドノードは、スマートエンドノードが通信しているエンドノードの（リモートエンドノードのMACアドレス、データラベル、接続されているエッジRBridgeのニックネーム）エントリのエンドノードテーブルを保持します。このテーブルのエントリは、エッジRBridgeがそのテーブルのエントリに入力するのと同じ方法で入力されます。
* learning from (source MAC address ingress nickname) on packets it decapsulates.
* カプセル化を解除したパケットの（送信元MACアドレス入力ニックネーム）から学習します。
* by querying a directory [RFC7067].
* ディレクトリを照会することにより[RFC7067]。
* by having some entries configured.
* いくつかのエントリを構成する。
o When Smart Endnode SE1 wishes to send unicast frame to remote node D, if the (MAC address of remote endnode D, Data Label, nickname) entry is in SE1's endnode table, SE1 encapsulates the ingress nickname as the nickname of the RBridge (RB1), egress nickname as indicated in D's table entry. If D is unknown, SE1 either queries a directory or encapsulates the packet as a multi-destination frame, using one of the trees that RB1 has specified in RB1's Smart-Hello. The mechanism for querying a directory is given in [RFC8171].
o スマートエンドノードSE1がユニキャストフレームをリモートノードDに送信する場合、（リモートエンドノードDのMACアドレス、データラベル、ニックネーム）エントリがSE1のエンドノードテーブルにある場合、SE1は入力ニックネームをRBridge（RB1）のニックネームとしてカプセル化します。 、Dのテーブルエントリに示されている下りニックネーム。 Dが不明の場合、SE1は、RB1のSmart-HelloでRB1が指定したツリーの1つを使用して、ディレクトリを照会するか、パケットをマルチ宛先フレームとしてカプセル化します。ディレクトリを問い合わせるためのメカニズムは[RFC8171]で与えられます。
o When SE1 wishes to send a Broadcast, Unknown Unicast, and Multicast (BUM) packet to the TRILL campus, SE1 encapsulates the packet using one of the trees that RB1 has specified.
o SE1がブロードキャスト、不明なユニキャスト、およびマルチキャスト（BUM）パケットをTRILLキャンパスに送信する場合、RB1が指定したツリーの1つを使用してパケットをカプセル化します。
If the Smart Endnode SE1 sends a multi-destination TRILL Data packet, the destination MAC of the outer Ethernet is the All-RBridges multicast address.
スマートエンドノードSE1が複数の宛先のTRILLデータパケットを送信する場合、外部イーサネットの宛先MACはAll-RBridgesマルチキャストアドレスです。
The Smart Endnode SE1 need not send Smart-Hellos as frequently as normal RBridges. These Smart-Hellos could be periodically unicast to the Appointed Forwarder RB1. In case RB1 crashes and restarts, or the DRB changes and SE1 receives the Smart-Hello without mentioning SE1, SE1 SHOULD send a Smart-Hello immediately. If RB1 is Appointed Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in its Smart-Hellos as a Smart Endnode neighbor.
スマートエンドノードSE1は、通常のRBridgeほど頻繁にSmart-Helloを送信する必要はありません。これらのSmart-Helloは、Appointed Forwarder RB1に定期的にユニキャストできます。 RB1がクラッシュして再起動する場合、またはDRBが変更され、SE1がSE1に言及せずにSmart-Helloを受信した場合、SE1はただちにSmart-Helloを送信する必要があります。 RB1が、SE1が要求するVLANのいずれかに対してAppointed Forwarderである場合、RB1はSE1をSmart-Helloにスマートエンドノードネイバーとしてリストする必要があります。
The attached edge RBridge processes and forwards TRILL Data packets based on the endnode property rather than for encapsulation and forwarding the native frames the same way as the traditional RBridges. There are several situations for the edge RBridges as follows:
アタッチされたエッジRBridgeは、従来のRBridgeと同じ方法でネイティブフレームをカプセル化して転送するのではなく、endnodeプロパティに基づいてTRILLデータパケットを処理して転送します。次のように、エッジRBridgeにはいくつかの状況があります。
o If receiving an encapsulated unicast TRILL Data packet from a port with a Smart Endnode, with RB1's nickname as ingress, the edge RBridge RB1 forwards the frame to the specified egress nickname, as with any encapsulated frame. However, RB1 SHOULD filter the encapsulation frame based on the inner source MAC and Data Label as specified for the Smart Endnode. If the MAC (or Data Label) is not among the expected entries of the Smart Endnode, the frame would be dropped by the edge RBridge. If the edge RBridge does not perform this check, it makes it easier for a rogue end station to inject bogus TRILL Data packets into the TRILL campus.
o スマートエンドノードのポートからカプセル化されたユニキャストTRILLデータパケットを受信し、RB1のニックネームを入力として使用すると、エッジRBridge RB1は、カプセル化されたフレームと同様に、指定された出力ニックネームにフレームを転送します。ただし、RB1は、スマートエンドノードに指定されている内部ソースMACおよびデータラベルに基づいてカプセル化フレームをフィルタリングする必要があります（SHOULD）。 MAC（またはデータラベル）がスマートエンドノードの予想されるエントリの中にない場合、フレームはエッジRBridgeによってドロップされます。エッジRBridgeがこのチェックを実行しない場合、不正なエンドステーションが偽のTRILLデータパケットをTRILLキャンパスに挿入することが容易になります。
o If receiving a unicast TRILL Data packet with RB1's nickname as egress from the TRILL campus, and the destination MAC address in the enclosed packet is a MAC address that has been listed by a Smart Endnode, RB1 leaves the packet encapsulated to that Smart Endnode. The outer Ethernet destination MAC is the destination Smart Endnode's MAC address, the inner destination MAC address is either the Smart Endnode's MAC address or some other MAC address that the Smart Endnode advertised in its Smart Hello, and the outer Ethernet source MAC address is the RB1's port MAC address. The edge RBridge still decreases the Hop count value by 1, for there is one hop between the RB1 and Smart Endnode.
o TRILLキャンパスからの出力としてRB1のニックネームを持つユニキャストTRILLデータパケットを受信し、同封されたパケットの宛先MACアドレスがスマートエンドノードによってリストされているMACアドレスである場合、RB1はパケットをカプセル化してそのスマートエンドノードに残します。外部イーサネット宛先MACは宛先スマートエンドノードのMACアドレスであり、内部宛先MACアドレスはスマートエンドノードのMACアドレスまたはスマートエンドノードがSmart Helloでアドバタイズしたその他のMACアドレスであり、外部イーサネット送信元MACアドレスはRB1ですポートのMACアドレス。 RB1とスマートエンドノードの間にホップが1つあるため、エッジRBridgeは依然としてホップカウント値を1減らします。
o If receiving a multi-destination TRILL Data packet from a port with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation to the TRILL campus based on the distribution tree indicated by the egress nickname. If the egress nickname does not correspond to a distribution tree, the packet is discarded. If there are any normal endnodes (i.e., endnodes that are not Smart Endnodes) attached to the edge RBridge RB1, RB1 decapsulates the frame and sends the native frame to these ports possibly pruned based on multicast listeners, in addition to forwarding the multi-destination TRILL frame to the rest of the campus.
o スマートエンドノードのあるポートから複数の宛先のTRILLデータパケットを受信した場合、RBridge RB1は、出口ニックネームで示される配布ツリーに基づいて、TRILLカプセル化をTRILLキャンパスに転送します。出力ニックネームが配布ツリーに対応していない場合、パケットは破棄されます。エッジRBridge RB1に接続されている通常のエンドノード（つまり、スマートエンドノードではないエンドノード）がある場合、RB1はフレームをカプセル化解除し、マルチキャストリスナーに基づいてプルーニングされたこれらのポートにネイティブフレームを送信するほか、マルチ宛先を転送しますキャンパスの残りの部分へのTRILLフレーム。
o If RB1 receives a native multi-destination data frame, which is sent by an endnode that is not a Smart Endnode, from a port, including hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), RB1 will encapsulate it as multi-destination TRILL Data packet, and send the encapsulated multi-destination TRILL Data packet out that same port to the Smart Endnodes attached to the port, and also send the encapsulated multi-destination TRILL Data packet to the TRILL campus through other ports.
o RB1が、スマートエンドノードではないエンドノードによって送信されたネイティブマルチ宛先データフレームを、ハイブリッドエンドノード（スマートエンドノードとスマートエンドノードではないエンドノード）を含むポートから受信すると、マルチエンドとしてカプセル化されます。宛先TRILLデータパケット、およびカプセル化された複数宛先TRILLデータパケットを同じポートからポートに接続されたスマートエンドノードに送信し、カプセル化された複数宛先TRILLデータパケットを他のポートを介してTRILLキャンパスに送信します。
o If RB1 receives a multi-destination TRILL Data packet from a remote RBridge, and the exit port includes hybrid endnodes (Smart Endnodes and endnodes that are not Smart Endnodes), it sends two copies of multicast frames out the port, one as native and the other as a TRILL-encapsulated frame. When a Smart Endnode receives a multi-destination TRILL Data packet, it learns the remote (MAC address, Data Label, nickname) entry. A Smart Endnode ignores native data frames. A normal (non-Smart) endnode receives the native frame and learns the remote MAC address and ignores the TRILL Data packet. This transit solution may bring some complexity for the edge RBridge and waste network bandwidth resource, so avoiding the hybrid endnodes scenario by attaching the endnodes that are Smart and non-Smart to different ports is RECOMMENDED.
o RB1がリモートRBridgeからマルチ宛先TRILLデータパケットを受信し、出口ポートにハイブリッドエンドノード（スマートエンドノードとスマートエンドノードではないエンドノード）が含まれている場合、マルチキャストフレームの2つのコピーをポートから送信します。その他はTRILLカプセル化フレームです。スマートエンドノードが複数の宛先のTRILLデータパケットを受信すると、リモート（MACアドレス、データラベル、ニックネーム）エントリを学習します。スマートエンドノードは、ネイティブデータフレームを無視します。通常の（非スマート）エンドノードはネイティブフレームを受信し、リモートMACアドレスを学習し、TRILLデータパケットを無視します。このトランジットソリューションは、エッジRBridgeに複雑さをもたらし、ネットワーク帯域幅リソースを浪費する可能性があるため、スマートおよび非スマートのエンドノードを異なるポートに接続することにより、ハイブリッドエンドノードシナリオを回避することをお勧めします。
Multihoming is a common scenario for the Smart Endnode. The Smart Endnode is on a link attached to the TRILL domain in two places: edge RBridges RB1 and RB2. Take Figure 4 as an example. The Smart Endnode SE1 is attached to the TRILL domain by RB1 and RB2 separately. Both RB1 and RB2 could announce their nicknames to SE1.
マルチホーミングは、スマートエンドノードの一般的なシナリオです。スマートエンドノードは、2つの場所でTRILLドメインに接続されたリンク上にあります：エッジRBridges RB1およびRB2。例として図4を見てください。スマートエンドノードSE1は、RB1およびRB2によって個別にTRILLドメインに接続されます。 RB1とRB2はどちらも、ニックネームをSE1にアナウンスできます。
. .....................
. +------+ .
. | RB1 | .
. /+------+ .
+----------+ ./ +-----+ . +----------+
|SE1(Smart |/. | RB3 |......| Smart |
| Endnode1)| .\ +-----+ . | Endnode2 |
+----------+ . \ . +----------+
. +-----+ .
. | RB2 | TRILL .
. +-----+ Domain .
.......................
Figure 4: Multihoming Scenario
図4：マルチホーミングシナリオ
Smart Endnode SE1 can choose either the nickname of RB1 or RB2 when encapsulating and forwarding a TRILL Data packet. If the active-active load balance is considered for the multihoming scenario, the
スマートエンドノードSE1は、TRILLデータパケットをカプセル化して転送するときに、RB1またはRB2のニックネームを選択できます。アクティブ/アクティブロードバランスがマルチホーミングシナリオで考慮される場合、
Smart Endnode SE1 could use both the nickname of RB1 and RB2 to encapsulate and forward TRILL Data packet. SE1 uses RB1's nickname when forwarding through RB1 and RB2's nickname when forwarding through RB2. This will cause MAC flip-flopping (see [RFC7379]) of the endnode table entry in the remote RBridges (or Smart Endnodes). The solution for the MAC flip-flopping issue is to set a multihoming bit in the RSV field of the TRILL Data packet. When remote RBridge RB3 or Smart Endnodes receive a data packet with the multihomed bit set, the endnode entries (SE1's MAC address, label, RB1's nickname) and (SE1's MAC address, label, RB2's nickname) will coexist as endnode entries in the remote RBridge. (An alternative solution would be to use the ESADI protocol to distribute multiple attachments of a MAC address of a multihoming group. The ESADI is deployed among the edge RBridges (see Section 5.3 of [RFC7357]).
スマートエンドノードSE1は、RB1とRB2の両方のニックネームを使用して、TRILLデータパケットをカプセル化して転送できます。 SE1は、RB1を介して転送するときにRB1のニックネームを使用し、RB2を介して転送するときにRB2のニックネームを使用します。これにより、リモートRBridges（またはスマートエンドノード）のエンドノードテーブルエントリのMACフリップフロップ（[RFC7379]を参照）が発生します。 MACフリップフロップ問題の解決策は、TRILLデータパケットのRSVフィールドにマルチホーミングビットを設定することです。リモートRBridge RB3またはスマートエンドノードがマルチホームビットが設定されたデータパケットを受信すると、エンドノードエントリ（SE1のMACアドレス、ラベル、RB1のニックネーム）と（SE1のMACアドレス、ラベル、RB2のニックネーム）がリモートRBridgeのエンドノードエントリとして共存します。 。 （別の解決策は、ESADIプロトコルを使用して、マルチホーミンググループのMACアドレスの複数のアタッチメントを配布することです。ESADIはエッジRBridge間にデプロイされます（[RFC7357]のセクション5.3を参照）。
Smart-Hellos can be secured by using Authentication TLVs based on [RFC5310]. If they are not secured, then it is easier for a rogue end station that does not posses the required keying material to be falsely recognized as a valid Smart Endnode.
Smart-Helloは、[RFC5310]に基づく認証TLVを使用して保護できます。それらが保護されていない場合は、必要なキー情報を所有していない不正なエンドステーションが有効なスマートエンドノードとして誤って認識されやすくなります。
For general TRILL Security Considerations, see [RFC6325]. As stated there, since end stations are connected to edge RBridge ports by Ethernet, those ports MAY require end stations to authenticate themselves using [IEEE802.1X] and authenticate and encrypt traffic to/from the RBridge port with [IEEE802.1AE].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。そこに述べられているように、エンドステーションはエッジRBridgeポートにイーサネットで接続されているため、これらのポートは[IEEE802.1X]を使用してエンドステーション自体を認証し、[IEEE802.1AE]でRBridgeポートとの間のトラフィックを認証および暗号化する必要があります。
If they misbehave, Smart Endnodes can forge arbitrary ingress and egress nicknames in the TRILL headers of the TRILL Data packets they construct. Decapsulating at egress RBridges or remote Smart Endnodes that believe such a forged ingress nickname would send future traffic destined for the inner-source MAC address of the TRILL data frame to the wrong edge RBridge if data-plane learning is in use. Because of this, an RBridge port should not be configured to support Smart Endnodes unless the end stations on that link are trusted or can be adequately authenticated.
それらが誤動作する場合、スマートエンドノードは、構築するTRILLデータパケットのTRILLヘッダーで任意の入力および出力ニックネームを偽造できます。データプレーン学習が使用されている場合、偽造された入力ニックネームがTRILLデータフレームの内部送信元MACアドレス宛ての将来のトラフィックを誤ったエッジRBridgeに送信すると考えられる出力RBridgeまたはリモートスマートエンドノードでカプセル化を解除します。このため、そのリンク上のエンドステーションが信頼されているか、適切に認証されない限り、スマートエンドノードをサポートするようにRBridgeポートを構成しないでください。
As with any end station, Smart Endnodes can forge the outer MAC addresses of packets they send (see Section 6 of [RFC6325].) Because they encapsulate TRILL Data packets, they can also forge inner MAC addresses. The encapsulation performed by Smart Endnodes also means they can send data in any Data Label, which means they must be trusted in order to enforce a security policy based on Data Labels.
エンドステーションと同様に、スマートエンドノードは送信するパケットの外部MACアドレスを偽造できます（[RFC6325]のセクション6を参照）。TRILLデータパケットをカプセル化するため、内部MACアドレスを偽造することもできます。スマートエンドノードによって実行されるカプセル化は、任意のデータラベルでデータを送信できることも意味します。つまり、データラベルに基づいてセキュリティポリシーを実施するには信頼できる必要があります。
The TRILL-Hello is a type of TRILL ES-IS and is defined in [RFC8171]. Receiving and processing TRILL-Hello for RBridges and Smart Endnodes would not bring more security and vulnerability issues than the TRILL ES-IS security defined in [RFC8171].
TRILL-HelloはTRILL ES-ISの一種であり、[RFC8171]で定義されています。 RBridgesとSmart EndnodesのTRILL-Helloを受信して処理しても、[RFC8171]で定義されているTRILL ES-ISセキュリティよりも多くのセキュリティと脆弱性の問題は発生しません。
For added security against the compromise of data due to its misdelivery for any reason, including the above, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station.
上記を含む、何らかの理由による誤配信によるデータの侵害に対する追加のセキュリティのために、エンドツーエンドの暗号化と認証を検討する必要があります。つまり、ソースエンドステーションから宛先エンドステーションへの暗号化と認証です。
The mechanism described in this document requires Smart Endnodes to be aware of the MAC address(es) of the TRILL edge RBridge(s) to which they are attached and the egress RBridge nickname from which the destination of the packets is reachable. With that information, Smart Endnodes can learn a substantial amount about the topology of the TRILL domain. Therefore, there could be a potential security risk when the Smart Endnodes are not trusted or are compromised.
このドキュメントで説明するメカニズムでは、スマートエンドノードが、それらが接続されているTRILLエッジRBridgeのMACアドレスと、パケットの宛先に到達できる出口RBridgeニックネームを認識する必要があります。その情報があれば、スマートエンドノードはTRILLドメインのトポロジについてかなりの量を学ぶことができます。したがって、スマートエンドノードが信頼されていない、または侵害されている場合、潜在的なセキュリティリスクが存在する可能性があります。
IANA has allocated APPsub-TLV type numbers for the Smart-MAC and Smart-Parameters APPsub-TLVs. The "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry has been updated as follows.
IANAは、Smart-MACおよびSmart-Parameters APPsub-TLVにAPPsub-TLVタイプ番号を割り当てました。 「IS-IS TLV 251アプリケーションID 1でのTRILL APPsub-TLVタイプ」レジストリが次のように更新されました。
+-----------+-------------------+------------+
| Protocol | Description | Reference |
+-----------+-------------------+------------+
| 22 | Smart-Parameters | RFC 8384 |
| 23 | Smart-MAC | RFC 8384 |
+-----------+-------------------+------------+
Table 1
表1
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[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, <https://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月、<https://www.rfc-editor.org/info/rfc5310>。
[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, <https://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、<https://www.rfc-editor.org/info/rfc6325>。
[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, <https://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月、<https://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, <https://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月、<https://www.rfc-editor.org/info/rfc7176>。
[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, <https://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月、<https://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, <https://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月、<https://www.rfc-editor.org/info/rfc7780>。
[RFC8171] Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms", RFC 8171, DOI 10.17487/RFC8171, June 2017, <https://www.rfc-editor.org/info/rfc8171>.
[RFC8171] Eastlake 3rd、D.、Dunbar、L.、Perlman、R。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：エッジディレクトリアシスタンスメカニズム」、RFC 8171、DOI 10.17487 / RFC8171、6月2017、<https://www.rfc-editor.org/info/rfc8171>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[IEEE802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE 802.1AE.
[IEEE802.1AE] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Media Access Control（MAC）Security」、IEEE 802.1AE。
[IEEE802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks -- Port-Based Network Access Control", IEEE 802.1X.
[IEEE802.1X] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control」、IEEE 802.1X。
[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, <https://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月、<https： //www.rfc-editor.org/info/rfc7067>。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <https://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントと、リンクの透過的な相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標"、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<https://www.rfc-editor.org/info/rfc7379>。
Acknowledgements
謝辞
The contributions of the following persons are gratefully acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya Krupakaran, and Andrew Qu.
Mingui Zhang、Weiguo Hao、Linda Dunbar、Kesava Vijaya Krupakaran、Andrew Quの各氏の貢献に感謝いたします。
Authors' Addresses
著者のアドレス
Radia Perlman Dell EMC 176 South Street Hopkinton, MA 01748 United States of America
Radia Perlman Dell EMC 176 South Street Hopkinton、MA 01748アメリカ合衆国
Phone: +1-206-291-367
Email: radiaperlman@gmail.com
Fangwei Hu ZTE Corporation No.889 Bibo Rd Shanghai 201203 China
ファンGはhu ZT E社no.889 BI Bord上海201203中国
Phone: +86 21 68896273
Email: hu.fangwei@zte.com.cn
Donald Eastlake Huawei Technologies 1424 Pro Shop Court Davenport, FL 33896 United States of America
Donald Eastlake Huawei Technologies 1424 Pro Shop Court Davenport、FL 33896アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Ting Liao Huawei Technologies Nanjing, Jiangsu 210012 China
ting Liao hu AはテクノロジーNaN京、江蘇省210012中国
Email: liaoting1@huawei.com