[要約] RFC 7379は、TRILLエッジでのアクティブ-アクティブ接続の問題と目標について説明しています。要約すると、このRFCの目的は、TRILLネットワークのエッジでのアクティブ-アクティブ接続の実現に関する問題を特定し、解決策を提案することです。
Internet Engineering Task Force (IETF) Y. Li
Request for Comments: 7379 W. Hao
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Perlman
EMC
J. Hudson
Brocade
H. Zhai
JIT
October 2014
Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge
多数のリンク（TRILL）エッジの透過的相互接続でのアクティブ-アクティブ接続の問題ステートメントと目標
Abstract
概要
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active-active connection at the TRILL edge.
IETF TRILL（多数のリンクの透過的相互接続）プロトコルは、フローレベルのマルチパスをサポートし、任意のトポロジーを持つネットワーク内のユニキャストおよびマルチ宛先トラフィックの両方に迅速なフェイルオーバーを提供します。 TRILLエッジでのアクティブ-アクティブ接続は、TRILLキャンパスに複数接続されている端末にこれらの特性を拡張したものです。この情報ドキュメントでは、TRILLエッジでアクティブ-アクティブ接続を提供する場合の高レベルの問題と目標について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7379.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7379で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Target Scenario .................................................4
2.1. LAALP and Edge Group Characteristics .......................6
3. Problems in Active-Active Connection at the TRILL Edge ..........7
3.1. Frame Duplications .........................................7
3.2. Loopback ...................................................8
3.3. Address Flip-Flop ..........................................8
3.4. Unsynchronized Information among Member RBridges ...........8
4. High-Level Requirements and Goals for Solutions .................9
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Acknowledgments ...................................................12
Authors' Addresses ................................................13
The IETF TRILL (Transparent Interconnection of Lots of Links) [RFC6325] protocol provides loop-free and per-hop-based multipath data forwarding with minimum configuration. TRILL uses IS-IS [IS-IS] [RFC6165] [RFC7176] as its control-plane routing protocol and defines a TRILL-specific header for user data. In a TRILL campus, communications between TRILL switches can:
IETF TRILL（多数のリンクの透過的相互接続）[RFC6325]プロトコルは、最小限の構成でループのないホップ単位のマルチパスデータ転送を提供します。 TRILLはIS-IS [IS-IS] [RFC6165] [RFC7176]をコントロールプレーンルーティングプロトコルとして使用し、ユーザーデータのTRILL固有のヘッダーを定義します。 TRILLキャンパスでは、TRILLスイッチ間の通信で次のことができます。
1) use multiple parallel links and/or paths,
1）複数の並列リンクやパスを使用します。
2) spread load over different links and/or paths at a fine-grained flow level through equal-cost multipathing of unicast traffic and multiple distribution trees for multi-destination traffic, and
2）ユニキャストトラフィックの等コストマルチパスとマルチ宛先トラフィックの複数の配信ツリーを介して、細かいフローレベルでさまざまなリンクやパスに負荷を分散します。
3) rapidly reconfigure to accommodate link or node failures or additions.
3）リンクまたはノードの障害または追加に対応するために迅速に再構成します。
To the degree practical, "active-active" is the extension of similar load spreading and robustness to the connections between end stations and the TRILL campus. Such end stations may have multiple ports and will be connected, directly or via bridges, to multiple edge TRILL switches. It must be possible, except in some failure conditions, to spread end-station traffic load at the granularity of flows across links to such multiple edge TRILL switches and rapidly reconfigure to accommodate topology changes.
「アクティブ-アクティブ」とは、実用的な程度で、エンドステーションとTRILLキャンパス間の接続に対する同様の負荷分散と堅牢性の拡張です。このようなエンドステーションには複数のポートがあり、直接またはブリッジを介して複数のエッジTRILLスイッチに接続されます。いくつかの障害状態を除いて、エンドステーションのトラフィック負荷をフローの粒度でリンク全体に渡ってそのような複数のエッジTRILLスイッチに分散させ、トポロジの変更に対応するために迅速に再構成できることが必要です。
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]で説明されているように解釈されます。
The acronyms and terminology in the RBridges base protocol [RFC6325] are used herein with the following additions:
RBridges基本プロトコル[RFC6325]の頭字語と用語は、以下の追加とともにここで使用されます。
CE: Customer Equipment (end station or bridge).
CE：カスタマー機器（エンドステーションまたはブリッジ）。
Data Label: VLAN or FGL (Fine-Grained Label [RFC7172]).
データラベル：VLANまたはFGL（細粒度ラベル[RFC7172]）。
LAALP: Local Active-Active Link Protocol. Any protocol similar to MC-LAG that runs in a distributed fashion on a CE, on the links from that CE to a set of edge group RBridges, and on those RBridges.
LAALP：ローカルアクティブ-アクティブリンクプロトコル。 MC、そのCEからエッジグループRBridgeのセットへのリンク、およびそれらのRBridgeで分散型で実行されるMC-LAGに類似したプロトコル。
MC-LAG: Multi-Chassis Link Aggregation. Proprietary extensions to IEEE Std 802.1AX-2011 [802.1AX] so that the aggregated links can, at one end of the aggregation, attach to different switches.
MC-LAG：マルチシャーシリンク集約。 IEEE Std 802.1AX-2011 [802.1AX]に対する独自の拡張機能により、集約されたリンクは、集約の一端で異なるスイッチに接続できます。
Edge group: a group of edge RBridges to which at least one CE is multiply attached using an LAALP. When multiple CEs attach to the exact same set of edge RBridges, those edge RBridges can be considered as a single edge group. An RBridge can be in more than one edge group.
エッジグループ：LAALPを使用して少なくとも1つのCEが複数接続されているエッジRBridgeのグループ。複数のCEがまったく同じエッジRBridgeのセットに接続する場合、それらのエッジRBridgeは単一のエッジグループと見なすことができます。 RBridgeは、複数のエッジグループに含めることができます。
RBridge: Routing Bridge. An alternative name for a TRILL switch.
RBridge：Routing Bridge。 TRILLスイッチの別名。
TRILL: Transparent Interconnection of Lots of Links.
TRILL：多くのリンクの透過的な相互接続。
TRILL switch: a device that implements the TRILL protocol; an alternative term for an RBridge.
TRILLスイッチ：TRILLプロトコルを実装するデバイス。 RBridgeの別名。
This section presents a typical scenario of active-active connection to a TRILL campus via multiple edge RBridges where the current TRILL Appointed Forwarder mechanism does not work as expected.
このセクションでは、現在のTRILL Appointed Forwarderメカニズムが期待どおりに機能しない、複数のエッジRBridgeを介したTRILLキャンパスへのアクティブ-アクティブ接続の典型的なシナリオを示します。
The TRILL Appointed Forwarder mechanism [RFC6439] can handle failover (active-standby), provides loop avoidance, and, with administrative configuration, provides load spreading based on VLAN. One and only one appointed RBridge can ingress/egress native frames into/from the TRILL campus for a given VLAN among all edge RBridges connecting a legacy network to the TRILL campus. This is true whether the legacy network is a simple point-to-point link or a complex bridged LAN or anything in between. By carefully selecting different RBridges as Appointed Forwarder for different sets of VLANs, load spreading over different edge RBridges across different Data Labels can be achieved.
TRILL Appointed Forwarderメカニズム[RFC6439]は、フェイルオーバー（アクティブ-スタンバイ）を処理でき、ループを回避し、管理構成により、VLANに基づいて負荷分散を提供します。レガシーネットワークをTRILLキャンパスに接続するすべてのエッジRBridge間で、指定された1つだけ指定されたRBridgeが、特定のVLANのTRILLキャンパスにネイティブフレームを出入りできます。これは、レガシーネットワークが単純なポイントツーポイントリンクであっても、複雑なブリッジLANであっても、あるいはその間のものであっても当てはまります。異なるVLANのセットに対してAppointed Forwarderとして異なるRBridgeを慎重に選択することにより、異なるデータラベル間で異なるエッジRBridgeに負荷を分散できます。
The Appointed Forwarder mechanism [RFC6439] requires all of the edge group RBridges to exchange TRILL IS-IS Hello packets through their access ports. As Figure 1 shows, when multiple access links of multiple edge RBridges are connected to a CE by an LAALP, Hello messages sent by RB1 via access port to CE1 will not be forwarded to RB2 by CE1. RB2 (and other members of LAALP1) will not see that Hello from RB1 via the LAALP1. Every member RBridge of LAALP1 thinks of itself as Appointed Forwarder on an LAALP1 link for all VLANs and will ingress/egress frames. Hence, the Appointed Forwarder mechanism cannot provide active-active or even active-standby service across the edge group in such a scenario.
Appointed Forwarderメカニズム[RFC6439]では、すべてのエッジグループRBridgeが、アクセスポートを介してTRILL IS-IS Helloパケットを交換する必要があります。図1に示すように、複数のエッジRBridgeの複数のアクセスリンクがLAALPによってCEに接続されている場合、アクセスポート経由でRB1からCE1に送信されたHelloメッセージは、CE1によってRB2に転送されません。 RB2（およびLAALP1の他のメンバー）は、RB1からLAALP1経由でHelloを認識しません。 LAALP1のすべてのメンバーRBridgeは、それ自体をすべてのVLANのLAALP1リンク上のAppointed Forwarderと見なし、フレームに出入りします。したがって、Appointed Forwarderメカニズムは、このようなシナリオでは、エッジグループ全体にアクティブ-アクティブまたはアクティブ-スタンバイサービスさえ提供できません。
----------------------
| |
| TRILL Campus |
| |
----------------------
| | |
----- | --------
| | |
+------+ +------+ +------+
| | | | | |
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
|..| |..| |..|
| +----+ | | | |
| +---|-----|--|----------+ |
| +-|---|-----+ +-----------+ |
| | | +------------------+ | |
LAALP1--->(| | |) (| | |) <---LAALPn
+-------+ . . . +-------+
| CE1 | | CEn |
| | | |
+-------+ +-------+
Figure 1: Active-Active Connection to TRILL Edge RBridges
図1：TRILLエッジRBridgeへのアクティブ-アクティブ接続
Active-active connection is useful when we want to achieve the following two goals:
アクティブ-アクティブ接続は、次の2つの目標を達成したい場合に役立ちます。
- Flow-based rather than VLAN-based load balancing is desired.
- VLANベースではなくフローベースのロードバランシングが必要です。
- More rapid failure recovery is desired.
- より迅速な障害回復が望まれます。
The current Appointed Forwarder mechanism relies on the TRILL Hello timer expiration to detect the unreachability of another edge RBridge connecting to the same local link. Then, reappointing the forwarder for specific VLANs may be required. Such procedures take time on the scale of seconds although this can be improved with TRILL use of Bidirectional Forwarding Detection (BFD) [RFC7175]. Active-active connection usually has a faster built-in mechanism for member node and/or link failure detection. Faster detection of failures minimizes the frame loss and recovery time.
現在のAppointed Forwarderメカニズムは、TRILL Helloタイマーの有効期限に依存して、同じローカルリンクに接続している別のエッジRBridgeの到達不能を検出します。次に、特定のVLANのフォワーダーを再指定する必要があります。このような手順は秒単位で時間がかかりますが、双方向フォワーディング検出（BFD）をTRILLで使用すると改善できます[RFC7175]。通常、アクティブ-アクティブ接続には、メンバーノードやリンクの障害を検出するためのより高速な組み込みメカニズムがあります。障害をより早く検出すると、フレームの損失と回復時間が最小限に抑えられます。
Today, LAALP is usually a proprietary facility whose implementation varies by vendor. So, to be sure the LAALP operates successfully across a group of edge RBridges, those edge RBridges will almost always have to be from the same vendor. In the case where the LAALP is an MC-LAG, the CE normally implements the logic described in IEEE Std 802.1AX-2011 [802.1AX], so proprietary elements would only be at
今日、LAALPは通常、ベンダーによって実装が異なる独自の施設です。したがって、LAALPがエッジRBridgeのグループ全体で正常に動作することを確認するには、ほとんどの場合、これらのエッジRBridgeは同じベンダーのものである必要があります。 LAALPがMC-LAGである場合、CEは通常、IEEE Std 802.1AX-2011 [802.1AX]で説明されているロジックを実装するため、独自の要素は
the end of the edge group. There is also a revision of IEEE Std 802.1AX-2011 [802.1AX] underway (802.1X-REV) to remove the restriction in IEEE Std 802.1AX-2011 [802.1AX] that there be one box at each end of the aggregation. So it is possible that, in the future, an LAALP could be implemented through such a revised IEEE Std 802.1AX-2011 [802.1AX] with standards-conformant logic at the ends of both the CE and edge group. In order to have a common understanding of active-active connection scenarios, the assumptions in Section 2.1 are made about the characteristics of the LAALP and edge group of RBridges.
エッジグループの終わり。 IEEE Std 802.1AX-2011 [802.1AX]の改訂版も進行中で（802.1X-REV）、集約の両端にボックスが1つあるというIEEE Std 802.1AX-2011 [802.1AX]の制限が取り除かれています。したがって、LAALPは、CEとエッジグループの両方の端に標準に準拠したロジックを備えたそのような改訂されたIEEE Std 802.1AX-2011 [802.1AX]を通じて実装される可能性があります。アクティブ/アクティブ接続のシナリオを一般的に理解するために、LAALPとRBridgesのエッジグループの特性についてセクション2.1の前提条件が設けられています。
For a CE connecting to multiple edge RBridges via an LAALP (active-active connection), the following characteristics apply:
LAALP（アクティブ-アクティブ接続）を介して複数のエッジRBridgeに接続するCEには、次の特性が適用されます。
a) The LAALP will deliver a frame from an end node to TRILL at exactly one edge group RBridge.
a) LAALPは、1つのエッジグループRBridgeでフレームをエンドノードからTRILLに配信します。
b) The LAALP will never forward frames it receives from one uplink to another.
b) LAALPは、1つのアップリンクから別のアップリンクに受信したフレームを転送しません。
c) The LAALP will attempt to send all frames for a given flow on the same uplink. To do this, it has some unknown rule for which frames get sent to which uplinks (typically based on a simple hash function of Layer 2 through 4 header fields).
c) LAALPは、同じアップリンクで特定のフローのすべてのフレームを送信しようとします。これを行うには、どのフレームがどのアップリンクに送信されるかについて、いくつかの未知のルールがあります（通常、レイヤー2から4のヘッダーフィールドの単純なハッシュ関数に基づいています）。
d) Frames are accepted from any of the uplinks and passed down to end nodes (if any exist).
d) フレームは任意のアップリンクから受け入れられ、エンドノード（存在する場合）に渡されます。
e) The LAALP cannot be assumed to send useful control information to the uplink such as "this is the set of other RBridges to which this CE is attached" or "these are all the MAC addresses attached".
e) LAALPは、「これはこのCEが接続されている他のRBridgeのセットです」または「これらはすべて接続されているすべてのMACアドレスです」などの有用な制御情報をアップリンクに送信するとは想定できません。
For an edge group of RBridges to which a CE is multiply attached with an LAALP:
LAALPでCEが複数接続されているRBridgeのエッジグループの場合：
a) Any two RBridges in the edge group are reachable from each other via the TRILL campus.
a) エッジグループ内の2つのRBridgeは、TRILLキャンパスを介して相互に到達可能です。
b) Each RBridge in the edge group knows an ID for each LAALP instance multiply attached to that group. The ID will be consistent across the edge group and globally unique across the TRILL campus. For example, if CE1 attaches to RB1, RB2, ... RBn using an LAALP, then each of the RBs will know, for the port to CE1, that it has a label such as "LAALP1".
b) エッジグループの各RBridgeは、そのグループに複数接続されている各LAALPインスタンスのIDを認識しています。 IDは、エッジグループ全体で一貫しており、TRILLキャンパス全体でグローバルに一意になります。たとえば、CE1がLAALPを使用してRB1、RB2、... RBnに接続する場合、各RBはCE1へのポートについて、「LAALP1」などのラベルがあることを認識します。
c) Each RB in the edge group can be configured with the set of acceptable VLANs for the ports to any CE. The acceptable VLANs configured for those ports should include all the VLANs the CE has joined and be consistent for all the member RBridges of the edge group.
c) エッジグループの各RBは、任意のCEへのポートの受け入れ可能なVLANのセットで構成できます。これらのポートに構成されている受け入れ可能なVLANには、CEが参加しているすべてのVLANが含まれ、エッジグループのすべてのメンバーRBridgeで一貫している必要があります。
d) When an RBridge fails, all the other RBridges that have formed an LAALP instance with it learn of the failure in a timely fashion.
d) RBridgeに障害が発生すると、LAALPインスタンスを形成している他のすべてのRBridgeは、障害をタイムリーに認識します。
e) When a downlink of an edge group RBridge to an LAALP instance fails, that RBridge and all the other RBridges participating in the LAALP instance, including that downlink, learn of the failure in a timely fashion.
e) LAALPインスタンスへのエッジグループRBridgeのダウンリンクが失敗すると、そのRBridgeと、そのダウンリンクを含むLAALPインスタンスに参加している他のすべてのRBridgeは、失敗をタイムリーに学習します。
f) The RBridges in the edge group have a mechanism to exchange information with each other, information such as the set of CEs they are connecting to or the IDs of the LAALP instances their downlinks are part of.
f) エッジグループのRBridgeには、接続しているCEのセットやダウンリンクが含まれているLAALPインスタンスのIDなどの情報を相互に交換するメカニズムがあります。
Other than the applicable characteristics above, the internals of an LAALP are out of the scope of TRILL.
上記の該当する特性を除いて、LAALPの内部はTRILLの範囲外です。
This section presents the problems that need to be addressed in active-active connection scenarios. The topology in Figure 1 is used in the following sub-sections as the example scenario for illustration purposes.
このセクションでは、アクティブ-アクティブ接続シナリオで対処する必要がある問題を示します。図1のトポロジは、以下のサブセクションで、説明のためのシナリオ例として使用されています。
When a remote RBridge ingresses a multi-destination TRILL data packet in VLAN x, all edge group RBridges of LAALP1 will receive the frame if any local CE1 joins VLAN x. As each of them thinks it is the Appointed Forwarder for VLAN x, without changes made for active-active connection support, they would all forward the frame to CE1. The bad consequence is that CE1 receives multiple copies of that multi-destination frame from the remote end-host source.
リモートRBridgeがVLAN xの複数の宛先TRILLデータパケットに入ると、ローカルCE1がVLAN xに参加した場合、LAALP1のすべてのエッジグループRBridgeがフレームを受信します。それぞれがVLAN xのAppointed Forwarderであると考えているため、アクティブ-アクティブ接続サポートに変更を加えずに、すべてのフレームをCE1に転送します。悪い結果は、CE1がリモートエンドホストソースからそのマルチ宛先フレームの複数のコピーを受信することです。
Frame duplication may also occur when an ingress RBridge is non-remote -- say, ingress and egress are two RBridges belonging to the same edge group. Assume LAALP m connects to an edge group g, and the edge group g consists of RB1, RB2, and RB3. The multi-destination frames ingressed from a port not connected to LAALP m by RB1 can be locally replicated to other ports on RB1 and also TRILL encapsulated and forwarded to RB2 and RB3. CE1 will receive duplicate copies from RB1, RB2, and RB3.
入力RBridgeがリモートではない場合にもフレームの重複が発生する可能性があります。たとえば、入力と出力が同じエッジグループに属する2つのRBridgeである場合です。 LAALP mがエッジグループgに接続し、エッジグループgがRB1、RB2、およびRB3で構成されていると仮定します。 RB1によってLAALP mに接続されていないポートから入ったマルチ宛先フレームは、RB1上の他のポートにローカルに複製でき、TRILLカプセル化してRB2およびRB3に転送することもできます。 CE1は、RB1、RB2、およびRB3から重複コピーを受け取ります。
Note that frame duplication is only a problem in multi-destination frame forwarding. Unicast forwarding does not have this issue as there is only ever one copy of the packet.
フレームの重複は、複数の宛先のフレーム転送でのみ問題になることに注意してください。パケットのコピーは1つしかないため、ユニキャスト転送にはこの問題はありません。
As shown in Figure 1, CE1 may send a native multi-destination frame to the TRILL campus via a member of the LAALP1 edge group (say RB1). This frame will be TRILL encapsulated and then forwarded through the campus to the multi-destination receivers. Other members (say RB2) of the same LAALP edge group will receive this multicast packet as well. In this case, without changes made for active-active connection support, RB2 will decapsulate the frame and egress it. The frame loops back to CE1.
図1に示すように、CE1は、LAALP1エッジグループ（RB1など）のメンバーを介して、ネイティブのマルチ宛先フレームをTRILLキャンパスに送信できます。このフレームはTRILLカプセル化され、キャンパスを介して複数の宛先のレシーバーに転送されます。同じLAALPエッジグループの他のメンバー（RB2など）も、このマルチキャストパケットを受信します。この場合、アクティブ-アクティブ接続のサポートに変更を加えない場合、RB2はフレームのカプセル化を解除して出力します。フレームはCE1にループバックします。
Consider RB1 and RB2 using their own nickname as ingress nickname for data into a TRILL campus. As shown in Figure 1, CE1 may send a data frame with the same VLAN and source Media Access Control (MAC) address to any member of the edge group LAALP1. If an egress RBridge receives TRILL data packets from different ingress RBridges but with the same source Data Label and MAC address, it learns different correspondences between a {Data Label and MAC address} and nickname when decapsulating the data frames. Address correspondence may keep flip-flopping among nicknames of the member RBridges of the LAALP for the same Data Label and MAC address. Existing hardware does not support data-plane learning of multiple nicknames for the same MAC address and Data Label -- when data-plane learning indicates attachment of the MAC address to a new nickname, it overwrites the old attachment nickname.
TRILLキャンパスへのデータの入力ニックネームとして独自のニックネームを使用するRB1とRB2を検討してください。図1に示すように、CE1は同じVLANと送信元のメディアアクセス制御（MAC）アドレスを持つデータフレームをエッジグループLAALP1の任意のメンバーに送信できます。出力RBridgeが異なる入力RBridgeからTRILLデータパケットを受信したが、ソースデータラベルとMACアドレスが同じである場合、データフレームのカプセル化解除時に{データラベルとMACアドレス}とニックネームの対応が異なります。アドレスの対応により、同じデータラベルとMACアドレスのLAALPのメンバーRBridgesのニックネーム間でフリップフロップが維持される場合があります。既存のハードウェアは、同じMACアドレスとデータラベルの複数のニックネームのデータプレーンラーニングをサポートしていません-データプレーンラーニングがMACアドレスの新しいニックネームへのアタッチを示すと、古いアタッチメントニックネームを上書きします。
Implementers have stated that most current TRILL switch hardware, when doing data-plane learning, behaves badly under these circumstances and, for example, interprets address flip-flopping as a severe network problem. It may also cause the returning traffic to go through different paths to reach the destination, resulting in persistent reordering of the frames.
実装者は、最新のTRILLスイッチハードウェアは、データプレーン学習を行う場合、これらの状況下では適切に動作せず、たとえば、アドレスフリップフロップを深刻なネットワーク問題として解釈すると述べています。また、戻りトラフィックが別のパスを経由して宛先に到達し、フレームの永続的な並べ替えが発生する可能性もあります。
A local RBridge, say RB1 connected to LAALP1, may have learned a correspondence between a {Data Label and MAC address} and nickname for a remote host h1 when h1 sends a packet to CE1. The returning traffic from CE1 may go to any other member RBridge of LAALP1, for example, RB2. RB2 may not have h1's correspondence between a {Data Label and MAC address} and nickname stored. Therefore, it has to do the flooding for unknown unicast addresses [RFC6325]. Such flooding is unnecessary since the returning traffic is almost always expected and RB1 had learned the address correspondence. It is desirable to avoid flooding; it imposes a greater burden on the network than known destination unicast traffic because the flooded traffic is sent over more links.
LA1に接続されたRB1などのローカルRBridgeは、h1がCE1にパケットを送信するときに、{データラベルとMACアドレス}とリモートホストh1のニックネームの対応を学習している可能性があります。 CE1からの戻りトラフィックは、LAALP1の他のメンバーRBridge、たとえばRB2に送られます。 RB2には、{データラベルとMACアドレス}とニックネームのh1の対応が格納されていない可能性があります。したがって、未知のユニキャストアドレスのフラッディングを行う必要があります[RFC6325]。戻りトラフィックはほとんど常に予想され、RB1はアドレスの対応を学習しているため、このようなフラッディングは不要です。洪水を避けることが望ましい。フラッディングされたトラフィックはより多くのリンクを介して送信されるため、既知の宛先ユニキャストトラフィックよりもネットワークに大きな負荷がかかります。
Synchronization of the correspondence between a {Data Label and MAC address} and nickname information among member RBridges will reduce such unnecessary flooding.
{データラベルとMACアドレス}とメンバーRBridge間のニックネーム情報の対応を同期させることで、このような不要なフラッディングを減らすことができます。
The problems identified in Section 3 should be solved in any solution for active-active connection to edge RBridges. The following high-level requirements and goals should be met.
セクション3で特定された問題は、エッジRBridgeへのアクティブ-アクティブ接続のソリューションで解決する必要があります。次の高レベルの要件と目標を満たす必要があります。
Data plane:
データプレーン：
1) All uplinks of a CE MUST be active: the LAALP is free to choose any uplink on which to send packets, and the CE is able to receive packets from any uplink of an edge group.
1）CEのすべてのアップリンクをアクティブにする必要があります。LAALPは、パケットを送信する任意のアップリンクを自由に選択でき、CEはエッジグループの任意のアップリンクからパケットを受信できます。
2) Loopback and frame duplication MUST be prevented.
2）ループバックとフレームの重複を防止する必要があります。
3) Learning of correspondence between a {Data Label and MAC address} and nickname by a remote RBridge MUST NOT flip-flop between the local multiply attached edge RBridges.
3）リモートRBridgeによる{データラベルとMACアドレス}とニックネームの間の対応の学習は、ローカルに複数接続されたエッジRBridge間でフリップフロップを実行してはなりません。
4) Packets for a flow SHOULD stay in order.
4）フローのパケットは順序どおりにとどまる必要があります。
5) The Reverse Path Forwarding Check MUST work properly as per the RBridges base protocol [RFC6325].
5）リバースパス転送チェックは、RBridgesベースプロトコル[RFC6325]に従って正しく動作する必要があります。
6) Single uplink failure on a CE to an edge group MUST NOT cause persistent packet delivery failure between a TRILL campus and CE.
6）エッジグループへのCEでの単一のアップリンク障害は、TRILLキャンパスとCE間の永続的なパケット配信障害を引き起こしてはなりません。
Control plane:
コントロールプレーン：
1) No requirement for new information to be passed between edge RBridges and CEs or between edge RBridges and end nodes exists.
1）エッジRBridgeとCE間、またはエッジRBridgeとエンドノード間で新しい情報を渡す必要はありません。
2) If there is any TRILL-specific information required to be exchanged between RBridges in an edge group, for example, Data Labels and MAC addresses binding to nicknames, a solution MUST specify the mechanism to perform such exchange unless this is handled internal to the LAALP.
2）エッジグループのRBridge間で交換する必要のあるTRILL固有の情報（データラベルやニックネームにバインドするMACアドレスなど）がある場合、これは内部で処理されない限り、そのような交換を実行するメカニズムをソリューションで指定する必要があります。 LAALP。
3) RBridges SHOULD be able to discover other members in the same edge group by exchanging their LAALP attachment information.
3）RBridgeは、LAALPアタッチメント情報を交換することにより、同じエッジグループ内の他のメンバーを検出できる必要があります（SHOULD）。
Configuration, incremental deployment, and others:
構成、増分展開など：
1) Solution SHOULD require minimal configuration.
1）ソリューションは最小限の構成を必要とします。
2) Solution SHOULD automatically detect misconfiguration of edge RBridge group.
2）ソリューションは、エッジRBridgeグループの設定ミスを自動的に検出する必要があります（SHOULD）。
3) Solution SHOULD support incremental deployment, that is, not require campus-wide upgrading for all RBridges, only changes to the edge group RBridges.
3）ソリューションは、インクリメンタルデプロイメントをサポートする必要があります。つまり、すべてのRBridgeをキャンパス全体でアップグレードする必要はなく、エッジグループRBridgeを変更するだけです。
4) Solution SHOULD be able to support from two up to at least four active-active uplinks on a multiply attached CE.
4）ソリューションは、複数接続されたCEで2つから少なくとも4つのアクティブ-アクティブアップリンクをサポートできる必要があります（SHOULD）。
5) Solution SHOULD NOT assume there is a dedicated physical link between any two edge RBridges in an edge group.
5）ソリューションは、エッジグループ内の2つのエッジRBridge間に専用の物理リンクがあると想定しないでください。
As an informational overview, this document does not introduce any extra security risks. Security risks introduced by a particular LAALP or other elements of solutions to the problems presented here will be discussed in the separate document(s) describing such LAALP or solutions.
情報の概要として、このドキュメントでは追加のセキュリティリスクを紹介していません。ここで提示された問題に対する特定のLAALPまたはソリューションの他の要素によって導入されるセキュリティリスクは、そのようなLAALPまたはソリューションを説明する個別のドキュメントで説明されます。
End-station links in TRILL are Ethernet links, and consideration should be given to securing them with link security as described in IEEE Std 802.1AE-2006 [802.1AE] for the protection of end-station data and link-level control messages, including any LAALP control messages.
TRILLのエンドステーションリンクはイーサネットリンクであり、IEEE Std 802.1AE-2006 [802.1AE]で説明されているように、リンクセキュリティでリンクを保護することを考慮して、エンドステーションデータとリンクレベルの制御メッセージを保護する必要があります。 LAALP制御メッセージ。
For general TRILL Security Considerations, see the RBridges base protocol [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、RBridges基本プロトコル[RFC6325]を参照してください。
[IS-IS] ISO/IEC, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, 2002.
[IS-IS] ISO / IEC、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービスを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル（ ISO 8473）」、ISO / IEC 10589：2002、Second Edition、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011, <http://www.rfc-editor.org/info/rfc6165>.
[RFC6165] Banerjee、A。およびD. Ward、「Extensions to IS-IS for Layer-2 Systems」、RFC 6165、2011年4月、<http://www.rfc-editor.org/info/rfc6165>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, 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、2011年7月、<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, 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、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, 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、May 2014、<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, 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、May 2014、<http://www.rfc-editor.org/info/rfc7176>。
[802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE Std 802.1AE-2006, 18 August 2006.
[802.1AE] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Security」、IEEE Std 802.1AE-2006、2006年8月18日。
[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks -- Link Aggregration", IEEE Std 802.1AX-2008, 3 November 2008.
[802.1AX] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-リンクアグリゲーション」、IEEE Std 802.1AX-2008、2008年11月3日。
[RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support", RFC 7175, May 2014, <http://www.rfc-editor.org/info/rfc7175>.
[RFC7175] Manral、V.、Eastlake 3rd、D.、Ward、D。、およびA. Banerjee、「多数のリンクの透過的相互接続（TRILL）：双方向転送検出（BFD）サポート」、RFC 7175、2014年5月、 <http://www.rfc-editor.org/info/rfc7175>。
Acknowledgments
謝辞
Special acknowledgments to Donald Eastlake, Adrian Farrel, and Mingui Zhang for their valuable comments.
ドナルドイーストレイク、エイドリアンファレル、ミンギチャンの貴重なコメントに対する特別な謝辞。
Authors' Addresses
著者のアドレス
Yizhou Li Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Y Iweekl IH UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Phone: +86-25-56625409
EMail: liyizhou@huawei.com
Weiguo Hao Huawei Technologies 101 Software Avenue, Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニュー、南京210012中国
Phone: +86-25-56623144
EMail: haoweiguo@huawei.com
Radia Perlman EMC 2010 256th Avenue NE, #200 Bellevue, WA 98007 United States
らぢあ ぺｒｌまん えＭＣ ２０１０ ２５６ｔｈ あゔぇぬえ ね、 ＃２００ べっぇゔえ、 わ ９８００７ うにてｄ Ｓたてｓ
EMail: Radia@alum.mit.edu
Jon Hudson Brocade 130 Holger Way San Jose, CA 95134 United States
Jon Hudson Brocade 130 Holger Way San Jose、CA 95134アメリカ合衆国
Phone: +1-408-333-4062
EMail: jon.hudson@gmail.com
Hongjun Zhai JIT
ho nもNZによるJIT
EMail: honjun.zhai@tom.com