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
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层虚拟网络提供互连功能。
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.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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（细粒度标签））。本文档指定了一个基于TRILL的分布式第3层网关解决方案，该解决方案为第3层子网间流量提供最佳单播转发。通过分布式网关支持，边缘RBridge在属于同一子网的终端站（ESs）之间提供基于第2层身份（地址和虚拟网络（VN，即数据标签））的路由，并且在属于同一路由域的不同子网的ESs之间提供基于第3层身份的路由。支持此功能的边缘RBridge需要为本地连接的ESs提供路由实例和第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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The terms and acronyms in [RFC6325] are used, with the following additions:
使用[RFC6325]中的术语和首字母缩略词，并添加以下内容：
AGG: Aggregation switch.
聚合开关。
ARP: Address Resolution Protocol [RFC826].
地址解析协议[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.
校园：使用TRILL协议的网络的名称，其含义与“桥接LAN”是使用桥接的网络的名称相同。在TRILL中，“校园”一词没有学术含义。
COR: Core switch.
核心交换机。
Data Label: VLAN or FGL [RFC7172].
数据标签：VLAN或FGL[RFC7172]。
DC: Data Center.
数据中心。
Edge RBridge: An RBridge that connects to one or more ESs without any intervening RBridges.
边缘RBridge：连接到一个或多个ESs的RBridge，没有任何中间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).
网关接口：第3层虚拟接口，用于终止第2层转发，并使用IP转发规则将IP流量转发到目标。来自网关上物理端口的传入流量将基于数据标签（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.
L2：第二层。
L3: IP Layer 3.
L3:IP第三层。
LSP: Link State PDU
链路状态PDU
ND: IPv6's Neighbor Discovery [RFC4861].
ND:IPv6的邻居发现[RFC4861]。
ToR: Top of Rack.
托尔：机架顶部。
VN: Virtual Network. In a TRILL campus, a unique 12-bit VLAN ID or a 24-bit FGL [RFC7172] identifies each 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.
虚拟路由和转发。在基于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.
通常有一个数据标签（VLAN或FGL）与每个IP子网相关联。对于子网内的通信量——即连接到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.
如果同一租户的两个ESs位于不同的子网上，并且需要彼此通信，则它们的数据包通常会转发到执行L3路由的IP 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节给出了TRILL校园中的一个简化示例，该校园有或没有使用VLAN数据标签的分布式L3网关。第3.2节详细描述了与使用集中式网关（即没有分布式三级网关）相关的问题。本文档的其余部分，特别是第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|
----- ----- ----- ----- ----- ----- ----- -----
------- --------
| 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直流网络
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属于一个租户网络，租户有四个子网，每个子网对应一个VLAN（表示一个单独的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 |
+----+----------------+-----------------+----------+
+----+----------------+-----------------+----------+
| 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.
假设一个集中式网关解决方案与COR1和COR2一起使用，作为图1中冗余的集中式网关。COR1和COR2分别为租户中的四个子网提供四个网关接口。在集中式三级网关解决方案中，租户内不同VLAN之间的所有流量必须通过COR1或COR2的集中式三级网关设备，即使流量在连接到同一边缘RBridge的两个ESs之间，因为只有三级网关可以更改流量的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.
这通常是次优的，因为两个ESs可能连接到同一个ToR，其中L3切换可能在本地执行。例如，在上面的图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
通过分布式三级网关，每个边缘RBridge充当本地连接ESs的默认三级网关，并具有将IP通信定向到其他边缘RBridge的IP路由器功能。每条边都有一条脊
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.
本地连接ESs只需要网关接口，即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:
当每个ES为其L3网关（即其IP路由器）ARP时，其连接的边缘RBridge将使用该RBridge的“网关MAC”进行响应。当ES稍后向L3网关发送IP流量时（如果目标IP在其子网之外，则会发送），边缘RBridge会截获IP数据包，因为目标MAC是其网关MAC。RBridge使用与该租户关联的路由实例路由IP数据包，并通过以下三种方式之一进行处理：
(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可以简单地将IP数据包从目标VLAN的右边缘端口发送出去。
(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和标识租户的内部.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. 集中式网关可能需要支持大量网关接口——在DC中，每个租户使用一个数据标签，每个租户使用一个接口——以便为TRILL园区中的所有L2 VN提供互连功能。
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.
边缘RBridges上的分布式网关解决了这些问题。通过分布式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网络中，每个租户都有一个或多个L2 VN，在正常情况下，每个租户对应一个路由域。通常，每个L2 VN使用不同的数据标签，并对应于一个或多个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]标识。不同的路由域可能有重叠的地址空间，但需要不同和单独的路由。属于同一子网的ESs通过L2转发进行通信；属于不同子网的同一租户的ESs通过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个VRF对应于n个租户，每个租户最多有m个段/子网（VN）。
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | Tenant n |---------| VRF n | |
| +------------+ | +------------+ | |
| | +-----+ | | | | | |
| | | VN1 | | | | | | |
| | +-----+ | | | VRF 1 | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | | VNm | | | | | | |
| | +-----+ | | | | | |
| | Tenant1 |-+ | | | |
| +------------+ | | | |
| +------------+ +------------+ |
| |
| Edge RBridge |
+---------------------------------------------+
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | 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继续基于同一子网上的ESs的L2 MAC地址执行路由，但对同一租户的不同子网上的ESs执行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上创建VRF实例，以隔离边缘RBridge上存在的不同路由域的IP转发过程。TRILL校园中唯一的租户ID标识每个路由域。网络运营商必须为每个路由域在每个边缘RBridge上一致地配置租户ID，以便相同ID始终指向相同的租户。否则，数据可能会传递到错误的租户。如果路由域分布在多个边缘RBridge上，则路由域的路由信息将通过链路状态数据库在这些边缘RBridge之间同步，以确保该路由域中所有ESs的可达性。路由信息实际上是用租户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
从数据平面的角度来看，所有边缘rbridge通过一个或多个TRILL跳跃彼此连接；然而，它们总是只有一个IP跃点。当入口RBridge接收到子网间
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.
来自目标MAC为边缘RBridge网关MAC的本地ES的IP流量，RBridge将执行以太网报头终止。所涉及的租户由流量的VLAN及其到达的端口确定。edge 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网关。在边缘RBridge上为连接ES建立网关接口。由于子网中的ESs可能分布在多个边缘RBridge上，因此为子网建立其网关接口的每个此类边缘RBridge应共享相同的网关MAC和网关IP地址配置。通过本地配置和网络配置协议（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
对于分布式网关，ES连接到的边缘RBridge似乎是其链路上的本地IP路由器。与任何IP网络一样，在ES开始发送子网间流量之前，它通过ARP/ND过程获取其网关的MAC。支持此分布式网关功能的本地连接边缘RBridge在接收网关IP的ARP/ND请求时始终使用网关MAC地址进行响应。通过ARP/ND过程
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.
edge RBridge可以学习通过L2连接到edge 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网络中，它通常提供对一个或多个IP前缀的访问。路由器/ES应使用连接TRILL edge RBridge运行IP路由协议。边缘RBridge将通过该IP路由协议学习路由器后面的IP前缀，然后RBridge将在相应的路由域中生成本地IP路由条目。如果这样的路由协议没有与边缘RBridge一起运行，那么只有在边缘RBridge上显式配置的路由器后面的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作为内部.MacDA。当从TRILL园区接收子网间流量时，出口RBridge依靠此租户数据标签来查找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).
当在边缘RBridge上的路由实例中学习到本地IP前缀时，边缘RBridge应公布该路由实例的IP前缀信息，以便其他边缘RBridge将生成IP路由条目。如果VN中的ESs分布在多个RBridge上，则这些RBridge必须将VN中的每个本地连接ES的IP地址播发到其他RBridge。如果VN中的ESs仅连接到一个边缘RBridge，则该RBridge只需要使用主机路由将与VN对应的子网通告给其他RBridge。TRILL校园内唯一的租户ID也在广告中，以区分不同租户之间的IP前缀，因为不同租户的IP地址空间可能重叠（见第7.3节和第7.4节）。
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保持时间的两倍）以允许丢弃飞行中的任何流量之前，不得重新分配租户数据标签。
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条目超时时，它将触发到其他边缘RBridge的边缘RBridge LSP播发，并删除相应的IP路由条目。如果ES是IP路由器，则边缘RBridge还通知其他边缘RBridge，它们必须删除与可通过该IP路由器访问的IP前缀相对应的路由条目。在IP前缀删除过程中，如果飞行中有流量，则在出口RBridge处丢弃该流量，因为没有到目的地的本地IP路由条目。
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接收到Inner.MacDA不同于本地租户网关MAC的流量时，该流量将被丢弃。如果边缘RBridge使用其中一个访问数据标签作为子网间租户数据标签，则流量将作为L2子网内流量转发，除非在边缘RBridge上实施特殊流量过滤策略。
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还可以指定一个昵称作为子网间流量转发的出口昵称。具有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 Extended Level 1 Flooding Scope（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].
TRILL主动-主动服务为ESs提供了流量级负载平衡和针对TRILL校园边缘链路故障的恢复能力，如[RFC7379]所述。
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
如果ES在主动-主动模式下连接到两个TRILL RBridge，例如RB1和RB2，则RB1和RB2必须都配置为充当ES的分布式L3网关，以便使用分布式网关。RB1和RB2各自通过ARP/ND过程学习ES的IP地址，然后分别向TRILL校园宣布IP地址。远程入口RBridge将生成一个IP路由条目，该条目对应于具有两个IP下一跳RB1和RB2的IP地址。当入口RBridge接收到子网间
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.
来自本地接入网络的流量，入口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属于租户1，但位于不同的子网中。
--------- ---------
| RB3 | | RB4 |
--------- ---------
# * # *
# **************************
########################### *
# *
# *
# *
--------- ---------
| RB1 | | RB2 |
--------- ---------
| |
----- -----
|ES1| |ES2|
----- -----
--------- ---------
| 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 |
+----+----------+------------------+------------------+----------+
+----+----------+------------------+------------------+----------+
| 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 |
+----+----------+------------------+------------------+----------+
+----+----------+------------------+------------------+----------+
| 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上租户1的昵称、VRF、租户标签和租户网关MAC如下：
+----+---------+-----------+-------+--------------+--------------+
| RB | Nickname| Tenant | VRF | Tenant Label | Gateway MAC |
+----+---------+-----------+-------+--------------+--------------+
| RB1| nick1 | Tenant1 | VRF1 | 100 | MAC1 |
+----+---------+-----------+-------+--------------+--------------+
| RB2| nick2 | Tenant1 | VRF2 | 100 | MAC2 |
+----+---------+-----------+-------+--------------+--------------+
+----+---------+-----------+-------+--------------+--------------+
| 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
租户编号：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
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
租户编号：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
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 |
+------------------+-------------+--------------+----------------+
+------------------+-------------+--------------+----------------+
| 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上的租户1远程路由表
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 |
+------------------+-------------+--------------+----------------+
+------------------+-------------+--------------+----------------+
| 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上的租户1远程路由表
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，RB1的网关MAC作为目标MAC，VLAN作为VLAN 10。
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路由表信息，以获得IP下一跳信息，其中包括出口RBridge的网关MAC（MAC2）、租户标签（VLAN 100）和出口昵称（nick2）。使用此信息，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执行颤音去封装。然后，它检查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参与分布式网关功能，它将通过租户标签和网关MAC APPsub TLV向TRILL园区宣布其租户网关MAC和租户数据标签。它应该分别通过IPv4前缀APPsub TLV和IPv6前缀APPsub TLV宣布其本地IPv4和IPv6前缀。如果RB1有多个昵称，它可以通过使用NickFlags APPsub TLV（SE标志设置为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在从本地ES接收子网间通信时，使用RB1的昵称、租户网关MAC和租户标签来执行子网间TRILL封装。昵称用作出口昵称，租户网关MAC用作Inner.MacDA，租户数据标签用作Inner.Label。以下APPsub TLV必须包含在E-L1FS 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 类型：设置为租户-GWMAC-LABEL子TLV类型（7）。2字节，因为此APPsub TLV显示在扩展TLV[RFC7356]中。
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 标签1：如果长度字段的值为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用作internal.MacDA。广告颤音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:
[RFC7780]中规定了NickFlags APPsub TLV，其中描述了in标志。SE标志分配如下：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Nickname |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IN|SE| RESV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NICKFLAG RECORD
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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前缀子TLV类型（8）。2字节，因为此APPsub TLV显示在扩展TLV[RFC7356]中。
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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前缀子TLV类型（9）。2字节，因为此APPsub TLV显示在扩展TLV[RFC7356]中。
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.
正确配置参与的边缘RBridges对于确保数据不会传递给错误的租户非常重要，因为这种不正确的传递会违反安全约束。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.
为避免飞行中数据的错误处理，请参阅第5.2节，了解租户标签重用和租户网关MAC更改的限制。以伪随机方式选择租户标签和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流量是透明的，这样的ESs可以自由使用他们想要的任何端到端安全协议。
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].
通过链路状态数据库，校园内所有其他RBridge都可以看到每个RBridge上支持分布式L3网关功能的配置。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应用程序标识符1下的TRILL APPsub TLV类型”注册表中分配了三个低于255的APPsub TLV类型编号。登记册已更新如下：
Type Name Reference
---- ------------------ -------------
7 TENANT-GWMAC-LABEL this document
Type Name Reference
---- ------------------ -------------
7 TENANT-GWMAC-LABEL this document
8 IPV4-PREFIX this document
8本文件的IPV4前缀
9 IPV6-PREFIX this document
9本文件的IPV6前缀
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位”注册表，如下所示：
Bit Mnemonic Description Reference
----- -------- ------------------- -------------
1 SE Inter-Subnet Egress this document
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，“路由桥（RBridges）：基本协议规范”，RFC 6325DOI 10.17487/RFC6325，2011年7月<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.，和D.Dutt，“大量链接的透明互连（TRILL）：细粒度标记”，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.，和A.Banerjee，“IS-IS大量链路的透明互连（TRILL）使用”，RFC 7176，DOI 10.17487/RFC7176，2014年5月<http://www.rfc-editor.org/info/rfc7176>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <http://www.rfc-editor.org/info/rfc7356>.
[RFC7356]Ginsberg，L.，Previdi，S.，和Y.Yang，“IS-IS洪水范围链路状态PDU（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.，和S.Gupta，“大量链接的透明互连（TRILL）：澄清，更正和更新”，RFC 7780，DOI 10.17487/RFC77802016年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]Plummer，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.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<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，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年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通用密码认证”，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 3rd，“大量链路透明互连中的损耗和延迟测量（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.
作者希望感谢唐纳德·伊斯特莱克、盖尔·诺布尔、穆罕默德·乌迈尔、苏珊·哈雷斯、吴光瑞、李振斌、胡志波、梁霞、斯科特·布拉德纳、斯蒂芬·法雷尔、肖恩·埃莫里、本·坎贝尔、罗斯·怀特、凯瑟琳·莫里亚蒂、苏雷什·克里希南、米娅·库勒温德和弗朗西斯·杜邦的重要贡献。
Authors' Addresses
作者地址
Weiguo Hao Huawei Technologies 101 Software Avenue Nanjing 210012 China
中国南京软件大道101号华为技术有限公司，邮编：210012
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li Huawei Technologies 101 Software Avenue Nanjing 210012 China
宜州利华为技术有限公司软件大道101号南京210012
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Andrew Qu MediaTec
屈宏发
Email: laodulaodu@gmail.com
Email: laodulaodu@gmail.com
Muhammad Durrani Equinix Inc.
穆罕默德·杜拉尼·埃克尼克斯公司。
Email: mdurrani@equinix.com
Email: mdurrani@equinix.com
Ponkarthick Sivamurugan IP Infusion RMZ Centennial Mahadevapura Post Bangalore 560048
班加罗尔马哈德瓦普拉百周年纪念酒店
Email: Ponkarthick.sivamurugan@ipinfusion.com
Email: Ponkarthick.sivamurugan@ipinfusion.com