[要約] RFC 8385は、TRILL（Transparent Interconnection of Lots of Links）プロトコルを使用してMPLS（Multiprotocol Label Switching）上で透過的なトランスポートを提供するための仕様です。このRFCの目的は、TRILLとMPLSの統合により、スケーラビリティと柔軟性を向上させ、ネットワークの効率性を高めることです。
Internet Engineering Task Force (IETF) M. Umair
Request for Comments: 8385 Cisco
Category: Informational S. Kingston Smiler
ISSN: 2070-1721 PALC Networks
D. Eastlake 3rd
Huawei
L. Yong
Independent
June 2018
Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS
多くのリンクの透過的な相互接続（TRILL）MPLS上の透過的なトランスポート
Abstract
概要
This document specifies methods to interconnect multiple TRILL (Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (Virtual Private LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network.
このドキュメントでは、既存のTRILLおよびVPLS（仮想プライベートLANサービス）標準を使用して、介在するMPLSネットワークで複数のTRILL（多数のリンクの透過的相互接続）サイトを相互接続する方法を指定します。このドキュメントでは、1）MPLSプロバイダーネットワークによって分離されている3つ以上のTRILLサイト間の接続を提供すること、および2）MPLSプロバイダーネットワークによって分離されている異なるテナントに単一の論理仮想化TRILLネットワークを提供することの2つの問題を扱います。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8385.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8385で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. TRILL-over-MPLS Model ...........................................5
3. VPLS Model ......................................................5
3.1. Entities in the VPLS Model .................................6
3.2. TRILL Adjacency for VPLS Model .............................7
3.3. MPLS Encapsulation for VPLS Model ..........................7
3.4. Loop-Free Provider PSN/MPLS ................................7
3.5. Frame Processing ...........................................7
4. VPTS Model ......................................................7
4.1. Entities in the VPTS Model .................................9
4.1.1. TRILL Intermediate Router (TIR) ....................10
4.1.2. Virtual TRILL Switch/Service Domain (VTSD) .........10
4.2. TRILL Adjacency for VPTS Model ............................10
4.3. MPLS Encapsulation for VPTS Model .........................10
4.4. Loop-Free Provider PSN/MPLS ...............................11
4.5. Frame Processing ..........................................11
4.5.1. Multi-destination Frame Processing .................11
4.5.2. Unicast Frame Processing ...........................11
5. VPTS Model versus VPLS Model ...................................11
6. Packet Processing between Pseudowires ..........................12
7. Efficiency Considerations ......................................12
8. Security Considerations ........................................12
9. IANA Considerations ............................................13
10. References ....................................................13
10.1. Normative References ....................................13
10.2. Informative References ..................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................16
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol [RFC6325] [RFC7177] [RFC7780] provides transparent forwarding in multi-hop networks with arbitrary topology and link technologies using a header with a hop count and link-state routing. TRILL provides optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. Intermediate Systems (ISs) implementing TRILL are called Routing Bridges (RBridges) or TRILL switches.
IETFの多くのリンクの透過的相互接続（TRILL）プロトコル[RFC6325] [RFC7177] [RFC7780]は、ホップカウントのあるヘッダーとリンク状態ルーティングを使用して、任意のトポロジとリンクテクノロジーを持つマルチホップネットワークで透過的な転送を提供します。 TRILLは、構成なしの最適なペアワイズ転送、一時的なループの期間中も安全な転送、およびユニキャストとマルチキャストの両方のトラフィックのマルチパスをサポートします。 TRILLを実装する中間システム（IS）は、ルーティングブリッジ（RBridges）またはTRILLスイッチと呼ばれます。
This document, in conjunction with [RFC7173] on TRILL transport using pseudowires, addresses two problems:
このドキュメントは、疑似配線を使用したTRILLトランスポートに関する[RFC7173]と組み合わせて、2つの問題に対処します。
1) providing connection between more than two TRILL sites that belong to a single TRILL network and are separated by an MPLS provider network using [RFC7173]. (Herein, this is also called "problem statement 1".)
1）単一のTRILLネットワークに属し、[RFC7173]を使用してMPLSプロバイダーネットワークによって分離されている3つ以上のTRILLサイト間の接続を提供します。 （ここでは、「問題文1」とも呼ばれます。）
2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. In short, this is for providing connection between TRILL sites belonging to a tenant/tenants over a MPLS provider network. (Herein, this is also called "problem statement 2".)
2）MPLSプロバイダーネットワークによって分離された異なるテナントに単一の論理仮想化TRILLネットワークを提供します。つまり、これは、MPLSプロバイダーネットワークを介してテナントに属するTRILLサイト間の接続を提供するためです。 （ここでは、「問題文2」とも呼ばれます。）
A tenant is the administrative entity on whose behalf their associated services are managed. Here, "tenant" refers to a TRILL campus that is segregated from other tenants for security reasons.
テナントは、関連するサービスが管理される管理エンティティです。ここで、「テナント」とは、セキュリティ上の理由で他のテナントから分離されているTRILLキャンパスを指します。
A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. This document also addresses the problem of multi-tenancy by isolating one tenant's traffic from the other.
マルチテナントの重要な要件は、1つのテナントのトラフィックが他のどのテナントからも見えないようにトラフィックを分離することです。このドキュメントでは、1つのテナントのトラフィックを他のテナントから分離することにより、マルチテナントの問題にも対処しています。
[RFC7173] mentions how to interconnect a pair of TRILL switch ports using pseudowires. This document explains how to connect multiple TRILL sites (not limited to only two sites) using the mechanisms and encapsulations defined in [RFC7173].
[RFC7173]は、疑似配線を使用してTRILLスイッチポートのペアを相互接続する方法について述べています。このドキュメントでは、[RFC7173]で定義されているメカニズムとカプセル化を使用して、複数のTRILLサイト（2つのサイトに限定されない）を接続する方法について説明します。
Acronyms and terms used in this document include the following:
このドキュメントで使用されている頭字語と用語は次のとおりです。
AC - Attachment Circuit [RFC4664]
AC-接続回路[RFC4664]
Data Label - VLAN Label or Fine-Grained Label database - IS-IS link state database
データラベル-VLANラベルまたは細粒度ラベルデータベース-IS-ISリンク状態データベース
ECMP - Equal-Cost Multipath
ECMP-等コストマルチパス
FGL - Fine-Grained Labeling [RFC7172]
FGL-きめの細かいラベル付け[RFC7172]
IS-IS - Intermediate System to Intermediate System [IS-IS]
IS-IS-中間システムから中間システム[IS-IS]
LAN - Local Area Network
LAN-ローカルエリアネットワーク
MPLS - Multiprotocol Label Switching
MPLS-マルチプロトコルラベルスイッチング
PBB - Provider Backbone Bridging
PBB-プロバイダーバックボーンブリッジング
PE - Provider Edge device
PE-プロバイダーエッジデバイス
PSN - Packet Switched Network
PSN-パケット交換ネットワーク
PW - Pseudowire [RFC4664]
ΠΩ-シュードビル[ΡΦΚ4664]
TIR - TRILL Intermediate Router (Device that has both IP/MPLS and TRILL functionality)
TIR-TRILL中間ルーター（IP / MPLSとTRILLの両方の機能を持つデバイス）
TRILL - Transparent Interconnection of Lots of Links OR Tunneled Routing in the Link Layer
TRILL-多くのリンクの透過的な相互接続、またはリンク層でのトンネルルーティング
TRILL site - A part of a TRILL campus that contains at least one RBridge.
TRILLサイト-少なくとも1つのRBridgeを含むTRILLキャンパスの一部。
VLAN - Virtual Local Area Network
VLAN-仮想ローカルエリアネットワーク
VPLS - Virtual Private LAN Service
VPLS-仮想プライベートLANサービス
VPTS - Virtual Private TRILL Service
VPTS-仮想プライベートTRILLサービス
VSI - Virtual Service Instance [RFC4664]
VSI-仮想サービスインスタンス[RFC4664]
VTSD - Virtual TRILL Switch Domain OR Virtual TRILL Service Domain. A Virtual RBridge that segregates one tenant's TRILL database as well as traffic from the other.
VTSD-仮想TRILLスイッチドメインまたは仮想TRILLサービスドメイン。 1つのテナントのTRILLデータベースと他のテナントのトラフィックを分離する仮想RBridge。
WAN - Wide Area Network
WAN-広域ネットワーク
TRILL over MPLS can be achieved in two different ways: a) the VPLS Model for TRILL b) the VPTS Model / TIR Model for TRILL
MPLS上のTRILLは、2つの異なる方法で実現できます。a）TRILLのVPLSモデルb）TRILLのVPTSモデル/ TIRモデル
Both these models can be used to solve problem statements 1 and 2. Herein, the VPLS Model for TRILL is also called "Model 1" and the VPTS Model / TIR Model is also called "Model 2".
これらのモデルはどちらも、問題ステートメント1および2を解決するために使用できます。ここでは、TRILLのVPLSモデルは「モデル1」とも呼ばれ、VPTSモデル/ TIRモデルは「モデル2」とも呼ばれます。
Figure 1 shows the topological model of TRILL over MPLS using the VPLS model. The PE routers in the below topology model should support all the functional components mentioned in [RFC4664].
図1は、VPLSモデルを使用したTRILL over MPLSのトポロジモデルを示しています。次のトポロジモデルのPEルータは、[RFC4664]で言及されているすべての機能コンポーネントをサポートする必要があります。
+-----+ +-----+
| RBa +---+ ........................... +---| RBb |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+----|PE1 | |PE2 |----+
+----+ MPLS Cloud +----+
. .
. +----+ .
..........|PE3 |...........
+----+ ^
| |
| +-- Emulated LAN
+-----+
| RBc |
+-----+
Site 3
Figure 1: Topological Model of TRILL over MPLS Connecting 3 TRILL Sites
図1：3つのTRILLサイトを接続するTRILL over MPLSのトポロジモデル
Figure 2 below shows the topological model of TRILL over MPLS to connect multiple TRILL sites belonging to a tenant. ("Tenant" here is a TRILL campus, not a specific Data Label.) VSI1 and VSI2 are two Virtual Service Instances that segregate Tenant1's traffic from other tenant traffic. VSI1 will maintain its own database for Tenant1; similarly, VSI2 will maintain its own database for Tenant2.
下の図2は、テナントに属する複数のTRILLサイトを接続するためのTRILL over MPLSのトポロジモデルを示しています。 （ここでの「テナント」は特定のデータラベルではなくTRILLキャンパスです。）VSI1とVSI2は、Tenant1のトラフィックを他のテナントトラフィックから分離する2つの仮想サービスインスタンスです。 VSI1はTenant1の独自のデータベースを維持します。同様に、VSI2はTenant2の独自のデータベースを維持します。
+-----+ ............................ +-----+
|RBat1+---+ . ++++++++++++++++++++++++ . +---|RBbt1|
+-----+ | . + + . | +-----+
Tenant1 | +----+ +----+ | Tenant1
Site 1 +----|VSI1| |VSI1|----+ Site 2
+----|VSI2| MPLS Cloud |VSI2|----+
| +----+ +----+ |
+-----+ | . + + . | +-----+
|RBat2+---+ . +++++++++ +----+ ++++++++ . +---|RBbt2|
+-----+ ............|VSI1|........... +-----+
Tenant2 |VSI2| Tenant2
Site 1 +----+ Site 2
|
+-----+
|RBct2|
+-----+
Tenant2 Site 3
.... VSI1 Path
++++ VSI2 Path
Figure 2: Topological Model for VPLS Model Connecting 2 Tenants with 3 Sites Each
図2：それぞれ3つのサイトを持つ2つのテナントを接続するVPLSモデルのトポロジモデル
In this model, TRILL sites are connected to VPLS-capable PE devices that provide a logical interconnect, such that TRILL RBridges belonging to a specific tenant are connected via a single bridged Ethernet. These PE devices are the same as the PE devices specified in [RFC4026]. The Attachment Circuit ports of PE routers are Layer 2 switch ports that are connected to the RBridges at a TRILL site. Here, each VPLS instance looks like an emulated LAN. This model is similar to connecting different RBridges by a Layer 2 bridge domain (multi-access link) as specified in [RFC6325]. This model doesn't requires any changes in PE routers to carry TRILL packets, as TRILL packets will be transferred transparently.
このモデルでは、TRILLサイトは、特定のテナントに属するTRILL RBridgeが単一のブリッジイーサネットを介して接続されるように、論理相互接続を提供するVPLS対応PEデバイスに接続されます。これらのPEデバイスは、[RFC4026]で指定されているPEデバイスと同じです。 PEルーターの接続回路ポートは、TRILLサイトでRBridgeに接続されているレイヤー2スイッチポートです。ここでは、各VPLSインスタンスはエミュレートされたLANのように見えます。このモデルは、[RFC6325]で指定されているように、レイヤー2ブリッジドメイン（マルチアクセスリンク）で異なるRBridgeを接続するのと似ています。 TRILLパケットは透過的に転送されるため、このモデルでは、TRILLパケットを伝送するためにPEルーターに変更を加える必要はありません。
The PE (VPLS-PE) and Customer Edge (CE) devices are defined in [RFC4026].
PE（VPLS-PE）およびCustomer Edge（CE）デバイスは[RFC4026]で定義されています。
The generic L2VPN transport functional components like Attachment Circuits, pseudowires, VSI, etc., are defined in [RFC4664].
接続回路、疑似配線、VSIなどの一般的なL2VPNトランスポート機能コンポーネントは、[RFC4664]で定義されています。
The RB (RBridge) and TRILL campus are defined in [RFC6325] as updated by [RFC7780].
RB（RBridge）およびTRILLキャンパスは、[RFC7780]によって更新された[RFC6325]で定義されています。
As specified in Section 3, the MPLS cloud looks like an emulated LAN (also called multi-access link or broadcast link). This results in RBridges at different sites looking like they are connected by a multi-access link. With such interconnection, the TRILL adjacencies over the link are automatically discovered and established through TRILL IS-IS control messages [RFC7177]. These IS-IS control messages are transparently forwarded by the VPLS domain, after doing MPLS encapsulation as specified in Section 3.3.
セクション3で指定されているように、MPLSクラウドはエミュレートされたLAN（マルチアクセスリンクまたはブロードキャストリンクとも呼ばれます）のように見えます。これにより、複数のサイトでRBridgeがマルチアクセスリンクで接続されているように見えます。このような相互接続により、リンク上のTRILL隣接関係はTRILL IS-IS制御メッセージ[RFC7177]を通じて自動的に検出および確立されます。これらのIS-IS制御メッセージは、セクション3.3で指定されているようにMPLSカプセル化を行った後、VPLSドメインによって透過的に転送されます。
Use of VPLS [RFC4762] [RFC4761] to interconnect TRILL sites requires no changes to a VPLS implementation -- in particular, the use of Ethernet pseudowires between VPLS PEs. A VPLS PE receives normal Ethernet frames from an RBridge (i.e., CE) and is not aware that the CE is an RBridge device. As an example, an MPLS-encapsulated TRILL packet within the MPLS network can use the format illustrated in Appendix A of [RFC7173] for the non-PBB case. For the PBB case, additional header fields illustrated in [RFC7041] can be added by the entry PE and removed by the exit PE.
VPLS [RFC4762] [RFC4761]を使用してTRILLサイトを相互接続する場合、VPLS実装に変更を加える必要はありません。特に、VPLS PE間のイーサネット疑似配線を使用する必要があります。 VPLS PEは、RBridge（つまり、CE）から通常のイーサネットフレームを受信し、CEがRBridgeデバイスであることを認識していません。例として、MPLSネットワーク内のMPLSカプセル化TRILLパケットは、非PBBの場合について、[RFC7173]の付録Aに示されているフォーマットを使用できます。 PBBの場合、[RFC7041]に示されている追加のヘッダーフィールドをエントリPEで追加し、出口PEで削除できます。
No explicit handling is required to avoid a loop-free topology. The "split horizon" technique specified in [RFC4664] will take care of avoiding loops in the provider PSN network.
ループのないトポロジーを回避するための明示的な処理は必要ありません。 [RFC4664]で指定されている「スプリットホライズン」手法は、プロバイダーのPSNネットワークでループを回避することを担当します。
The PE devices transparently process the TRILL control and data frames. Procedures to forward the frames are defined in [RFC4664].
PEデバイスは、TRILLコントロールとデータフレームを透過的に処理します。フレームを転送する手順は[RFC4664]で定義されています。
The Virtual Private TRILL Service (VPTS) is a Layer 2 TRILL service that emulates TRILL service across a Wide Area Network (WAN). VPTS is similar to what VPLS does for a bridged core but provides a TRILL core. VPLS provides "Virtual Private LAN Service" for different customers. VPTS provides "Virtual Private TRILL Service" for different TRILL tenants.
仮想プライベートTRILLサービス（VPTS）は、ワイドエリアネットワーク（WAN）全体でTRILLサービスをエミュレートするレイヤー2 TRILLサービスです。 VPTSは、ブリッジコアに対してVPLSが行うことと似ていますが、TRILLコアを提供します。 VPLSは、さまざまな顧客に「仮想プライベートLANサービス」を提供します。 VPTSは、さまざまなTRILLテナントに「仮想プライベートTRILLサービス」を提供します。
Figure 3 shows the topological model of TRILL over MPLS using VPTS. In this model, the PE routers are replaced with TRILL Intermediate Routers (TIRs), and the VSIs are replaced with Virtual TRILL Switch Domains (VTSDs). The TIR devices must be capable of supporting both MPLS and TRILL as specified in Section 4.1.1. The TIR devices are interconnected via PWs and appear as a unified emulated TRILL campus with each VTSD inside a TIR equivalent to an RBridge.
図3は、VPTSを使用したTRILL over MPLSのトポロジモデルを示しています。このモデルでは、PEルーターはTRILL中間ルーター（TIR）に置き換えられ、VSIは仮想TRILLスイッチドメイン（VTSD）に置き換えられます。 TIRデバイスは、セクション4.1.1で指定されているように、MPLSとTRILLの両方をサポートできる必要があります。 TIRデバイスはPWを介して相互接続され、RBridgeと同等のTIR内に各VTSDを備えた統合エミュレートされたTRILLキャンパスとして表示されます。
Below are some of the reasons for interconnecting TRILL sites without isolating the TRILL control plane of one TRILL site from other sites.
以下は、あるTRILLサイトのTRILLコントロールプレーンを他のサイトから分離せずにTRILLサイトを相互接続する理由のいくつかです。
1) Nickname uniqueness: One of the basic requirements of TRILL is that RBridge nicknames are unique within the campus [RFC6325]. If we segregate the control plane of one TRILL site from other TRILL sites and provide interconnection between these sites, it may result in nickname collision.
1）ニックネームの一意性：TRILLの基本的な要件の1つは、RBridgeのニックネームがキャンパス内で一意であることです[RFC6325]。 1つのTRILLサイトのコントロールプレーンを他のTRILLサイトから分離し、これらのサイト間の相互接続を提供すると、ニックネームの衝突が発生する可能性があります。
2) Distribution trees and their pruning: When a TRILL Data packet traverses a Distribution Tree, it will stay on it even in other TRILL sites. If no end-station service is enabled for a particular Data Label in a TRILL site, the distribution tree may be pruned and TRILL data packets of that particular Data Label might never get to another TRILL site where the packets had no receivers. The TRILL Reverse Path Forwarding (RPF) check will always be performed on the packets that are received by TIRs through pseudowires.
2）配布ツリーとそのプルーニング：TRILLデータパケットが配布ツリーを通過するとき、他のTRILLサイトでもそのツリーに留まります。 TRILLサイトの特定のデータラベルに対してエンドステーションサービスが有効になっていない場合、配布ツリーがプルーニングされ、その特定のデータラベルのTRILLデータパケットが、パケットのレシーバーがない別のTRILLサイトに到達しない可能性があります。 TRILL Reverse Path Forwarding（RPF）チェックは、疑似配線を通じてTIRによって受信されたパケットに対して常に実行されます。
3) Hop count values: When a TRILL data packet is received over a pseudowire by a TIR, the TIR does the processing of Hop Count defined in [RFC6325] and will not perform any resetting of Hop Count.
3）ホップカウント値：TRILLデータパケットがTIRによって疑似配線を介して受信されると、TIRは[RFC6325]で定義されているホップカウントの処理を行い、ホップカウントのリセットを実行しません。
+-----+ +-----+
| RBa +---+ ........................... +---| RBb |
+-----+ | . . | +-----+
Site 1 | +----+ +----+ | Site 2
+----|TIR1| |TIR2|----+
+----+ MPLS Cloud +----+
. .
. +----+ .
..........|TIR3|...........
+----+ ^
| |
| +-- Emulated TRILL
+-----+
| RBc |
+-----+
Site 3
Figure 3: Topological Model of VPTS/TIR Connecting 3 TRILL Sites
図3：3つのTRILLサイトを接続するVPTS / TIRのトポロジモデル
In Figure 3, Site 1, Site 2, and Site 3 (running the TRILL protocol) are connected to TIR devices. These TIR devices, along with the MPLS cloud, look like a unified emulated TRILL network. Only the PE devices in the MPLS network should be replaced with TIRs so the intermediate provider routers are agnostic to the TRILL protocol.
図3では、サイト1、サイト2、およびサイト3（TRILLプロトコルを実行）がTIRデバイスに接続されています。これらのTIRデバイスは、MPLSクラウドとともに、統合されたエミュレートされたTRILLネットワークのように見えます。 MPLSネットワーク内のPEデバイスのみをTIRで置き換える必要があるため、中間プロバイダーのルーターはTRILLプロトコルに依存しません。
Figure 4 below extends the topological model of TRILL over MPLS to connect multiple TRILL sites belonging to a tenant ("tenant" here is a campus, not a Data Label) using the VPTS model. VTSD1 and VTSD2 are two Virtual TRILL Switch Domains (Virtual RBridges) that segregate Tenant1's traffic from Tenant2's traffic. VTSD1 will maintain its own TRILL database for Tenant1; similarly, VTSD2 will maintain its own TRILL database for Tenant2.
以下の図4は、VPLSモデルを使用して、テナント（ここでは「テナント」はデータラベルではなくキャンパスです）に属する複数のTRILLサイトを接続するようにMPLS over TRILLのトポロジモデルを拡張しています。 VTSD1とVTSD2は、Tenant1のトラフィックをTenant2のトラフィックから分離する2つの仮想TRILLスイッチドメイン（仮想RBridge）です。 VTSD1は、Tenant1の独自のTRILLデータベースを維持します。同様に、VTSD2はTenant2の独自のTRILLデータベースを維持します。
+-----+ ............................ +-----+
|RBat1+---+ . ######################## . +---|RBbt1|
+-----+ | . # # . | +-----+
Tenant1 | +-----+ +-----+ | Tenant1
Site 1 +----|VTSD1| |VTSD1|----+ Site 2
+----|VTSD2| MPLS Cloud |VTSD2|----+
| +-----+ +-----+ |
+-----+ | . # # . | +-----+
|RBat2+---+ . #########+-----+######### . +---|RBbt2|
+-----+ ...........|VTSD1|........... +-----+
Tenant2 |VTSD2| ^ Tenant2
Site 1 +-----+ | Site 2
| |
+-----+ +-----Emulated
|RBct2| TRILL
+-----+
Tenant2 Site 3
.... VTSD1 Connectivity
#### VTSD2 Connectivity
Figure 4: Topological Model of VPTS/TIR Connecting 2 Tenants with 3 TRILL Sites
図4：2つのテナントと3つのTRILLサイトを接続するVPTS / TIRのトポロジモデル
The CE devices are defined in [RFC4026].
CEデバイスは[RFC4026]で定義されています。
The generic L2VPN transport functional components like Attachment Circuits, pseudowires, etc., are defined in [RFC4664].
アタッチメント回路、疑似配線などの一般的なL2VPNトランスポート機能コンポーネントは、[RFC4664]で定義されています。
The RB (RBridge) and TRILL campus are defined in [RFC6325] as updated by [RFC7780].
RB（RBridge）およびTRILLキャンパスは、[RFC7780]によって更新された[RFC6325]で定義されています。
This model introduces two new entities, TIR and VTSD, which are described below.
このモデルでは、以下に説明する2つの新しいエンティティ、TIRとVTSDが導入されています。
The TIRs must be capable of running both VPLS and TRILL protocols. TIR devices are a superset of the VPLS-PE devices defined in [RFC4026] with the additional functionality of TRILL. The VSI that provides transparent bridging functionality in the PE device is replaced with VTSD in a TIR.
TIRは、VPLSプロトコルとTRILLプロトコルの両方を実行できる必要があります。 TIRデバイスは、[RFC4026]で定義されているVPLS-PEデバイスのスーパーセットであり、TRILLの追加機能を備えています。 PEデバイスで透過的なブリッジング機能を提供するVSIは、TIRでVTSDに置き換えられます。
The VTSD is similar to the VSI (Layer 2 bridge) in the VPLS model, but the VTSD acts as a TRILL RBridge. The VTSD is a superset of the VSI and must support all the functionality provided by the VSI as defined in [RFC4026]. Along with VSI functionality, the VTSD must be capable of supporting TRILL protocols and forming TRILL adjacencies. The VTSD must be capable of performing all the operations that a standard TRILL switch can do.
VTSDはVPLSモデルのVSI（レイヤー2ブリッジ）に似ていますが、VTSDはTRILL RBridgeとして機能します。 VTSDはVSIのスーパーセットであり、[RFC4026]で定義されているVSIによって提供されるすべての機能をサポートする必要があります。 VSI機能に加えて、VTSDはTRILLプロトコルをサポートし、TRILL隣接関係を形成できる必要があります。 VTSDは、標準のTRILLスイッチで実行できるすべての操作を実行できる必要があります。
One VTSD instance per tenant must be maintained when multiple tenants are connected to a TIR. The VTSD must maintain all the information kept by the RBridge on a per-tenant basis. The VTSD must also take care of segregating one tenant's traffic from another's. Each VTSD will have its own nickname for each tenant. If a TIR supports 10 TRILL tenants, it needs to be assigned with 10 TRILL nicknames, one for the nickname space of each of its tenants, and run 10 copies of TRILL protocols, one for each tenant. It is possible that it would have the same nickname for two or more tenants, but, since the TRILL data and control traffic are separated for the tenants, there is no confusion.
複数のテナントがTIRに接続されている場合、テナントごとに1つのVTSDインスタンスを維持する必要があります。 VTSDは、RBridgeが保持するすべての情報をテナントごとに維持する必要があります。 VTSDは、あるテナントのトラフィックを別のテナントのトラフィックから分離することも処理する必要があります。各VTSDには、テナントごとに独自のニックネームがあります。 TIRが10個のTRILLテナントをサポートする場合、10個のTRILLニックネームを割り当て、それぞれのテナントのニックネームスペースに1つと、TRILLプロトコルのコピーを10個（各テナントに1つ）実行する必要があります。 2つ以上のテナントで同じニックネームを持つ可能性がありますが、TRILLデータと制御トラフィックはテナントごとに分離されているため、混乱はありません。
The VTSD must be capable of forming a TRILL adjacency with the corresponding VTSDs present in its peer VPTS neighbor and also with the neighboring RBridges of the TRILL sites. The procedure to form TRILL adjacency is specified in [RFC7173] and [RFC7177].
VTSDは、ピアVPTSネイバーに存在する対応するVTSDと、またTRILLサイトの隣接RBridgeとTRILL隣接関係を形成できる必要があります。 TRILL隣接を形成する手順は、[RFC7173]と[RFC7177]で指定されています。
The VPTS model uses PPP or Ethernet pseudowires for MPLS encapsulation as specified in [RFC7173] and requires no changes in the packet format in that RFC. In accordance with [RFC7173], the PPP encapsulation is the default.
VPTSモデルは、[RFC7173]で指定されているように、MPLSカプセル化にPPPまたはイーサネット疑似配線を使用し、そのRFCのパケット形式を変更する必要はありません。 [RFC7173]に従い、PPPカプセル化がデフォルトです。
This model isn't required to employ the "split horizon" mechanism in the provider PSN network, as TRILL takes care of loop-free topology using distribution trees. Any multi-destination packet will traverse a distribution tree path. All distribution trees are calculated based on the TRILL base protocol standard [RFC6325] as updated by [RFC7780].
TRILLは配布ツリーを使用してループのないトポロジを処理するため、このモデルはプロバイダーPSNネットワークで「スプリットホライズン」メカニズムを採用する必要はありません。複数の宛先パケットはすべて、配布ツリーパスを通過します。すべての配布ツリーは、[RFC7780]によって更新されたTRILLベースプロトコル標準[RFC6325]に基づいて計算されます。
This section specifies multi-destination and unicast frame processing in the VPTS/TIR model.
このセクションでは、VPTS / TIRモデルでのマルチ宛先およびユニキャストフレーム処理を指定します。
Any multi-destination (unknown unicast, multicast, or broadcast, as indicated by the multi-destination bit in the TRILL header) packets inside a VTSD will be processed or forwarded through the distribution tree for which they were encapsulated on TRILL ingress. If any multi-destination packet is received from the wrong pseudowire at a VTSD, the TRILL protocol running in the VTSD will perform an RPF check as specified in [RFC7780] and drop the packet.
VTSD内のすべてのマルチ宛先（不明なユニキャスト、マルチキャスト、またはブロードキャスト、TRILLヘッダーのマルチ宛先ビットで示される）パケットは、TRILL入力でカプセル化された配布ツリーを通じて処理または転送されます。 VTSDで誤った疑似配線から複数の宛先パケットを受信した場合、VTSDで実行されているTRILLプロトコルは、[RFC7780]で指定されているようにRPFチェックを実行し、パケットをドロップします。
The pruning mechanism in distribution trees, as specified in [RFC6325] and [RFC7780], can also be used to avoid forwarding of multi-destination data packets on the branches where there are no potential destinations.
[RFC6325]と[RFC7780]で指定されている配布ツリーのプルーニングメカニズムを使用して、潜在的な宛先がないブランチでの複数宛先データパケットの転送を回避することもできます。
Unicast packets are forwarded in the same way they get forwarded in a standard TRILL campus as specified in [RFC6325]. If multiple equal-cost paths are available over pseudowires to reach the destination, then VTSD should be capable of doing ECMP for those equal-cost paths.
ユニキャストパケットは、[RFC6325]で指定されている標準のTRILLキャンパスで転送されるのと同じ方法で転送されます。疑似配線を介して宛先に到達するために複数の等コストパスが利用可能な場合、VTSDはそれらの等コストパスに対してECMPを実行できる必要があります。
The VPLS model uses a simpler loop-breaking rule: the "split horizon" rule, where a PE must not forward traffic from one PW to another in the same VPLS mesh. In contrast, the VPTS model uses distribution trees for loop-free topology. As this is an emulated TRILL service, for interoperability purposes, the VPTS model is the default.
VPLSモデルは、より単純なループ遮断ルール、つまり「スプリットホライズン」ルールを使用します。このルールでは、PEはトラフィックを同じVPLSメッシュ内のあるPWから別のPWに転送してはなりません。対照的に、VPTSモデルは、ループのないトポロジに分散ツリーを使用します。これはエミュレートされたTRILLサービスであるため、相互運用性のために、VPTSモデルがデフォルトです。
Whenever a packet gets received over a pseudowire, a VTSD will decapsulate the MPLS headers then check the TRILL header. If the egress nickname in the TRILL header is for a TRILL site located beyond another pseudowire, then the VTSD will encapsulate the packet with new MPLS headers and send it across the proper pseudowire.
パケットが疑似配線を介して受信されるたびに、VTSDはMPLSヘッダーのカプセル化を解除してから、TRILLヘッダーを確認します。 TRILLヘッダーの出力ニックネームが別の疑似配線の向こう側にあるTRILLサイト用である場合、VTSDは新しいMPLSヘッダーでパケットをカプセル化し、適切な疑似配線を介して送信します。
For example, in Figure 3, consider that the pseudowire between TIR1 and TIR2 fails. Then, TIR1 will communicate with TIR2 via TIR3. Whenever packets that are destined to TIR3 are received from the pseudowire between TIR1 and TIR3, the VTSD inside TIR3 will decapsulate the MPLS headers, then check the TRILL header's egress nickname field. If the egress nickname indicates it is destined for the RBridge in Site 3, then the packet will be sent to RBc; if the egress nickname is located at Site 2, VTSD will add MPLS headers for the pseudowire between TIR3 and TIR2 and forward the packet on that pseudowire.
たとえば、図3で、TIR1とTIR2の間の疑似配線に障害が発生したとします。次に、TIR1はTIR3を介してTIR2と通信します。 TIR3宛てのパケットがTIR1とTIR3の間の疑似配線から受信されるたびに、TIR3内のVTSDがMPLSヘッダーをカプセル化解除し、次にTRILLヘッダーの出力ニックネームフィールドを確認します。出力ニックネームがサイト3のRBridge宛てであることを示している場合、パケットはRBcに送信されます。出力ニックネームがサイト2にある場合、VTSDはTIR3とTIR2の間の疑似配線にMPLSヘッダーを追加し、その疑似配線でパケットを転送します。
Since the VPTS model uses distribution trees for processing of multi-destination data packets, it is always advisable to have at least one distribution tree root located in every TRILL site. This will prevent data packets from being received at TRILL sites where end-station service is not enabled for that data packet.
VPTSモデルはマルチ宛先データパケットの処理に配布ツリーを使用するため、すべてのTRILLサイトに少なくとも1つの配布ツリールートを配置することを常にお勧めします。これにより、データパケットに対してエンドステーションサービスが有効になっていないTRILLサイトでデータパケットが受信されなくなります。
This document specifies methods using existing standards and facilities in ways that do not create new security problems.
このドキュメントでは、新しいセキュリティの問題を引き起こさない方法で、既存の標準と機能を使用する方法を指定します。
For general VPLS security considerations, including discussion of isolating customers from each other, see [RFC4761] and [RFC4762].
VPLSのセキュリティに関する一般的な考慮事項については、顧客を相互に分離することを含め、[RFC4761]および[RFC4762]を参照してください。
For security considerations for transport of TRILL by pseudowires, see [RFC7173]. In particular, since pseudowires are supported by MPLS or IP, which are in turn supported by a link layer, that document recommends using IP security, such as IPsec [RFC4301] or DTLS [RFC6347], or the lower link-layer security, such as MACSEC [802.1AE] for Ethernet links.
疑似配線によるTRILLの転送に関するセキュリティの考慮事項については、[RFC7173]を参照してください。特に、疑似配線はMPLSまたはIPによってサポートされ、次にリンク層によってサポートされるため、このドキュメントでは、IPsec [RFC4301]またはDTLS [RFC6347]などのIPセキュリティ、またはより低いリンク層セキュリティなどを使用することを推奨しています。イーサネットリンクのMACSEC [802.1AE]として。
Transmission outside the customer environment through the provider environment, as described in this document, increases risk of compromise or injection of false data through failure of tenant isolation or by the provider. In the VPLS model (Section 3), the use of link encryption and authentication between the CEs of a tenant that is being connected through provider facilities should be a good defense. In the VPTS model (Section 4), it is assumed that the CEs will peer with virtual TRILL switches of the provider network, and thus link security between TRILL switch ports is inadequate as it will terminate at the edge PE. Thus, encryption and authentication from end station to end station and authentication are more appropriate for the VPTS model.
このドキュメントで説明されているように、プロバイダー環境を介して顧客環境の外に送信すると、テナントの分離の失敗やプロバイダーによる侵害や不正なデータの挿入のリスクが高まります。 VPLSモデル（セクション3）では、プロバイダー施設を介して接続されているテナントのCE間でリンクの暗号化と認証を使用することで、十分な防御が可能になります。 VPTSモデル（セクション4）では、CEはプロバイダーネットワークの仮想TRILLスイッチとピアリングすることが想定されており、エッジPEで終端するため、TRILLスイッチポート間のリンクセキュリティは不十分です。したがって、エンドステーションからエンドステーションへの暗号化と認証、および認証は、VPTSモデルに適しています。
For added security against the compromise of data, end-to-end encryption and authentication should be considered; that is, encryption and authentication from source end station to destination end station. This would typically be provided by IPsec [RFC4301] or DTLS [RFC6347] or other protocols convenient to protect the information of concern.
データの侵害に対するセキュリティを強化するには、エンドツーエンドの暗号化と認証を検討する必要があります。つまり、ソースエンドステーションから宛先エンドステーションへの暗号化と認証です。これは通常、IPsec [RFC4301]、DTLS [RFC6347]、または問題の情報を保護するのに便利なその他のプロトコルによって提供されます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[IS-IS] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, 2002.
[IS-IS] ISO、「コネクションレスモードのネットワークサービスを提供するためのプロトコル（ISO 8473）と組み合わせて使用するための中間システムから中間システムへのルーティング情報交換プロトコル」、ISO / IEC 10589：2002、2002。
[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K。、編、およびY. Rekhter、編、「自動検出とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https ：//www.rfc-editor.org/info/rfc4761>。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、DOI 10.17487 / RFC4762、2007年1月、<https ：//www.rfc-editor.org/info/rfc4762>。
[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>。
[RFC7173] Yong, L., Eastlake 3rd, D., Aldrin, S., and J. Hudson, "Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires", RFC 7173, DOI 10.17487/RFC7173, May 2014, <https://www.rfc-editor.org/info/rfc7173>.
[RFC7173] Yong、L.、Eastlake 3rd、D.、Aldrin、S。、およびJ. Hudson、「トランスペアレントインターコネクションオブリンクス（TRILL）Transport using Pseudowires」、RFC 7173、DOI 10.17487 / RFC7173、2014年5月、 <https://www.rfc-editor.org/info/rfc7173>。
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and V. Manral, "Transparent Interconnection of Lots of Links (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014, <https://www.rfc-editor.org/info/rfc7177>.
[RFC7177] Eastlake 3rd、D.、Perlman、R.、Ghanwani、A.、Yang、H.、and V. Manral、 "Transparent Interconnection of Lots of Links（TRILL）：Adjacency"、RFC 7177、DOI 10.17487 / RFC7177 、2014年5月、<https://www.rfc-editor.org/info/rfc7177>。
[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>。
[802.1AE] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", IEEE Std 802.1AE, DOI 10.1109/IEEESTD.2006.245590.
[802.1AE] IEEE、「IEEE Standard for Local and Metropolitan Area Networks：Media Access Control（MAC）Security」、IEEE Std 802.1AE、DOI 10.1109 / IEEESTD.2006.245590。
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <https://www.rfc-editor.org/info/rfc4026>.
[RFC4026] Andersson、L。およびT. Madsen、「Provider Provisioned Virtual Private Network（VPN）Terminology」、RFC 4026、DOI 10.17487 / RFC4026、2005年3月、<https://www.rfc-editor.org/info/ rfc4026>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006, <https://www.rfc-editor.org/info/rfc4664>.
[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、「Framework for Layer 2 Virtual Private Networks（L2VPNs）」、RFC 4664、DOI 10.17487 / RFC4664、2006年9月、<https：// www。 rfc-editor.org/info/rfc4664>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>。
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, November 2013, <https://www.rfc-editor.org/info/rfc7041>.
[RFC7041] Balus、F.、Ed。、Sajassi、A.、Ed。、and N. Bitar、Ed。、 "Extensions to the Virtual Private LAN Service（VPLS）Provider Edge（PE）Model for Provider Backbone Bridging"、 RFC 7041、DOI 10.17487 / RFC7041、2013年11月、<https://www.rfc-editor.org/info/rfc7041>。
[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>。
Acknowledgements
謝辞
The contributions of Andrew G. Malis are gratefully acknowledged in improving the quality of this document.
Andrew G. Malisの貢献は、このドキュメントの品質の向上に感謝しています。
Authors' Addresses
著者のアドレス
Mohammed Umair Cisco Systems SEZ, Cessna Business Park Sarjapur - Marathahalli Outer Ring road Bengaluru - 560103 India
Mohammed Umair Cisco Systems SEZ、Cesna Business Park Sarjapur-Marathahalli Outer Ring road Bengaluru-560103 India
Email: mohammed.umair2@gmail.com
S. Kingston Smiler PALC NETWORKS PVT LTD Envision Technology Center #119, 1st Floor, Road No.3 EPIP Area Phase 1, Whitefield Near Vydehi Hospital Bengaluru - 560066, Karnataka India
S. Kingston Smiler PALC NETWORKS PVT LTD Envision Technology Center＃119、1st Floor、Road No.3 EPIP Area Phase 1、Whitefield Near Vydehi Hospital Bengaluru-560066、Karnataka India
Email: kingstonsmiler@gmail.com
Donald Eastlake 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 United States of America
ドナルドイーストレイク3rd Huawei Technologies 155 Beaver Streetミルフォード、マサチューセッツ州01757アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Lucy Yong Independent
ルーシー・ヨン独立
Phone: +1-469-227-5837
Email: lucyyong@gmail.com