[要約] 要約： RFC 7956は、TRILL（Transparent Interconnection of Lots of Links）分散レイヤー3ゲートウェイの仕様を定義しています。この仕様は、TRILLネットワーク内で異なるサブネット間の通信を可能にするためのゲートウェイ機能を提供します。目的： RFC 7956の目的は、TRILLネットワーク内での異なるサブネット間の通信を効率的かつ透明に行うためのゲートウェイの動作と要件を定義することです。これにより、TRILLネットワークのスケーラビリティと柔軟性が向上します。
Internet Engineering Task Force (IETF) W. Hao
Request for Comments: 7956 Y. Li
Category: Standards Track Huawei
ISSN: 2070-1721 A. Qu
MediaTec
M. Durrani
Equinix Inc.
P. Sivamurugan
IP Infusion
September 2016
Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway
多数のリンクの透過的な相互接続（TRILL）分散型レイヤー3ゲートウェイ
Abstract
概要
The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter-subnet traffic forwarding but has the following issues:
基本TRILL（たくさんのリンクの透過的相互接続）プロトコルは、レイヤー2サブネット内トラフィックには最適なペアワイズデータフレーム転送を提供しますが、レイヤー3サブネット間トラフィックには提供しません。集中型ゲートウェイソリューションは通常、レイヤー3のサブネット間トラフィック転送に使用されますが、次の問題があります。
1. Sub-optimum forwarding paths for inter-subnet traffic.
1. サブネット間トラフィックの最適ではない転送パス。
2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per Data Label used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.
2. TRILLキャンパス内のすべてのレイヤー2仮想ネットワークに相互接続機能を提供するために、データセンター内の非常に多くのゲートウェイインターフェイス（テナントが使用するデータラベルごとにテナントごとに1つ）をサポートする必要がある集中型ゲートウェイ。
3. A traffic bottleneck at the gateway.
3. ゲートウェイでのトラフィックのボトルネック。
This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues.
このドキュメントでは、これらの集中型ゲートウェイの問題を解決するオプションのTRILL分散ゲートウェイソリューションを指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 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 http://www.rfc-editor.org/info/rfc7956.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7956で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Document Organization ......................................3
2. Conventions Used in This Document ...............................4
3. Simplified Example and Problem Statement ........................5
3.1. Simplified Example .........................................6
3.2. Problem Statement Summary ..................................8
4. Layer 3 Traffic Forwarding Model ................................9
5. Distributed Gateway Solution Details ...........................10
5.1. Local Routing Information .................................11
5.2. Local Routing Information Synchronization .................12
5.3. Active-Active Access ......................................14
5.4. Data Traffic Forwarding Process ...........................15
6. Distributed Layer 3 Gateway Process Example ....................16
6.1. Control-Plane Process .....................................17
6.2. Data-Plane Process ........................................19
7. TRILL Protocol Extensions ......................................20
7.1. The Tenant Label and Gateway MAC APPsub-TLV ...............20
7.2. The SE Flag in the NickFlags APPsub-TLV ...................21
7.3. The IPv4 Prefix APPsub-TLV ................................22
7.4. The IPv6 Prefix APPsub-TLV ................................23
8. Security Considerations ........................................24
9. Management Considerations ......................................24
10. IANA Considerations ...........................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Acknowledgments ...................................................27
Authors' Addresses ................................................28
The TRILL (Transparent Interconnection of Lots of Links) protocol [RFC6325] [RFC7780] provides a solution for least-cost transparent routing in multi-hop networks with arbitrary topologies and link technologies, using IS-IS [IS-IS] [RFC7176] link-state routing and a hop count. TRILL switches are sometimes called RBridges (Routing Bridges).
TRILL（多数のリンクの透過的相互接続）プロトコル[RFC6325] [RFC7780]は、IS-IS [IS-IS] [RFC7176]を使用して、任意のトポロジーとリンクテクノロジーを備えたマルチホップネットワークにおける最小コストの透過ルーティングのソリューションを提供しますリンクステートルーティングとホップカウント。 TRILLスイッチは、RBridges（ルーティングブリッジ）と呼ばれることもあります。
The base TRILL protocol provides optimal unicast forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic, where "subnet" means a different IP address prefix and, typically, a different Data Label (VLAN or FGL (Fine-Grained Label)). This document specifies a TRILL-based distributed Layer 3 gateway solution that provides optimal unicast forwarding for Layer 3 inter-subnet traffic. With distributed gateway support, an edge RBridge provides routing based on the Layer 2 identity (address and Virtual Network (VN, i.e., Data Label)) among End Stations (ESs) that belong to the same subnet and also provides routing based on the Layer 3 identity among ESs that belong to different subnets of the same routing domain. An edge RBridge supporting this feature needs to provide routing instances and Layer 3 gateway interfaces for locally connected ESs. Such routing instances provide IP address isolation between tenants. In the TRILL distributed Layer 3 gateway solution, inter-subnet traffic can be fully spread over edge RBridges, so there is no single bottleneck.
基本TRILLプロトコルは、レイヤー2のサブネット内トラフィックには最適なユニキャスト転送を提供しますが、レイヤー3のサブネット間トラフィックには提供しません。「サブネット」は、異なるIPアドレスプレフィックスと、通常は異なるデータラベル（VLANまたはFGL（Fine-グレインラベル））。このドキュメントでは、レイヤー3のサブネット間トラフィックに最適なユニキャスト転送を提供するTRILLベースの分散型レイヤー3ゲートウェイソリューションについて説明します。分散ゲートウェイのサポートにより、エッジRBridgeは、同じサブネットに属するエンドステーション（ES）間のレイヤー2 ID（アドレスおよび仮想ネットワーク（VN、つまりデータラベル））に基づくルーティングを提供し、レイヤーに基づくルーティングも提供します同じルーティングドメインの異なるサブネットに属するES間の3つのID。この機能をサポートするエッジRBridgeは、ローカルに接続されたESにルーティングインスタンスとレイヤー3ゲートウェイインターフェイスを提供する必要があります。このようなルーティングインスタンスは、テナント間のIPアドレス分離を提供します。 TRILL分散型レイヤー3ゲートウェイソリューションでは、サブネット間トラフィックをエッジRBridgeに完全に分散できるため、単一のボトルネックはありません。
This document is organized as follows: Section 3 gives a simplified example and also a more detailed problem statement. Section 4 gives the Layer 3 traffic forwarding model. Section 5 provides a distributed gateway solution overview. Section 6 gives a detailed distributed gateway solution example. Section 7 describes the TRILL protocol extensions needed to support this distributed gateway solution.
このドキュメントは次のように構成されています。セクション3は、簡単な例と、より詳細な問題ステートメントを示しています。セクション4は、レイヤー3トラフィック転送モデルを示しています。セクション5では、分散ゲートウェイソリューションの概要を説明します。セクション6では、詳細な分散ゲートウェイソリューションの例を示します。セクション7では、この分散ゲートウェイソリューションをサポートするために必要な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 terms and acronyms in [RFC6325] are used, with the following additions:
[RFC6325]の用語と頭字語が使用され、以下が追加されています。
AGG: Aggregation switch.
AGG：集約スイッチ。
ARP: Address Resolution Protocol [RFC826].
ARP：アドレス解決プロトコル[RFC826]。
Campus: The name for a network using the TRILL protocol in the same sense that a "bridged LAN" is the name for a network using bridging. In TRILL, the word "campus" has no academic implication.
キャンパス：「ブリッジLAN」がブリッジングを使用するネットワークの名前であるのと同じ意味で、TRILLプロトコルを使用するネットワークの名前。 TRILLでは、「キャンパス」という言葉は学問的な意味を持ちません。
COR: Core switch.
COR：コアスイッチ。
Data Label: VLAN or FGL [RFC7172].
データラベル：VLANまたはFGL [RFC7172]。
DC: Data Center.
DC：データセンター。
Edge RBridge: An RBridge that connects to one or more ESs without any intervening RBridges.
エッジRBridge：RBridgeを介在させずに1つ以上のESに接続するRBridge。
ES: End Station. A Virtual Machine or physical server, whose address is either the destination or source of a data frame.
ES：エンドステーション。アドレスがデータフレームの宛先またはソースのいずれかである仮想マシンまたは物理サーバー。
FGL: Fine-Grained Label [RFC7172].
FGL：きめの細かいラベル[RFC7172]。
Gateway interface: A Layer 3 virtual interface that terminates Layer 2 forwarding and forwards IP traffic to the destination using IP forwarding rules. Incoming traffic from a physical port on a gateway will be distributed to its virtual gateway interface based on the Data Label (VLAN or FGL).
ゲートウェイインターフェイス：レイヤー2転送を終了し、IP転送ルールを使用してIPトラフィックを宛先に転送するレイヤー3仮想インターフェイス。ゲートウェイの物理ポートからの受信トラフィックは、データラベル（VLANまたはFGL）に基づいて仮想ゲートウェイインターフェイスに配信されます。
Inner.MacDA: The inner MAC destination address in a TRILL Data packet [RFC6325].
Inner.MacDA：TRILLデータパケットの内部MAC宛先アドレス[RFC6325]。
Inner.MacSA: The inner MAC source address in a TRILL Data packet [RFC6325].
Inner.MacSA：TRILLデータパケットの内部MAC送信元アドレス[RFC6325]。
Inner.VLAN: The inner VLAN tag in a TRILL Data packet payload [RFC6325].
Inner.VLAN：TRILLデータパケットペイロードの内部VLANタグ[RFC6325]。
L2: Layer 2.
いいえ：リアA.
L3: IP Layer 3.
L3：IPレイヤー3。
LSP: Link State PDU
LSP：リンク状態PDU
ND: IPv6's Neighbor Discovery [RFC4861].
ND：IPv6の近隣探索[RFC4861]。
ToR: Top of Rack.
ToR：トップオブラック。
VN: Virtual Network. In a TRILL campus, a unique 12-bit VLAN ID or a 24-bit FGL [RFC7172] identifies each VN.
VN：仮想ネットワーク。 TRILLキャンパスでは、一意の12ビットVLAN IDまたは24ビットFGL [RFC7172]が各VNを識別します。
VRF: Virtual Routing and Forwarding. In IP-based computer networks, VRF technology supports multiple instances of routing tables existing within the same router at the same time.
VRF：仮想ルーティングおよび転送。 IPベースのコンピューターネットワークでは、VRFテクノロジは、同じルーター内に同時に存在するルーティングテーブルの複数のインスタンスをサポートします。
There is normally a Data Label (VLAN or FGL) associated with each IP subnet. For traffic within a subnet -- that is, IP traffic to another ES in the same Data Label attached to the TRILL campus -- the ES just ARPs for the MAC address of the destination ES's IP. It then uses this MAC address for traffic to that destination. TRILL routes the ingressed TRILL Data packets to the destination's edge RBridge based on the egress nickname for that destination MAC address and Data Label. This is the regular TRILL base protocol [RFC6325] process.
通常、各IPサブネットに関連付けられたデータラベル（VLANまたはFGL）があります。サブネット内のトラフィック、つまりTRILLキャンパスに接続された同じデータラベル内の別のESへのIPトラフィックの場合、ESは宛先ESのIPのMACアドレスのARPだけです。次に、その宛先へのトラフィックにこのMACアドレスを使用します。 TRILLは、その宛先MACアドレスとデータラベルの出力ニックネームに基づいて、入力されたTRILLデータパケットを宛先のエッジRBridgeにルーティングします。これは通常のTRILLベースプロトコル[RFC6325]プロセスです。
If two ESs of the same tenant are on different subnets and need to communicate with each other, their packets are typically forwarded to an IP L3 gateway that performs L3 routing and, if necessary, changes the Data Label. Either a centralized L3 gateway solution or the distributed L3 gateway solution specified in this document can be used for inter-subnet traffic forwarding.
同じテナントの2つのESが異なるサブネット上にあり、互いに通信する必要がある場合、それらのパケットは通常、L3ルーティングを実行するIP L3ゲートウェイに転送され、必要に応じてデータラベルが変更されます。このドキュメントで指定されている集中型L3ゲートウェイソリューションまたは分散型L3ゲートウェイソリューションは、サブネット間トラフィック転送に使用できます。
Section 3.1 gives a simplified example in a TRILL campus with and without a distributed L3 gateway using VLAN Data Labels. Section 3.2 gives a detailed description of the issues related to using a centralized gateway (i.e., without a distributed L3 gateway). The remainder of this document, particularly Section 5, describes the distributed gateway solution in detail.
セクション3.1は、VLANデータラベルを使用した分散型L3ゲートウェイがある場合とない場合のTRILLキャンパスでの簡単な例を示しています。セクション3.2では、集中型ゲートウェイの使用（つまり、分散L3ゲートウェイなし）に関連する問題について詳しく説明しています。このドキュメントの残りの部分、特にセクション5では、分散ゲートウェイソリューションについて詳しく説明します。
Figure 1 depicts a TRILL DC network, where ToR switches are edge RBridges and the AGGs and CORs are non-edge RBridges.
図1は、TRILL DCネットワークを示しています。ToRスイッチはエッジRBridgeで、AGGとCORは非エッジRBridgeです。
------- --------
| COR1| | COR2 |
------- --------
| |
------- -------
|AGG1 | |AGG2 |
------- -------
| |
-----------------------------------------------------
| -------------|------------------|----------------|
| | | | | | | |
------- ------- ------- -------
| RB1 | | RB2 | | RB3 | | RB4 |
|ToR1 | |ToR2 | |ToR3 | |ToR4 |
------- ------- ------- -------
| | | | | | | |
----- ----- ----- ----- ----- ----- ----- -----
|ES1| |ES2| |ES3| |ES4| |ES5| |ES6| |ES7| |ES8|
----- ----- ----- ----- ----- ----- ----- -----
Figure 1: A Typical TRILL DC Network
図1：典型的なTRILL DCネットワーク
ES1 through ES8 belong to one tenant network, and the tenant has four subnets with each subnet corresponding to one VLAN (which indicates one individual L2 VN). Each ES's IP address, VLAN, and subnet are listed below:
ES1からES8は1つのテナントネットワークに属し、テナントには4つのサブネットがあり、各サブネットは1つのVLAN（1つの個別のL2 VNを示す）に対応しています。各ESのIPアドレス、VLAN、およびサブネットを以下に示します。
+----+----------------+-----------------+----------+
| ES | IP Address | Subnet | VLAN |
+----+----------------+-----------------+----------+
| ES1| 192.0.2.2 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+
| ES2| 198.51.100.2 | 198.51.100.0/24 | 11 |
+----+----------------+-----------------+----------+
| ES3| 192.0.2.3 | 192.0.2.0/24 | 10 |
+----+----------------+-----------------+----------+
| ES4| 198.51.100.3 | 198.51.100.0/24 | 11 |
+----+----------------+-----------------+----------+
| ES5| 203.0.113.2 | 203.0.113.0/25 | 12 |
+----+----------------+-----------------+----------+
| ES6| 203.0.113.130 | 203.0.113.128/25| 13 |
+----+----------------+-----------------+----------+
| ES7| 203.0.113.3 | 203.0.113.0/25 | 12 |
+----+----------------+-----------------+----------+
| ES8| 203.0.113.131 | 203.0.113.128/25| 13 |
+----+----------------+-----------------+----------+
Assume that a centralized gateway solution is used with both COR1 and COR2 acting as centralized gateways for redundancy in Figure 1. COR1 and COR2 each have four gateway interfaces for the four subnets in the tenant. In the centralized L3 gateway solution, all traffic within the tenant between different VLANs must go through the centralized L3 gateway device of COR1 or COR2, even if the traffic is between two ESs connected to the same edge RBridge, because only the L3 gateway can change the VLAN labeling of the traffic.
図1の冗長性のために、COR1とCOR2の両方が集中型ゲートウェイとして機能する集中型ゲートウェイソリューションが使用されていると想定します。COR1とCOR2はそれぞれ、テナントの4つのサブネットに対して4つのゲートウェイインターフェイスを備えています。集中型L3ゲートウェイソリューションでは、同じエッジRBridgeに接続されている2つのES間のトラフィックであっても、異なるVLAN間のテナント内のすべてのトラフィックは、COR1またはCOR2の集中型L3ゲートウェイデバイスを通過する必要があります。トラフィックのVLANラベル。
This is generally sub-optimal because the two ESs may be connected to the same ToR where L3 switching could have been performed locally. For example, in Figure 1 above, the unicast IP traffic between ES1 and ES2 has to go through a centralized gateway of COR1 or COR2. It can't be locally routed between them on ToR1. However, if an edge RBridge has the distributed gateway capabilities specified in this document, then it can still perform optimum L2 forwarding for intra-subnet traffic and, in addition, optimum L3 forwarding for inter-subnet traffic, thus delivering optimum forwarding for unicast packets in all important cases.
L3スイッチングがローカルで実行されている可能性がある場合、2つのESが同じToRに接続される可能性があるため、これは一般的に最適ではありません。たとえば、上記の図1では、ES1とES2の間のユニキャストIPトラフィックは、COR1またはCOR2の集中型ゲートウェイを経由する必要があります。 ToR1でローカルにルーティングすることはできません。ただし、エッジRBridgeにこのドキュメントで指定されている分散ゲートウェイ機能がある場合でも、サブネット内トラフィックに対して最適なL2転送を実行でき、さらにサブネット間トラフィックに対して最適なL3転送を実行できるため、ユニキャストパケットに最適な転送を提供できます。すべての重要なケースで。
With a distributed L3 gateway, each edge RBridge acts as a default L3 gateway for local connecting ESs and has IP router capabilities to direct IP communications to other edge RBridges. Each edge RBridge only needs gateway interfaces for local connecting ESs, i.e., RB1 and RB2 need gateway interfaces only for VLAN 10 and VLAN 11 while RB3 and RB4 need gateway interfaces only for VLAN 12 and VLAN 13. No device needs to maintain gateway interfaces for all VLANs in the entire network. This will enhance scalability in terms of the number of tenants and subnets per tenant.
分散型L3ゲートウェイでは、各エッジRBridgeはローカル接続ESのデフォルトL3ゲートウェイとして機能し、IP通信を他のエッジRBridgeに転送するIPルーター機能を備えています。各エッジRBridgeはローカル接続ESのゲートウェイインターフェイスのみを必要とします。つまり、RB1とRB2はVLAN 10とVLAN 11のゲートウェイインターフェイスのみを必要とし、RB3とRB4はVLAN 12とVLAN 13のゲートウェイインターフェイスのみを必要とします。ネットワーク全体のすべてのVLAN。これにより、テナントとテナントあたりのサブネットの数の点でスケーラビリティが向上します。
When each ES ARPs for its L3 gateway, that is, its IP router, the edge RBridge to which it is connected will respond with that RBridge's "gateway MAC". When the ES later sends IP traffic to the L3 gateway, which it does if the destination IP is outside of its subnet, the edge RBridge intercepts the IP packet because the destination MAC is its gateway MAC. That RBridge routes the IP packet using the routing instance associated with that tenant, handling it in one of three ways:
L3ゲートウェイ、つまりそのIPルーターの各ES ARPが接続されているエッジRBridgeは、そのRBridgeの「ゲートウェイMAC」で応答します。 ESが後でIPトラフィックをL3ゲートウェイに送信すると、宛先IPがサブネットの外にある場合は、宛先MACがゲートウェイMACであるため、エッジRBridgeがIPパケットをインターセプトします。そのRBridgeは、そのテナントに関連付けられたルーティングインスタンスを使用してIPパケットをルーティングし、次の3つの方法のいずれかで処理します。
(1) ES1 communicates with ES2. The destination IP is connected to the same edge RBridge; the RBridge of ToR1 can simply transmit the IP packet out the right edge port in the destination VLAN.
（1）ES1はES2と通信します。宛先IPは同じエッジRBridgeに接続されています。 ToR1のRBridgeは、宛先VLANの右エッジポートからIPパケットを送信するだけです。
(2) If the destination IP is located in an outside network, the edge RBridge encapsulates it as a TRILL Data packet and sends it to the actual TRILL campus edge RBridge connecting to an external IP router.
（2）宛先IPが外部ネットワークにある場合、エッジRBridgeはそれをTRILLデータパケットとしてカプセル化し、外部IPルーターに接続している実際のTRILLキャンパスエッジRBridgeに送信します。
(3) ES1 communicates with ES4. The destination ES is connected to a different edge RBridge; the ingress RBridge ToR1 uses TRILL encapsulation to route the IP packet to the correct egress RBridge ToR2, using the egress RBridge's gateway MAC and an Inner.VLAN identifying the tenant. Finally, the egress RBridge terminates the TRILL encapsulation and routes the IP packet to the destination ES based on the routing instance for that tenant.
（3）ES1はES4と通信します。宛先ESは別のエッジRBridgeに接続されています。入力RBridge ToR1はTRILLカプセル化を使用して、IPパケットを正しい出力RBridge ToR2にルーティングし、出力RBridgeのゲートウェイMACとテナントを識別するInner.VLANを使用します。最後に、出力RBridgeはTRILLカプセル化を終了し、そのテナントのルーティングインスタンスに基づいてIPパケットを宛先ESにルーティングします。
With FGL [RFC7172], in theory, up to 16 million L2 VNs can be supported in a TRILL campus. To support inter-subnet traffic, a very large number of L3 gateway interfaces could be needed on a centralized gateway, if each VN corresponds to a subnet and there are many tenants with many subnets per tenant. It is a big burden for the centralized gateway to support so many interfaces. In addition, all inter-subnet traffic will go through a centralized gateway that may become a traffic bottleneck.
FGL [RFC7172]を使用すると、理論上、TRILLキャンパスで最大1600万のL2 VNをサポートできます。サブネット間トラフィックをサポートするには、各VNがサブネットに対応し、テナントごとに多くのサブネットを持つ多くのテナントがある場合、集中ゲートウェイで非常に多数のL3ゲートウェイインターフェイスが必要になる可能性があります。中央ゲートウェイが非常に多くのインターフェースをサポートすることは大きな負担です。さらに、すべてのサブネット間トラフィックは、トラフィックのボトルネックになる可能性がある集中型ゲートウェイを通過します。
The centralized gateway has the following issues:
集中型ゲートウェイには次の問題があります。
1. Sub-optimum forwarding paths for inter-subnet traffic can occur due to the requirements to perform IP routing and possibly change Data Labels at a centralized gateway.
1. IPルーティングを実行し、場合によっては集中型ゲートウェイでデータラベルを変更する必要があるため、サブネット間トラフィックの最適ではない転送パスが発生する可能性があります。
2. The centralized gateway may need to support a very large number of gateway interfaces -- in a DC, one per tenant per Data Label used by that tenant -- to provide interconnect functionality for all the L2 VNs in the TRILL campus.
2. 集中型ゲートウェイは、TRILLキャンパス内のすべてのL2 VNに相互接続機能を提供するために、非常に多くのゲートウェイインターフェイス（DCでは、テナントが使用するデータラベルごとにテナントごとに1つ）をサポートする必要がある場合があります。
3. There may be a traffic bottleneck at the centralized gateway.
3. 集中型ゲートウェイでトラフィックのボトルネックが発生している可能性があります。
A distributed gateway on edge RBridges addresses these issues. Through the distributed L3 gateway solution, the inter-subnet traffic is fully dispersed and is transmitted along optimal pair-wise forwarding paths, improving network efficiency.
エッジRBridgeの分散ゲートウェイは、これらの問題に対処します。分散型L3ゲートウェイソリューションを通じて、サブネット間のトラフィックは完全に分散され、最適なペアワイズフォワーディングパスに沿って送信されるため、ネットワークの効率が向上します。
In a DC network, each tenant has one or more L2 VNs, and, in normal cases, each tenant corresponds to one routing domain. Normally, each L2 VN uses a different Data Label and corresponds to one or more IP subnets.
DCネットワークでは、各テナントに1つ以上のL2 VNがあり、通常、各テナントは1つのルーティングドメインに対応しています。通常、各L2 VNは異なるデータラベルを使用し、1つ以上のIPサブネットに対応します。
Each L2 VN in a TRILL campus is identified by a unique 12-bit VLAN ID or 24-bit FGL [RFC7172]. Different routing domains may have overlapping address space but need distinct and separate routes. The ESs that belong to the same subnet communicate through L2 forwarding; ESs of the same tenant that belong to different subnets communicate through L3 routing.
TRILLキャンパスの各L2 VNは、一意の12ビットVLAN IDまたは24ビットFGL [RFC7172]によって識別されます。異なるルーティングドメインではアドレス空間が重複している場合がありますが、個別の個別のルートが必要です。同じサブネットに属するESは、L2転送を介して通信します。異なるサブネットに属する同じテナントのESは、L3ルーティングを介して通信します。
Figure 2 depicts the model where there are n VRFs corresponding to n tenants, with each tenant having up to m segments/subnets (VNs).
図2は、n個のテナントに対応するn個のVRFがあり、各テナントが最大m個のセグメント/サブネット（VN）を持つモデルを示しています。
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | Tenant n |---------| VRF n | |
| +------------+ | +------------+ | |
| | +-----+ | | | | | |
| | | VN1 | | | | | | |
| | +-----+ | | | VRF 1 | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | | VNm | | | | | | |
| | +-----+ | | | | | |
| | Tenant1 |-+ | | | |
| +------------+ | | | |
| +------------+ +------------+ |
| |
| Edge RBridge |
+---------------------------------------------+
Figure 2: Edge RBridge Model as Distributed Gateway
図2：分散ゲートウェイとしてのエッジRBridgeモデル
With the TRILL distributed gateway solution, an edge RBridge continues to perform routing based on the L2 MAC address for the ESs that are on the same subnet but performs IP routing for the ESs that are on the different subnets of the same tenant.
TRILL分散ゲートウェイソリューションでは、エッジRBridgeは、同じサブネット上にあるESのL2 MACアドレスに基づいて引き続きルーティングを実行しますが、同じテナントの異なるサブネット上にあるESに対してはIPルーティングを実行します。
As the IP address space in different routing domains can overlap, VRF instances need to be created on each edge RBridge to isolate the IP forwarding process for different routing domains present on the edge RBridge. A Tenant ID unique across the TRILL campus identifies each routing domain. The network operator MUST configure the Tenant IDs on each edge RBridge for each routing domain consistently so that the same ID always refers to the same tenant. Otherwise, data might be delivered to the wrong tenant. If a routing domain spreads over multiple edge RBridges, routing information for the routing domain is synchronized among these edge RBridges through the link-state database to ensure reachability to all ESs in that routing domain. The routing information is, in effect, labeled with the Tenant ID to differentiate the routing domains.
異なるルーティングドメインのIPアドレス空間は重複する可能性があるため、エッジRBridgeに存在する異なるルーティングドメインのIP転送プロセスを分離するには、各エッジRBridgeにVRFインスタンスを作成する必要があります。 TRILLキャンパス全体で一意のテナントIDは、各ルーティングドメインを識別します。ネットワークオペレーターは、各ルーティングドメインの各エッジRBridgeでテナントIDを一貫して構成する必要があるため、同じIDは常に同じテナントを参照します。そうしないと、データが間違ったテナントに配信される可能性があります。ルーティングドメインが複数のエッジRBridgeに広がる場合、ルーティングドメインのルーティング情報は、リンクステートデータベースを介してこれらのエッジRBridge間で同期され、そのルーティングドメイン内のすべてのESへの到達可能性が保証されます。実際には、ルーティング情報はテナントIDでラベル付けされており、ルーティングドメインを区別しています。
From the data-plane perspective, all edge RBridges are connected to each other via one or more TRILL hops; however, they are always just a single IP hop away. When an ingress RBridge receives inter-subnet IP traffic from a local ES whose destination MAC is the edge RBridge's gateway MAC, that RBridge will perform Ethernet header termination. The tenant involved is determined by the VLAN of the traffic and the port on which it arrives. The edge RBridge looks up in its IP routing table for that tenant how to route the traffic to the IP next hop. If the destination ES is connected to a remote edge RBridge, the remote RBridge will be the IP next hop for traffic forwarding. For such inter-subnet traffic, the ingress RBridge will rewrite the original Ethernet header with the ingress RBridge's gateway MAC address as the Inner.MacSA and the egress RBridge's gateway MAC address as the Inner.MacDA and then perform TRILL encapsulation to the remote RBridge's nickname, setting the inner Data Label to indicate the tenant involved. TRILL then routes it to the remote edge RBridge through the TRILL campus.
データプレーンの観点から見ると、すべてのエッジRBridgeは、1つ以上のTRILLホップを介して相互に接続されています。ただし、それらは常に1つのIPホップだけです。入力RBridgeが宛先ESがエッジRBridgeのゲートウェイMACであるローカルESからサブネット間IPトラフィックを受信すると、そのRBridgeはイーサネットヘッダー終端を実行します。関連するテナントは、トラフィックのVLANとトラフィックが到着するポートによって決定されます。エッジRBridgeは、IPルーティングテーブルで、そのテナントのトラフィックをIPネクストホップにルーティングする方法を検索します。宛先ESがリモートエッジRBridgeに接続されている場合、リモートRBridgeはトラフィック転送のIPネクストホップになります。このようなサブネット間トラフィックの場合、入力RBridgeは、入力RBridgeのゲートウェイMACアドレスをInner.MacSAとして、出力RBridgeのゲートウェイMACアドレスをInner.MacDAとして元のイーサネットヘッダーを書き換え、リモートRBridgeのニックネームへのTRILLカプセル化を実行します、関係するテナントを示すように内部データラベルを設定します。次にTRILLは、それをTRILLキャンパスを介してリモートエッジRBridgeにルーティングします。
When that remote edge RBridge receives the traffic, it will decapsulate the TRILL Data packet and see that the inner destination MAC is its gateway MAC. It then terminates the inner Ethernet encapsulation and looks up the destination IP in the RBridge's IP forwarding table for the tenant indicated by the inner Data Label, to route it to the destination ES.
そのリモートエッジRBridgeがトラフィックを受信すると、それはTRILLデータパケットのカプセル化を解除し、内部宛先MACがそのゲートウェイMACであることを確認します。次に、内部イーサネットカプセル化を終了し、RBridgeのIP転送テーブルで宛先IPを検索して、内部データラベルで示されたテナントを探し、宛先ESにルーティングします。
Through this method, TRILL with distributed gateways provides optimum pair-wise data routing for inter-subnet traffic.
この方法により、分散ゲートウェイを備えたTRILLは、サブネット間トラフィックに最適なペアワイズデータルーティングを提供します。
An ES can be locally connected to an edge RBridge through an L2 network (such as a point-to-point Ethernet link or a bridged LAN) or externally connected through an L3 IP network.
ESは、L2ネットワーク（ポイントツーポイントイーサネットリンクやブリッジLANなど）を介してエッジRBridgeにローカルに接続するか、L3 IPネットワークを介して外部に接続できます。
If the ES is connected to an edge RBridge through an L2 network, then the edge RBridge acts as an L3 gateway for the ES. A gateway interface is established on the edge RBridge for the connecting ES. Because the ESs in a subnet may be spread over multiple edge RBridges, each such edge RBridge that establishes its gateway interface for the subnet SHOULD share the same gateway MAC and gateway IP address configuration. Sharing the configuration and insuring configuration consistency can be done by local configuration and Network Configuration Protocol (NETCONF) / YANG models.
ESがL2ネットワークを介してエッジRBridgeに接続されている場合、エッジRBridgeはESのL3ゲートウェイとして機能します。接続するESのエッジRBridgeにゲートウェイインターフェイスが確立されます。サブネット内のESは複数のエッジRBridgeに分散している可能性があるため、サブネットのゲートウェイインターフェイスを確立するこのような各エッジRBridgeは、同じゲートウェイMACおよびゲートウェイIPアドレス構成を共有する必要があります（SHOULD）。構成の共有と構成の一貫性の保証は、ローカル構成とネットワーク構成プロトコル（NETCONF）/ YANGモデルで実行できます。
With a distributed gateway, the edge RBridge to which an ES is connected appears to be the local IP router on its link. As in any IP network, before the ES starts to send inter-subnet traffic, it acquires its gateway's MAC through the ARP/ND process. Local connecting edge RBridges that support this distributed gateway feature always respond with the gateway MAC address when receiving ARP/ND requests for the gateway IP. Through the ARP/ND process, the edge RBridge can learn the IP and MAC correspondence of a local ES connected to the edge RBridge by L2 and then generate local IP routing entries for that ES in the corresponding routing domain.
分散ゲートウェイでは、ESが接続されているエッジRBridgeは、そのリンク上のローカルIPルーターのように見えます。他のIPネットワークと同様に、ESはサブネット間トラフィックの送信を開始する前に、ARP / NDプロセスを通じてゲートウェイのMACを取得します。この分散ゲートウェイ機能をサポートするローカル接続エッジRBridgeは、ゲートウェイIPのARP / ND要求を受信すると、常にゲートウェイMACアドレスで応答します。 ARP / NDプロセスを通じて、エッジRBridgeは、L2によってエッジRBridgeに接続されたローカルESのIPおよびMAC対応を学習し、対応するルーティングドメインでそのESのローカルIPルーティングエントリを生成できます。
To TRILL, an IP router connected to an edge RBridge looks like an ES. If a router/ES is located in an external IP network, it normally provides access to one or more IP prefixes. The router/ES SHOULD run an IP routing protocol with the connecting TRILL edge RBridge. The edge RBridge will learn the IP prefixes behind the router/ES through that IP routing protocol, and the RBridge will then generate local IP routing entries in the corresponding routing domain. If such a routing protocol is not run with the edge RBridge, then only the IP prefixes behind the router/ES that are explicitly configured on the edge RBridge will be accessible.
TRILLでは、エッジRBridgeに接続されたIPルーターはESのように見えます。ルーター/ ESが外部IPネットワークにある場合、通常、1つ以上のIPプレフィックスへのアクセスを提供します。ルーター/ ESは、接続するTRILLエッジRBridgeでIPルーティングプロトコルを実行する必要があります（SHOULD）。エッジRBridgeは、そのIPルーティングプロトコルを介してルーター/ ESの背後にあるIPプレフィックスを学習し、RBridgeは対応するルーティングドメインにローカルIPルーティングエントリを生成します。このようなルーティングプロトコルがエッジRBridgeで実行されていない場合、アクセスできるのは、エッジRBridgeで明示的に構成されているルーター/ ESの背後のIPプレフィックスのみです。
When a routing instance is created on an edge RBridge, the Tenant ID, tenant Data Label (VLAN or FGL), and tenant gateway MAC that correspond to that instance are configured and MUST be globally advertised (see Section 7.1). The Tenant ID uniquely identifies that tenant throughout the campus. The tenant Data Label identifies that tenant at the edge RBridge. The tenant gateway MAC MAY identify that tenant, all tenants, or some subset of tenants at the edge RBridge.
ルーティングインスタンスがエッジRBridgeで作成されると、そのインスタンスに対応するテナントID、テナントデータラベル（VLANまたはFGL）、およびテナントゲートウェイMACが構成され、グローバルにアドバタイズされる必要があります（セクション7.1を参照）。テナントIDは、キャンパス全体でそのテナントを一意に識別します。テナントデータラベルは、エッジRBridgeにあるテナントを識別します。テナントゲートウェイMACは、エッジRBridgeでそのテナント、すべてのテナント、またはテナントのサブセットを識別できます。
When an ingress RBridge performs inter-subnet traffic TRILL encapsulation, the ingress RBridge uses the Data Label advertised by the egress RBridge as the inner VLAN or FGL and uses the tenant gateway MAC advertised by the egress RBridge as the Inner.MacDA. The egress RBridge relies on this tenant Data Label to find the local VRF instance for the IP forwarding process when receiving inter-subnet traffic from the TRILL campus. (The role of the tenant Data Label is akin to an MPLS VPN Label in an MPLS IP / MPLS VPN network.) Tenant Data Labels are independently allocated on each edge RBridge for each routing domain. An edge RBridge can use an access Data Label from a routing domain to act as the inter-subnet Data Label, or the edge RBridge can use a Data Label different from any access Data Labels to be a tenant Data Label. It is implementation dependent, and there is no restriction on this assignment of Data Labels.
入力RBridgeがサブネット間トラフィックのTRILLカプセル化を実行する場合、入力RBridgeは、出力RBridgeによってアドバタイズされたデータラベルを内部VLANまたはFGLとして使用し、出力RBridgeによってアドバタイズされたテナントゲートウェイMACをInner.MacDAとして使用します。出力RBridgeは、このテナントデータラベルに依存して、TRILLキャンパスからサブネット間トラフィックを受信するときに、IP転送プロセスのローカルVRFインスタンスを見つけます。 （テナントデータラベルの役割は、MPLS IP / MPLS VPNネットワークのMPLS VPNラベルに似ています。）テナントデータラベルは、各ルーティングドメインの各エッジRBridgeに個別に割り当てられます。エッジRBridgeは、ルーティングドメインからのアクセスデータラベルを使用してサブネット間データラベルとして機能できます。または、エッジRBridgeは、アクセスデータラベルとは異なるデータラベルを使用してテナントデータラベルにすることができます。これは実装に依存しており、このデータラベルの割り当てに制限はありません。
The tenant gateway MAC differentiates inter-subnet L3 traffic from intra-subnet L2 traffic on the egress RBridge. Each tenant on an RBridge can use a different gateway MAC or the same tenant gateway MAC for inter-subnet traffic purposes. This is also implementation dependent, and there is no restriction on it.
テナントゲートウェイMACは、出力RBridge上のサブネット間L3トラフィックとサブネット内L2トラフィックを区別します。 RBridge上の各テナントは、サブネット間トラフィックの目的で、異なるゲートウェイMACまたは同じテナントゲートウェイMACを使用できます。これも実装に依存しており、制限はありません。
When a local IP prefix is learned in a routing instance on an edge RBridge, the edge RBridge should advertise the IP prefix information for the routing instance so that other edge RBridges will generate IP routing entries. If the ESs in a VN are spread over multiple RBridges, these RBridges MUST advertise each local connecting ES's IP address in the VN to other RBridges. If the ESs in a VN are only connected to one edge RBridge, that RBridge only needs to advertise the subnet corresponding to the VN to other RBridges using host routes. A Tenant ID unique across the TRILL campus is also carried in the advertisement to differentiate IP prefixes between different tenants, because the IP address space of different tenants can overlap (see Sections 7.3 and 7.4).
ローカルIPプレフィックスがエッジRBridgeのルーティングインスタンスで学習されると、エッジRBridgeはルーティングインスタンスのIPプレフィックス情報をアドバタイズし、他のエッジRBridgeがIPルーティングエントリを生成するようにします。 VN内のESが複数のRBridgeに分散している場合、これらのRBridgeは、VN内の各ローカル接続ESのIPアドレスを他のRBridgeに通知しなければなりません（MUST）。 VN内のESが1つのエッジRBridgeにのみ接続されている場合、そのRBridgeは、ホストルートを使用して、VNに対応するサブネットを他のRBridgeに通知するだけで済みます。 TRILLキャンパス全体で一意のテナントIDは、異なるテナントのIPアドレス空間が重複する可能性があるため（セクション7.3および7.4を参照）、異なるテナント間でIPプレフィックスを区別するために、アドバタイズメントにも含まれます。
If a tenant is deleted on an edge RBridge RB1, RB1 updates the local tenant Data Label, tenant gateway MAC, and related IP prefix information it is advertising to include only the rest of the tenants. It may take some time for these updates to reach all other RBridges, so during this period of time there may be transient route inconsistency among the edge RBridges. If there is traffic in flight during this time, it will be dropped at the egress RBridge due to local tenant deletion. When a stable state is reached, the traffic to the deleted tenant will be dropped by the ingress RBridge. Therefore, the transient route inconsistency won't cause issues other than wasting some network bandwidth.
エッジRBridge RB1でテナントが削除されると、RB1はローカルテナントのデータラベル、テナントゲートウェイMAC、およびアドバタイズしている関連IPプレフィックス情報を更新して、残りのテナントのみを含めます。これらの更新が他のすべてのRBridgeに到達するまでに時間がかかる場合があるため、この期間中、エッジRBridge間で一時的なルートの不整合が発生する可能性があります。この間に飛行中のトラフィックがある場合、ローカルテナントの削除により、出力RBridgeでドロップされます。安定した状態に達すると、削除されたテナントへのトラフィックは入力RBridgeによってドロップされます。したがって、一時的なルートの不整合は、ネットワーク帯域幅の浪費以外の問題を引き起こしません。
If a new tenant is created and a previously used tenant Data Label is assigned to the new tenant immediately, this may cause a security policy violation for the traffic in flight, because when the egress RBridge receives traffic from the old tenant, it will forward it in the new tenant's routing instance and deliver it to the wrong destination. So, a tenant Data Label MUST NOT be reallocated until a reasonable amount of time -- for example, twice the IS-IS Holding Time generally in use in the TRILL campus -- has passed to allow any traffic in flight to be discarded.
新しいテナントが作成され、以前に使用されたテナントデータラベルが新しいテナントにすぐに割り当てられた場合、下りRBridgeが古いテナントからトラフィックを受信すると転送するため、進行中のトラフィックにセキュリティポリシー違反が発生する可能性があります。新しいテナントのルーティングインスタンスで、それを間違った宛先に配信します。したがって、妥当な時間（たとえば、TRILLキャンパスで一般的に使用されているIS-IS保持時間の2倍）が経過して、飛行中のトラフィックを破棄できるまで、テナントデータラベルを再割り当てしないでください。
When the ARP entry in an edge RBridge for an ES times out, it will trigger an edge RBridge LSP advertisement to other edge RBridges with the corresponding IP routing entry deleted. If the ES is an IP router, the edge RBridge also notifies other edge RBridges that they must delete the routing entries corresponding to the IP prefixes accessible through that IP router. During the IP prefix deleting process, if there is traffic in flight, the traffic will be discarded at the egress RBridge because there is no local IP routing entry to the destination.
ESのエッジRBridgeのARPエントリがタイムアウトすると、対応するIPルーティングエントリが削除された他のエッジRBridgeへのエッジRBridge LSPアドバタイズメントがトリガーされます。 ESがIPルーターの場合、エッジRBridgeは他のエッジRBridgeにも、そのIPルーターを介してアクセス可能なIPプレフィックスに対応するルーティングエントリを削除する必要があることを通知します。 IPプレフィックス削除プロセス中に、処理中のトラフィックがある場合、宛先へのローカルIPルーティングエントリがないため、トラフィックは出力RBridgeで破棄されます。
If an edge RBridge changes its tenant gateway MAC, it will trigger an edge RBridge LSP advertisement to other edge RBridges, giving the new gateway MAC to be used as the Inner.MacDA for future traffic destined to the edge RBridge. During the gateway MAC changing process, if there is traffic in flight using the old gateway MAC as the Inner.MacDA, the traffic will be discarded or will be forwarded as L2 intra-subnet traffic on the edge RBridge. If the inter-subnet tenant Data Label is a unique Data Label that is different from any access Data Labels, when the edge RBridge receives the traffic whose Inner.MacDA is different from the local tenant gateway MAC, the traffic will be discarded. If the edge RBridge uses one of the access Data Labels as an inter-subnet tenant Data Label, the traffic will be forwarded as L2 intra-subnet traffic unless a special traffic-filtering policy is enforced on the edge RBridge.
エッジRBridgeがテナントゲートウェイMACを変更すると、他のエッジRBridgeへのエッジRBridge LSPアドバタイズメントがトリガーされ、新しいゲートウェイMACがエッジRBridge宛の将来のトラフィックのInner.MacDAとして使用されます。ゲートウェイMACの変更プロセス中に、古いゲートウェイMACをInner.MacDAとして使用しているトラフィックがある場合、そのトラフィックは破棄されるか、エッジRBridge上のL2イントラサブネットトラフィックとして転送されます。サブネット間テナントデータラベルがアクセスデータラベルとは異なる一意のデータラベルである場合、エッジRBridgeがローカルテナントゲートウェイMACとは異なるInner.MacDAのトラフィックを受信すると、トラフィックは破棄されます。エッジRBridgeがアクセスデータラベルの1つをサブネット間テナントデータラベルとして使用する場合、特別なトラフィックフィルタリングポリシーがエッジRBridgeに適用されていない限り、トラフィックはL2サブネット内トラフィックとして転送されます。
If there are multiple nicknames owned by an edge RBridge, the edge RBridge can also specify one nickname as the egress nickname for inter-subnet traffic forwarding. A NickFlags APPsub-TLV with the SE flag set can be used for this purpose. If the edge RBridge doesn't specify a nickname for this purpose, the ingress RBridge can use any one of the nicknames owned by the egress as the egress nickname for inter-subnet traffic forwarding.
エッジRBridgeが所有する複数のニックネームがある場合、エッジRBridgeは、サブネット間トラフィック転送用の出力ニックネームとして1つのニックネームを指定することもできます。 SEフラグが設定されたNickFlags APPsub-TLVをこの目的に使用できます。エッジRBridgeがこの目的でニックネームを指定しない場合、入力RBridgeは、サブネット間トラフィック転送の出力ニックネームとして、出力が所有するニックネームのいずれかを使用できます。
TRILL Extended Level 1 Flooding Scope (E-L1FS) FS-LSP [RFC7780] APPsub-TLVs are used for IP routing information synchronization in each routing domain among edge RBridges. Based on the synchronized information from other edge RBridges, each edge RBridge generates routing entries in each routing domain for remote IP addresses and subnets.
TRILL拡張レベル1フラッディングスコープ（E-L1FS）FS-LSP [RFC7780] APPsub-TLVは、エッジRBridge間の各ルーティングドメインでのIPルーティング情報の同期に使用されます。他のエッジRBridgeからの同期情報に基づいて、各エッジRBridgeは、リモートIPアドレスとサブネットの各ルーティングドメインにルーティングエントリを生成します。
Through this solution, the intra-subnet forwarding and inter-subnet IP routing functions are integrated, and network management and deployment are simplified.
このソリューションにより、サブネット内転送機能とサブネット間IPルーティング機能が統合され、ネットワークの管理と導入が簡素化されます。
TRILL active-active service provides ESs with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in [RFC7379].
[RFC7379]で説明されているように、TRILLアクティブ-アクティブサービスはESにフローレベルのロードバランスとTRILLキャンパスのエッジでのリンク障害に対する回復力を提供します。
If an ES is connected to two TRILL RBridges, say RB1 and RB2, in active-active mode, RB1 and RB2 MUST both be configured to act as a distributed L3 gateway for the ES in order to use a distributed gateway. RB1 and RB2 each learn the ES's IP address through the ARP/ND process, and then they announce the IP address to the TRILL campus independently. The remote ingress RBridge will generate an IP routing entry corresponding to the IP address with two IP next hops of RB1 and RB2. When the ingress RBridge receives inter-subnet traffic from a local access network, the ingress RBridge selects RB1 or RB2 as the IP next hop based on least cost or, if costs are equal, the local load-balancing algorithm. The traffic will then be transmitted to the selected next-hop destination RB1 or RB2 through the TRILL campus.
ESが2つのTRILL RBridge、たとえばRB1とRB2に接続されている場合、アクティブ-アクティブモードでは、RB1とRB2の両方が、分散ゲートウェイを使用するためにESの分散L3ゲートウェイとして機能するように構成する必要があります。 RB1とRB2はそれぞれ、ARP / NDプロセスを通じてESのIPアドレスを学習し、IPアドレスをTRILLキャンパスに個別にアナウンスします。リモート入力RBridgeは、RB1とRB2の2つのIPネクストホップを持つIPアドレスに対応するIPルーティングエントリを生成します。入力RBridgeがローカルアクセスネットワークからサブネット間トラフィックを受信すると、入力RBridgeは、最小コスト、またはコストが等しい場合はローカルロードバランシングアルゴリズムに基づいて、RB1またはRB2をIPネクストホップとして選択します。トラフィックは、TRILLキャンパスを介して、選択されたネクストホップ宛先RB1またはRB2に送信されます。
After ES1, connected by L2 in VLAN-x, acquires its gateway's MAC, it can start inter-subnet data traffic transmission to ES2 in VLAN-y.
VLAN-xのL2で接続されたES1がゲートウェイのMACを取得すると、VLAN-yのES2へのサブネット間データトラフィック送信を開始できます。
When the edge RBridge attached to ES1 receives inter-subnet traffic from ES1, that RBridge performs L2 header termination; then, using the local VRF corresponding to VLAN-x, it performs the IP routing process in that VRF.
ES1に接続されたエッジRBridgeがES1からサブネット間トラフィックを受信すると、そのRBridgeはL2ヘッダー終端を実行します。次に、VLAN-xに対応するローカルVRFを使用して、そのVRFでIPルーティングプロセスを実行します。
If destination ES2 is attached to the same edge RBridge, the traffic will be locally forwarded to ES2 by that RBridge. Compared to the centralized gateway solution, the forwarding path is optimal, and a traffic detour through the centralized gateway is avoided.
宛先ES2が同じエッジRBridgeに接続されている場合、トラフィックはそのRBridgeによってローカルにES2に転送されます。集中型ゲートウェイソリューションと比較して、転送パスは最適であり、集中型ゲートウェイを経由するトラフィックの迂回が回避されます。
If ES2 is attached to a remote edge RBridge, the remote edge RBridge is the IP next hop, and the inter-subnet traffic is forwarded to the IP next hop through TRILL encapsulation. If there are multiple equal-cost shortest paths between the ingress RBridge and the egress RBridge, all these paths can be used for inter-subnet traffic forwarding, so load-spreading can be achieved for inter-subnet traffic.
ES2がリモートエッジRBridgeに接続されている場合、リモートエッジRBridgeはIPネクストホップであり、サブネット間トラフィックはTRILLカプセル化を通じてIPネクストホップに転送されます。入力RBridgeと出力RBridgeの間に等コストの最短パスが複数ある場合、これらすべてのパスをサブネット間トラフィックの転送に使用できるため、サブネット間トラフィックの負荷分散を実現できます。
When the remote RBridge receives the inter-subnet TRILL-encapsulated traffic, the RBridge decapsulates these TRILL packets and checks the Inner.MacDA. If that MAC address is the local gateway MAC corresponding to the inner label (VLAN or FGL), the inner label will be used to find the corresponding local VRF; the IP routing process in that VRF will then be performed, and the traffic will be locally forwarded to destination ES2.
リモートRBridgeがサブネット間TRILLカプセル化トラフィックを受信すると、RBridgeはこれらのTRILLパケットをカプセル化解除し、Inner.MacDAをチェックします。そのMACアドレスが内部ラベル（VLANまたはFGL）に対応するローカルゲートウェイMACである場合、内部ラベルは対応するローカルVRFを見つけるために使用されます。そのVRFのIPルーティングプロセスが実行され、トラフィックはローカルで宛先ES2に転送されます。
In summary, this solution avoids traffic detours through a central gateway. Both inter-subnet and intra-subnet traffic can be forwarded along pair-wise shortest paths, and network bandwidth is conserved.
要約すると、このソリューションは中央ゲートウェイを経由するトラフィックの迂回を回避します。サブネット間トラフィックとサブネット内トラフィックの両方をペア単位の最短パスに沿って転送でき、ネットワーク帯域幅が節約されます。
This section gives a detailed description of a distributed L3 gateway solution example for IPv4 and IPv6.
このセクションでは、IPv4およびIPv6の分散L3ゲートウェイソリューションの例について詳しく説明します。
In Figure 3, RB1 and RB2 support the distribution gateway function, ES1 connects to RB1, and ES2 connects to RB2. ES1 and ES2 belong to Tenant1 but are in different subnets.
図3では、RB1とRB2が配布ゲートウェイ機能をサポートし、ES1がRB1に接続し、ES2がRB2に接続しています。 ES1とES2はTenant1に属していますが、異なるサブネットにあります。
--------- ---------
| RB3 | | RB4 |
--------- ---------
# * # *
# **************************
########################### *
# *
# *
# *
--------- ---------
| RB1 | | RB2 |
--------- ---------
| |
----- -----
|ES1| |ES2|
----- -----
Figure 3: Distributed Gateway Scenario
図3：分散ゲートウェイのシナリオ
For IPv4, the IP address, VLAN, and subnet information of ES1 and ES2 are as follows:
IPv4の場合、ES1およびES2のIPアドレス、VLAN、およびサブネット情報は次のとおりです。
+----+----------+------------------+------------------+----------+
| ES | Tenant | IP Address | Subnet | VLAN |
+----+----------+------------------+------------------+----------+
| ES1| Tenant1 | 192.0.2.2 | 192.0.2.0/24 | 10 |
+----+----------+------------------+------------------+----------+
| ES2| Tenant1 | 198.51.100.2 | 198.51.100.0/24 | 20 |
+----+----------+------------------+------------------+----------+
Figure 4: IPv4 ES Information
図4：IPv4 ES情報
For IPv6, the IP address, VLAN, and subnet information of ES1 and ES2 are as follows:
IPv6の場合、ES1およびES2のIPアドレス、VLAN、およびサブネット情報は次のとおりです。
+----+----------+------------------+------------------+----------+
| ES | Tenant | IP Address | Subnet | VLAN |
+----+----------+------------------+------------------+----------+
| ES1| Tenant1 | 2001:db8:0:1::2 |2001:db8:0:1::0/64| 10 |
+----+----------+------------------+------------------+----------+
| ES2| Tenant1 | 2001:db8:0:2::2 |2001:db8:0:2::0/64| 20 |
+----+----------+------------------+------------------+----------+
Figure 5: IPv6 ES Information
図5：IPv6 ES情報
The nickname, VRF, tenant Label, and tenant gateway MAC for Tenant1 on RB1 and RB2 are as follows:
RB1およびRB2上のTenant1のニックネーム、VRF、テナントラベル、およびテナントゲートウェイMACは、次のとおりです。
+----+---------+-----------+-------+--------------+--------------+
| RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC |
+----+---------+-----------+-------+--------------+--------------+
| RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 |
+----+---------+-----------+-------+--------------+--------------+
| RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 |
+----+---------+-----------+-------+--------------+--------------+
Figure 6: RBridge Information
図6：RBridge情報
RB1 advertises the following local routing information to the TRILL campus:
RB1は、次のローカルルーティング情報をTRILLキャンパスにアドバタイズします。
Tenant ID: 1
テナントID：1
Tenant gateway MAC: MAC1
テナントゲートウェイMAC：MAC1
Tenant Label for Tenant1: VLAN 100
テナント1のテナントラベル：VLAN 100
IPv4 prefix for Tenant1: 192.0.2.0/24
テナント1のIPv4プレフィックス：192.0.2.0/24
IPv6 prefix for Tenant1: 2001:db8:0:1::0/64
RB2 announces the following local routing information to the TRILL campus:
RB2は、次のローカルルーティング情報をTRILLキャンパスにアナウンスします。
Tenant ID: 1
テナントID：1
Tenant gateway MAC: MAC2
テナントゲートウェイMAC：MAC2
Tenant Label for Tenant1: VLAN 100
テナント1のテナントラベル：VLAN 100
IPv4 prefix for Tenant1: 198.51.100.0/24
テナント1のIPv4プレフィックス：198.51.100.0/24
IPv6 prefix for Tenant1: 2001:db8:0:2::0/64
Relying on the routing information from RB2, remote routing entries on RB1 are generated as follows:
RB2からのルーティング情報に基づいて、RB1上のリモートルーティングエントリは次のように生成されます。
+------------------+-------------+--------------+----------------+
| Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname|
+------------------+-------------+--------------+----------------+
|198.51.100.0/24 | MAC2 | 100 | nick2 |
+------------------+-------------+--------------+----------------+
|2001:db8:0:2::0/64| MAC2 | 100 | nick2 |
+------------------+-------------+--------------+----------------+
Figure 7: Tenant1 Remote Routing Table on RB1
図7：RB1上のTenant1リモートルーティングテーブル
Similarly, relying on the routing information from RB1, remote routing entries on RB2 are generated as follows:
同様に、RB1からのルーティング情報に依存して、RB2上のリモートルーティングエントリは次のように生成されます。
+------------------+-------------+--------------+----------------+
| Prefix/Mask | Inner.MacDA | Inner VLAN | Egress Nickname|
+------------------+-------------+--------------+----------------+
| 192.0.2.0/24 | MAC1 | 100 | nick1 |
+------------------+-------------+--------------+----------------+
|2001:db8:0:1::0/64| MAC1 | 100 | nick1 |
+------------------+-------------+--------------+----------------+
Figure 8: Tenant1 Remote Routing Table on RB2
図8：RB2上のTenant1リモートルーティングテーブル
Assuming that ES1 sends unicast inter-subnet traffic to ES2, the traffic forwarding process is as follows:
ES1がユニキャストのサブネット間トラフィックをES2に送信すると仮定すると、トラフィック転送プロセスは次のようになります。
1. ES1 sends unicast inter-subnet traffic to RB1 with RB1's gateway's MAC as the destination MAC and the VLAN as VLAN 10.
1. ES1は、RB1のゲートウェイのMACを宛先MACとして、VLANをVLAN 10として、ユニキャストサブネット間トラフィックをRB1に送信します。
2. Ingress RBridge (RB1) forwarding process:
2. 入力RBridge（RB1）転送プロセス：
RB1 checks the destination MAC. If the destination MAC equals the local gateway MAC, the gateway function will terminate the L2 header and perform L3 routing.
RB1は宛先MACをチェックします。宛先MACがローカルゲートウェイMACと等しい場合、ゲートウェイ機能はL2ヘッダーを終了し、L3ルーティングを実行します。
RB1 looks up IP routing table information by destination IP and Tenant ID to get IP next-hop information, which includes the egress RBridge's gateway MAC (MAC2), tenant Label (VLAN 100), and egress nickname (nick2). Using this information, RB1 will perform inner Ethernet header encapsulation and TRILL encapsulation. RB1 will use MAC2 as the Inner.MacDA, MAC1 (RB1's own gateway MAC) as the Inner.MacSA, VLAN 100 as the Inner.VLAN, nick2 as the egress nickname, and nick1 as the ingress nickname.
RB1は、宛先IPおよびテナントIDによってIPルーティングテーブル情報を検索して、出力RBridgeのゲートウェイMAC（MAC2）、テナントラベル（VLAN 100）、および出力ニックネーム（nick2）を含むIPネクストホップ情報を取得します。この情報を使用して、RB1は内部イーサネットヘッダーカプセル化とTRILLカプセル化を実行します。 RB1は、MAC2をInner.MacDAとして使用し、MAC1（RB1の独自のゲートウェイMAC）をInner.MacSAとして使用し、VLAN 100をInner.VLANとして使用し、nick2を出力ニックネームとして使用し、nick1を入力ニックネームとして使用します。
RB1 looks up TRILL forwarding information by egress nickname and sends the traffic to the TRILL next hop as per [RFC6325]. The traffic will be sent to RB3 or RB4 as a result of load-balancing.
RB1は、出力ニックネームでTRILL転送情報を検索し、[RFC6325]に従ってトラフィックをTRILLネクストホップに送信します。トラフィックは、ロードバランシングの結果としてRB3またはRB4に送信されます。
Assuming that the traffic is forwarded to RB3, the following occurs:
トラフィックがRB3に転送されると仮定すると、次のことが起こります。
3. Transit RBridge (RB3) forwarding process:
3. トランジットRBridge（RB3）転送プロセス：
RB3 looks up TRILL forwarding information by egress nickname and forwards the traffic to RB2 as per [RFC6325].
RB3は出力ニックネームでTRILL転送情報を検索し、[RFC6325]に従ってトラフィックをRB2に転送します。
4. Egress RBridge forwarding process:
4. 出力RBridge転送プロセス：
As the egress nickname is RB2's own nickname, RB2 performs TRILL decapsulation. It then checks the Inner.MacDA and, because that MAC is equal to the local gateway MAC, performs inner Ethernet header termination. Using the inner VLAN, RB2 finds the local corresponding VRF and looks up the packet's destination IP address in the VRF's IP routing table. The traffic is then locally forwarded to ES2 with VLAN 20.
出力ニックネームはRB2自体のニックネームであるため、RB2はTRILLカプセル化解除を実行します。次に、Inner.MacDAをチェックし、そのMACはローカルゲートウェイのMACと等しいため、内部イーサネットヘッダー終端を実行します。 RB2は内部VLANを使用して、対応するローカルVRFを見つけ、VRFのIPルーティングテーブルでパケットの宛先IPアドレスを検索します。その後、トラフィックはVLAN 20を使用してローカルにES2に転送されます。
If an edge RBridge RB1 participates in the distributed gateway function, it announces its tenant gateway MAC and tenant Data Label to the TRILL campus through the tenant Label and gateway MAC APPsub-TLV. It should announce its local IPv4 and IPv6 prefixes through the IPv4 Prefix APPsub-TLV and the IPv6 Prefix APPsub-TLV, respectively. If RB1 has multiple nicknames, it can announce one nickname for use by the distributed gateway, by using the NickFlags APPsub-TLV with the SE flag set to 1.
エッジRBridge RB1が分散ゲートウェイ機能に参加する場合、エッジRBridge RB1は、そのテナントゲートウェイMACおよびテナントデータラベルを、テナントラベルおよびゲートウェイMAC APPsub-TLVを通じてTRILLキャンパスに通知します。ローカルのIPv4プレフィックスとIPv6プレフィックスは、それぞれIPv4プレフィックスAPPsub-TLVとIPv6プレフィックスAPPsub-TLVでアナウンスする必要があります。 RB1に複数のニックネームがある場合、SEフラグを1に設定してNickFlags APPsub-TLVを使用することにより、分散ゲートウェイで使用する1つのニックネームをアナウンスできます。
The remote ingress RBridges belonging to the same routing domain use this information to generate IP routing entries in that routing domain. These RBridges use the nickname, tenant gateway MAC, and tenant Label of RB1 to perform inter-subnet TRILL encapsulation when they receive inter-subnet traffic from a local ES. The nickname is used as the egress nickname, the tenant gateway MAC is used as the Inner.MacDA, and the tenant Data Label is used as the Inner.Label. The following APPsub-TLVs MUST be included in a TRILL GENINFO TLV in E-L1FS FS-LSPs [RFC7780].
同じルーティングドメインに属するリモート入力RBridgeは、この情報を使用して、そのルーティングドメインにIPルーティングエントリを生成します。これらのRBridgeは、RB1のニックネーム、テナントゲートウェイMAC、およびテナントラベルを使用して、ローカルESからサブネット間トラフィックを受信するときにサブネット間TRILLカプセル化を実行します。ニックネームは出力ニックネームとして使用され、テナントゲートウェイMACはInner.MacDAとして使用され、テナントデータラベルはInner.Labelとして使用されます。以下のAPPsub-TLVは、E-L1FS FS-LSP [RFC7780]のTRILL GENINFO TLVに含まれている必要があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv1 | Label1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv2 | Label2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+
| Tenant Gateway MAC (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+
o Type: Set to the TENANT-GWMAC-LABEL sub-TLV type (7). 2 bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
o タイプ：TENANT-GWMAC-LABELサブTLVタイプ（7）に設定します。このAPPsub-TLVは拡張TLV [RFC7356]に表示されるため、2バイト。
o Length: If the Label1 field is used to represent a VLAN, the value of the Length field is 12. If the Label1 and Label2 fields are used to represent an FGL, the value of the Length field is 14.
o 長さ：Label1フィールドを使用してVLANを表す場合、長さフィールドの値は12です。Label1およびLabel2フィールドを使用してFGLを表す場合、長さフィールドの値は14です。
o Tenant ID: This identifies a Tenant ID unique across the TRILL campus.
o テナントID：TRILLキャンパス全体で一意のテナントIDを識別します。
o Resv1: 4 bits that MUST be sent as zero and ignored on receipt.
o Resv1：ゼロとして送信し、受信時に無視する必要がある4ビット。
o Label1: If the value of the Length field is 12, it identifies a tenant Label corresponding to a VLAN ID. If the value of the Length field is 14, it identifies the higher 12 bits of a tenant Label corresponding to an FGL.
o Label1：Lengthフィールドの値が12の場合、VLAN IDに対応するテナントラベルを識別します。長さフィールドの値が14の場合、FGLに対応するテナントラベルの上位12ビットを識別します。
o Resv2: 4 bits that MUST be sent as zero and ignored on receipt. Only present if the Length field is 14.
o Resv2：ゼロとして送信し、受信時に無視する必要がある4ビット。長さフィールドが14の場合にのみ存在します。
o Label2: This field has the lower 12 bits of the tenant Label corresponding to an FGL. Only present if the Length field is 14.
o Label2：このフィールドには、FGLに対応するテナントラベルの下位12ビットがあります。長さフィールドが14の場合にのみ存在します。
o Tenant Gateway MAC: This identifies the local gateway MAC corresponding to the Tenant ID. The remote ingress RBridges use the gateway MAC as the Inner.MacDA. The advertising TRILL RBridge uses the gateway MAC to differentiate L2 intra-subnet traffic and L3 inter-subnet traffic in the egress direction.
o テナントゲートウェイMAC：これは、テナントIDに対応するローカルゲートウェイMACを識別します。リモート入力RBridgeは、ゲートウェイMACをInner.MacDAとして使用します。アドバタイズTRILL RBridgeは、ゲートウェイMACを使用して、出力方向のL2サブネット内トラフィックとL3サブネット間トラフィックを区別します。
The NickFlags APPsub-TLV is specified in [RFC7780], where the IN flag is described. The SE Flag is assigned as follows:
NickFlags APPsub-TLVは[RFC7780]で指定されており、INフラグが記述されています。 SEフラグは次のように割り当てられます。
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
o SE: If the SE flag is set to 1, it indicates that the advertising RBridge suggests that the Nickname SHOULD be used as the Inter-Subnet Egress nickname for inter-subnet traffic forwarding. If the SE flag is set to 0, that Nickname SHOULD NOT be used for that purpose. The SE flag is ignored if the NickFlags APPsub-TLV is advertised by an RBridge that does not own the Nickname.
o SE：SEフラグが1に設定されている場合、広告RBridgeがニックネームをサブネット間トラフィック転送のサブネット間出口ニックネームとして使用する必要があることを示唆していることを示します。 SEフラグが0に設定されている場合、そのニックネームはその目的には使用しないでください。 NickFlags APPsub-TLVが、ニックネームを所有していないRBridgeによって通知されている場合、SEフラグは無視されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to the IPV4-PREFIX sub-TLV type (8). 2 bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
o タイプ：IPV4-PREFIXサブTLVタイプ（8）に設定します。このAPPsub-TLVは拡張TLV [RFC7356]に表示されるため、2バイト。
o Total Length: This 2-byte unsigned integer indicates the total length of the Tenant ID, Prefix Length, and Prefix fields, in octets. A value of 0 indicates that no IPv4 prefix is being advertised.
o 全長：この2バイトの符号なし整数は、テナントID、プレフィックス長、およびプレフィックスフィールドの全長をオクテットで示します。値0は、アドバタイズされているIPv4プレフィックスがないことを示します。
o Tenant ID: This identifies a Tenant ID unique across the TRILL campus.
o テナントID：TRILLキャンパス全体で一意のテナントIDを識別します。
o Prefix Length: The Prefix Length field indicates the length, in bits, of the IPv4 address prefix. A length of 0 (i.e., the prefix itself is 0 octets) indicates a prefix that matches all IPv4 addresses.
o プレフィックス長：プレフィックス長フィールドは、IPv4アドレスプレフィックスの長さをビット単位で示します。長さ0（つまり、プレフィックス自体が0オクテット）は、すべてのIPv4アドレスに一致するプレフィックスを示します。
o Prefix: The Prefix field contains an IPv4 address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of the trailing bits is irrelevant. For example, if the Prefix Length is 12, indicating 12 bits, then the Prefix is 2 octets and the low-order 4 bits of the Prefix are irrelevant.
o 接頭辞：接頭辞フィールドにはIPv4アドレスの接頭辞が含まれ、その後にフィールドの終わりがオクテット境界に入るのに十分な後続ビットが続きます。後続ビットの値は無関係であることに注意してください。たとえば、プレフィックス長が12で12ビットを示す場合、プレフィックスは2オクテットで、プレフィックスの下位4ビットは無関係です。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(1)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (1) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| ..... | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
|PrefixLength(N)| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
| Prefix (N) | (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
o Type: Set to the IPV6-PREFIX sub-TLV type (9). 2 bytes, because this APPsub-TLV appears in an extended TLV [RFC7356].
o タイプ：IPV6-PREFIXサブTLVタイプ（9）に設定します。このAPPsub-TLVは拡張TLV [RFC7356]に表示されるため、2バイト。
o Total Length: This 2-byte unsigned integer indicates the total length of the Tenant ID, Prefix Length, and Prefix fields, in octets. A value of 0 indicates that no IPv6 prefix is being advertised.
o 全長：この2バイトの符号なし整数は、テナントID、プレフィックス長、およびプレフィックスフィールドの全長をオクテットで示します。値0は、IPv6プレフィックスが通知されていないことを示します。
o Tenant ID: This identifies a Tenant ID unique across the TRILL campus.
o テナントID：TRILLキャンパス全体で一意のテナントIDを識別します。
o Prefix Length: The Prefix Length field indicates the length, in bits, of the IPv6 address prefix. A length of 0 (i.e., the prefix itself is 0 octets) indicates a prefix that matches all IPv6 addresses.
o プレフィックス長：プレフィックス長フィールドは、IPv6アドレスプレフィックスの長さをビット単位で示します。長さが0（つまり、プレフィックス自体が0オクテット）は、すべてのIPv6アドレスに一致するプレフィックスを示します。
o Prefix: The Prefix field contains an IPv6 address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary. Note that the value of the trailing bits is irrelevant. For example, if the Prefix Length is 100, indicating 100 bits, then the Prefix is 13 octets and the low-order 4 bits of the Prefix are irrelevant.
o プレフィックス：プレフィックスフィールドにはIPv6アドレスプレフィックスが含まれ、その後にフィールドの終わりがオクテット境界に入るのに十分な後続ビットが続きます。後続ビットの値は無関係であることに注意してください。たとえば、プレフィックス長が100の場合、100ビットを示し、プレフィックスは13オクテットであり、プレフィックスの下位4ビットは無関係です。
Correct configuration of the participating edge RBridges is important to assure that data is not delivered to the wrong tenant, as such incorrect delivery would violate security constraints. IS-IS security [RFC5310] can be used to secure the information advertised by the edge RBridges in LSPs and FS-LSPs.
参加しているエッジRBridgeを正しく構成することは、データが間違ったテナントに配信されないようにするために重要です。誤った配信は、セキュリティの制約に違反するためです。 IS-ISセキュリティ[RFC5310]を使用して、LSPおよびFS-LSPのエッジRBridgeによってアドバタイズされる情報を保護できます。
To avoid the mishandling of data in flight, see Section 5.2 for constraints on the reuse of a tenant Label and on tenant gateway MAC changes. Selecting tenant Labels and IDs in a pseudorandom fashion [RFC4086] can make it more difficult for an adversary to guess a tenant Label or ID that is in use.
処理中のデータの誤処理を回避するために、テナントラベルの再利用とテナントゲートウェイのMAC変更に関する制約については、セクション5.2を参照してください。疑似ランダムな方法でテナントラベルとIDを選択すると[RFC4086]、攻撃者が使用中のテナントラベルまたはIDを推測することがさらに困難になる可能性があります。
Particularly sensitive data should be encrypted end-to-end -- that is, from the source ES to the destination ES. Since the TRILL campus is, for the most part, transparent to ES traffic, such ESs are free to use whatever end-to-end security protocol they would like.
特に機密性の高いデータは、エンドツーエンドで暗号化する必要があります。つまり、ソースESから宛先ESまで暗号化する必要があります。 TRILLキャンパスは、ほとんどの場合、ESトラフィックに対して透過的であるため、そのようなESは、エンドツーエンドのセキュリティプロトコルを自由に使用できます。
For general TRILL security considerations, see [RFC6325].
TRILLのセキュリティに関する一般的な考慮事項については、[RFC6325]を参照してください。
The configuration at each RBridge to support the distributed L3 gateway feature is visible, via the link-state database, to all other RBridges in the campus. Operations, Administration, and Maintenance (OAM) facilities for TRILL are primarily specified in [RFC7455] and [RFC7456].
分散L3ゲートウェイ機能をサポートするための各RBridgeの構成は、リンクステートデータベースを介して、キャンパス内の他のすべてのRBridgeに表示されます。 TRILLの運用、管理、保守（OAM）機能は、主に[RFC7455]および[RFC7456]で指定されています。
IANA has assigned three APPsub-TLV type numbers that are lower than 255 in the "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" registry. The registry has been updated as follows:
IANAは、「IS-IS TLV 251アプリケーションID 1のTRILL APPsub-TLVタイプ」レジストリで、255未満の3つのAPPsub-TLVタイプ番号を割り当てました。レジストリは次のように更新されました。
Type Name Reference
---- ------------------ -------------
7 TENANT-GWMAC-LABEL this document
8 IPV4-PREFIX this document
8このドキュメントのIPV4-PREFIX
9 IPV6-PREFIX this document
9このドキュメントのIPV6-PREFIX
IANA has assigned a flag bit in the NickFlags APPsub-TLV as described in Section 7.2 and updated the "NickFlags Bits" registry, created by [RFC7780], as follows:
IANAは、セクション7.2で説明されているように、NickFlags APPsub-TLVにフラグビットを割り当て、[RFC7780]によって作成された "NickFlags Bits"レジストリを次のように更新しました。
Bit Mnemonic Description Reference
----- -------- ------------------- -------------
1 SE Inter-Subnet Egress this document
[IS-IS] International Organization for Standardization, "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 Standard 10589, 2002.
[IS-IS]国際標準化機構、「コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用する中間システムから中間システムへのドメイン内ルーティング情報交換プロトコル」、ISO標準10589、2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.
[RFC6325] Perlman、R.、Eastlake 3rd、D.、Dutt、D.、Gai、S。、およびA. Ghanwani、「Routing Bridges（RBridges）：Base Protocol Specification」、RFC 6325、DOI 10.17487 / RFC6325、7月2011、<http://www.rfc-editor.org/info/rfc6325>。
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and D. Dutt, "Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling", RFC 7172, DOI 10.17487/RFC7172, May 2014, <http://www.rfc-editor.org/info/rfc7172>.
[RFC7172] Eastlake 3rd、D.、Zhang、M.、Agarwal、P.、Perlman、R.、and D. Dutt、 "Transparent Interconnection of Lots of Links（TRILL）：Fine-Grained Labeling"、RFC 7172、DOI 10.17487 / RFC7172、2014年5月、<http://www.rfc-editor.org/info/rfc7172>。
[RFC7176] Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, D., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 7176, DOI 10.17487/RFC7176, May 2014, <http://www.rfc-editor.org/info/rfc7176>.
[RFC7176] Eastlake 3rd、D.、Senevirathne、T.、Ghanwani、A.、Dutt、D.、and A. Banerjee、 "Transparent Interconnection of Lots of Links（TRILL）Use of IS-IS"、RFC 7176、DOI 10.17487 / RFC7176、2014年5月、<http://www.rfc-editor.org/info/rfc7176>。
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356] Ginsberg、L.、Previdi、S。、およびY. Yang、「IS-IS Flooding Scope Link State PDU（LSPs）」、RFC 7356、DOI 10.17487 / RFC7356、2014年9月、<http：// www。 rfc-editor.org/info/rfc7356>。
[RFC7780] Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., Ghanwani, A., and S. Gupta, "Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, <http://www.rfc-editor.org/info/rfc7780>.
[RFC7780] Eastlake 3rd、D.、Zhang、M.、Perlman、R.、Banerjee、A.、Ghanwani、A.、and S. Gupta、 "Transparent Interconnection of Lots of Links（TRILL）：Clarifications、Corrections、andアップデート」、RFC 7780、DOI 10.17487 / RFC7780、2016年2月、<http://www.rfc-editor.org/info/rfc7780>。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、DOI 10.17487 / RFC0826、1982年11月、<http：/ /www.rfc-editor.org/info/rfc826>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[RFC7379] Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai, "Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October 2014, <http://www.rfc-editor.org/info/rfc7379>.
[RFC7379] Li、Y.、Hao、W.、Perlman、R.、Hudson、J。、およびH. Zhai、「問題のステートメントとリンクの多くの透過的相互接続（TRILL）エッジでのアクティブ-アクティブ接続の目標」 "、RFC 7379、DOI 10.17487 / RFC7379、2014年10月、<http://www.rfc-editor.org/info/rfc7379>。
[RFC7455] Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake 3rd, D., Aldrin, S., and Y. Li, "Transparent Interconnection of Lots of Links (TRILL): Fault Management", RFC 7455, DOI 10.17487/RFC7455, March 2015, <http://www.rfc-editor.org/info/rfc7455>.
[RFC7455] Senevirathne、T.、Finn、N.、Salam、S.、Kumar、D.、Eastlake 3rd、D.、Aldrin、S。、およびY. Li、「多数のリンクの透過的な相互接続（TRILL）：障害管理」、RFC 7455、DOI 10.17487 / RFC7455、2015年3月、<http://www.rfc-editor.org/info/rfc7455>。
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, DOI 10.17487/RFC7456, March 2015, <http://www.rfc-editor.org/info/rfc7456>.
[RFC7456] Mizrahi、T.、Senevirathne、T.、Salam、S.、Kumar、D。、およびD. Eastlake 3位、「リンクの透過的な相互接続における損失と遅延の測定（TRILL）」、RFC 7456、DOI 10.17487 / RFC7456、2015年3月、<http://www.rfc-editor.org/info/rfc7456>。
Acknowledgments
謝辞
The authors wish to acknowledge the important contributions of Donald Eastlake, Gayle Noble, Mohammed Umair, Susan Hares, Guangrui Wu, Zhenbin Li, Zhibo Hu, Liang Xia, Scott Bradner, Stephen Farrell, Shawn Emery, Ben Campbell, Russ White, Kathleen Moriarty, Suresh Krishnan, Mirja Kuehlewind, and Francis Dupont.
著者は、ドナルドイーストレイク、ゲイルノーブル、モハメッドウムエア、スーザンハレス、グァンルイウー、ジェンビンリー、ジボフー、リャンシア、スコットブラドナー、スティーブンファレル、ショーンエメリー、ベンキャンベル、ラスホワイト、キャスリーンモリアーティの重要な貢献を認めたい、Suresh Krishnan、Mirja Kuehlewind、Francis Dupont。
Authors' Addresses
著者のアドレス
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China
Wei Hao H oh UAはテクノロジー101ソフトウェアアベニューNaN京210012中国
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
Y I週l IH UAはテクノロジー101ソフトウェアアベニューNaNjing 210012中国
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Andrew Qu MediaTec
Andrew Qu MediaTec
Email: laodulaodu@gmail.com
Muhammad Durrani Equinix Inc.
Muhammad Durrani Equinix Inc.
Email: mdurrani@equinix.com
Ponkarthick Sivamurugan IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048
Pokarthic Sivamurugan IP Infosion Ramaz Centennial Mahadevapura Post Bangalore 560048
Email: Ponkarthick.sivamurugan@ipinfusion.com