[要約] RFC 7781は、TRILL（Transparent Interconnection of Lots of Links）におけるActive-Active Accessのための疑似ニックネームに関するものである。このRFCの目的は、TRILLネットワークにおいてActive-Activeアクセスをサポートするための疑似ニックネームの仕組みを提案することである。
Internet Engineering Task Force (IETF) H. Zhai
Request for Comments: 7781 JIT
Category: Standards Track T. Senevirathne
ISSN: 2070-1721 Consultant
R. Perlman
EMC
M. Zhang
Y. Li
Huawei Technologies
February 2016
Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access
多数のリンクの透過的な相互接続（TRILL）：アクティブ/アクティブアクセスの疑似ニックネーム
Abstract
概要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edge RBridge (Routing Bridge, or TRILL switch) group providing active-active access to such an end station is represented as a virtual RBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active-active access by such end stations.
IETF TRILL（多数のリンクの透過的相互接続）プロトコルは、任意のトポロジーを持つネットワーク内のユニキャストおよびマルチ宛先トラフィックの両方に対してフローレベルのマルチパスをサポートします。 TRILLエッジでのアクティブ-アクティブアクセスは、RFC 7379で説明されているように、TRILLキャンパスに複数接続されている端末にこれらの特性を拡張したものです。このドキュメントでは、アクティブなこのような端末へのアクティブなアクセスは、仮想RBridgeとして表されます。このドキュメントでは、仮想RBridgeの概念とその疑似ニックネームに基づいて、そのような端末によるTRILLアクティブ/アクティブアクセスの方法を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7781.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7781で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology and Acronyms ...................................6
2. Overview ........................................................7
3. Virtual RBridge and Its Pseudo-Nickname .........................9
4. Auto-Discovery of Member RBridges ..............................10
4.1. Discovering Member RBridge for an RBv .....................11
4.2. Selection of Pseudo-Nickname for an RBv ...................13
5. Distribution Trees and Designated Forwarder ....................14
5.1. Different Trees for Different Member RBridges .............15
5.2. Designated Forwarder for Member RBridges ..................16
5.3. Ingress Nickname Filtering ................................18
6. TRILL Traffic Processing .......................................19
6.1. Ingressing Native Frames ..................................19
6.2. Egressing TRILL Data Packets ..............................20
6.2.1. Unicast TRILL Data Packets .........................20
6.2.2. Multi-Destination TRILL Data Packets ...............21
7. MAC Information Synchronization in Edge Group ..................22
8. Member Link Failure in an RBv ..................................23
8.1. Link Protection for Unicast Frame Egressing ...............24
9. TLV Extensions for Edge RBridge Group ..........................24
9.1. PN-LAALP-Membership APPsub-TLV ............................24
9.2. PN-RBv APPsub-TLV .........................................26
9.3. PN-MAC-RI-LAALP Boundary APPsub-TLVs ......................27
9.4. LAALP IDs .................................................29
10. OAM Packets ...................................................29
11. Configuration Consistency .....................................29
12. Security Considerations .......................................30
13. IANA Considerations ...........................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................33
Acknowledgments ...................................................34
Contributors ......................................................34
Authors' Addresses ................................................35
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] 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]は、構成なしの最適なペアワイズデータフレーム転送、一時的なループの期間中も安全な転送、およびユニキャストトラフィックとマルチキャストトラフィックの両方のマルチパスのサポートを提供します。 TRILLは、IS-IS [IS-IS] [RFC7176]リンクステートルーティングを使用し、ホップカウントを含むヘッダーを使用してトラフィックをカプセル化することにより、これを実現します。 TRILLを実装するデバイスは、RBridges（ルーティングブリッジ）またはTRILLスイッチと呼ばれます。
In the base TRILL protocol, an end node can be attached to the TRILL campus via a point-to-point link or a shared link such as a bridged LAN (Local Area Network). Although there might be more than one edge RBridge on a shared link, to avoid potential forwarding loops, one and only one of the edge RBridges is permitted to provide forwarding service for end-station traffic in each VLAN (Virtual LAN). That RBridge is referred to as the Appointed Forwarder (AF) for that VLAN on the link [RFC6325] [RFC6439]. However, in some practical deployments, to increase the access bandwidth and reliability, an end station might be multiply connected to several edge RBridges, and all of the uplinks are handled via a Local Active-Active Link Protocol (LAALP [RFC7379]) such as Multi-Chassis Link Aggregation (MC-LAG) or Distributed Resilient Network Interconnect (DRNI) [802.1AX]. In this case, it is required that traffic can be ingressed into, and egressed from, the TRILL campus by any of the RBridges for each given VLAN. These RBridges constitute an Active-Active Edge (AAE) RBridge group.
基本TRILLプロトコルでは、エンドノードをポイントツーポイントリンクまたはブリッジドLAN（ローカルエリアネットワーク）などの共有リンクを介してTRILLキャンパスに接続できます。共有リンクには複数のエッジRBridgeが存在する可能性がありますが、潜在的な転送ループを回避するために、各RBridgeの1つだけが各VLAN（仮想LAN）のエンドステーショントラフィックに転送サービスを提供することが許可されています。そのRBridgeは、リンク上のそのVLANのAppointed Forwarder（AF）と呼ばれます[RFC6325] [RFC6439]。ただし、一部の実際的な展開では、アクセス帯域幅と信頼性を高めるために、エンドステーションが複数のエッジRBridgeに複数接続され、すべてのアップリンクが次のようなローカルアクティブ-アクティブリンクプロトコル（LAALP [RFC7379]）を介して処理されます。 Multi-Chassis Link Aggregation（MC-LAG）またはDistributed Resilient Network Interconnect（DRNI）[802.1AX]。この場合、特定の各VLANのRBridgeのいずれかによって、トラフィックがTRILLキャンパスに出入りできることが必要です。これらのRBridgeは、Active-Active Edge（AAE）RBridgeグループを構成します。
With an LAALP, traffic with the same VLAN and source Media Access Control (MAC) address but belonging to different flows will frequently be sent to different member RBridges of the AAE group and then ingressed into the TRILL campus. When an egress RBridge receives such TRILL Data packets ingressed by different RBridges, it learns different correspondences between a {Data Label and MAC address} and nickname continuously when decapsulating the packets if it has data-plane address learning enabled. This issue is known as "MAC address flip-flopping"; it makes most TRILL switches behave badly and causes the returning traffic to reach the destination via different paths, resulting in persistent reordering of the frames. In addition to this issue, other issues, such as duplicate egressing and loopback of multi-destination frames, may also disturb an end station multiply connected to the member RBridges of an AAE group [RFC7379].
LAALPを使用すると、同じVLANと送信元のメディアアクセス制御（MAC）アドレスを持つが、異なるフローに属するトラフィックは、AAEグループの異なるメンバーRBridgeに頻繁に送信され、次にTRILLキャンパスに入力されます。出力RBridgeは、さまざまなRBridgeによって入力されたこのようなTRILLデータパケットを受信すると、データプレーンアドレス学習が有効になっている場合、パケットのカプセル化解除時に{データラベルとMACアドレス}とニックネームの間のさまざまな対応を継続的に学習します。この問題は「MACアドレスフリップフロップ」として知られています。ほとんどのTRILLスイッチの動作が悪くなり、戻りトラフィックが異なるパスを介して宛先に到達するため、フレームの永続的な並べ替えが発生します。この問題に加えて、複数の宛先フレームの出力とループバックの重複などの他の問題も、AAEグループのメンバーRBridgesに複数接続されている端末を妨害する可能性があります[RFC7379]。
This document addresses the AAE issues of TRILL by specifying how members of an edge RBridge group can be represented by a virtual RBridge (RBv) and assigned a pseudo-nickname. A member RBridge of such a group uses a pseudo-nickname instead of its own nickname as the ingress RBridge nickname when ingressing frames received on attached LAALP links. Other methods are possible: for example, the specification in this document and the specification in [RFC7782] could be simultaneously deployed for different AAE groups in the same campus. If the method defined in [RFC7782] is used, edge TRILL switches need to support the capability indicated by the Capability Flags APPsub-TLV as specified in Section 4.2 of [RFC7782]. If the method defined in this document is adopted, all TRILL switches need to support the Affinity sub-TLV defined in [RFC7176] and [RFC7783]. For a TRILL campus that deploys both of these AAE methods, TRILL switches are required to support both methods. However, it is desirable to only adopt one method in a TRILL campus so that the operating expense, complexity of troubleshooting, etc., can be reduced.
このドキュメントでは、エッジRBridgeグループのメンバーを仮想RBridge（RBv）で表現し、疑似ニックネームを割り当てる方法を指定することにより、TRILLのAAE問題に対処します。そのようなグループのメンバーRBridgeは、接続されているLAALPリンクで受信されたフレームを入力するときに、自身のニックネームではなく疑似ニックネームを入力RBridgeニックネームとして使用します。他の方法も可能です。たとえば、このドキュメントの仕様と[RFC7782]の仕様は、同じキャンパス内の異なるAAEグループに同時に展開できます。 [RFC7782]で定義されている方法を使用する場合、エッジTRILLスイッチは、[RFC7782]のセクション4.2で指定されている機能フラグAPPsub-TLVで示される機能をサポートする必要があります。このドキュメントで定義されている方法を採用する場合、すべてのTRILLスイッチは、[RFC7176]および[RFC7783]で定義されているAffinity sub-TLVをサポートする必要があります。これらのAAEメソッドの両方を導入するTRILLキャンパスでは、両方のメソッドをサポートするためにTRILLスイッチが必要です。ただし、運用費用やトラブルシューティングの複雑さなどを軽減できるように、TRILLキャンパスでは1つの方法のみを採用することが望ましいです。
The main body of this document is organized as follows:
このドキュメントの本文は次のように構成されています。
o Section 2 provides an overview of the TRILL active-active access issues and the reason that a virtual RBridge (RBv) is used to resolve the issues.
o セクション2では、TRILLのアクティブ/アクティブアクセスの問題の概要と、問題を解決するために仮想RBridge（RBv）が使用される理由について説明します。
o Section 3 describes the concept of a virtual RBridge (RBv) and its pseudo-nickname.
o セクション3では、仮想RBridge（RBv）の概念とその疑似ニックネームについて説明します。
o Section 4 describes how edge RBridges can support an RBv automatically and get a pseudo-nickname for the RBv.
o セクション4では、エッジRBridgeがRBvを自動的にサポートし、RBvの疑似ニックネームを取得する方法について説明します。
o Section 5 discusses how to protect multi-destination traffic against disruption due to Reverse Forwarding Path (RPF) check failure, duplication, forwarding loops, etc.
o セクション5では、Reverse Forwarding Path（RPF）チェックの失敗、重複、転送ループなどによる中断から複数の宛先のトラフィックを保護する方法について説明します。
o Section 6 covers the special processing of native frames and TRILL Data packets at member RBridges of an RBv (also referred to as an Active-Active Edge (AAE) RBridge group).
o セクション6では、RBvのメンバーRBridge（Active-Active Edge（AAE）RBridgeグループとも呼ばれる）でのネイティブフレームとTRILLデータパケットの特別な処理について説明します。
o Section 7 describes the MAC information synchronization among the member RBridges of an RBv.
o セクション7では、RBvのメンバーRBridge間のMAC情報の同期について説明します。
o Section 8 discusses protection against downlink failure at a member RBridge.
o セクション8では、メンバーRBridgeでのダウンリンク障害に対する保護について説明します。
o Section 9 lists the necessary TRILL code points and data structures for a pseudo-nickname AAE RBridge group.
o セクション9は、疑似ニックネームAAE RBridgeグループに必要なTRILLコードポイントとデータ構造を示しています。
This document uses the acronyms and terms defined in [RFC6325] and [RFC7379], as well as the following additional acronyms:
このドキュメントでは、[RFC6325]と[RFC7379]で定義されている頭字語と用語、および次の追加の頭字語を使用しています。
AAE: Active-active Edge RBridge group. A group of edge RBridges to which at least one Customer Equipment (CE) node is multiply attached with an LAALP. AAE is also referred to as "edge group" or "virtual RBridge" in this document.
AAE：Active-Active Edge RBridgeグループ。 LAALPで少なくとも1つのCustomer Equipment（CE）ノードが複数接続されているエッジRBridgeのグループ。このドキュメントでは、AAEは「エッジグループ」または「仮想RBridge」とも呼ばれます。
Campus: A TRILL network consisting of TRILL switches, links, and possibly bridges bounded by end stations and IP routers. For TRILL, there is no "academic" implication in the name "campus".
キャンパス：TRILLスイッチ、リンク、および場合によっては端末とIPルーターで囲まれたブリッジで構成されるTRILLネットワーク。 TRILLの場合、「キャンパス」という名前には「学問的」な意味合いはありません。
CE: Customer Equipment (end station or bridge). The device can be either physical or virtual equipment.
CE：カスタマー機器（エンドステーションまたはブリッジ）。デバイスは、物理装置または仮想装置のいずれかです。
Data Label: VLAN or Fine-Grained Label (FGL).
データラベル：VLANまたはファイングレインラベル（FGL）。
DF: Designated Forwarder.
DF：指定フォワーダー。
DRNI: Distributed Resilient Network Interconnect. A link aggregation specified in [802.1AX] that can provide an LAALP between (a) one, two, or three CEs and (b) two or three RBridges.
DRNI：Distributed Resilient Network Interconnect。 [a）1つ、2つ、または3つのCEと（b）2つまたは3つのRBridge間でLAALPを提供できる、[802.1AX]で指定されたリンク集約。
E-L1FS: Extended Level 1 Flooding Scope [RFC7356].
E-L1FS：拡張レベル1フラッディングスコープ[RFC7356]。
ESADI: End-Station Address Distribution Information.
ESADI：End-Station Address Distribution Information。
FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル付けまたはきめの細かいラベル付けまたはきめの細かいラベル[RFC7172]。
LAALP: Local Active-Active Link Protocol [RFC7379], e.g., MC-LAG or DRNI.
LAALP：ローカルアクティブ-アクティブリンクプロトコル[RFC7379]、たとえば、MC-LAGまたはDRNI。
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions of Link Aggregation [802.1AX] that can provide an LAALP between one CE and two or more RBridges.
MC-LAG：マルチシャーシリンク集約。 1つのCEと2つ以上のRBridge間でLAALPを提供できるリンク集約[802.1AX]の独自の拡張。
OE-flag: A flag used by a member RBridge of a given LAALP to tell other edge RBridges of this LAALP whether this LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as the given LAALP does. When this flag for an LAALP is 1, it means that the LAALP needs to be served by an RBv by itself and is not willing to share, that is, it should Occupy an RBv Exclusively (OE).
OE-flag：特定のLAALPのメンバーRBridgeがこのLAALPの他のエッジRBridgeに、このLAALPが他のLAALPとRBvを共有して、特定のLAALPが行うのと同じエッジRBridgeのセットに多重接続する意思があるかどうかを通知するために使用されるフラグ。 LAALPのこのフラグが1の場合、LAALPはRBvによって単独でサービスされる必要があり、共有する意思がないことを意味します。つまり、LAALPはRBvを排他的に占有する必要があります（OE）。
RBv: Virtual RBridge. An alias for "active-active edge RBridge group" in this document.
RBv：仮想RBridge。このドキュメントの「アクティブ-アクティブエッジRBridgeグループ」のエイリアス。
vDRB: The Designated RBridge in an RBv. It is responsible for deciding the pseudo-nickname for the RBv.
vDRB：RBv内の指定されたRBridge。 RBvの疑似ニックネームを決定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
To minimize impact during failures and maximize available access bandwidth, Customer Equipment (referred to as "CE" in this document) may be multiply connected to the TRILL campus via multiple edge RBridges.
障害時の影響を最小限に抑え、利用可能なアクセス帯域幅を最大化するために、お客様の機器（このドキュメントでは「CE」と呼ばれます）は、複数のエッジRBridgeを介してTRILLキャンパスに複数接続できます。
Figure 1 shows such a typical deployment scenario, where CE1 attaches to RB1, RB2, ... RBk and treats all of the uplinks as an LAALP bundle. RB1, RB2, ... RBk then constitute an AAE RBridge group for CE1 in this LAALP. Even if a member RBridge or an uplink fails, CE1 will still get frame forwarding service from the TRILL campus if there are still member RBridges and uplinks available in the AAE group. Furthermore, CE1 can make flow-based load balancing across the available member links of the LAALP bundle in the AAE group when it communicates with other CEs across the TRILL campus [RFC7379].
図1は、CE1がRB1、RB2、... RBkに接続し、すべてのアップリンクをLAALPバンドルとして扱う、このような典型的な導入シナリオを示しています。 RB1、RB2、... RBkは、このLAALPのCE1のAAE RBridgeグループを構成します。メンバーのRBridgeまたはアップリンクに障害が発生した場合でも、AAEグループでメンバーのRBridgeとアップリンクがまだ利用可能であれば、CE1はTRILLキャンパスからフレーム転送サービスを取得します。さらに、CE1は、TRILLキャンパス全体で他のCEと通信するときに、AAEグループ内のLAALPバンドルの利用可能なメンバーリンク全体でフローベースのロードバランシングを行うことができます[RFC7379]。
----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
+-----+ | +--------+
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1-->(| | |) (| | |) <--LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
+-------+ +-------+
Figure 1: Active-Active Connection to TRILL Edge RBridges
図1：TRILLエッジRBridgeへのアクティブ-アクティブ接続
By design, an LAALP (say LAALP1) does not forward packets received on one member port to other member ports. As a result, the TRILL Hello messages sent by one member RBridge (say RB1) via a port to CE1 will not be forwarded to other member RBridges by CE1. That is to say, member RBridges will not see each other's Hellos via the LAALP. So, every member RBridge of LAALP1 thinks of itself as Appointed Forwarder for all VLANs enabled on an LAALP1 link and can ingress/egress frames simultaneously in these VLANs [RFC6439].
設計上、LAALP（たとえばLAALP1）は、あるメンバーポートで受信したパケットを他のメンバーポートに転送しません。その結果、ポートを介して1つのメンバーRBridge（RB1など）からCE1に送信されるTRILL Helloメッセージは、CE1によって他のメンバーRBridgeに転送されません。つまり、メンバーRBridgesは、LAALPを介してお互いのHelloを参照しません。したがって、LAALP1のすべてのメンバーRBridgeは、自身をLAALP1リンクで有効になっているすべてのVLANのAppointed Forwarderと見なし、これらのVLANで同時にフレームを入力/出力できます[RFC6439]。
The simultaneous flow-based ingressing/egressing can cause some problems. For example, simultaneous egressing of multi-destination traffic by multiple member RBridges will result in frame duplication at CE1 (see Section 3.1 of [RFC7379]); simultaneous ingressing of frames originated by CE1 for different flows in the same VLAN with the same source MAC address will result in MAC address flip-flopping at remote egress RBridges that have data-plane address learning enabled (see Section 3.3 of [RFC7379]). The flip-flopping would in turn cause packet reordering in reverse traffic.
フローベースの同時イングレス/イングレスは、いくつかの問題を引き起こす可能性があります。たとえば、複数のメンバーのRBridgeによる複数の宛先トラフィックの同時出力は、CE1でフレームの重複を引き起こします（[RFC7379]のセクション3.1を参照）。同じ送信元MACアドレスを持つ同じVLAN内の異なるフローのCE1によって開始されたフレームの同時進入は、データプレーンアドレス学習が有効になっているリモート出力RBridgeでMACアドレスのフリップフロップを引き起こします（[RFC7379]のセクション3.3を参照）。次に、フリップフロップにより、逆トラフィックでパケットの並べ替えが発生します。
Edge RBridges learn correspondences between a {Data Label and MAC address} and nickname by default when decapsulating TRILL Data packets (see Section 4.8.1 of [RFC6325], as updated by [RFC7172]). Assuming that the default data-plane learning is enabled at edge RBridges, MAC address flip-flopping can be solved by using a virtual RBridge together with its pseudo-nickname. This document specifies a way to do so.
Edge RBridgeは、TRILLデータパケットのカプセル化を解除するときに、{データラベルとMACアドレス}とニックネームの間の対応をデフォルトで学習します（[RFC7172]によって更新された[RFC6325]のセクション4.8.1を参照）。デフォルトのデータプレーン学習がエッジRBridgeで有効になっていると仮定すると、仮想RBridgeとその疑似ニックネームを使用することにより、MACアドレスのフリップフロップを解決できます。このドキュメントでは、その方法を説明しています。
A virtual RBridge (RBv) represents a group of edge RBridges to which at least one CE is multiply attached using an LAALP. More precisely, it represents a group of ports on the edge RBridges providing end-station service and the service provided to the CE(s) on these ports, through which the CE(s) is multiply attached to the TRILL campus using LAALP(s). Such end-station service ports are called RBv ports; in contrast, other access ports at edge RBridges are called regular access ports in this document. RBv ports are always LAALP connecting ports, but not vice versa (see Section 4.1). For an edge RBridge, if one or more of its end-station service ports are ports of an RBv, that RBridge is a member RBridge of that RBv.
仮想RBridge（RBv）は、LAALPを使用して少なくとも1つのCEが複数接続されているエッジRBridgeのグループを表します。より正確には、エンドステーションサービスを提供するエッジRBridge上のポートのグループと、これらのポート上のCEに提供されるサービスを表します。これらのポートを通じて、CEはLAALPを使用してTRILLキャンパスに複数接続されます。 ）。このような端末のサービスポートはRBvポートと呼ばれます。対照的に、このドキュメントでは、エッジRBridgeの他のアクセスポートを通常のアクセスポートと呼びます。 RBvポートは常にLAALP接続ポートですが、その逆ではありません（セクション4.1を参照）。エッジRBridgeの場合、1つ以上のエンドステーションサービスポートがRBvのポートである場合、そのRBridgeはそのRBvのメンバーRBridgeです。
For the convenience of description, a virtual RBridge is also referred to as an Active-Active Edge (AAE) group in this document. In the TRILL campus, an RBv is identified by its pseudo-nickname, which is different from any RBridge's regular nickname(s). An RBv has one and only one pseudo-nickname. Each member RBridge (say RB1, RB2 ..., RBk) of an RBv (say RBvn) advertises RBvn's pseudo-nickname using a Nickname sub-TLV in its TRILL IS-IS LSP (Link State PDU) [RFC7176] and SHOULD do so with maximum priority of use (0xFF), along with their regular nickname(s). (Maximum priority is recommended to avoid the disruption to an AAE group that would occur if the nickname were taken away by a higher-priority RBridge.) Then, from these LSPs, other RBridges outside the AAE group know that RBvn is reachable through RB1 to RBk.
説明の便宜上、このドキュメントでは仮想RBridgeをActive-Active Edge（AAE）グループとも呼びます。 TRILLキャンパスでは、RBvはその疑似ニックネームで識別されます。これは、RBridgeの通常のニックネームとは異なります。 RBvには、疑似ニックネームが1つだけあります。 RBv（たとえばRBvn）の各メンバーRBridge（たとえばRB1、RB2 ...、RBk）は、そのTRILL IS-IS LSP（リンク状態PDU）[RFC7176]でニックネームサブTLVを使用してRBvnの疑似ニックネームをアドバタイズし、SHOULDを実行しますそのため、使用の最大優先度（0xFF）と通常のニックネームを使用します。 （ニックネームが優先度の高いRBridgeによって削除された場合に発生するAAEグループの中断を回避するために、最高の優先度が推奨されます。）次に、これらのLSPから、AAEグループ外の他のRBridgeは、RBvnを介してRBvnに到達できることを認識します。 RBk。
A member RBridge (say RBi) loses its membership in RBvn when its last port in RBvn becomes unavailable due to failure, reconfiguration, etc. RBi then removes RBvn's pseudo-nickname from its LSP and distributes the updated LSP as usual. From those updated LSPs, other RBridges know that there is no path to RBvn through RBi now.
メンバーRBridge（RBiなど）は、RBvnの最後のポートが障害や再構成などにより利用できなくなると、RBvnのメンバーシップを失います。RBiは、RBvnの疑似ニックネームをLSPから削除し、通常どおりに更新されたLSPを配布します。これらの更新されたLSPから、他のRBridgeは、RBiを介したRBvnへのパスがないことを認識しています。
When member RBridges receive native frames on their RBv ports and decide to ingress the frames into the TRILL campus, they use that RBv's pseudo-nickname instead of their own regular nicknames as the ingress nickname to encapsulate them into TRILL Data packets. So, when these packets arrive at an egress RBridge, even if they are originated by the same end station in the same VLAN but ingressed by different member RBridges, no address flip-flopping is observed on the egress RBridge when decapsulating these packets. (When a member RBridge of an AAE group ingresses a frame from a non-RBv port, it still uses its own regular nickname as the ingress nickname.)
メンバーのRBridgeは、RBvポートでネイティブフレームを受信し、フレームをTRILLキャンパスに入力することを決定すると、独自の通常のニックネームの代わりにそのRBvの疑似ニックネームを入力ニックネームとして使用して、TRILLデータパケットにカプセル化します。したがって、これらのパケットが出力RBridgeに到着すると、それらが同じVLAN内の同じエンドステーションによって発信され、異なるメンバーRBridgeによって入力された場合でも、これらのパケットのカプセル化解除時に、出力RBridgeでアドレスフリップフロップは観察されません。 （AAEグループのメンバーRBridgeが非RBvポートからフレームに入るとき、それはまだそれ自身の通常のニックネームを入力ニックネームとして使用します。）
Since an RBv is not a physical node and no TRILL frames are forwarded between its ports via an LAALP, pseudonode LSP(s) MUST NOT be created for an RBv. An RBv cannot act as a root when constructing distribution trees for multi-destination traffic, and its pseudo-nickname is ignored when determining the distribution tree root for the TRILL campus [RFC7783]. So, the tree root priority of the RBv's nickname MUST be set to 0, and this nickname MUST NOT be listed in the "s" nicknames (see Section 4.5 of [RFC6325]) by the RBridge holding the highest-priority tree root nickname.
RBvは物理ノードではなく、TRALフレームはLAALPを介してポート間で転送されないため、RBvに対して疑似ノードLSPを作成してはなりません（MUST NOT）。 RBvは、複数の宛先のトラフィックの配布ツリーを構築するときにルートとして機能することができず、TRILLキャンパスの配布ツリーのルートを決定するときにその擬似ニックネームは無視されます[RFC7783]。したがって、RBvのニックネームのツリールートの優先度は0に設定する必要があり、このニックネームは、最高の優先度のツリールートニックネームを保持するRBridgeによって「s」ニックネーム（[RFC6325]のセクション4.5を参照）にリストされてはなりません（MUST NOT）。
NOTE: In order to reduce the consumption of nicknames, especially in a large TRILL campus with lots of RBridges and/or active-active accesses, when multiple CEs attach to exactly the same set of edge RBridges via LAALPs, those edge RBridges should be considered a single RBv with a single pseudo-nickname.
注：ニックネームの消費を減らすために、特に多くのRBridgeやアクティブ-アクティブアクセスがある大規模なTRILLキャンパスでは、複数のCEがLAALPを介してまったく同じエッジRBridgeのセットに接続する場合、それらのエッジRBridgeを検討する必要があります。単一の疑似ニックネームを持つ単一のRBv。
Edge RBridges connected to a CE via an LAALP can automatically discover each other with minimal configuration through the exchange of LAALP connection information.
LAALPを介してCEに接続されたエッジRBridgeは、LAALP接続情報を交換することにより、最小限の構成で互いに自動的に検出できます。
From the perspective of edge RBridges, a CE that connects to edge RBridges via an LAALP can be identified by the ID of the LAALP that is unique across the TRILL campus (for example, the MC-LAG or DRNI System ID [802.1AX]), which is referred to as an LAALP ID in this document. On each such edge RBridge, the access port to such a CE is associated with an LAALP ID for the CE. An LAALP is considered valid on an edge RBridge only if the RBridge still has an operational downlink to that LAALP. For such an edge RBridge, it advertises a list of LAALP IDs for its valid local LAALPs to other edge RBridges via its E-L1FS FS-LSP(s) [RFC7356] [RFC7780]. Based on the LAALP IDs advertised by other RBridges, each RBridge can know which edge RBridges could constitute an AAE group (see Section 4.1 for more details). One RBridge is then elected from the group to allocate an available nickname (the pseudo-nickname) for the group (see Section 4.2 for more details).
エッジRBridgesの観点から、LAALPを介してエッジRBridgesに接続するCEは、TRILLキャンパス全体で一意のLAALPのID（たとえば、MC-LAGまたはDRNIシステムID [802.1AX]）によって識別できます。 。これは、このドキュメントではLAALP IDと呼ばれています。そのような各エッジRBridgeで、そのようなCEへのアクセスポートは、CEのLAALP IDに関連付けられます。 LAALPは、RBridgeがそのLAALPへのダウンリンクがまだ機能している場合にのみ、エッジRBridgeで有効と見なされます。そのようなエッジRBridgeの場合、有効なローカルLAALPのLAALP IDのリストを、E-L1FS FS-LSP（s）[RFC7356] [RFC7780]を介して他のエッジRBridgeにアドバタイズします。他のRBridgeによって通知されたLAALP IDに基づいて、各RBridgeは、どのエッジRBridgeがAAEグループを構成できるかを知ることができます（詳細については、セクション4.1を参照）。次に、1つのRBridgeがグループから選出され、グループに使用可能なニックネーム（疑似ニックネーム）が割り当てられます（詳細については、セクション4.2を参照）。
Take Figure 2 as an example, where CE1 and CE2 multiply attach to RB1, RB2, and RB3 via LAALP1 and LAALP2, respectively; CE3 and CE4 attach to RB3, and RB4 via LAALP3 and LAALP4, respectively. Assume that LAALP3 is configured to occupy a virtual RBridge by itself.
図2を例にとると、CE1およびCE2はそれぞれLAALP1およびLAALP2を介してRB1、RB2、およびRB3に複数接続されます。 CE3とCE4は、それぞれLAALP3とLAALP4を介してRB3とRB4に接続します。 LAALP3が仮想RBridgeを単独で占有するように構成されていると想定します。
------------------------
/ \
| TRILL Campus |
\ /
-------------------------
| | | |
+-------+ | | +----------+
| | | |
+-------+ +-------+ +-------+ +-------+
| RB1 | | RB2 | | RB3 | | RB4 |
+-------+ +-------+ +-------+ +-------+
| | | | | | | | | |
| +--------|--+ | +-------|-+ | +-------|---+ |
| +----------+ | | | | | | | |
| | +-----------|-|-|-------+ | +-------+ | |
| | | | | | | | | |
LAALP1->(| | |) LAALP2->(| | |) LAALP3->(| |) LAALP4->(| |)
+-------+ +-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 | | CE4 |
+-------+ +-------+ +-------+ +-------+
Figure 2: Different LAALPs to TRILL Campus
図2：TRILLキャンパスへのさまざまなLAALP
RB1 and RB2 advertise {LAALP1, LAALP2} in the PN-LAALP-Membership APPsub-TLV (see Section 9.1 for more details) via their TRILL E-L1FS FS-LSPs, respectively; RB3 announces {LAALP1, LAALP2, LAALP3, LAALP4}, and RB4 announces {LAALP3, LAALP4}, respectively.
RB1およびRB2は、それぞれTRILL E-L1FS FS-LSPを介してPN-LAALPメンバーシップAPPsub-TLV（詳細についてはセクション9.1を参照）で{LAALP1、LAALP2}をアドバタイズします。 RB3はそれぞれ{LAALP1、LAALP2、LAALP3、LAALP4}をアナウンスし、RB4は{LAALP3、LAALP4}をアナウンスします。
An edge RBridge is called an "LAALP related RBridge" if it has at least one LAALP configured on an access port. On receipt of the PN-LAALP-Membership APPsub-TLVs, RBn ignores them if it is not an LAALP related RBridge; otherwise, RBn SHOULD use the LAALP information contained in the sub-TLVs, along with its own PN-LAALP-Membership APPsub-TLVs, to decide which RBv(s) it should join and which edge RBridges constitute each such RBv. Based on the information received, each of the four RBridges knows the following:
エッジRBridgeは、アクセスポートで少なくとも1つのLAALPが構成されている場合、「LAALP関連RBridge」と呼ばれます。 PN-LAALP-Membership APPsub-TLVを受信すると、それがLAALP関連のRBridgeでない場合、RBnはそれらを無視します。それ以外の場合、RBnは、サブTLVに含まれるLAALP情報を、独自のPN-LAALP-Membership APPサブ-TLVとともに使用して、どのRBvに参加し、どのエッジRBridgeがそのような各RBvを構成するかを決定する必要があります。受信した情報に基づいて、4つのRBridgeはそれぞれ次のことを認識しています。
LAALP ID OE-flag Set of edge RBridges
--------- -------- ---------------------
LAALP1 0 {RB1, RB2, RB3}
LAALP2 0 {RB1, RB2, RB3}
LAALP3 1 {RB3, RB4}
LAALP4 0 {RB3, RB4}
where the OE-flag indicates whether a given LAALP is willing to share an RBv with other LAALPs that multiply attach to the same set of edge RBridges as the given LAALP does.
ここで、OEフラグは、特定のLAALPが、特定のLAALPと同じエッジRBridgeの同じセットに複数接続される他のLAALPとRBvを共有する意思があるかどうかを示します。
For an LAALP (for example, LAALP3), if its OE-flag is one, it means that LAALP3 does not want to share, so it MUST Occupy an RBv Exclusively (OE). Support of OE is optional. RBridges that do not support OE ignore the OE-flag and act as if it were zero (see Section 11 ("Configuration Consistency")).
LAALP（たとえば、LAALP3）の場合、そのOEフラグが1であれば、LAALP3は共有したくないため、RBvを排他的に占有する必要があります（OE）。 OEのサポートはオプションです。 OEをサポートしないRBridgeは、OEフラグを無視し、ゼロであるかのように動作します（セクション11（「構成の一貫性」）を参照）。
Otherwise, the LAALP (for example, LAALP1) will share an RBv with other LAALPs if possible. By default, this flag is set to zero. For an LAALP, this flag is considered 1 if any edge RBridge advertises it as (value) 1 (see Section 9.1).
それ以外の場合、LAALP（たとえば、LAALP1）は、可能であれば、RBvを他のLAALPと共有します。デフォルトでは、このフラグはゼロに設定されています。 LAALPの場合、エッジRBridgeが（値）1として通知する場合、このフラグは1と見なされます（セクション9.1を参照）。
In the above table, there might be some LAALPs that attach to a single RBridge due to misconfiguration or link failure, etc. Those LAALPs are considered to be invalid entries. Each of the LAALP related edge RBridges then performs the following algorithm to decide which valid LAALPs can be served by an RBv.
上記の表では、構成の誤りやリンク障害などのために、単一のRBridgeに接続するいくつかのLAALPがある可能性があります。これらのLAALPは無効なエントリと見なされます。次に、LAALPに関連する各エッジRBridgeは、次のアルゴリズムを実行して、RBvがサービスできる有効なLAALPを決定します。
Step 1: Take all the valid LAALPs that have their OE-flags set to 1 out of the table and create an RBv for each such LAALP.
ステップ1：OEフラグが1に設定されているすべての有効なLAALPをテーブルから取り出し、そのようなLAALPごとにRBvを作成します。
Step 2: Sort the valid LAALPs left in the table in descending order based on the number of RBridges in their associated set of multihomed RBridges. If several LAALPs have the same number of RBridges, these LAALPs are then ordered in ascending order in the proper places of the table, based on their LAALP IDs considered to be unsigned integers. (For example, in the above table, both LAALP1 and LAALP2 have three member RBridges, assuming that the LAALP1 ID is smaller than the LAALP2 ID, so LAALP1 is followed by LAALP2 in the ordered table.)
手順2：関連するマルチホームRBridgeセットのRBridgeの数に基づいて、テーブルに残っている有効なLAALPを降順で並べ替えます。複数のLAALPに同じ数のRBridgeがある場合、これらのLAALPは、符号なし整数と見なされるLAALP IDに基づいて、テーブルの適切な場所に昇順で並べられます。 （たとえば、上記の表では、LAALP1とLAALP2の両方に3つのメンバーRBridgeがあります。LAALP1IDがLAALP2 IDよりも小さいと想定されるため、順序付けされた表ではLAALP1の後にLAALP2が続きます。）
Step 3: Take the first valid LAALP (say LAALP_i) with the maximum set of RBridges, say S_i, out of the table and create a new RBv (say RBv_i) for it.
手順3：最初の有効なLAALP（たとえばLAALP_i）をRBridgeの最大セット（S_iなど）でテーブルから取り出し、新しいRBv（たとえばRBv_i）を作成します。
Step 4: Walk through the remaining valid LAALPs in the table one by one, pick up all the valid LAALPs whose sets of multi-homed RBridges contain exactly the same RBridges as that of LAALP_i, and take them out of the table. Then, appoint RBv_i as the servicing RBv for those LAALPs.
ステップ4：テーブル内の残りの有効なLAALPを1つずつ確認し、マルチホームRBridgeのセットにLAALP_iとまったく同じRBridgeが含まれているすべての有効なLAALPを取得し、それらをテーブルから取り出します。次に、それらのLAALPのサービスRBvとしてRBv_iを指定します。
Step 5: Repeat Steps 3 and 4 for any LAALPs left, until all the valid entries in the table are associated with an RBv.
ステップ5：テーブル内のすべての有効なエントリがRBvに関連付けられるまで、残りのLAALPに対してステップ3と4を繰り返します。
After performing the above steps, all the four RBridges know that LAALP3 is served by an RBv, say RBv1, which has RB3 and RB4 as member RBridges; LAALP1 and LAALP2 are served by another RBv, say RBv2, which has RB1, RB2, and RB3 as member RBridges; and LAALP4 is served by RBv3, which has RB3 and RB4 as member RBridges, shown as follows:
上記の手順を実行した後、4つのRBridgeはすべて、LAALP3がRBv、たとえばメンバーRBridgesとしてRB3とRB4を持つRBv1によって処理されることを認識します。 LAALP1とLAALP2は、メンバーRBridgesとしてRB1、RB2、およびRB3を持つ別のRBv、たとえばRBv2によって処理されます。 LAALP4は、RB3とRB4をメンバーRBridgeとして持つRBv3によって処理されます。次に例を示します。
RBv Serving LAALPs Member RBridges
----- ------------------- ---------------
RBv1 {LAALP3} {RB3, RB4}
RBv2 {LAALP1, LAALP2} {RB1, RB2, RB3}
RBv3 {LAALP4} {RB3, RB4}
In each RBv, one of the member RBridges is elected as the vDRB (referred to in this document as the Designated RBridge of the RBv). Then, this RBridge picks up an available nickname as the pseudo-nickname for the RBv and announces it to all other member RBridges of the RBv via its TRILL E-L1FS FS-LSPs (refer to Section 9.2 for the relative extended sub-TLVs).
各RBvでは、メンバーRBridgesの1つがvDRBとして選出されます（このドキュメントでは、RBvの指定RBridgeと呼ばれます）。次に、このRBridgeは、使用可能なニックネームをRBvの疑似ニックネームとして取得し、そのTRILL E-L1FS FS-LSPを介してRBvの他のすべてのメンバーRBridgeに通知します（相対拡張サブTLVについてはセクション9.2を参照） 。
As described in Section 3, in the TRILL campus, an RBv is identified by its pseudo-nickname. In an AAE group, one member RBridge is elected for the duty of selecting a pseudo-nickname for this RBv; this RBridge will be the vDRB. The winner in the group is the RBridge with the largest IS-IS System ID considered to be an unsigned integer. Then, based on its TRILL IS-IS link-state database and the potential pseudo-nickname(s) reported in the PN-LAALP-Membership APPsub-TLVs by other member RBridges of this RBv (see Section 9.1 for more details), the vDRB selects an available nickname as the pseudo-nickname for this RBv and advertises it to the other RBridges via its E-L1FS FS-LSP(s) (see Section 9.2 and [RFC7780]). Except as provided below, the selection of a nickname to use as the pseudo-nickname follows the usual TRILL rules given in [RFC6325], as updated by [RFC7780].
セクション3で説明したように、TRILLキャンパスでは、RBvはその疑似ニックネームで識別されます。 AAEグループでは、1つのメンバーRBridgeが、このRBvの疑似ニックネームを選択する義務のために選出されます。このRBridgeはvDRBになります。グループの勝者は、符号なし整数と見なされる最大のIS-ISシステムIDを持つRBridgeです。次に、そのTRILL IS-ISリンク状態データベースと、このRBvの他のメンバーRBridges（詳細についてはセクション9.1を参照）によってPN-LAALP-Membership APPsub-TLVで報告された潜在的な疑似ニックネームに基づいて、 vDRBは、このRBvの疑似ニックネームとして使用可能なニックネームを選択し、そのE-L1FS FS-LSP（s）を介して他のRBridgeに通知します（セクション9.2および[RFC7780]を参照）。以下で提供されるものを除いて、疑似ニックネームとして使用するニックネームの選択は、[RFC7780]によって更新された、[RFC6325]で提供される通常のTRILLルールに従います。
To reduce the traffic disruption caused by the changing of nicknames, if possible, the vDRB SHOULD attempt to reuse the pseudo-nickname recently used by the group when selecting nickname for the RBv. To help the vDRB to do so, each LAALP related RBridge advertises a reusing pseudo-nickname for each of its LAALPs in its PN-LAALP-Membership APPsub-TLV if it has used such a pseudo-nickname for that LAALP recently. Although it is up to the implementation of the vDRB as to how to treat the reusing pseudo-nicknames, the following are RECOMMENDED:
ニックネームの変更によって引き起こされるトラフィックの中断を減らすために、可能であれば、vDRBは、RBvのニックネームを選択するときにグループが最近使用した疑似ニックネームの再利用を試みる必要があります（SHOULD）。 vDRBがそうするのを助けるために、LAALPに関連する各RBridgeは、そのLAALPに最近そのような疑似ニックネームを使用した場合、PN-LAALP-Membership APPsub-TLV内の各LAALPの再利用疑似ニックネームをアドバタイズします。再利用する疑似ニックネームの処理方法はvDRBの実装次第ですが、以下を推奨します。
o If there are multiple available reusing pseudo-nicknames that are reported by all the member RBridges of some LAALPs in this RBv, the available one that is reported by the largest number of such LAALPs is chosen as the pseudo-nickname for this RBv. If a tie exists, the reusing pseudo-nickname with the smallest value considered to be an unsigned integer is chosen.
o このRBv内の一部のLAALPのすべてのメンバーRBridgeによって報告される複数の利用可能な再利用疑似ニックネームがある場合、そのようなLAALPの最大数によって報告される利用可能なものは、このRBvの疑似ニックネームとして選択されます。同順位が存在する場合、符号なし整数と見なされる最小値を持つ再利用疑似ニックネームが選択されます。
o If only one reusing pseudo-nickname is reported, it SHOULD be chosen if available.
o 再利用する疑似ニックネームが1つだけ報告される場合は、可能であればそれを選択する必要があります（SHOULD）。
If there is no available reusing pseudo-nickname reported, the vDRB selects a nickname by its usual method.
再利用可能な疑似ニックネームが報告されていない場合、vDRBは通常の方法でニックネームを選択します。
The selected pseudo-nickname is then announced by the vDRB to other member RBridges of this RBv in the PN-RBv APPsub-TLV (see Section 9.2).
選択された疑似ニックネームは、PN-RBv APPsub-TLV内のこのRBvの他のメンバーRBridgeにvDRBによってアナウンスされます（セクション9.2を参照）。
In an AAE group, as each of the member RBridges thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would all ingress frames into, and egress frames from, the TRILL campus for all VLANs. For multi-destination frames, more than one member RBridge ingressing them may cause some of the resulting TRILL Data packets to be discarded due to failure of the Reverse Path Forwarding (RPF) check on other RBridges; for multi-destination traffic, more than one RBridge egressing it may cause local CE(s) to receive duplicate frames. Furthermore, in an AAE group, a multi-destination frame sent by a CE (say CEi) may be ingressed into the TRILL campus by one member RBridge, and another member RBridge will then receive it from the TRILL campus and egress it to CEi; this will result in loopback of the frame for CEi. These problems are all described in [RFC7379].
AAEグループでは、メンバーRBridgesのそれぞれがそれをVLAN xのAppointed Forwarderであると認識しているため、アクティブ-アクティブ接続のサポートに変更を加えないと、すべてのVLANのTRILLキャンパスにすべての入力フレームとそこから出力フレームが送信されます。複数の宛先フレームの場合、それらに進入する複数のメンバーRBridgeは、他のRBridgeでのリバースパス転送（RPF）チェックの失敗により、結果のTRILLデータパケットの一部を破棄する可能性があります。複数の宛先のトラフィックの場合、複数のRBridgeが出力されると、ローカルCEが重複フレームを受信する可能性があります。さらに、AAEグループでは、CE（たとえば、CEi）によって送信された複数宛先フレームは、1つのメンバーRBridgeによってTRILLキャンパスに入力され、別のメンバーRBridgeは、それをTRILLキャンパスから受信してCEiに出力します。これにより、CEiのフレームがループバックされます。これらの問題はすべて[RFC7379]で説明されています。
In the following subsections, the first two issues are discussed in Sections 5.1 and 5.2, respectively; the third issue is discussed in Section 5.3.
次のサブセクションでは、最初の2つの問題について、それぞれセクション5.1および5.2で説明します。 3番目の問題については、セクション5.3で説明します。
In TRILL, RBridges normally use distribution trees to forward multi-destination frames. (Under some circumstances, they can be unicast, as specified in [RFC7172].) An RPF check, along with other types of checks, is used to avoid temporary multicast loops during topology changes (Section 4.5.2 of [RFC6325]). The RPF check mechanism only accepts a multi-destination frame ingressed by an RBridge (say RBi) and forwarded on a distribution tree if it arrives at another RBridge (say RBn) on the expected port. If the frame arrives on any other port, the frame MUST be dropped.
TRILLでは、RBridgeは通常、配信ツリーを使用して複数の宛先フレームを転送します。 （状況によっては、[RFC7172]で指定されているように、ユニキャストになる可能性があります。）RPFチェックは、他のタイプのチェックとともに、トポロジ変更中の一時的なマルチキャストループを回避するために使用されます（[RFC6325]のセクション4.5.2）。 RPFチェックメカニズムは、RBridge（たとえばRBi）によって入力され、予想されるポートで別のRBridge（たとえばRBn）に到着した場合に配布ツリーで転送される複数の宛先フレームのみを受け入れます。フレームが他のポートに到着した場合は、フレームをドロップする必要があります。
To avoid address flip-flopping on remote RBridges, member RBridges use the RBv's pseudo-nickname instead of their regular nicknames as the ingress nickname to ingress native frames, including multi-destination frames. From the view of other RBridges, these frames appear as if they were ingressed by the RBv. When multi-destination frames of different flows are ingressed by different member RBridges of an RBv and forwarded along the same distribution tree, they may arrive at RBn on different ports. Some of them will violate the RPF check principle at RBn and be dropped, which will result in lost traffic.
リモートRBridgeでのアドレスフリップフロップを回避するために、メンバーRBridgeは、通常のニックネームの代わりにRBvの疑似ニックネームを、複数の宛先フレームを含む入力ネイティブフレームへの入力ニックネームとして使用します。他のRBridgeから見ると、これらのフレームはあたかもRBvから侵入されたかのように見えます。異なるフローの複数の宛先フレームがRBvの異なるメンバーRBridgesから入り、同じ配信ツリーに沿って転送されると、それらは異なるポートのRBnに到着する場合があります。それらのいくつかは、RBnでのRPFチェックの原則に違反してドロップされるため、トラフィックが失われます。
In an RBv, if a different member RBridge uses different distribution trees to ingress multi-destination frames, the RPF check violation issue can be fixed. The Coordinated Multicast Trees (CMT) document [RFC7783] proposes such an approach and makes use of the Affinity sub-TLV defined in [RFC7176] to tell other RBridges which trees a member RBridge (say RBi) may choose when ingressing multi-destination frames; all RBridges in the TRILL campus can then calculate RPF check information for RBi on those trees, taking the tree affinity information into account [RFC7783].
RBvでは、異なるメンバーRBridgeが異なる配布ツリーを使用して複数の宛先フレームに進入する場合、RPFチェック違反の問題を修正できます。 Coordinated Multicast Trees（CMT）ドキュメント[RFC7783]は、このようなアプローチを提案し、[RFC7176]で定義されているAffinity sub-TLVを利用して、メンバーRBridge（RBiなど）がマルチ宛先フレームに入るときに選択するツリーを他のRBridgeに通知します。 ; TRILLキャンパス内のすべてのRBridgeは、ツリーアフィニティ情報を考慮して、これらのツリーのRBiのRPFチェック情報を計算できます[RFC7783]。
This document uses the approach proposed in [RFC7783] to fix the RPF check violation issue. Please refer to [RFC7783] for more details regarding this approach.
このドキュメントでは、[RFC7783]で提案されているアプローチを使用して、RPFチェック違反の問題を修正しています。このアプローチの詳細については、[RFC7783]を参照してください。
Take Figure 3 as an example, where CE1 and CE2 are served by an RBv that has RB1 and RB2 as member RBridges. In VLAN x, the three CEs can communicate with each other.
図3を例にとると、CE1とCE2は、RB1とRB2をメンバーRBridgeとして持つRBvによって処理されます。 VLAN xでは、3つのCEは相互に通信できます。
---------------------
/ \ +-----+
| TRILL Campus |---| RBn |
\ / +-----+
-----------------------
| |
+----+ +------+
| |
+---------+ +--------+
| RB1 | | RB2 |
| oooooooo|oooooooooooooooo|ooooo |
+o--------+ RBv +-----o--+
o|oooo|oooooooooooooooooooo|o|o |
| +--|--------------------+ | |
| | +---------+ +----------+ |
(| |)<-LAALP1 (| |)<-LAALP2 |
+-------+ +-------+ +-------+
| CE1 | | CE2 | | CE3 |
+-------+ +-------+ +-------+
Figure 3: A Topology with Multihomed and Single-Homed CEs
図3：マルチホームCEとシングルホームCEのトポロジ
When a remote RBridge (say RBn) sends a multi-destination TRILL Data packet in VLAN x (or the FGL that VLAN x maps to, if the packet is FGL), both RB1 and RB2 will receive it. As each of them thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would both forward the frame to CE1/CE2. As a result, CE1/CE2 would receive duplicate copies of the frame through this RBv.
リモートRBridge（たとえばRBn）がVLAN x（またはパケットがFGLの場合はVLAN xがマップするFGL）で複数の宛先のTRILLデータパケットを送信すると、RB1とRB2の両方がそれを受信します。それぞれがVLAN xのAppointed Forwarderであると考えているため、アクティブ/アクティブ接続のサポートに変更を加えずに、フレームをCE1 / CE2に転送します。その結果、CE1 / CE2はこのRBvを介してフレームの重複コピーを受信します。
In another case, assume that CE3 is single-homed to RB2. When it transmits a native multi-destination frame onto link CE3-RB2 in VLAN x, the frame can be locally replicated to the ports to CE1/CE2, and also encapsulated into TRILL Data packet and ingressed into the TRILL campus. When the packet arrives at RB1 across the TRILL campus, it will be egressed to CE1/CE2 by RB1. CE1/CE2 then receives duplicate copies from RB1 and RB2.
別のケースでは、CE3がRB2にシングルホームされていると想定します。ネイティブのマルチ宛先フレームをVLAN xのリンクCE3-RB2に送信すると、フレームはローカルでCE1 / CE2のポートに複製され、TRILLデータパケットにカプセル化されてTRILLキャンパスに入力されます。パケットがTRILLキャンパスを介してRB1に到着すると、RB1によってCE1 / CE2に出力されます。 CE1 / CE2は、RB1およびRB2から重複したコピーを受信します。
In this document, the Designated Forwarder (DF) for a VLAN is introduced to avoid duplicate copies. The basic idea of the DF is to elect one RBridge per VLAN from an RBv to egress multi-destination TRILL Data traffic and replicate locally received multi-destination native frames to the CEs served by the RBv.
このドキュメントでは、重複コピーを回避するために、VLANの指定フォワーダー（DF）が導入されています。 DFの基本的な考え方は、RBvからVLANごとに1つのRBridgeを選出して、マルチ宛先TRILLデータトラフィックを出力し、ローカルで受信したマルチ宛先ネイティブフレームを、RBvがサービスするCEに複製することです。
Note that the DF has an effect only on the egressing/replicating of multi-destination traffic. It has no effect on the ingressing, forwarding, or egressing of unicast frames. Furthermore, the DF check is performed only for RBv ports, not on regular access ports.
DFは、複数の宛先のトラフィックの出力/複製にのみ影響することに注意してください。ユニキャストフレームの入力、転送、または出力には影響しません。さらに、DFチェックはRBvポートに対してのみ実行され、通常のアクセスポートでは実行されません。
Each RBridge in an RBv elects a DF using the same algorithm; this guarantees that, per VLAN, the same RBridge is elected as the DF by all members of the RBv.
RBvの各RBridgeは、同じアルゴリズムを使用してDFを選出します。これにより、VLANごとに、RBvのすべてのメンバーによって同じRBridgeがDFとして選出されることが保証されます。
If we assume that there are m LAALPs and k member RBridges in an RBv, then (1) each LAALP is referred to as "LAALPi", where 0 <= i < m, and (2) each RBridge is referred to as "RBj", where 0 <= j < k. The DF election algorithm per VLAN is as follows:
RBvにm個のLAALPとk個のメンバーRBridgeがあると仮定すると、（1）各LAALPは「LAALPi」と呼ばれ、0 <= i <m、および（2）各RBridgeは「RBj」と呼ばれます。 "、ここで0 <= j <k。 VLANごとのDF選定アルゴリズムは次のとおりです。
Step 1: For LAALPi, sort all the RBridges in numerically ascending order based on SHA-256(System IDj | LAALP IDi) considered to be an unsigned integer, where SHA-256 is the hash function specified in [RFC6234], "System IDj" is the 6-byte IS-IS System ID of RBj, "|" means concatenation, and "LAALP IDi" is the LAALP ID for LAALPi. The System ID and LAALP ID are considered to be byte strings. In the case of a tie, the tied RBridges are sorted in numerically ascending order by their System IDs considered to be unsigned integers.
ステップ1：LAALPiの場合、すべてのRBridgeを、符号なし整数と見なされるSHA-256（システムIDj | LAALP IDi）に基づいて数値の昇順でソートします。ここで、SHA-256は[RFC6234]で指定されたハッシュ関数です。「システムIDj "はRBjの6バイトのIS-ISシステムIDです、" | "は連結を意味し、「LAALP IDi」はLAALPiのLAALP IDです。システムIDとLAALP IDはバイト文字列と見なされます。タイの場合、タイのRBridgeは、符号なし整数と見なされるシステムIDによって数値の昇順でソートされます。
Step 2: Each RBridge in the numerically sorted list is assigned a monotonically increasing number j, such that increasing number j corresponds to its position in the sorted list, i.e., the first RBridge (the one with the smallest SHA-256(System ID | LAALP ID)) is assigned zero and the last is assigned k-1.
ステップ2：数値でソートされたリスト内の各RBridgeには単調に増加する番号jが割り当てられ、増加する番号jはソートされたリスト内のその位置、つまり最初のRBridge（SHA-256（システムID | LAALP ID））にはゼロが割り当てられ、最後にはk-1が割り当てられます。
Step 3: For each VLAN ID n, choose the RBridge whose number equals (n mod k) as the DF.
手順3：各VLAN ID nについて、（n mod k）に等しい番号を持つRBridgeをDFとして選択します。
Step 4: Repeat Steps 1-3 for the remaining LAALPs until there is a DF per VLAN per LAALP in the RBv.
ステップ4：RBvのLAALPごとにVLANごとにDFが存在するようになるまで、残りのLAALPに対してステップ1〜3を繰り返します。
For any multi-destination native frames of VLAN x that are received, if RBi is an LAALP attached RBridge, there are three cases where RBi replicates the multi-destination frame, as follows:
受信されたVLAN xの複数宛先ネイティブフレームの場合、RBiがLAALP接続のRBridgeである場合、RBiが複数宛先フレームを複製するケースは次の3つです。
1) Local replication of the frame to regular (non-AAE) access ports as per [RFC6325] (and [RFC7172] for FGL).
1）[RFC6325]（およびFGLの[RFC7172]）に従って、通常の（非AAE）アクセスポートへのフレームのローカルレプリケーション。
2) RBv ports associated with the same pseudo-nickname as that of the incoming port, no matter whether RBi is the DF for the frame's VLAN on the outgoing ports, except that the frame MUST NOT be replicated back to the incoming port. RBi cannot simply depend on the DF to forward the multi-destination frame back into the AAEs associated with the pseudo-nickname, as that would cause the source CE to get the frame back, which is a violation of basic Ethernet properties. The DF will not forward such a frame back into the AAE due to ingress nickname filtering as described in Section 5.3.
2）フレームが着信ポートに複製されてはならないことを除いて、RBiが発信ポート上のフレームのVLANのDFであるかどうかに関係なく、着信ポートと同じ擬似ニックネームに関連付けられたRBvポートRBiは、DFに依存して複数の宛先フレームを疑似ニックネームに関連付けられたAAEに転送することはできません。これは、ソースCEがフレームを取り戻すためであり、これは基本的なイーサネットプロパティの違反です。セクション5.3で説明されているように、ニックネームフィルタリングの入力により、DFはこのようなフレームをAAEに転送しません。
3) RBv ports on which RBi is the DF for the frame's VLAN while they are associated with different pseudo-nickname(s) than that of the incoming port.
3）RBiがフレームのVLANのDFであるRBvポート。これらのポートは、着信ポートとは異なる疑似ニックネームに関連付けられています。
For any multi-destination TRILL Data packets that are received, RBi MUST NOT egress it out of the RBv ports where it is not the DF for the frame's Inner.VLAN (or for the VLAN corresponding to the Inner.Label if the packet is an FGL one). Otherwise, whether or not to egress it out of such ports is further subject to the filtering check result of the frame's ingress nickname on these ports (see Section 5.3).
受信された複数の宛先TRILLデータパケットについて、RBiは、フレームのInner.VLAN（または、パケットがFGL one）。それ以外の場合、そのようなポートから出力するかどうかは、これらのポートでのフレームの入力ニックネームのフィルタリングチェック結果の影響を受けます（セクション5.3を参照）。
As shown in Figure 3, CE1 may send multi-destination traffic in VLAN x to the TRILL campus via a member RBridge (say RB1). The traffic is then TRILL-encapsulated by RB1 and delivered through the TRILL campus to multi-destination receivers. RB2 may receive the traffic and egress it back to CE1 if it is the DF for VLAN x on the port to LAALP1. The traffic then loops back to CE1 (see Section 3.2 of [RFC7379]).
図3に示すように、CE1はメンバーRBridge（たとえばRB1）を介してVLAN xの複数の宛先トラフィックをTRILLキャンパスに送信できます。次に、トラフィックはRB1によってTRILLカプセル化され、TRILLキャンパスを介して複数の宛先のレシーバーに配信されます。 LARB1へのポート上のVLAN xのDFである場合、RB2はトラフィックを受信し、CE1に出力を戻すことがあります。その後、トラフィックはループしてCE1に戻ります（[RFC7379]のセクション3.2を参照）。
To fix the above issue, this document requires an ingress nickname filtering check. The idea is to check the ingress nickname of a multi-destination TRILL Data packet before egressing a copy of it out of an RBv port. If the ingress nickname matches the pseudo-nickname of the RBv (associated with the port), the filtering check should fail and the copy MUST NOT be egressed out of that RBv port. Otherwise, the copy is egressed out of that port if it has also passed other checks, such as the Appointed Forwarder check described in Section 4.6.2.5 of [RFC6325] and the DF check described in Section 5.2.
上記の問題を修正するには、このドキュメントで入力ニックネームフィルタリングチェックが必要です。このアイデアは、RBvポートからコピーの出力を送信する前に、複数宛先のTRILLデータパケットの入力ニックネームを確認することです。入力ニックネームがRBv（ポートに関連付けられている）の疑似ニックネームと一致する場合、フィルタリングチェックは失敗し、コピーはそのRBvポートから出力されてはなりません（MUST NOT）。それ以外の場合、[RFC6325]のセクション4.6.2.5で説明されているAppointed Forwarderチェックやセクション5.2で説明されているDFチェックなどの他のチェックにも合格すると、コピーはそのポートから出力されます。
Note that this ingress nickname filtering check has no effect on the multi-destination native frames that are received on access ports and replicated to other local ports (including RBv ports), since there is no ingress nickname associated with such frames. Furthermore, for the RBridge regular access ports, there is no pseudo-nickname associated with them, so no ingress nickname filtering check is required on those ports.
このようなニックネームフィルタリングチェックは、アクセスポートで受信され、他のローカルポート（RBvポートを含む）に複製される複数の宛先のネイティブフレームに影響を与えないことに注意してください。さらに、RBridge通常アクセスポートの場合、それらに関連付けられた疑似ニックネームはないため、これらのポートで入力ニックネームフィルタリングチェックは必要ありません。
More details of data packet processing on RBv ports are given in the next section.
RBvポートでのデータパケット処理の詳細については、次のセクションで説明します。
This section provides more details of native frame and TRILL Data packet processing as it relates to the RBv's pseudo-nickname.
このセクションでは、RBvの疑似ニックネームに関連するネイティブフレームとTRILLデータパケット処理の詳細について説明します。
When RB1 receives a unicast native frame from one of its ports that has end-station service enabled, it processes the frame as described in Section 4.6.1.1 of [RFC6325], with the following exception:
RB1は、エンドステーションサービスが有効になっているポートの1つからユニキャストネイティブフレームを受信すると、[RFC6325]のセクション4.6.1.1で説明されているようにフレームを処理しますが、次の例外があります。
o If the port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
o ポートがRBvポートである場合、RB1は、フレームでTRILLカプセル化を行うときに、通常のニックネームの1つではなく、RBvの疑似ニックネームを入力ニックネームとして使用します。
When RB1 receives a native multi-destination (broadcast, unknown unicast, or multicast) frame from one of its access ports (including regular access ports and RBv ports), it processes the frame as described in Section 4.6.1.2 of [RFC6325], with the following exceptions:
RB1は、そのアクセスポートの1つ（通常のアクセスポートとRBvポートを含む）からネイティブマルチ宛先（ブロードキャスト、不明なユニキャスト、またはマルチキャスト）フレームを受信すると、[RFC6325]のセクション4.6.1.2で説明されているようにフレームを処理します。次の例外があります。
o If the incoming port is an RBv port, RB1 uses the RBv's pseudo-nickname instead of one of its regular nickname(s) as the ingress nickname when doing TRILL encapsulation on the frame.
o 着信ポートがRBvポートの場合、RB1は、フレームでTRILLカプセル化を行うときに、通常のニックネームの1つではなく、RBvの疑似ニックネームを入力ニックネームとして使用します。
o For the copies of the frame replicated locally to RBv ports, there are two cases, as follows:
o ローカルでRBvポートに複製されたフレームのコピーの場合、次の2つのケースがあります。
- If the outgoing port(s) is associated with the same pseudo-nickname as that of the incoming port but not with the same LAALP as the incoming port, the copies are forwarded out of that outgoing port(s) after passing the Appointed Forwarder check for the frame's VLAN. That is to say, the copies are processed on such port(s), as discussed in Section 4.6.1.2 of [RFC6325].
- 発信ポートが着信ポートと同じ擬似ニックネームに関連付けられているが、着信ポートと同じLAALPに関連付けられていない場合、Appointed Forwarderチェックに合格した後、コピーはその発信ポートから転送されます。フレームのVLAN。つまり、[RFC6325]のセクション4.6.1.2で説明されているように、コピーはそのようなポートで処理されます。
- Else, the Designated Forwarder (DF) check is also made on the outgoing ports for the frame's VLAN after the Appointed Forwarder check, and the copies are not output through any ports that failed the DF check (i.e., RB1 is not the DF for the frame's VLAN on the ports). Otherwise, the copies are forwarded out of the outgoing ports that pass both the Appointed Forwarder check and the DF check (see Section 5.2).
- それ以外の場合、指定フォワーダ（DF）チェックは、指定フォワーダチェックの後にフレームのVLANの発信ポートでも行われ、コピーはDFチェックに失敗したポートから出力されません（つまり、RB1はDFのDFではありません）。ポート上のフレームのVLAN）。それ以外の場合、Appointed ForwarderチェックとDFチェックの両方に合格した発信ポートからコピーが転送されます（セクション5.2を参照）。
For any such frames received, the MAC address information learned by observing it, together with the LAALP ID of the incoming port, SHOULD be shared with other member RBridges in the group (see Section 7).
そのようなフレームを受信した場合、それを観察することで学習したMACアドレス情報と、着信ポートのLAALP IDは、グループ内の他のメンバーのRBridgeと共有する必要があります（セクション7を参照）。
This section describes egress processing of the TRILL Data packets received on an RBv member RBridge (say RBn). Section 6.2.1 describes the egress processing of unicast TRILL Data packets, and Section 6.2.2 specifies the egressing of multi-destination TRILL Data packets.
このセクションでは、RBvメンバーRBridge（たとえばRBn）で受信したTRILLデータパケットの出力処理について説明します。セクション6.2.1では、ユニキャストTRILLデータパケットの出力処理について説明し、セクション6.2.2では、複数宛先のTRILLデータパケットの出力を指定します。
When receiving a unicast TRILL Data packet, RBn checks the egress nickname in the TRILL Header of the packet. If the egress nickname is one of RBn's regular nicknames, the packet is processed as defined in Section 4.6.2.4 of [RFC6325].
ユニキャストTRILLデータパケットを受信すると、RBnはパケットのTRILLヘッダーの出力ニックネームをチェックします。出力ニックネームがRBnの通常のニックネームの1つである場合、パケットは[RFC6325]のセクション4.6.2.4の定義に従って処理されます。
If the egress nickname is the pseudo-nickname of a local RBv, RBn is responsible for learning the source MAC address, unless data-plane learning has been disabled. The learned {Inner.MacSA, Data Label, ingress nickname} triplet SHOULD be shared within the AAE group as described in Section 7.
出力ニックネームがローカルRBvの疑似ニックネームである場合、データプレーン学習が無効にされていない限り、RBnは送信元MACアドレスの学習を担当します。学習した{Inner.MacSA、Data Label、ingress nickname}トリプレットは、セクション7で説明するように、AAEグループ内で共有する必要があります（SHOULD）。
The packet is then decapsulated to its native form. The Inner.MacDA and Data Label are looked up in RBn's local forwarding tables, and one of the three following cases will occur. RBn uses the first case that applies and ignores the remaining cases:
その後、パケットはカプセル化解除されてネイティブの形式になります。 Inner.MacDAとデータラベルはRBnのローカル転送テーブルで検索され、次の3つのケースのいずれかが発生します。 RBnは、適用される最初のケースを使用し、残りのケースを無視します。
o If the destination end station identified by the Inner.MacDA and Data Label is on a local link, the native frame is sent onto that link with the VLAN from the Inner.VLAN or VLAN corresponding to the Inner.Label if the packet is FGL.
o Inner.MacDAとデータラベルで識別される宛先エンドステーションがローカルリンク上にある場合、ネイティブフレームは、パケットがFGLの場合、Inner.VLANまたはInner.Labelに対応するVLANからVLANを使用してそのリンクに送信されます。
o Else if RBn can reach the destination through another member RBridge (say RBk), it tunnels the native frame to RBk by re-encapsulating it into a unicast TRILL Data packet and sends it to RBk. RBn uses RBk's regular nickname instead of the pseudo-nickname as the egress nickname for the re-encapsulation, and the ingress nickname remains unchanged (somewhat similar to Section 2.4.2.1 of [RFC7780]). If the Hop Count value of the packet is too small for it to reach RBk safely, RBn SHOULD increase that value properly in doing the re-encapsulation. (NOTE: When receiving that re-encapsulated TRILL Data packet, as the egress nickname of the packet is RBk's regular nickname rather than the pseudo-nickname of a local RBv, RBk will process it per Section 4.6.2.4 of [RFC6325] and will not re-forward it to another RBridge.)
o そうでない場合、RBnが別のメンバーRBridge（RBkなど）を介して宛先に到達できる場合は、ネイティブフレームをユニキャストTRILLデータパケットに再カプセル化してRBkにトンネルし、それをRBkに送信します。 RBnは、再カプセル化の出力ニックネームとして、疑似ニックネームの代わりにRBkの通常のニックネームを使用し、入力ニックネームは変更されません（[RFC7780]のセクション2.4.2.1と多少似ています）。パケットのホップカウント値が小さすぎてRBkに安全に到達できない場合、RBnは再カプセル化を行う際にその値を適切に増やす必要があります（SHOULD）。 （注：再カプセル化されたTRILLデータパケットを受信すると、パケットの出力ニックネームはローカルRBvの疑似ニックネームではなくRBkの通常のニックネームであるため、RBkは[RFC6325]のセクション4.6.2.4に従って処理し、別のRBridgeに再転送しないでください。）
o Else, RBn does not know how to reach the destination; it sends the native frame out of all the local ports on which it is Appointed Forwarder for the Inner.VLAN (or Appointed Forwarder for the VLAN into which the Inner.Label maps on that port for an FGL TRILL Data packet [RFC7172]).
o そうでなければ、RBnは目的地に到達する方法を知りません。 Inner.VLANのAppointed Forwarder（または、FGL TRILLデータパケット[RFC7172]のInner.LabelがそのポートにマップするVLANのAppointed Forwarder）であるすべてのローカルポートからネイティブフレームを送信します。
When RB1 receives a multi-destination TRILL Data Packet, it checks and processes the packet as described in Section 4.6.2.5 of [RFC6325], with the following exception:
RB1が複数の宛先のTRILLデータパケットを受信すると、[RFC6325]のセクション4.6.2.5で説明されているようにパケットをチェックして処理しますが、次の例外があります。
o On each RBv port where RBn is the Appointed Forwarder for the packet's Inner.VLAN (or for the VLAN to which the packet's Inner.Label maps on that port if it is an FGL TRILL Data packet), the DF check (see Section 5.2) and the ingress nickname filtering check (see Section 5.3) are further performed. For such an RBv port, if either the DF check or the filtering check fails, the frame MUST NOT be egressed out of that port. Otherwise, it can be egressed out of that port.
o RBnがパケットのInner.VLAN（またはパケットのInner.LabelがFGL TRILLデータパケットの場合はそのポートにマップされるVLANの）の指定フォワーダーである各RBvポートで、DFチェック（セクション5.2を参照）さらに、入力ニックネームフィルタリングチェック（セクション5.3を参照）がさらに実行されます。そのようなRBvポートの場合、DFチェックまたはフィルタリングチェックのいずれかが失敗した場合、フレームはそのポートから出力されてはなりません（MUST NOT）。それ以外の場合は、そのポートから出力できます。
An edge RBridge, say RB1 in LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host (say h1) when h1 sends a packet to CE1. The returning traffic from CE1 may go to another member RBridge of LAALP1 (for example, RB2). RB2 may not have that correspondence stored. Therefore, it has to do the flooding for unknown unicast. Such flooding is unnecessary, since the returning traffic is almost always expected and RB1 had learned the address correspondence. To avoid the unnecessary flooding, RB1 SHOULD share the correspondence with other RBridges of LAALP1. RB1 synchronizes the correspondence by using the MAC-Reachability (MAC-RI) sub-TLV [RFC6165] in its ESADI-LSPs [RFC7357].
LA1のRB1などのエッジRBridgeは、h1がCE1にパケットを送信するときに、{データラベルとMACアドレス}とリモートホストのニックネーム（h1など）の対応を学習している可能性があります。 CE1からの戻りトラフィックは、LAALP1の別のメンバーRBridge（たとえば、RB2）に送られます。 RB2には、対応が保存されていない場合があります。したがって、不明なユニキャストのフラッディングを行う必要があります。戻りトラフィックはほとんど常に予想され、RB1はアドレスの対応を学習していたため、このようなフラッディングは不要です。不必要なフラッディングを回避するために、RB1はLAALP1の他のRBridgeと通信を共有する必要があります（SHOULD）。 RB1は、ESADI-LSP [RFC7357]でMAC-Reachability（MAC-RI）サブTLV [RFC6165]を使用して対応を同期化します。
On the other hand, RB2 has learned the MAC address and Data Label of CE1 when CE1 sends a frame to h1 through RB2. The returning traffic from h1 may go to RB1. RB1 may not have CE1's MAC address and Data Label stored even though it is in the same LAALP for CE1 as RB2. Therefore, it has to flood the traffic out of all its access ports where it is Appointed Forwarder for the VLAN (see Section 6.2.1) or the VLAN the FGL maps to on that port if the packet is FGL. Such flooding is unnecessary, since the returning traffic is almost always expected and RB2 had learned CE1's MAC and Data Label information. To avoid that unnecessary flooding, RB2 SHOULD share the MAC address and Data Label with other RBridges of LAALP1. RB2 synchronizes the MAC address and Data Label by enclosing the relative MAC-RI TLV within a pair of boundary TRILL APPsub-TLVs for LAALP1 (see Section 9.3) in its ESADI-LSP [RFC7357]. After receiving the enclosed MAC-RI TLVs, the member RBridges of LAALP1 (i.e., LAALP1 related RBridges) treat the MAC address and Data Label as if it were learned by them locally on their member port of LAALP1; the LAALP1 unrelated RBridges just ignore LAALP1's boundary APPsub-TLVs and treat the MAC address and Data Label as specified in [RFC7357]. Furthermore, in order to make the LAALP1 unrelated RBridges know that the MAC and Data Label are reachable through the RBv that provides service to LAALP1, the Topology-ID/Nickname field of the MAC-RI TLV SHOULD carry the pseudo-nickname of the RBv, rather than a zero value or one of the originating RBridge's (i.e., RB2's) regular nicknames.
一方、CE1がRB2を介してh1にフレームを送信すると、RB2はMACアドレスとCE1のデータラベルを学習しました。 h1からの戻りトラフィックはRB1に向かう場合があります。 RB2とCE1の同じLAALPにある場合でも、RB1にはCE1のMACアドレスとデータラベルが格納されていない場合があります。したがって、パケットがFGLの場合、VLANのAppointed Forwarder（セクション6.2.1を参照）またはFGLがそのポートにマップするVLANであるすべてのアクセスポートからトラフィックをフラッディングする必要があります。戻りトラフィックはほとんど常に予想され、RB2はCE1のMACおよびデータラベル情報を学習していたため、このようなフラッディングは不要です。その不必要なフラッディングを回避するために、RB2はMACアドレスとデータラベルをLAALP1の他のRBridgeと共有する必要があります。 RB2は、ESADI-LSP [RFC7357]のLAALP1の境界TRILL APPsub-TLVのペア内に相対MAC-RI TLVを含めることにより、MACアドレスとデータラベルを同期します（セクション9.3を参照）。同封のMAC-RI TLVを受信した後、LAALP1のメンバーRBridges（つまり、LAALP1関連のRBridges）は、MACアドレスとデータラベルを、LAALP1のメンバーポートでローカルに学習されたかのように扱います。 LAALP1の無関係なRBridgeはLAALP1の境界APPsub-TLVを無視し、MACアドレスとデータラベルを[RFC7357]で指定されているように扱います。さらに、LAALP1にサービスを提供するRBvを介してMACおよびデータラベルに到達できることをLAALP1の無関係なRBridgeに知らせるために、MAC-RI TLVのトポロジーID /ニックネームフィールドは、RBvの疑似ニックネームを運ぶ必要があります（SHOULD）。ゼロ値または元のRBridge（つまり、RB2）の通常のニックネームではなく、
As shown in Figure 4, suppose that the link RB1-CE1 fails. Although a new RBv will be formed by RB2 and RB3 to provide active-active service for LAALP1 (see Section 5), the unicast traffic to CE1 might still be forwarded to RB1 before the remote RBridge learns that CE1 is attached to the new RBv. That traffic might be disrupted by the link failure. Section 8.1 discusses failure protection in this scenario.
図4に示すように、リンクRB1-CE1に障害が発生したとします。 LAALP1にアクティブ-アクティブサービスを提供するために新しいRBvがRB2とRB3によって形成されますが（セクション5を参照）、CE1が新しいRBvに接続されていることをリモートRBridgeが認識する前に、CE1へのユニキャストトラフィックがRB1に転送される可能性があります。そのトラフィックは、リンク障害によって中断される可能性があります。セクション8.1では、このシナリオでの障害保護について説明します。
However, multi-destination TRILL Data packets can reach all member RBridges of the new RBv and be egressed to CE1 by either RB2 or RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the packet's Inner.Label maps to in the new RBv). Although there might be a transient hang time between failure and the establishment of the new RBv, special actions to protect against downlink failure for such multi-destination packets are not needed.
ただし、複数宛先のTRILLデータパケットは、新しいRBvのすべてのメンバーRBridgeに到達し、RB2またはRB3（つまり、トラフィックのInner.VLANまたはパケットのInner.LabelがマッピングするVLANの新しいDF）によってCE1に出力されます。新しいRBv）。障害と新しいRBvの確立の間に一時的なハング時間が存在する可能性がありますが、そのような複数の宛先のパケットのダウンリンク障害から保護するための特別なアクションは必要ありません。
------------------
/ \
| TRILL Campus |
\ /
--------------------
| | |
+---+ | +----+
| | |
+------+ +------+ +------+
| RB1 | | RB2 | | RB3 |
ooooooo|ooooo|oooooo|ooo|ooooo |
o+------+ RBv +------+ +-----o+
o|oooo|ooooooo|oooo|ooooo|oo|o
| | | +-|-----+ |
\|/+--|-------+ | +------+ |
- B | +----------|------+ | |
/|\| +-----------+ | | |
(| | |)<--LAALP1 (| | |)<--LAALP2
+-------+ +-------+
| CE1 | | CE2 |
+-------+ +-------+
B - Failed Link or Link Bundle
B-失敗したリンクまたはリンクバンドル
Figure 4: A Multi-Homed CE with a Failed Link
図4：リンクに障害が発生したマルチホームCE
When the link CE1-RB1 fails, RB1 loses its direct connection to CE1. The MAC entry through the failed link to CE1 is removed from RB1's local forwarding table immediately. Another MAC entry learned from another member RBridge of LAALP1 (for example, RB2, since it is still a member RBridge of LAALP1) is installed into RB1's forwarding table (see Section 9.3). In that new entry, RB2 (identified by one of its regular nicknames) is the egress RBridge for CE1's MAC address. Then, when a TRILL Data packet to CE1 is delivered to RB1, it can be tunneled to RB2 after being re-encapsulated (the ingress nickname remains unchanged and the egress nickname is replaced by RB2's regular nickname) based on the above installed MAC entry (see bullet 2 in Section 6.2.1). RB2 then receives the frame and egresses it to CE1.
リンクCE1-RB1に障害が発生すると、RB1はCE1への直接接続を失います。障害が発生したCE1へのリンクを介したMACエントリは、RB1のローカル転送テーブルからすぐに削除されます。 LAALP1の別のメンバーRBridge（たとえば、まだLAALP1のメンバーRBridgeであるため、RB2）から学習した別のMACエントリは、RB1の転送テーブルにインストールされます（セクション9.3を参照）。その新しいエントリでは、RB2（通常のニックネームの1つで識別される）がCE1のMACアドレスの出力RBridgeです。次に、CE1へのTRILLデータパケットがRB1に配信されると、再インストールされた後、RB2にトンネリングできます（入力ニックネームは変更されず、出力ニックネームはRB2の通常のニックネームに置き換えられます）。セクション6.2.1の箇条書き2を参照してください）。次に、RB2はフレームを受信し、CE1に出力します。
After failure recovery, RB1 learns that it can reach CE1 via link CE1-RB1 again by observing CE1's native frames or from the MAC information synchronization by member RBridge(s) of LAALP1 as described in Section 7. It then restores the MAC entry to its previous one and downloads it to its data-plane "fast path" logic.
障害回復後、RB1は、CE1のネイティブフレームを監視することにより、またはセクション7で説明したLAALP1のメンバーRBridgeによるMAC情報同期から、リンクCE1-RB1を介してCE1に再度到達できることを学習します。次に、MACエントリをその以前のものと、それをデータプレーンの「高速パス」ロジックにダウンロードします。
The following subsections specify the APPsub-TLVs needed to support pseudo-nickname edge groups.
次のサブセクションでは、疑似ニックネームエッジグループをサポートするために必要なAPPsub-TLVを指定します。
This APPsub-TLV is used by an edge RBridge to announce its associated pseudo-nickname LAALP information. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format:
このAPPsub-TLVは、関連する疑似ニックネームLAALP情報を通知するためにエッジRBridgeによって使用されます。これは、TRIL GENINFO TLV [RFC7357]のサブTLVとして定義され、E-L1FS FS-LSP [RFC7780]で配布されます。次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-LAALP-Membership | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP RECORD(n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
Figure 5: PN-LAALP-Membership Advertisement APPsub-TLV
図5：PN-LAALPメンバーシップアドバタイズメントAPPsub-TLV
where each LAALP RECORD has the following form:
各LAALP RECORDの形式は次のとおりです。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 ..
+--+-+-+-+-+-+-+-+
|OE| RESV | (1 byte)
+--+-+-+-+-+-+-+-+
| Size | (1 byte)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reusing Pseudo-Nickname | (2 bytes)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID | (variable)
+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
o PN-LAALP-Membership (2 bytes): Defines the type of this sub-TLV, 2.
o PN-LAALP-Membership（2バイト）：このサブTLVのタイプ、2を定義します。
o Length (2 bytes): The sum of the lengths of the LAALP RECORDs.
o 長さ（2バイト）：LAALP RECORDの長さの合計。
o OE (1 bit): A flag indicating whether or not the LAALP wants to occupy an RBv by itself; 1 for occupying by itself (or Occupying Exclusively (OE)). By default, it is set to 0 on transmit. This bit is used for edge RBridge group auto-discovery (see Section 4.1). For any one LAALP, the values of this flag might conflict in the LSPs advertised by different member RBridges of that LAALP. In that case, the flag for that LAALP is considered to be 1.
o OE（1ビット）：LAALPが単独でRBvを占有するかどうかを示すフラグ。単独で占有する場合は1（または占有する場合（OE））。デフォルトでは、送信時に0に設定されています。このビットは、エッジRBridgeグループの自動検出に使用されます（セクション4.1を参照）。いずれかのLAALPについて、このLAALPの異なるメンバーRBridgeによって通知されるLSPでこのフラグの値が競合する可能性があります。その場合、そのLAALPのフラグは1と見なされます。
o RESV (7 bits): MUST be transmitted as zero and ignored on receipt.
o RESV（7ビット）：ゼロとして送信し、受信時に無視する必要があります。
o Size (1 byte): Size of the remaining part of the LAALP RECORD (2 plus the length of the LAALP ID).
o サイズ（1バイト）：LAALP RECORDの残りの部分のサイズ（2とLAALP IDの長さ）。
o Reusing Pseudo-Nickname (2 bytes): Suggested pseudo-nickname of the AAE group serving the LAALP. If the LAALP is not served by any AAE group, this field MUST be set to zero. It is used by the originating RBridge to help the vDRB to reuse the previous pseudo-nickname of an AAE group (see Section 4.2).
o 疑似ニックネームの再利用（2バイト）：LAALPを提供するAAEグループの推奨疑似ニックネーム。 LAALPがどのAAEグループによっても提供されていない場合、このフィールドはゼロに設定する必要があります。これは、元のRBridgeによって使用され、vDRBがAAEグループの以前の疑似ニックネームを再利用できるようにします（セクション4.2を参照）。
o LAALP ID (variable): The ID of the LAALP. See Section 9.4.
o LAALP ID（変数）：LAALPのID。セクション9.4を参照してください。
On receipt of such an APPsub-TLV, if RBn is not an LAALP related edge RBridge, it ignores the sub-TLV; otherwise, it parses the sub-TLV. When new LAALPs are found or old ones are withdrawn compared to its old copy, and they are also configured on RBn, RBn performs the "Member RBridges Auto-Discovery" procedure described in Section 4.
このようなAPPsub-TLVを受信すると、RBnがLAALP関連のエッジRBridgeでない場合、サブTLVは無視されます。それ以外の場合は、サブTLVを解析します。新しいLAALPが見つかった場合、または古いコピーが古いコピーと比較して取り消され、それらがRBnでも構成されている場合、RBnは、セクション4で説明されている「メンバーRBridges自動検出」手順を実行します。
The PN-RBv APPsub-TLV is used by a Designated RBridge of a virtual RBridge (vDRB) to dictate the pseudo-nickname for the LAALPs served by the RBv. It is defined as a sub-TLV of the TRILL GENINFO TLV [RFC7357] and is distributed in E-L1FS FS-LSPs [RFC7780]. It has the following format:
PN-RBv APPsub-TLVは、仮想RBridge（vDRB）の指定RBridgeによって使用され、RBvによって提供されるLAALPの疑似ニックネームを指示します。これは、TRIL GENINFO TLV [RFC7357]のサブTLVとして定義され、E-L1FS FS-LSP [RFC7780]で配布されます。次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PN-RBv | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBv's Pseudo-Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LAALP ID Size | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
| LAALP ID (n) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+
o PN-RBv (2 bytes): Defines the type of this sub-TLV, 3.
o PN-RBv（2バイト）：このサブTLVのタイプを定義します。3。
o Length (2 bytes): 3+n*k bytes, where there are n LAALP IDs, each of size k bytes. k is found in the LAALP ID Size field below. If Length is not 3 plus an integer times k, the sub-TLV is corrupt and MUST be ignored.
o 長さ（2バイト）：3 + n * kバイト。LAALPIDがn個あり、それぞれサイズはkバイトです。 kは、以下のLAALP IDサイズフィールドにあります。 Lengthが3プラスkの整数倍でない場合、サブTLVは破損しているため、無視する必要があります。
o RBv's Pseudo-Nickname (2 bytes): The appointed pseudo-nickname for the RBv that serves the LAALPs listed in the following fields.
o RBvの疑似ニックネーム（2バイト）：以下のフィールドにリストされているLAALPを提供するRBvに指定された疑似ニックネーム。
o LAALP ID Size (1 byte): The size of each of the following LAALP IDs in this sub-TLV. 8 if the LAALPs listed are MC-LAGs or DRNI (Section 6.3.2 of [802.1AX]). The value in this field is the k value that appears in the formula for Length above.
o LAALP IDサイズ（1バイト）：このサブTLV内の次の各LAALP IDのサイズ。リストされているLAALPがMC-LAGまたはDRNIである場合は8（[802.1AX]のセクション6.3.2）。このフィールドの値は、上記の長さの式に表示されるk値です。
o LAALP ID (LAALP ID Size bytes): The ID of the LAALP. See Section 9.4.
o LAALP ID（LAALP IDサイズバイト）：LAALPのID。セクション9.4を参照してください。
This sub-TLV may occur multiple times with the same RBv pseudo-nickname; this means that all of the LAALPs listed are identified by that pseudo-nickname. For example, if there are LAALP IDs of different length, then the LAALP IDs of each size would have to be listed in a separate sub-TLV.
このサブTLVは、同じRBv疑似ニックネームで複数回発生することがあります。これは、リストされているすべてのLAALPがその疑似ニックネームによって識別されることを意味します。たとえば、異なる長さのLAALP IDがある場合、各サイズのLAALP IDを個別のサブTLVにリストする必要があります。
Because a PN-RBv APPsub-TLV is distributed as part of the application link state by using the E-L1FS FS-LSP [RFC7780], creation, changes to contents, or withdrawal of a PN-RBv APPsub-TLV is accomplished by the Designated RBridge updating and flooding an E-L1FS PDU.
PN-RBv APPsub-TLVは、E-L1FS FS-LSP [RFC7780]を使用してアプリケーションリンク状態の一部として配布されるため、PN-RBv APPsub-TLVの作成、内容の変更、または撤回は、 E-L1FS PDUを更新およびフラッディングする指定のRBridge。
On receipt of such a sub-TLV, if RBn is not an LAALP related edge RBridge, it ignores the sub-TLV. Otherwise, if RBn is also a member RBridge of the RBv identified by the list of LAALPs, it associates the pseudo-nickname with the ports of these LAALPs and downloads the association to data-plane fast path logic. At the same time, RBn claims the RBv's pseudo-nickname across the campus and announces the RBv as its child on the corresponding tree or trees using the Affinity sub-TLV [RFC7176] [RFC7783].
そのようなサブTLVを受信すると、RBnがLAALP関連のエッジRBridgeでない場合、サブTLVは無視されます。それ以外の場合、RBnがLAALPのリストで識別されるRBvのメンバーRBridgeでもある場合、RBNは疑似ニックネームをこれらのLAALPのポートに関連付け、関連付けをデータプレーン高速パスロジックにダウンロードします。同時に、RBnはキャンパス全体でRBvの疑似ニックネームを要求し、Affinity sub-TLV [RFC7176] [RFC7783]を使用して、対応するツリー上の子としてRBvをアナウンスします。
In this document, two APPsub-TLVs are used as boundary APPsub-TLVs for an edge RBridge to enclose the MAC-RI TLV(s) containing the MAC address information learned from the local port of an LAALP when this RBridge wants to share the information with other edge RBridges. They are defined as TRILL APPsub-TLVs [RFC7357]. The PN-MAC-RI-LAALP-INFO-START APPsub-TLV has the following format:
このドキュメントでは、2つのAPPsub-TLVが境界RBridgeの境界APPsub-TLVとして使用され、このRBridgeが情報を共有する場合に、LAALPのローカルポートから学習したMACアドレス情報を含むMAC-RI TLVを囲みます。他のエッジRBridgeと。それらはTRILL APPsub-TLVs [RFC7357]として定義されています。 PN-MAC-RI-LAALP-INFO-START APPsub-TLVの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=PN-MAC-RI-LAALP-INFO-START| (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
| LAALP ID | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+
o PN-MAC-RI-LAALP-INFO-START (2 bytes): Defines the type of this sub-TLV, 4.
o PN-MAC-RI-LAALP-INFO-START（2バイト）：このサブTLVのタイプを定義します、4。
o Length (2 bytes): The size of the following LAALP ID. 8 if the LAALP listed is an MC-LAG or DRNI.
o 長さ（2バイト）：次のLAALP IDのサイズ。リストされているLAALPがMC-LAGまたはDRNIの場合は8。
o LAALP ID (variable): The ID of the LAALP (see Section 9.4).
o LAALP ID（変数）：LAALPのID（セクション9.4を参照）。
The PN-MAC-RI-LAALP-INFO-END APPsub-TLV is defined as follows:
PN-MAC-RI-LAALP-INFO-END APPsub-TLVは次のように定義されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=PN-MAC-RI-LAALP-INFO-END | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o PN-MAC-RI-LAALP-INFO-END (2 bytes): Defines the type of this sub-TLV, 5.
o PN-MAC-RI-LAALP-INFO-END（2バイト）：このサブTLVのタイプ、5を定義します。
o Length (2 bytes): 0.
o 長さ（2バイト）：0。
This pair of APPsub-TLVs can be carried multiple times in an ESADI-LSP and in multiple ESADI-LSPs. When an LAALP related edge RBridge (say RBn) wants to share with other edge RBridges the MAC addresses learned on its local ports of different LAALPs, it uses one or more pairs of such APPsub-TLVs for each such LAALP in its ESADI-LSPs. Each encloses the MAC-RI TLVs containing the MAC addresses learned from a specific LAALP. Furthermore, if the LAALP is served by a local RBv, the value of the Topology-ID/Nickname field in the relative MAC-RI TLVs SHOULD be the pseudo-nickname of the RBv, rather than one of RBn's regular nicknames or a zero value. Then, on receipt of such a MAC-RI TLV, remote RBridges know that the contained MAC addresses are reachable through the RBv.
このAPPsub-TLVのペアは、ESADI-LSPおよび複数のESADI-LSPで複数回伝送できます。 LAALP関連のエッジRBridge（たとえばRBn）が他のエッジRBridgeと、異なるLAALPのローカルポートで学習したMACアドレスを共有する場合、ESADI-LSP内のそのような各LAALPに対して、そのようなAPPsub-TLVの1つ以上のペアを使用します。それぞれが、特定のLAALPから学習したMACアドレスを含むMAC-RI TLVを囲みます。さらに、LAALPがローカルRBvによって提供される場合、相対MAC-RI TLVのTopology-ID / Nicknameフィールドの値は、RBnの通常のニックネームの1つまたはゼロ値ではなく、RBvの疑似ニックネームである必要があります（SHOULD）。 。次に、そのようなMAC-RI TLVを受信すると、リモートRBridgeは、含まれているMACアドレスがRBvを介して到達可能であることを認識します。
On receipt of such boundary APPsub-TLVs, when the edge RBridge is not an LAALP related one or cannot recognize such sub-TLVs, it ignores them and continues to parse the enclosed MAC-RI TLVs per [RFC7357]. Otherwise, the recipient parses the boundary APPsub-TLVs. The PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-END pair MUST occur within one TRILL GENINFO TLV. If an END is encountered without any previous START in the ESADI-LSP, the END APPsub-TLV is ignored. After encountering a START, if the end of the ESADI-LSP is reached without encountering an END, then the end of the ESADI-LSP is treated as if it were a PN-MAC-RI-LAALP-INFO-END. The boundary APPsub-TLVs and TLVs between them are handled as follows:
そのような境界APPsub-TLVを受信すると、エッジRBridgeがLAALP関連のものではないか、そのようなサブTLVを認識できない場合、それらは無視され、[RFC7357]に基づいて同封のMAC-RI TLVの解析が続行されます。それ以外の場合、受信者は境界APPsub-TLVを解析します。 PN-MAC-RI-LAALP-INFO-START / PN-MAC-RI-LAALP-INFO-ENDペアは、1つのTRILL GENINFO TLV内で発生する必要があります。 ESADI-LSP内に以前のSTARTなしでENDが検出された場合、END APPsub-TLVは無視されます。 STARTに遭遇した後、ENDに遭遇することなくESADI-LSPの終わりに達した場合、ESADI-LSPの終わりは、PN-MAC-RI-LAALP-INFO-ENDであるかのように扱われます。境界APPsub-TLVとそれらの間のTLVは、次のように処理されます。
1) If the edge RBridge is configured with the contained LAALP and the LAALP is also enabled locally, it treats all the MAC addresses contained in the following MC-RI TLVs enclosed by the corresponding pair of boundary APPsub-TLVs as if they were learned from its local port of that LAALP;
1）含まれているLAALPでエッジRBridgeが構成されており、LAALPもローカルで有効になっている場合、対応する境界APPsub-TLVのペアで囲まれた次のMC-RI TLVに含まれるすべてのMACアドレスが、それらから学習されたかのように扱われますそのLAALPのローカルポート。
2) Else, it ignores these boundary APPsub-TLVs and continues to parse the following MAC-RI TLVs per [RFC7357] until another pair of boundary APPsub-TLVs is encountered.
2）それ以外の場合は、これらの境界APPsub-TLVを無視し、別のペアの境界APPsub-TLVが検出されるまで、[RFC7357]に従って次のMAC-RI TLVを解析し続けます。
The LAALP ID identifies an AAE RBridge group in the TRILL campus and thus MUST be unique across the campus. In all of the APPsub-TLVs specified above, the length of the LAALP ID can be determined from a size field. If that length is 8 bytes, the LAALP ID is an MC-LAG or DRNI identifier as specified in Section 6.3.2 of [802.1AX]. The meaning and structure of LAALP IDs of other lengths are reserved and may be specified in future documents.
LAALP IDはTRILLキャンパス内のAAE RBridgeグループを識別するため、キャンパス全体で一意である必要があります。上記で指定したすべてのAPPsub-TLVで、LAALP IDの長さはサイズフィールドから決定できます。その長さが8バイトの場合、LAALP IDは、[802.1AX]のセクション6.3.2で指定されているMC-LAGまたはDRNI識別子です。他の長さのLAALP IDの意味と構造は予約されており、将来のドキュメントで指定される可能性があります。
Attention must be paid when generating Operations, Administration, and Maintenance (OAM) packets. To ensure that the response messages can return to the originating member RBridge of an RBv, a pseudo-nickname cannot be used as the ingress nickname in TRILL OAM messages, except in the response to an OAM message that has that RBv's pseudo-nickname as the egress nickname. For example, assume that RB1 is a member RBridge of RBvi. RB1 cannot use RBvi's pseudo-nickname as the ingress nickname when originating OAM messages; otherwise, the responses to the messages may be delivered to another member RBridge of RBvi rather than RB1. But when RB1 responds to the OAM message with RBvi's pseudo-nickname as the egress nickname, it can use that pseudo-nickname as the ingress nickname in the response message.
Operations、Administration、and Maintenance（OAM）パケットを生成するときは注意が必要です。応答メッセージがRBvの元のメンバーであるRBridgeに確実に戻るようにするために、そのRBvの疑似ニックネームをOAMメッセージとして含むOAMメッセージへの応答以外では、疑似ニックネームをTRILL OAMメッセージの入力ニックネームとして使用できません出力ニックネーム。たとえば、RB1がRBviのメンバーRBridgeであるとします。 RB1は、OAMメッセージの発信時に、RBviの疑似ニックネームを入力ニックネームとして使用できません。そうでない場合、メッセージへの応答は、RB1ではなく、RBviの別のメンバーRBridgeに配信されます。ただし、RB1がRBviの疑似ニックネームを出力ニックネームとしてOAMメッセージに応答する場合、その疑似ニックネームを応答メッセージの入力ニックネームとして使用できます。
Since RBridges cannot use OAM messages for the learning of MAC addresses (Section 3.2.1 of [RFC7174]), it will not lead to MAC address flip-flopping at a remote RBridge, even though RB1 uses its regular nicknames as ingress nicknames in its TRILL OAM messages, and at the same time RB1 uses RBvi's pseudo-nickname in its TRILL Data packets.
RBridgesはMACアドレスの学習にOAMメッセージを使用できないため（[RFC7174]のセクション3.2.1）、RB1が通常のニックネームを入力ニックネームとして使用している場合でも、リモートRBridgeでMACアドレスのフリップフロップは発生しません。 TRILL OAMメッセージと同時に、RB1はTRILLデータパケットでRBviの疑似ニックネームを使用します。
The VLAN membership of all the RBridge ports in an LAALP MUST be the same. Any inconsistencies in VLAN membership may result in packet loss or non-shortest paths.
LAALPのすべてのRBridgeポートのVLANメンバーシップは同じである必要があります。 VLANメンバーシップに不整合があると、パケットが失われたり、最短パスにならない場合があります。
Take Figure 1 as an example. Suppose that RB1 configures VLAN1 and VLAN2 for the CE1-RB1 link, while RB2 only configures VLAN1 for the CE1-RB2 link. Both RB1 and RB2 use the same ingress nickname RBv for all frames originating from CE1. Hence, a remote RBridge (say RBx) will learn that CE1's MAC address in VLAN2 is originating from the RBv. As a result, on the return path, RBx may deliver VLAN2 traffic to RB2. However, RB2 does not have VLAN2 configured on the CE1-RB2 link, and hence the frame may be dropped or has to be redirected to RB1 if RB2 knows that RB1 can reach CE1 in VLAN2.
図1を例にとります。 RB1がCE1-RB1リンクのVLAN1とVLAN2を構成し、RB2がCE1-RB2リンクのVLAN1のみを構成するとします。 RB1とRB2の両方が、CE1から発信されたすべてのフレームに同じ入力ニックネームRBvを使用します。したがって、リモートRBridge（RBxなど）は、VLAN2のCE1のMACアドレスがRBvから発信されていることを学習します。その結果、リターンパスで、RBxはVLAN2トラフィックをRB2に配信する可能性があります。ただし、RB2ではCE1-RB2リンクにVLAN2が設定されていないため、RB1がVLAN2のCE1に到達できることをRB2が認識している場合、フレームがドロップされるか、RB1にリダイレクトされる必要があります。
How LAALP implementations maintain consistent VLAN configuration on the TRILL switch LAALP ports is out of scope for the TRILL protocol. However, considering the consequences that might be caused by inconsistencies, TRILL switches MUST disable the ports connected to an LAALP with an inconsistent VLAN configuration.
LAALP実装がTRILLスイッチの一貫したVLAN構成を維持する方法LAALPポートはTRILLプロトコルの範囲外です。ただし、不整合によって引き起こされる可能性のある結果を考慮して、TRILLスイッチは、一貫性のないVLAN構成でLAALPに接続されたポートを無効にする必要があります。
It is important that if any VLAN in an LAALP is being mapped by edge RBridges to an FGL [RFC7172] the mapping MUST be the same for all edge RBridge ports in the LAALP. Otherwise, for example, unicast FGL TRILL Data packets from remote RBridges may get mapped into different VLANs, depending on which edge RBridge receives and egresses them.
LAALPのいずれかのVLANがエッジRBridgesによってFGL [RFC7172]にマッピングされている場合、LAALPのすべてのエッジRBridgeポートでマッピングが同じである必要があります。それ以外の場合、たとえば、リモートRBridgeからのユニキャストFGL TRILLデータパケットは、どのエッジRBridgeがそれらを受信して出力するかに応じて、異なるVLANにマッピングされる可能性があります。
It is important that RBridges in an AAE group not be configured to assert the OE-flag if any RBridge in the group does not implement it. Since, as stated in [RFC7379], the RBridges in an AAE edge group are expected to be from the same vendor, due to the proprietary nature of deployed LAALPs, this will normally follow automatically from all of the RBridges in an AAE edge group supporting, or not supporting, OE.
グループ内のRBridgeがそれを実装していない場合、AAEグループ内のRBridgeがOEフラグをアサートするように構成されていないことが重要です。 [RFC7379]で述べられているように、AAEエッジグループのRBridgeは同じベンダーのものであることが期待されているため、展開されたLAALPの独自の性質により、これは通常、サポートするAAEエッジグループのすべてのRBridgeから自動的に続きます。 、またはサポートしていません。
Authenticity for contents transported in IS-IS PDUs is enforced using regular IS-IS security mechanisms [IS-IS] [RFC5310].
IS-IS PDUで転送されるコンテンツの信頼性は、通常のIS-ISセキュリティメカニズム[IS-IS] [RFC5310]を使用して実施されます。
For security considerations pertaining to extensions transported by TRILL ESADI, see the Security Considerations section in [RFC7357].
TRILL ESADIによって転送される拡張機能に関連するセキュリティの考慮事項については、[RFC7357]のセキュリティに関する考慮事項のセクションを参照してください。
Since currently deployed LAALPs [RFC7379] are proprietary, security over membership in, and internal management of, active-active edge groups is proprietary. If authentication is not used, a rogue RBridge that insinuates itself into an active-active edge group can disrupt end-station traffic flowing into or out of that group. For example, if there are N RBridges in the group, it could typically control 1/Nth of the traffic flowing out of that group and a similar amount of unicast traffic flowing into that group. For multi-destination traffic flowing into that group, it could control all that was in a VLAN for which it was the DF and can exercise substantial control over the DF election by changing its own System ID.
現在展開されているLAALP [RFC7379]は独自仕様であるため、アクティブ-アクティブエッジグループのメンバーシップおよび内部管理に関するセキュリティは独自仕様です。認証が使用されていない場合、自身をアクティブ/アクティブエッジグループに含める不正なRBridgeは、そのグループに出入りするエンドステーショントラフィックを妨害する可能性があります。たとえば、グループにN個のRBridgeがある場合、通常、そのグループから流出するトラフィックの1 / Nと、そのグループに流入する同様の量のユニキャストトラフィックを制御できます。そのグループに流入する複数の宛先トラフィックの場合、それはそれがDFであるVLAN内にあったものすべてを制御でき、独自のシステムIDを変更することによりDFの選択を大幅に制御できます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
IANA has allocated four code points from the range below 255 for the four TRILL APPsub-TLVs specified in Section 9 and added them to the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry, as follows:
IANAは、セクション9で指定された4つのTRILL APPsub-TLVに255未満の範囲から4つのコードポイントを割り当て、次のようにそれらを「IS-IS TLV 251アプリケーションID 1のTRILL APPsub-TLVタイプ」レジストリに追加しました。
Type Name Reference
---- -------------------------- ---------
2 PN-LAALP-Membership RFC 7781
3 PN-RBv RFC 7781
4 PN-MAC-RI-LAALP-INFO-START RFC 7781
5 PN-MAC-RI-LAALP-INFO-END RFC 7781
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", IEEE Std 802.1AX-2014, DOI 10.1109/IEEESTD.2014.7055197, December 2014.
[802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE Std 802.1AX-2014、DOI 10.1109 / IEEESTD.2014.7055197、2014年12月。
[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>。
[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>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<http：//www.rfc- editor.org/info/rfc6234>。
[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>。
[RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC 6439, DOI 10.17487/RFC6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC6439] Perlman、R.、Eastlake、D.、Li、Y.、Banerjee、A.、and F. Hu、 "Routing Bridges（RBridges）：Appointed Forwarders"、RFC 6439、DOI 10.17487 / RFC6439、November 2011、 <http://www.rfc-editor.org/info/rfc6439>。
[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>。
[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フラッディングスコープリンクステートPDU（LSP）」、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>。
[RFC7783] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL)", RFC 7783, DOI 10.17487/RFC7783, February 2016, <http://www.rfc-editor.org/info/rfc7783>.
[RFC7783] Senevirathne、T.、Pathangi、J。、およびJ. Hudson、「多数のリンクの透過的相互接続（TRILL）のための協調マルチキャストツリー（CMT）」、RFC 7783、DOI 10.17487 / RFC7783、2016年2月、<http ：//www.rfc-editor.org/info/rfc7783>。
[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, November 2002.
[IS-IS]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用する、中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル（ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, <http://www.rfc-editor.org/info/rfc7174>.
[RFC7174] Salam、S.、Senevirathne、T.、Aldrin、S。、およびD. Eastlake 3rd、「透過的な相互リンクの多くのリンク（TRILL）運用、管理、および保守（OAM）フレームワーク」、RFC 7174、DOI 10.17487 / RFC7174、2014年5月、<http://www.rfc-editor.org/info/rfc7174>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc7379>。
[RFC7782] Zhang, M., Perlman, R., Zhai, H., Durrani, M., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments", RFC 7782, DOI 10.17487/RFC7782, February 2016, <http://www.rfc-editor.org/info/rfc7782>.
[RFC7782] Zhang、M.、Perlman、R.、Zhai、H.、Durrani、M。、およびS. Gupta、「複数のMACアタッチメントを使用したリンクの透過的相互接続（TRILL）アクティブ-アクティブエッジ」、RFC 7782 、DOI 10.17487 / RFC7782、2016年2月、<http://www.rfc-editor.org/info/rfc7782>。
Acknowledgments
謝辞
We would like to thank Mingjiang Chen for his contributions to this document. Additionally, we would like to thank Erik Nordmark, Les Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Janardhanan Pathangi, Jon Hudson, and Fangwei Hu for their good questions and comments.
このドキュメントへの貢献に感謝した明江陳氏に感謝します。さらに、Erik Nordmark、Les Ginsberg、Ayan Banerjee、Dinesh Dutt、Anoop Ghanwani、Janardhanan Pathangi、Jon Hudson、およびFangwei Huの質問とコメントに感謝します。
Contributors
貢献者
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニューNaN京210012中国
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States
Donald E. Eastlake 3rd Huawei Technologies 155 Beaver Streetミルフォード、MA 01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Authors' Addresses
著者のアドレス
Hongjun Zhai Jinling Institute of Technology 99 Hongjing Avenue, Jiangning District Nanjing, Jiangsu 211169 China
ニュージーランドの命令によると、インスティチュートオブテクノロジー99ホンアベニュー、江寧区NaN京、江蘇211169中国
Email: honjun.zhai@tom.com
Tissa Senevirathne Consultant
Tissa Senevirathneコンサルタント
Email: tsenevir@gmail.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
らぢあ ぺｒｌまん えＭＣ ２０１０ ２５６ｔｈ あゔぇぬえ ね、 ＃２００ べっぇゔえ、 わ ９８００７ うにてｄ Ｓたてｓ
Email: Radia@alum.mit.edu
Mingui Zhang Huawei Technologies No. 156 Beiqing Rd., Haidian District Beijing 100095 China
min鬼Zhang hu Aはテクノロジーno。156 be iqing RD。、Hショートポイント地区北京100095中国
Email: zhangmingui@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56625409
Email: liyizhou@huawei.com