[要約] RFC 8361は、TRILLプロトコルにおけるアクティブ-アクティブなブロードキャスト、不明なユニキャスト、マルチキャスト（BUM）トラフィックのための集中型レプリケーションについて説明しています。このRFCの目的は、TRILLネットワークでのBUMトラフィックの効率的な処理とスケーラビリティの向上を実現することです。
Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 8361 Y. Li
Updates: 6325 Huawei Technologies
Category: Standards Track M. Durrani
ISSN: 2070-1721 Equinix
S. Gupta
IP Infusion
A. Qu
MediaTec
April 2018
Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic
多数のリンクの透過的相互接続（TRILL）：アクティブ-アクティブブロードキャスト、不明なユニキャスト、およびマルチキャスト（BUM）トラフィックの集中レプリケーション
Abstract
概要
In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325.
多くのリンクの透過的相互接続（TRILL）アクティブ-アクティブアクセスで、RFC 7781で指定されている疑似ニックネームメカニズムを使用すると、リバースパス転送（RPF）チェックエラーの問題が発生することがあります。このドキュメントでは、このRPFチェックエラーを解決するソリューションについて説明します集中レプリケーションによる問題。すべての入力ルーティングブリッジ（RBridge）は、ブロードキャスト、不明なユニキャスト、およびマルチキャスト（BUM）トラフィックを、ユニキャストTRILLカプセル化を使用して集中型ノードに送信します。集中ノードはBUMトラフィックを受信すると、パケットのカプセル化を解除し、TRILLベースプロトコル（RFC 6325）に従って確立された配布ツリーを使用して、それらを宛先RBridgeに転送します。入力RBridgeと集中型レプリケーションノードの間にあるRBridgeでRPFチェックの失敗を回避するには、RPF計算アルゴリズムに変更を加える必要があります。各RBridgeのRPFチェックは、中央のノードが実際の入力RBridgeを使用して計算されるのではなく、入力RBridgeであるかのように計算される必要があります。このドキュメントはRFC 6325を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8361.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8361で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Centralized Replication Solution Overview .......................4
4. Frame Duplication from Remote RBridge ...........................6
5. Local Forwarding Behavior on Ingress RBridge ....................6
6. Loop Prevention among RBridges in an Edge Group .................8
7. Centralized Replication Forwarding Process ......................9
8. BUM Traffic Load-Balancing among Multiple Centralized Nodes ....10
9. Coexisting with the CMT Solution (RFC 7783) ....................11
10. Network Upgrade Analysis ......................................12
11. TRILL Protocol Extensions .....................................13
11.1. "R" and "C" Flag in the Nickname Flags APPsub-TLV ........13
12. Security Considerations .......................................14
13. IANA Considerations ...........................................14
14. References ....................................................15
14.1. Normative References .....................................15
14.2. Informative References ...................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The IETF TRILL protocol [RFC6325] provides multipath data forwarding that is loop free and per-hop based with minimum configuration. TRILL uses IS-IS [RFC6165] [RFC7176] as its control plane routing protocol and defines a TRILL-specific header for user data.
IETF TRILLプロトコル[RFC6325]は、最小限の構成でループのないホップ単位のマルチパスデータ転送を提供します。 TRILLはIS-IS [RFC6165] [RFC7176]をコントロールプレーンルーティングプロトコルとして使用し、ユーザーデータのTRILL固有のヘッダーを定義します。
Customer Equipment (CE) devices can be multihomed to a set of edge RBridges forming an edge group where active-active service can be provided. In that case, all of the uplinks from a CE 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) [IEEE802.1AX]. An active-active flow-based load-sharing mechanism can achieve better load-balancing and high reliability. A CE device can be a Layer 3 (L3) end system by itself or a bridge switch through which L3 end systems access the TRILL campus.
Customer Equipment（CE）デバイスは、アクティブ-アクティブサービスを提供できるエッジグループを形成するエッジRBridgeのセットにマルチホーム化できます。その場合、CEからのすべてのアップリンクは、Multi-Chassis Link Aggregation（MC-LAG）やDistributed Resilient Network Interconnect（DRNI）[IEEE802。などのLocal Active-Active Link Protocol（LAALP）[RFC7379]を介して処理されます。 1AX]。アクティブ-アクティブフローベースの負荷分散メカニズムは、より優れた負荷分散と高い信頼性を実現できます。 CEデバイスは、それ自体がレイヤ3（L3）エンドシステム、またはL3エンドシステムがTRILLキャンパスにアクセスするためのブリッジスイッチにすることができます。
In active-active access, the pseudo-nickname solution in [RFC7781] can be used to avoid Media Access Control (MAC) flip-flop on remote RBridges. The basic idea is to use a virtual RBridge (RBv) with a single pseudo-nickname to represent an edge group. Any member RBridge of that edge group uses this pseudo-nickname rather than its own nickname as the ingress nickname when it injects TRILL data frames to the TRILL campus. The use of the nickname solves the address flip-flop issue by setting the nickname learned by a remote RBridge to be the pseudo-nickname. However, it introduces another issue of incorrect packet dropping as follows: When a pseudo-nickname is used by an edge RBridge as the ingress nickname to forward BUM traffic, any RBridges (RBn) sitting between the ingress RBridge and the distribution tree root will treat the traffic as if it were ingressed from the RBv. If the same distribution tree is used by different edge RBridges of the same RBv, the traffic may arrive at some RBn from different ports. Then, the Reverse Path Forwarding (RPF) check required by TRILL [RFC6325] fails, and the BUM traffic received on unexpected ports will be dropped by RBn.
アクティブ-アクティブアクセスでは、[RFC7781]の疑似ニックネームソリューションを使用して、リモートRBridgeでのメディアアクセス制御（MAC）フリップフロップを回避できます。基本的な考え方は、エッジグループを表すために、単一の疑似ニックネームを持つ仮想RBridge（RBv）を使用することです。そのエッジグループのメンバーRBridgeは、TRILLデータフレームをTRILLキャンパスに挿入するときに、独自のニックネームではなくこの疑似ニックネームを入力ニックネームとして使用します。ニックネームを使用すると、リモートRBridgeが学習したニックネームを疑似ニックネームに設定することにより、アドレスフリップフロップの問題が解決されます。ただし、次のように、不正なパケットドロップの別の問題が発生します。疑似ニックネームがエッジRBridgeによって入力ニックネームとして使用され、BUMトラフィックを転送すると、入力RBridgeと配布ツリールートの間にあるすべてのRBridge（RBn）が処理されます。あたかもRBvから入ったかのようにトラフィック。同じディストリビューションツリーが同じRBvの異なるエッジRBridgeで使用されている場合、トラフィックは異なるポートからいくつかのRBnに到着する可能性があります。次に、TRILL [RFC6325]で必要なリバースパス転送（RPF）チェックが失敗し、予期しないポートで受信されたBUMトラフィックはRBnによってドロップされます。
This document specifies a centralized replication solution for BUM traffic forwarding to resolve the issue of incorrect packet drop caused by the RPF check failure in the virtual RBridge case. The basic idea is that all ingress RBridges send BUM traffic to a centralized node, which MUST be a distribution tree root, using unicast TRILL encapsulation. When the centralized node receives the packets, it decapsulates and forwards them to their destination RBridges using a distribution tree established as per the TRILL base protocol. This document updates [RFC6325]; per [RFC6325], multi-destination traffic is ingressed to a multi-destination TRILL data packet. However, per this document, when using the centralized replication feature, multi-destination traffic is initially ingressed to a unicast TRILL data packet.
このドキュメントでは、仮想RBridgeの場合のRPFチェックエラーが原因で発生する不正なパケットドロップの問題を解決するためのBUMトラフィック転送の集中レプリケーションソリューションについて説明します。基本的な考え方は、すべての入力RBridgeが、ユニキャストTRILLカプセル化を使用して、分散ツリールートである必要がある集中ノードにBUMトラフィックを送信することです。集中ノードはパケットを受信すると、カプセル化を解除し、TRILLベースプロトコルに従って確立された配布ツリーを使用して宛先のRBridgeに転送します。このドキュメントは[RFC6325]を更新します。 [RFC6325]に従って、複数の宛先のトラフィックは複数の宛先のTRILLデータパケットに入力されます。ただし、このドキュメントによれば、集中レプリケーション機能を使用する場合、マルチ宛先トラフィックは最初にユニキャストTRILLデータパケットに入力されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The abbreviations and terminology in [RFC6325] are used herein with the following additions:
本書では、[RFC6325]の略語と用語を次のように追加して使用しています。
BUM: Broadcast, Unknown unicast, and Multicast
BUM：ブロードキャスト、不明なユニキャスト、およびマルチキャスト
CE: Customer Equipment (as in [RFC7783]), as relates to a device (end station or bridge). The device can be either physical or virtual equipment.
CE：デバイス（エンドステーションまたはブリッジ）に関連する顧客機器（[RFC7783]と同様）。デバイスは、物理装置または仮想装置のいずれかです。
Data Label: VLAN or Fine-Grained Labeled (FGL) [RFC7172]
データラベル：VLANまたはファイングレインラベル（FGL）[RFC7172]
DF: Designated Forwarder [RFC7781]
DF：Designated Forwarder [RFC7781]
FGL: Fine-Grained Label [RFC7172]
FGL：きめの細かいラベル[RFC7172]
LAALP: Local Active-Active Link Protocol [RFC7379]
LAALP：ローカルアクティブ-アクティブリンクプロトコル[RFC7379]
MAC flip flop: A problem where the attachment point of a MAC address appears to a remote switch to keep changing. See Section 3.3 of [RFC7379].
MACフリップフロップ：MACアドレスの接続点がリモートスイッチに表示され、変化し続ける問題。 [RFC7379]のセクション3.3をご覧ください。
MC-LAG: Multi-Chassis Link Aggregation
MC-LAG：マルチシャーシリンク集約
RPF: Reverse Path Forwarding
RPF：リバースパス転送
When an edge RBridge receives BUM traffic from a CE device, it uses unicast TRILL encapsulation instead of multicast encapsulation to send the packets to a centralized node. The centralized node MUST be a distribution tree root. Distribution tree roots are normally chosen to be high-capacity core RBridges with many high-bandwidth adjacencies. This constraint makes it practical, as described below, to support centralized replication with only software changes to transit RBridges.
エッジRBridgeは、CEデバイスからBUMトラフィックを受信すると、マルチキャストカプセル化の代わりにユニキャストTRILLカプセル化を使用して、パケットを集中型ノードに送信します。集中ノードは配布ツリーのルートでなければなりません。ディストリビューションツリーのルートは通常、多くの高帯域幅の隣接関係を持つ大容量コアRBridgeとして選択されます。この制約により、以下で説明するように、トランジットRBridgeへのソフトウェアの変更のみで集中レプリケーションをサポートすることが現実的になります。
The TRILL header of the unicast TRILL encapsulation contains an "ingress RBridge nickname" field and an "egress RBridge nickname" field [RFC6325]. If the ingress RBridge receives the BUM packet from a port that is in an active-active edge group using [RFC7781], it sets the ingress RBridge nickname to be the pseudo-nickname rather than its own nickname to avoid MAC flip-flop (see Section 3.3 of [RFC7379]) on remote RBridges. The egress RBridge nickname is set to a special nickname of the centralized node that is used to differentiate the centralized replication purpose unicast TRILL encapsulation from a normal unicast TRILL encapsulation. This special nickname is called an "R-nickname".
ユニキャストTRILLカプセル化のTRILLヘッダーには、「入力RBridgeニックネーム」フィールドと「出力RBridgeニックネーム」フィールド[RFC6325]が含まれています。入力RBridgeが[RFC7781]を使用してアクティブ-アクティブエッジグループ内のポートからBUMパケットを受信した場合、MACフリップフロップを回避するために、入力RBridgeニックネームをそれ自体のニックネームではなく疑似ニックネームに設定します（ [RFC7379]のセクション3.3）をリモートRBridgeで。出力RBridgeニックネームは、集中型レプリケーション目的のユニキャストTRILLカプセル化と通常のユニキャストTRILLカプセル化を区別するために使用される集中型ノードの特別なニックネームに設定されます。この特別なニックネームは「Rニックネーム」と呼ばれます。
When the centralized RBridge receives a unicast TRILL-encapsulated packet with its R-nickname as the egress nickname, it decapsulates the packet. Then, the centralized RBridge replicates and forwards the BUM packet to the packet's destination RBridges using one of the distribution trees established per the TRILL base protocol [RFC6325]. It MUST use a distribution tree whose tree root is the centralized RBridge itself. (An RBridge may be the root of more than one tree.) When the centralized RBridge forwards the BUM traffic, it simply sends it on the distribution tree as if it were a locally ingressed frame, except that the ingress nickname remains the same as that in the packet it received to ensure that the MAC address learning by all egress RBridges is bound to the pseudo-nickname.
集中型RBridgeは、Rニックネームを出力ニックネームとして持つユニキャストTRILLカプセル化パケットを受信すると、パケットのカプセル化を解除します。次に、集中型RBridgeは、TRILLベースプロトコル[RFC6325]に従って確立された配信ツリーの1つを使用して、BUMパケットを複製し、パケットの宛先RBridgeに転送します。ツリールートが集中型RBridge自体である配布ツリーを使用する必要があります。 （RBridgeは複数のツリーのルートである場合があります。）中央集中型RBridgeがBUMトラフィックを転送するとき、ローカルイングレスフレームであるかのように、それをディストリビューションツリーに送信しますが、イングレスニックネームは同じです。受信したパケットで、すべての出力RBridgeによって学習されるMACアドレスが疑似ニックネームにバインドされていることを確認します。
When the replicated packet is forwarded by each RBridge along the distribution tree starting from the centralized node, an RPF check is performed per [RFC6325]. For any RBridge sitting between the ingress RBridge and the centralized replication node, the incoming port of such a BUM packet should be the centralized-node-facing port, as the multicast traffic always comes from the centralized node in this solution. However, the RPF port as the result of distribution tree calculation as specified in [RFC6325] will be the real ingress RBridge-facing port, as it uses the edge group's virtual RBridge as the ingress RBridge, so the RPF check will fail.
複製されたパケットが、集中型ノードから始まる配布ツリーに沿って各RBridgeによって転送されると、RPFチェックが[RFC6325]に従って実行されます。入力RBridgeと集中レプリケーションノードの間にあるRBridgeの場合、マルチキャストトラフィックは常にこのソリューションの集中ノードから送信されるため、このようなBUMパケットの受信ポートは集中ノードに面したポートである必要があります。ただし、[RFC6325]で指定された分散ツリー計算の結果としてのRPFポートは、エッジグループの仮想RBridgeを入力RBridgeとして使用するため、実際の入力RBridgeに面するポートとなり、RPFチェックは失敗します。
To solve this problem, some change in the RPF test is required. In this case, the RPF calculation on each RBridge should use the centralized node as the ingress RBridge for each tree for which that node is the root instead of the real ingress virtual RBridge to perform the calculation. As a result, the RPF check will accept traffic on the centralized-node-facing port of the RBridge for multi-destination traffic. This prevents incorrect frame drops by the RPF check.
この問題を解決するには、RPFテストに変更を加える必要があります。この場合、各RBridgeのRPF計算では、計算を実行するために、実際の入力仮想RBridgeではなく、そのノードがルートである各ツリーの入力RBridgeとして、集中型ノードを使用する必要があります。その結果、RPFチェックは、複数の宛先のトラフィックについて、RBridgeの集中ノードに面したポート上のトラフィックを受け入れます。これにより、RPFチェックによる誤ったフレームドロップが防止されます。
The change in the actual RPF check on a received multi-destination TRILL data packet is easy. The RPF check from [RFC6325] is a check to see if a triple of {ingress nickname, tree, receiving RBridge port} is allowed. (The tree is indicated by the nickname of its root, which is stored in the TRILL Header "egress nickname" field.) When determining the RPF check, if "ingress nickname" is using centralized replication (indicated by a C-nickname, see Section 9), then the check is based on distribution from the tree root. If "ingress nickname" is not using centralized replication, then the check is based on distribution from the RBridge having the ingress nickname.
受信した複数の宛先のTRILLデータパケットに対する実際のRPFチェックの変更は簡単です。 [RFC6325]からのRPFチェックは、{入力ニックネーム、ツリー、受信RBridgeポート}のトリプルが許可されているかどうかを確認するチェックです。 （ツリーはそのルートのニックネームで示され、TRILLヘッダーの「出力ニックネーム」フィールドに格納されます。）RPFチェックを判別するときに、「入力ニックネーム」が集中型レプリケーションを使用しているかどうか（Cニックネームで示されます。セクション9）の場合、チェックはツリールートからの配布に基づいています。 「入力ニックネーム」が集中型レプリケーションを使用していない場合、チェックは、入力ニックネームを持つRBridgeからの配布に基づいています。
To differentiate the centralized replication unicast TRILL encapsulation from normal unicast TRILL encapsulation, the R-nickname is introduced for centralized replication. When the centralized node receives unicast TRILL encapsulation traffic with the egress nickname R-nickname, it decapsulates the packet and then forwards the packet to the destination RBridges through a distribution tree for which it is the root by re-encapsulation as aforementioned. In TRILL, RBridges can hold multiple nicknames, so the centralized RBridge simply obtains another nickname to use as the R-nickname. The centralized RBridge or RBridges should announce their R-nickname to all TRILL campuses through the TRILL Link State PDU (LSP) extension specified in Section 11.
集中レプリケーションユニキャストTRILLカプセル化と通常のユニキャストTRILLカプセル化を区別するために、集中レプリケーション用にRニックネームが導入されました。中央集中型ノードは、出力ニックネームR-ニックネームのユニキャストTRILLカプセル化トラフィックを受信すると、パケットのカプセル化を解除し、前述の再カプセル化によってルートである配布ツリーを通じてパケットを宛先RBridgeに転送します。 TRILLでは、RBridgeは複数のニックネームを保持できるため、集中型RBridgeは、Rニックネームとして使用する別のニックネームを取得するだけです。中央集中型RBridgeは、セクション11で指定されたTRILL Link State PDU（LSP）拡張を通じて、すべてのTRILLキャンパスにRニックネームを通知する必要があります。
Frame duplication may occur when a remote host sends a multi-destination frame to a local CE that has an active-active connection to the TRILL campus. To avoid the local CE receiving multiple copies from a remote RBridge, the Designated Forwarder (DF) mechanism is supported for egress-direction multicast traffic.
リモートホストがTRILLキャンパスへのアクティブ/アクティブ接続を持つローカルCEに複数の宛先フレームを送信すると、フレームの重複が発生する可能性があります。ローカルCEがリモートRBridgeから複数のコピーを受信することを回避するために、出力方向マルチキャストトラフィックに対してDesignated Forwarder（DF）メカニズムがサポートされています。
The DF election mechanism [RFC7781] allows only one port of one RBridge in an active-active group to forward multicast traffic from the TRILL campus to the local access side for each VLAN. The basic idea of using DF is to elect one RBridge per VLAN from an edge group to be responsible for egressing the BUM traffic. [RFC7781] describes the DF election mechanism among member RBridges involved in an edge group.
DF選出メカニズム[RFC7781]では、アクティブ/アクティブグループ内の1つのRBridgeの1つのポートのみが、各VLANのTRILLキャンパスからローカルアクセス側にマルチキャストトラフィックを転送できます。 DFを使用する基本的な考え方は、BUMトラフィックの出力を担当するエッジグループからVLANごとに1つのRBridgeを選択することです。 [RFC7781]は、エッジグループに関与するメンバーRBridge間のDF選出メカニズムを説明しています。
If the DF election mechanism is used for frame-duplication prevention, access ports on an RBridge are categorized as one of three types: non-group, group DF port, and group non-DF port. The last two types can be called group ports. Each of the group ports is associated with a pseudo-nickname. If consistent nickname allocation to edge group RBridges is used, it is possible that the same pseudo-nickname is associated with more than one port on a single RBridge. A typical scenario is that CE1 is connected to RB1 and RB2 by LAALP1, whereas CE2 is connected to RB1 and RB2 by LAALP2. In order to conserve the number of pseudo-nicknames used, member ports for both LAALP1 and LAALP2 on RB1 and RB2 are all associated with the same pseudo-nickname.
フレーム重複防止にDF選択メカニズムが使用される場合、RBridge上のアクセスポートは、非グループ、グループDFポート、およびグループ非DFポートの3つのタイプのいずれかに分類されます。最後の2つのタイプは、グループポートと呼ぶことができます。各グループポートは、疑似ニックネームに関連付けられています。エッジグループRBridgeへのニックネームの一貫した割り当てが使用されている場合、同じ疑似ニックネームが単一のRBridge上の複数のポートに関連付けられている可能性があります。典型的なシナリオは、CE1がLAALP1によってRB1およびRB2に接続されているのに対し、CE2はLAALP2によってRB1およびRB2に接続されていることです。使用される疑似ニックネームの数を節約するために、RB1とRB2のLAALP1とLAALP2の両方のメンバーポートは、すべて同じ疑似ニックネームに関連付けられています。
When an ingress RBridge (RB1) receives BUM traffic from a local active-active connected CE (CE1) device, the traffic will be injected into the TRILL campus with TRILL encapsulation; it will be replicated and forwarded to all destination RBridges through central replication, including the ingress RBridge itself, along a TRILL distribution tree. To avoid the traffic looping back to the original sender CE, an ingress nickname of the CE group's pseudo-nickname is used for traffic filtering.
入力RBridge（RB1）がローカルのアクティブ-アクティブ接続されたCE（CE1）デバイスからBUMトラフィックを受信すると、トラフィックはTRILLカプセル化でTRILLキャンパスに注入されます。これは、TRILL配布ツリーに沿って、イングレスRBridge自体を含む中央レプリケーションを介して複製され、すべての宛先RBridgeに転送されます。トラフィックが元の送信者CEにループバックしないようにするために、CEグループの疑似ニックネームの入力ニックネームがトラフィックフィルタリングに使用されます。
However, if there are two CEs, say CE1 and CE2, connecting to the ingress RB1 and each associated with the same pseudo-nickname, RB1 needs to locally replicate and forward to CE2, because another copy of the BUM traffic between CE1 and CE2 through the TRILL campus will be blocked by the traffic filtering.
ただし、CE1とCE2の2つのCEがあり、入力RB1に接続し、それぞれが同じ疑似ニックネームに関連付けられている場合、RB1はローカルで複製してCE2に転送する必要があります。 TRILLキャンパスはトラフィックフィルタリングによってブロックされます。
If CE1 and CE2 are not associated with the same pseudo-nickname, the copy of the BUM traffic between CE1 and CE2 through the TRILL campus won't be blocked by the traffic filtering. To avoid duplicated traffic on receiver CE, there cannot be local replicated BUM traffic between these two CEs on ingress RB1.
CE1とCE2が同じ疑似ニックネームに関連付けられていない場合、TRILLキャンパスを介したCE1とCE2間のBUMトラフィックのコピーは、トラフィックフィルタリングによってブロックされません。レシーバーCEでのトラフィックの重複を回避するために、入力RB1のこれら2つのCE間にローカルで複製されたBUMトラフィックは存在できません。
In summary, to ensure correct BUM traffic forwarding behavior for each CE, the local replication behavior on the ingress RBridge is as follows:
要約すると、各CEの正しいBUMトラフィック転送動作を保証するために、入力RBridgeでのローカルレプリケーション動作は次のとおりです。
1. Replicate to the active-active group ports associated with the same pseudo-nickname as that associated with the incoming port.
1. 着信ポートに関連付けられているものと同じ疑似ニックネームに関連付けられているアクティブ-アクティブグループのポートに複製します。
2. Do not replicate to active-active group ports associated with other pseudo-nicknames.
2. 他の疑似ニックネームに関連付けられているアクティブ-アクティブグループポートには複製しないでください。
3. Do not replicate to non-edge-group ports.
3. エッジグループ以外のポートには複製しないでください。
The above local forwarding behavior on the ingress RBridge of RB1 can be called "centralized replication local forwarding behavior A".
RB1の入力RBridgeでの上記のローカル転送動作は、「集中レプリケーションローカル転送動作A」と呼ぶことができます。
If ingress RBridge RB1 itself is the centralized replication node, BUM traffic injected by RB1 into the TRILL campus won't loop back to RB1. In this case, the local forwarding behavior is called centralized replication local forwarding behavior B. Behavior B on RB1 is as follows:
入力RBridge RB1自体が集中レプリケーションノードである場合、RB1によってTRILLキャンパスに注入されたBUMトラフィックは、RB1にループバックしません。この場合、ローカル転送動作は集中レプリケーションローカル転送動作Bと呼ばれます。RB1での動作Bは次のとおりです。
1. Local replication to the ports associated with the same pseudo-nickname as that associated with the incoming port.
1. 着信ポートに関連付けられているものと同じ疑似ニックネームに関連付けられているポートへのローカル複製。
2. Local replication to the group DF port associated with different pseudo-nicknames. Do not replicate to group non-DF ports associated with different pseudo-nicknames.
2. 異なる疑似ニックネームに関連付けられたグループDFポートへのローカル複製。異なる疑似ニックネームに関連付けられている非DFポートをグループ化するために複製しないでください。
3. Local replication to non-edge-group ports.
3. エッジグループ以外のポートへのローカルレプリケーション。
If a CE sends a BUM packet through a DF port to an ingress RBridge, that RBridge will forward that packet to all or a subset of the other RBridges that only have non-DF ports for that active-active group. Because BUM traffic forwarding to non-DF ports isn't allowed, in this case, the frame won't loop back to the CE.
CEがDFポートを介してBUMパケットを入力RBridgeに送信すると、そのRBridgeは、そのアクティブ-アクティブグループの非DFポートのみを持つ他のRBridgeのすべてまたはサブセットにそのパケットを転送します。非DFポートへのBUMトラフィック転送は許可されていないため、この場合、フレームはCEにループバックしません。
If a CE sends a BUM packet through a non-DF port to an ingress RBridge, say RB1, then RB1 will forward that packet to other RBridges that have a DF port for that active-active group. In this case, the frame will loop back to the CE and the traffic split-horizon filtering mechanism is used to avoid looping back among RBridges in the edge group.
CEが非DFポートを介してBUMパケットを入力RBridge、たとえばRB1に送信すると、RB1はそのアクティブ-アクティブグループ用のDFポートを持つ他のRBridgeにそのパケットを転送します。この場合、フレームはCEにループバックし、トラフィックスプリットホライズンフィルタリングメカニズムを使用して、エッジグループ内のRBridge間のループバックを回避します。
This split-horizon mechanism relies on the ingress nickname field in the TRILL header to check if a packet's egress port belongs to the same active-active group as the packet's incoming port to the TRILL campus.
このスプリットホライズンメカニズムは、TRILLヘッダーの入力ニックネームフィールドを使用して、パケットの出力ポートがTRILLキャンパスへのパケットの受信ポートと同じアクティブ/アクティブグループに属しているかどうかを確認します。
When the ingress RBridge receives BUM traffic from an active-active connected CE device, the traffic will be sent through the TRILL campus with TRILL encapsulation to a centralized RBridge. There it will be replicated and forwarded to its destination RBridges, which include the ingress RBridge itself, through a TRILL distribution tree. If the same pseudo-nickname is used for two active-active access CEs as the ingress nickname, an egress RBridge can use that nickname to filter traffic forwarding to all local CEs. In this case, the traffic between these two CEs goes through the local RBridge and another copy of the traffic from the TRILL campus is filtered. If different ingress nicknames are used for two connecting CE devices, the access ports connecting to these two CEs should be isolated from each other. The BUM traffic between these two CEs should go through the TRILL campus; otherwise, the destination CE connected to same RBridge with the sender CE will receive two copies of the traffic.
入力RBridgeがアクティブ-アクティブに接続されたCEデバイスからBUMトラフィックを受信すると、トラフィックはTRILLカプセル化されたTRILLキャンパスを介して集中型RBridgeに送信されます。そこで複製され、TRILL配布ツリーを介して、入力RBridge自体を含む宛先RBridgeに転送されます。 2つのアクティブ-アクティブアクセスCEに同じニックネームが入力ニックネームとして使用されている場合、出力RBridgeはそのニックネームを使用して、すべてのローカルCEへのトラフィック転送をフィルタリングできます。この場合、これら2つのCE間のトラフィックはローカルRBridgeを通過し、TRILLキャンパスからのトラフィックの別のコピーがフィルタリングされます。 2つの接続CEデバイスに異なる入力ニックネームが使用されている場合、これら2つのCEに接続しているアクセスポートは互いに分離する必要があります。これら2つのCE間のBUMトラフィックはTRILLキャンパスを通過する必要があります。そうでない場合、送信側CEと同じRBridgeに接続されている宛先CEは、トラフィックの2つのコピーを受信します。
+-----------+
| (RB5) |
+-----------+
|
+-----------+
| (RB4) |
+-----------+
| | |
-------- | --------
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RB3)|
+------+ +------+ +------+
* | * | * | ^
* | * | * | ^
* ----------*-------------*-- ^
***************************** | ^
* | ^
LAALP1 * LAALP2 | ^
+------+ +------+ +------+
| CE1 | | CE2 | | CE3 |
+------+ +------+ +------+
Figure 1: TRILL Active-Active Access
図1：TRILLアクティブ-アクティブアクセス
Note: The asterisk line, hyphen & vertical bar line, and circumflex line in this figure indicate the connection of the various CEs to the various RBs.
注：この図のアスタリスク線、ハイフンと垂直バーの線、サーカムフレックス線は、さまざまなCEとさまざまなRBの接続を示しています。
Assuming the centralized replication solution is used in the example network of above Figure 1: RB5 is the distribution tree root and centralized replication node; CE1 and CE2 are active-active accessed to RB1, RB2, and RB3 through LAALP1 and LAALP2, respectively; and CE3 is single-homed to RB3. The RBridge's own nicknames of RB1 to RB5 are nick1 to nick5, respectively. RB1, RB2, and RB3 use the same pseudo-nickname for LAALP1 and LAALP2; that pseudo-nickname is P-nick. The R-nickname on the centralized replication node of RB5 is S-nick.
上記の図1のネットワーク例で集中型レプリケーションソリューションが使用されていると仮定すると、RB5は配布ツリーのルートであり、集中型レプリケーションノードです。 CE1およびCE2は、それぞれLAALP1およびLAALP2を介してRB1、RB2、およびRB3にアクセスされるアクティブ-アクティブです。また、CE3はRB3にシングルホームされています。 RBridge自身のRB1〜RB5のニックネームは、それぞれnick1〜nick5です。 RB1、RB2、およびRB3は、LAALP1およびLAALP2に同じ疑似ニックネームを使用します。その疑似ニックネームはP-ニックです。 RB5の集中レプリケーションノードのRニックネームはSニックネームです。
The BUM traffic forwarding process from CE1 to CE2 and CE3 is as follows:
CE1からCE2およびCE3へのBUMトラフィック転送プロセスは次のとおりです。
1. CE1 sends BUM traffic to RB3.
1. CE1はBUMトラフィックをRB3に送信します。
2. RB3 replicates and sends the BUM traffic to CE2 locally. RB2 also sends the traffic to RB5 using unicast TRILL encapsulation. In the TRILL Header, the ingress nickname is set as P-nick and the egress nickname is set as S-nick.
2. RB3はBUMトラフィックを複製し、CE2にローカルに送信します。 RB2はまた、ユニキャストTRILLカプセル化を使用してトラフィックをRB5に送信します。 TRILLヘッダーでは、入力ニックネームはP-nickとして設定され、出力ニックネームはS-nickとして設定されます。
3. RB5 decapsulates the unicast TRILL data packet. Then, it uses a distribution tree for which it is the root to forward the packet as a multi-destination TRILL data packet. The egress nickname in the multi-destination TRILL Header is the nick5 and the ingress nickname is still P-nick. If RB3 had sent the unicast to some nickname that was not an R-nickname, the packet would not be re-encapsulated. If it is sent to an R-nickname that is not a tree root, it either will not be forwarded at all or, if it is re-encapsulated and forwarded, will be subject to incorrect pruning and will not be delivered to all of its intended recipients.
3. RB5は、ユニキャストTRILLデータパケットのカプセル化を解除します。次に、ルートである配布ツリーを使用して、パケットを複数の宛先のTRILLデータパケットとして転送します。複数宛先のTRILLヘッダーの出口ニックネームはnick5であり、入口ニックネームは引き続きP-nickです。 RB3がRニックネームではないニックネームにユニキャストを送信した場合、パケットは再カプセル化されません。ツリールートではないRニックネームに送信された場合、それはまったく転送されないか、再カプセル化されて転送された場合、誤ったプルーニングの対象となり、そのすべてに配信されません。意図された受信者。
4. RB4 receives multicast TRILL traffic from RB5. The incoming traffic port is the up port facing the distribution tree root. RB4's RPF check will be correct based on the changed RPF port calculation algorithm in this document. After the RPF check is performed, it forwards the traffic to all other egress RBridges (RB1, RB2, and RB3).
4. RB4は、RB5からマルチキャストTRILLトラフィックを受信します。着信トラフィックポートは、配布ツリールートに面するアップポートです。このドキュメントで変更されたRPFポート計算アルゴリズムに基づいて、RB4のRPFチェックは正しいものになります。 RPFチェックが実行された後、トラフィックは他のすべての出力RBridge（RB1、RB2、およびRB3）に転送されます。
5. RB3 receives multicast TRILL traffic from RB4. It decapsulates the multi-destination TRILL data packet. Because the ingress nickname of P-nick is equivalent to the nickname of local LAALPs connecting to CE1 and CE2, RB3 doesn't forward the traffic to CE1 and CE2 to avoid a duplicated frame. RB3 only forwards the packet to CE3.
5. RB3は、RB4からマルチキャストTRILLトラフィックを受信します。複数の宛先のTRILLデータパケットのカプセル化を解除します。 P-nickの入力ニックネームは、CE1およびCE2に接続するローカルLAALPのニックネームと同等であるため、RB3は、フレームの重複を回避するためにトラフィックをCE1およびCE2に転送しません。 RB3はパケットをCE3にのみ転送します。
6. RB1 and RB2 receive multicast TRILL traffic from RB4. The forwarding process is similar to the process on RB3, i.e., because the ingress nickname of P-nick is equivalent to the nickname of the local LAALPs connecting CE1 and CE2, they also don't forward the traffic to local CE1 and CE2.
6. RB1とRB2は、RB4からマルチキャストTRILLトラフィックを受信します。転送プロセスはRB3のプロセスと同様です。つまり、P-nickの入力ニックネームは、CE1とCE2を接続するローカルLAALPのニックネームと同等であるため、トラフィックをローカルCE1とCE2に転送しません。
To support unicast TRILL encapsulation BUM traffic load-balancing, multiple centralized replication nodes can be deployed and the traffic can be spread over these nodes based on data label (VLAN or FGL). Furthermore, if it was desirable for a centralized node to be sent more of this BUM traffic, it could hold two or more R-nicknames. The share of BUM traffic it would receive would be proportional to the number of R-nicknames it held.
ユニキャストTRILLカプセル化BUMトラフィックのロードバランシングをサポートするために、複数の集中レプリケーションノードを展開し、データラベル（VLANまたはFGL）に基づいてこれらのノードにトラフィックを分散できます。さらに、集中ノードがこのBUMトラフィックをより多く送信することが望ましい場合は、2つ以上のRニックネームを保持できます。受信するBUMトラフィックの割合は、保持するRニックネームの数に比例します。
Assuming there are k different R-nicknames held by centralized nodes in a TRILL campus, the VLAN-based (or FGL-based [RFC7172]) load-balancing algorithm used by an ingress active-active access RBridge is as follows:
TRILLキャンパス内の集中型ノードが保持するk個の異なるRニックネームがあるとすると、入力アクティブ/アクティブアクセスRBridgeが使用するVLANベース（またはFGLベース[RFC7172]）のロードバランシングアルゴリズムは次のとおりです。
1. All R-nicknames are ordered and numbered from 0 to k-1 in ascending order, treating the nicknames as unsigned 16-bit integers.
1. すべてのRニックネームは、0からk-1まで昇順で番号が付けられ、ニックネームは符号なし16ビット整数として扱われます。
2. For data label ID m, choose the R-nickname whose index is given by (m mod k) as egress nickname for BUM traffic unicast TRILL encapsulation.
2. データラベルID mの場合、BUMトラフィックユニキャストTRILLカプセル化の出力ニックネームとして、（m mod k）によってインデックスが指定されるRニックネームを選択します。
For example, there are three R-Nicknames (RNs). The RNs will be ordered RN0 to RN2. Assuming there are five VLANs from VLAN ID1 to ID5 spreading among edge RBridges, the traffic in VLAN1 will go to RN1, VLAN2 will go to RN2, and so on.
たとえば、3つのRニックネーム（RN）があります。 RNは、RN0からRN2の順に注文されます。エッジRBridge間に広がるVLAN ID1からID5までの5つのVLANがあるとすると、VLAN1のトラフィックはRN1に行き、VLAN2はRN2に行く、というようになります。
When an ingress RBridge participating in an active-active connection receives BUM traffic from a local CE, the RBridge decides which R-nickname to send the traffic to based on the VLAN-based load-spreading algorithm; thus, data-label-based load-balancing for the BUM traffic can be achieved using multiple centralized nodes/multiple R-nicknames.
アクティブ-アクティブ接続に参加している入力RBridgeがローカルCEからBUMトラフィックを受信すると、RBridgeは、VLANベースの負荷分散アルゴリズムに基づいて、トラフィックを送信するRニックネームを決定します。したがって、BUMトラフィックのデータラベルベースのロードバランシングは、複数の集中ノード/複数のRニックネームを使用して実現できます。
+------+ +------+
|(RB6) | |(RB7) |
+------+ +------+
------------------|-----------|----------------------
| | | | |
+------+ +------+ +------+ +------+ +------+
|(RB1) | |(RB2) | |(RB3) | |(RB4) | |(RB5) |
+------+ +------+ +------+ +------+ +------+
| | | | |
------------ -------------------------
| |
+------+ +------+
| CE1 | | CE2 |
+------+ +------+
Figure 2: CMT and Centralized Replication Coexisting Scenario
図2：CMTと一元化されたレプリケーションの共存シナリオ
Both the centralized replication solution and the Coordinated Multicast Trees (CMT) solution from [RFC7783] rely on using pseudo-nicknames to avoid MAC flip-flop on remote RBridges. These two solutions can coexist in a single TRILL campus. Each solution can be selected by each active-active edge group of RBridges independently.
集中型レプリケーションソリューションと[RFC7783]のCoordinated Multicast Trees（CMT）ソリューションはどちらも、リモートRBridgeでのMACフリップフロップを回避するために、疑似ニックネームの使用に依存しています。これら2つのソリューションは、1つのTRILLキャンパスで共存できます。各ソリューションは、RBridgeのアクティブ/アクティブエッジグループごとに個別に選択できます。
As illustrated in Figure 2, RB1 and RB2 use CMT for CE1's active-active access; RB3, RB4, and RB5 use the centralized replication for CE2's active-active access.
図2に示すように、RB1とRB2はCE1のアクティブ/アクティブアクセスにCMTを使用します。 RB3、RB4、およびRB5は、CE2のアクティブ/アクティブアクセスに集中型レプリケーションを使用します。
For the centralized replication solution, edge group RBridges MUST announce the local pseudo-nickname using the Nickname Flags APPsub-TLV with C flag set. A nickname with the C flag set is called a "C-nickname". A transit RBridge will perform the centralized replication-specific RPF check algorithm if it receives TRILL data packets with a C-nickname as the ingress nickname.
集中型レプリケーションソリューションの場合、エッジグループRBridgesは、Cフラグが設定されたニックネームフラグAPPsub-TLVを使用してローカルの疑似ニックネームを通知する必要があります。 Cフラグが設定されたニックネームは、「Cニックネーム」と呼ばれます。中継RBridgeは、Cニックネームを入力ニックネームとして持つTRILLデータパケットを受信すると、レプリケーション固有のRPFチェックアルゴリズムを集中的に実行します。
An edge group using CMT [RFC7783] MUST NOT set the C flag on the pseudo-nickname it is using. This is already mandatory behavior because any RBridge originating a Nickname Flags APPsub-TLV is required by [RFC7780] to set any flag bit it does not know about to zero. If an edge RBridge using CMT [RFC7783] nevertheless set the C-bit for an edge group pseudo-nickname, it is very likely that BUM traffic encapsulated with that nickname as ingress would be incorrectly pruned early in its distribution and would, thus, reach few (possibly none) of its intended targets. To avoid confusion, a pseudo-nickname MUST NOT be shared between a centralized replication edge group and a CMT-based edge group.
CMT [RFC7783]を使用するエッジグループは、使用している疑似ニックネームにCフラグを設定してはなりません（MUST NOT）。 [RFC7780]は、ニックネームフラグAPPsub-TLVを発信するRBridgeが、不明なフラグビットをゼロに設定する必要があるため、これはすでに必須の動作です。それでもCMT [RFC7783]を使用するエッジRBridgeがエッジグループの疑似ニックネームのCビットを設定した場合、そのニックネームで入力としてカプセル化されたBUMトラフィックは、配信の早い段階で誤ってプルーニングされ、到達する可能性があります。意図されたターゲットのいくつか（おそらくなし）。混乱を避けるため、一元化されたレプリケーションエッジグループとCMTベースのエッジグループ間で疑似ニックネームを共有してはなりません（MUST NOT）。
Centralized nodes will typically need software and hardware upgrades to support centralized replication, which stitches together the TRILL unicast traffic decapsulation process and the process of normal TRILL multicast traffic forwarding along the distribution tree.
一元化されたノードは通常、一元化されたレプリケーションをサポートするためにソフトウェアとハードウェアのアップグレードを必要とします。これは、TRILLユニキャストトラフィックのカプセル化解除プロセスと、配布ツリーに沿った通常のTRILLマルチキャストトラフィック転送のプロセスを統合します。
Active-active connection edge RBridges will typically need software and hardware upgrades to support unicast TRILL encapsulation for BUM traffic; the process is similar to other head-end replication processes.
BUMトラフィックのユニキャストTRILLカプセル化をサポートするには、通常、アクティブ-アクティブ接続エッジRBridgeでソフトウェアとハードウェアのアップグレードが必要です。このプロセスは、他のヘッドエンドレプリケーションプロセスと似ています。
Transit nodes typically need only a software upgrade to support the changed RPF port calculation algorithm.
トランジットノードは通常、変更されたRPFポート計算アルゴリズムをサポートするためにソフトウェアのアップグレードのみを必要とします。
Two new flags, "R" and "C", are specified in the Nickname Flags APPsub-TLV [RFC7780]. A nickname with the R flag set is called an "R-nickname" and a nickname with the C flag set is called a "C-nickname". The R-nickname is a specialized nickname attached to a centralized node to differentiate unicast TRILL-encapsulated BUM traffic from normal unicast TRILL traffic. The C-nickname flag is set on the pseudo-nickname for each edge group that uses the centralized replication. A C-nickname is a specialized pseudo-nickname for which transit RBridges perform a different RPF check algorithm for TRILL data packets with the C-nickname in the ingress nickname field.
ニックネームフラグAPPsub-TLV [RFC7780]で、2つの新しいフラグ「R」と「C」が指定されています。 Rフラグが設定されたニックネームは「R-ニックネーム」と呼ばれ、Cフラグが設定されたニックネームは「C-ニックネーム」と呼ばれます。 Rニックネームは、ユニキャストTRILLでカプセル化されたBUMトラフィックを通常のユニキャストTRILLトラフィックと区別するために、集中ノードに接続された特殊なニックネームです。 Cニックネームフラグは、集中レプリケーションを使用する各エッジグループの疑似ニックネームに設定されます。 Cニックネームは、通過RBridgeが入力ニックネームフィールドにCニックネームを持つTRILLデータパケットに対して異なるRPFチェックアルゴリズムを実行するための特殊な疑似ニックネームです。
When active-active edge RBridges use centralized replication to forward BUM traffic, the R-nickname is used as the egress nickname and the C-nickname is used as ingress nickname in the TRILL header for the unicast TRILL encapsulation of BUM traffic.
アクティブ-アクティブエッジRBridgeが集中レプリケーションを使用してBUMトラフィックを転送する場合、R-ニックネームは出力ニックネームとして使用され、C-ニックネームはBUMトラフィックのユニキャストTRILLカプセル化のTRILLヘッダーで入力ニックネームとして使用されます。
If this APPsub-TLV is being advertised by an RBridge that does not have the nickname appearing in the Nickname Flags APPsub-TLV, the R and C flag bits in the APPsub-TLV MUST be treated as if they were zero. If an RBridge that is not a distribution tree root advertises an R-nickname, that nickname MUST NOT be treated as an R-nickname but rather as an ordinary nickname; that is, the R-nickname flag is ignored for all purposes if the nickname is held by an RBridge that is not a tree root.
このAPPsub-TLVが、ニックネームフラグAPPsub-TLVにニックネームが表示されていないRBridgeによってアドバタイズされている場合、APPsub-TLVのRおよびCフラグビットは、それらがゼロであるかのように扱わなければなりません（MUST）。配布ツリーのルートではないRBridgeがRニックネームをアドバタイズする場合、そのニックネームをRニックネームとしてではなく、通常のニックネームとして扱う必要があります。つまり、ニックネームがツリールートではないRBridgeによって保持されている場合、R-ニックネームフラグはすべての目的で無視されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE|R | C| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
o R = If the R flag is one, it indicates that the advertising TRILL switch holding Nickname is a centralized replication node, and Nickname is used as egress nickname for edge group RBridges to inject BUM traffic into the TRILL campus when the edge group RBridges use this centralized replication solution for active-active access. If the R flag is zero, that nickname will not be used for that purpose.
o R = Rフラグが1の場合、ニックネームを保持しているアドバタイズTRILLスイッチが集中レプリケーションノードであることを示し、エッジグループRBridgeがエッジグループRBridgeを使用する場合、ニックネームがエッジグループRBridgeの出力ニックネームとして使用され、BILLトラフィックをTRILLキャンパスに注入します。アクティブ/アクティブアクセスのための集中レプリケーションソリューション。 Rフラグがゼロの場合、そのニックネームはその目的には使用されません。
o C = If C flag is one, it indicates that the TRILL traffic with this nickname as an ingress nickname requires the special RPF check algorithm specified in Section 3. If the C flag is zero, that nickname will not be used for that purpose.
o C = Cフラグが1の場合、このニックネームを入力ニックネームとして持つTRILLトラフィックには、セクション3で指定された特別なRPFチェックアルゴリズムが必要であることを示します。Cフラグがゼロの場合、そのニックネームはその目的で使用されません。
Due to errors or due to transient inconsistent LSPs when the link state database is converging after a configuration change or the like, it is possible for there to be inconsistent Nickname Flags APPsub-TLVs for the same nickname. In this case, it is RECOMMENDED that the nickname be treated as if the R / C flag were set if any Nickname Flags APPsub-TLV for that nickname has the R / C flag set.
エラーや、構成変更などの後でリンク状態データベースが収束するときの一時的な一貫性のないLSPが原因で、同じニックネームに対して一貫性のないニックネームフラグAPPsub-TLVが存在する可能性があります。この場合、そのニックネームのニックネームフラグAPPsub-TLVにR / Cフラグが設定されている場合、R / Cフラグが設定されているかのようにニックネームを処理することをお勧めします。
This document does not introduce any extra security risks. A rogue RBridge that is a tree root can attract traffic by advertising an R-nickname. However, this does not represent a substantial increase in risk as RBridges could cause problems in a number of other ways by advertising low-cost adjacencies or making themselves the highest priority tree root or the like. In general, the protection against an untrusted device acting as an RBridge and wrecking havoc is to use IS-IS authentication [RFC5310] and configure and administer the TRILL campus so that only trusted RBridges have the authentication key.
このドキュメントでは、追加のセキュリティリスクは紹介していません。ツリールートである不正なRBridgeは、Rニックネームをアドバタイズすることでトラフィックを引き付けることができます。ただし、RBridgeが低コストの隣接関係をアドバタイズしたり、それら自体を最高の優先度のツリールートなどにすることにより、他の多くの方法で問題を引き起こす可能性があるため、これはリスクの大幅な増加を表すものではありません。一般に、信頼できないデバイスがRBridgeとして機能し、大混乱を引き起こすことに対する保護は、IS-IS認証[RFC5310]を使用し、TRILLキャンパスを構成および管理して、信頼できるRBridgeのみが認証キーを持つようにすることです。
For general TRILL security considerations, see [RFC6325]. For security considerations related to pseudo-nickname active-active, see [RFC7781].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。疑似ニックネームactive-activeに関連するセキュリティの考慮事項については、[RFC7781]を参照してください。
IANA has assigned two bits in the Nickname Flags APPsubTLV flags for the R and C bits discussed in Section 11.1 and update the "NickFlags Bits" subregistry of the "Transparent Interconnection of Lots of Links (TRILL) Parameters" registry as follows:
IANAは、セクション11.1で説明したRおよびCビットのニックネームフラグAPPsubTLVフラグに2ビットを割り当て、「リンクの透過的な相互接続（TRILL）パラメータ」レジストリの「NickFlagsビット」サブレジストリを次のように更新しました。
Bit Mnemonic Description Reference
--- -------- -------------------- -----------
2 R Replication Nickname [RFC8361]
3 C Special RPF Check [RFC8361]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<https://www.rfc-editor.org/info/rfc5310>。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, DOI 10.17487/RFC6165, April 2011, <https://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月、<https://www.rfc-editor.org/info / rfc6165>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <https://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<https://www.rfc-editor.org/info/rfc6325>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <https://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<https://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <https://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<https://www.rfc-editor.org/info/rfc7176>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <https://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<https://www.rfc-editor.org/info/rfc7780>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC7781] Zhai, H., Senevirathne, T., Perlman, R., Zhang, M., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access", RFC 7781, DOI 10.17487/RFC7781, February 2016, <https://www.rfc-editor.org/info/rfc7781>.
[RFC7781] Zhai、H.、Senevirathne、T.、Perlman、R.、Zhang、M.、Y。Li、「多数のリンクの透過的な相互接続（TRILL）：アクティブ-アクティブアクセスの疑似ニックネーム」、RFC 7781、DOI 10.17487 / RFC7781、2016年2月、<https://www.rfc-editor.org/info/rfc7781>。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <https://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントと、リンクの透過的な相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標"、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<https://www.rfc-editor.org/info/rfc7379>。
[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, <https://www.rfc-editor.org/info/rfc7783>.
[RFC7783] Senevirathne、T.、Pathangi、J。、およびJ. Hudson、「多数のリンクの透過的な相互接続（TRILL）のための協調マルチキャストツリー（CMT）」、RFC 7783、DOI 10.17487 / RFC7783、2016年2月、<https ：//www.rfc-editor.org/info/rfc7783>。
[IEEE802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregation", IEEE 802.1AX, DOI 10.1109/IEEESTD.2017.7888436, March 2017, <http://ieeexplore.ieee.org/document/7888436/>.
[IEEE802.1AX] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Link Aggregation」、IEEE 802.1AX、DOI 10.1109 / IEEESTD.2017.7888436、March 2017、<http://ieeexplore.ieee.org/document/7888436 />。
Acknowledgments
謝辞
The authors wish to acknowledge the important contributions of Donald Eastlake, Hongjun Zhai, Xiaomin Wu, Liang Xia, and Francis Dupont.
著者は、ドナルドイーストレイク、ホンジュンジャイ、シャオミンウー、リャンシャ、フランシスデュポンの重要な貢献に感謝したいと思います。
Authors' Addresses
著者のアドレス
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Email: haoweiguo@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Email: liyizhou@huawei.com
Muhammad Durrani Equinix
ムハンマドデュラニエクイニクス
Email: mdurrani@equinix.com
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore - 560048 India
Sujay Gupta IP Infusion RMZ Centennial Mahadevapura Post Bangalore-560048インド
Email: sujay.gupta@ipinfusion.com
Andrew Qu MediaTec
Andrew Qu MediaTec
Email: laodulaodu@gmail.com