TRILL Weiguo Hao
Yizhou Li
Donald Eastlake
Liang Xia
Internet Draft Huawei
Intended status: Informational June 9, 2014
Expires: December 2014
TRILL Distributed Layer 3 Gateway Framework
draft-hao-trill-irb-04.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
Hao & Li Expires December 9, 2014 [Page 1]
Internet-Draft TRILL Distributed Gateway Solution June 2014
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 9, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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.
Abstract
Currently TRILL protocol can only provide optimal pair-wise data
frame forwarding for layer 2 intra-subnet traffic, not for layer 3
inter-subnet traffic. Normally centralized gateway solution is used
for layer 3 inter-subnet traffic forwarding. Centralized gateway
solution has following issues:
1. Sub-optimum forwarding path for inter-subnet traffic.
2. Huge number of gateway interfaces, 16M in extreme case, needs to
be supported on the centralized gateway.
3. Traffic bottleneck on the gateways.
TRILL distributed gateway solution is proposed in this document,
this solution can resolve the above centralized gateway issues.
Hao & Li Expires December 9, 2014 [Page 2]
Internet-Draft TRILL Distributed Gateway Solution June 2014
TRILL LSP extension can be used for synchronizing routing
information in each routing domain among edge RBridges.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 4
3. Problem Statement ........................................... 4
4. Layer 3 traffic forwarding model............................. 6
5. Distributed gateway solution overview........................ 6
5.1. Local routing information............................... 7
5.2. Local routing information synchronization............... 8
5.3. Data traffic forwarding process......................... 9
6. Distributed layer 3 gateway process example................. 10
6.1. Control plane process.................................. 11
6.2. Data plane process..................................... 12
7. TRILL protocol extension.................................... 13
7.1. The tenant gateway MAC sub-TLV......................... 13
7.2. The tenant VLAN sub-TLV................................ 14
7.3. The IPv4 Prefix sub-TLV................................ 15
8. Security Considerations..................................... 15
9. IANA Considerations ........................................ 15
10. Normative References....................................... 15
11. Informative References..................................... 16
12. Acknowledgments ........................................... 16
1. Introduction
The IETF has standardized the TRILL (Transparent Interconnection of
Lots of Links) protocol [RFC6325] that provides a solution for least
cost transparent routing in multi-hop networks with arbitrary
topologies and link technologies, using [IS-IS] [RFC6165]
[RFC6326bis] link-state routing and a hop count. TRILL switches are
sometimes called RBridges (Routing Bridges).
Currently, TRILL only provides the optimal unicast forwarding for
Layer 2 intra-subnet traffic, not for Layer 3 inter-subnet traffic.
In this document, a TRILL-based distributed layer 3 gateway solution
is introduced to provide the optimal unicast forwarding for Layer 3
inter-subnet traffic. The edge RBridge supports bridging among end
stations(ESs) that belong to same subnet and routing among end
stations that belong to different subnets of same routing domain at
same time. The edge RBridge needs to provide routing instances and
layer 3 gateway interfaces for local connected ESs. The routing
instances are for IP address isolation for each tenant. In TRILL
distributed layer 3 gateway solution, inter-subnet traffic can be
Hao & Li Expires December 9, 2014 [Page 3]
Internet-Draft TRILL Distributed Gateway Solution June 2014
fully dispersed among edge RBridges, so there is no single
bottleneck.
This document is organized as follows: Section 3 describes why a
distributed gateway solution is required. Section 4 gives layer 3
traffic forwarding model. Section 5 gives distributed gateway
solution overview. Section 6 gives a distributed gateway example.
Section 7 describes TRILL protocol extensions to support TRILL
distributed gateway solution.
2. Conventions used in this document
End Station: ES. VM or physical server, whose address is either a
destination or the source of a data frame.
ND: IPv6's Neighbor Discovery [RFC4861].
VN: Virtual Network. Each virtual network is identified by a unique
12-bit VLAN ID or 24-bit Fine Grained Label [FGL] in TRILL network.
VRF: Virtual Routing and Forwarding. In IP-based computer networks,
Virtual Routing and Forwarding (VRF) is a technology that allows
multiple instances of a routing table to co-exist within the same
router at the same time.
3. Problem Statement
-------- ---------
| GW1 | | GW2 |
| | | |
--------- ---------
| |
| |
--------- ---------
| AGG1 | | AGG2 |
| | | |
--------- ---------
| |
__________|_________________________________|_______________________
| | | | |
__|_________|___________|___________________ |____________________ |
| | | | | | | |
| | | | | | | |
--------- --------- --------- ---------
| TOR1 | | TOR2 | | TOR3 | | TOR4 |
Hao & Li Expires December 9, 2014 [Page 4]
Internet-Draft TRILL Distributed Gateway Solution June 2014
| | | | | | | |
--------- --------- --------- ---------
| | | | | | | |
| | | | | | | |
__|_ _|___ ____ ____ ____ ____ ____ ____
|E | |E | |E | |E | |E | |E | |E | |E |
|S1| |S2| |S3| |S4| |S5| |S6| |S7| |S8|
---- ---- ---- ---- ---- ---- ---- ----
Figure 1 A typical DC network
Figure 1 depicts a Data Center Network (DCN) using TRILL where edge
RBs are Top of Rack (ToR) switches.
Centralized gateway GW1 and GW2 in figure 1 provide the layer 3
packet forwarding for both north-south traffic and east-west inter
subnet traffic between ESs.
If two end stations of same tenant are on two different subnets and
need to communicate with each other, their packets need to be
forwarded all the way to a centralized layer 3 GW to perform L3
forwarding. This is generally sub-optimal because the two end
stations may be connected to the same TOR where L3 switching could
have been performed locally. If an edge RB has distributed gateway
capability, then it can perform optimum L2 forwarding for intra-
subnet traffic and optimum L3 forwarding for inter-subnet traffic,
delivering optimum forwarding for unicast packets in all important
cases. For example, in above figure1, assuming ES1(10.1.1.2 ) and
ES2(20.1.1.2) belongs to different subnet of same tenant, the
unicast IP traffic between them should go through centralized
gateway, it can't be locally forwarded on TOR1.
When Fine Grained Label [RFC7172] is introduced, theoretically 16M
layer 2 VN can be supported in a TRILL campus. To support inter-
subnet traffic, up to 16M layer 3 gateway interface should be
created on a centralized gateway if each VN corresponds to a subnet.
It is a huge burden for the centralized gateway to support so many
interfaces.In addition all inter-subnet traffic will go through the
centralized gateway which may become the traffic bottleneck.
In summary, the centralized gateway has the following issues:
1. Sub-optimum forwarding path for inter-subnet traffic.
2. Huge number of gateway interfaces, 16M in extreme case, needs to
be supported on the centralized gateway.
Hao & Li Expires December 9, 2014 [Page 5]
Internet-Draft TRILL Distributed Gateway Solution June 2014
3. Traffic bottleneck on the gateways.
Distributed gateway on edge RBridges can be used to address these
issues.
4. Layer 3 traffic forwarding model
+---------------------------------------------+
| |
| +-----------+ +-----------+ |
| | Tenant n |---------| VRF n | |
| +------------+ | +------------+ | |
| | +-----+ | | | | | |
| | | VN1 | | | | | | |
| | +-----+ | | | VRF 1 | | |
| | .. +-------+ | | |
| | +-----+ | | | | | |
| | | VNm | | | | | | |
| | +-----+ | | | | | |
| | Tenant 1 |-+ | | | |
| +------------+ | | | |
| +------------+ +------------+ |
| |
| Edge RB |
+---------------------------------------------+
Figure 2 Edge RB Model as distributed GW
In a data center network (DCN), each tenant may include one or more
layer 2 virtual network and in normal cases each tenant corresponds
to one routing domain (RD). Normally each layer 2 virtual network
corresponds to one or more subnets.
Each layer 2 virtual network in a TRILL campus is identified by a
unique 12-bit VLAN ID or 24-bit Fine Grained Label [FGL]. Different
routing domains may have overlapping address space but need distinct
and separate routes. The end systems that belongs to the same subnet
communicate through L2 forwarding, end systems of same tenant that
belongs to different subnet communicate through L3 forwarding.
The above figure 2 depicts the model where there are N VRFs
corresponding to N tenants with each tenant having up to M
segments/subnets (virtual network).
5. Distributed gateway solution overview
In the TRILL distributed gateway scenario, an edge RBridge must
perform Layer 2 routing for the ESs that are on the same subnet and
Hao & Li Expires December 9, 2014 [Page 6]
Internet-Draft TRILL Distributed Gateway Solution June 2014
IP routing for the ESs that are on the different subnets of same
tenant.
As IP address space in different routing domain can be overlapped,
so VRF should be created on each edge RBridge to isolate IP
forwarding process among different routing domain. Each routing
domain is identified by a globally unique tenant ID. The operators
should ensure the consistency of the tenant ID on each edge RBridge
for each routing domain. If a routing domain spreads over multiple
edge RBridges, routing information of the routing domain should be
synchronized among these edge RBridges to ensure the reachability to
all ESs in that routing domain. Tenant ID should be carried with the
routing information synchronization to differentiate the routing
domain.
From data plane perspective, all edge RBridges are connected to each
other via one or multiple TRILL hops, however they are always a
single IP hop away. When an ingress RBridge receives inter-subnet
traffic from local ES whose destination MAC is gateway MAC, the
RBridge will perform Ethernet header termination and look up IP
forwarding table to forward the traffic to IP next hop. If
destination ES is connected to a remote edge RBridge, the remote
RBridge will be the IP next hop for traffic forwarding. Ingress
RBridge will perform TRILL encapsulation for such inter-subnet
traffic and forward it to the remote RBridge through TRILL campus.
When the remote RBridge receives the traffic, the RBridge will
decapsulate TRILL header and then looks up IP forwarding table to
forward it to the destination ES. Through this solution, TRILL can
provide pair-wise data frame routing for inter-subnet traffic.
5.1. Local routing information
An ES can be locally connected to an edge RBridges through layer 2
network or through external layer 3 IP network.
If the ES is connected to an edge RBridge through layer 2 network,
then the edge RBridge must act as layer 3 GW for the ES. Gateway
interface should be established on the edge RBridge for the
connecting ES. Because the ESs of same subnet may spread over
multiple edge RBridges, each of these edge RBridges should establish
it's gateway interface for the subnet, these gateway interfaces on
different edge RBridges share same gateway MAC and gateway IP
address.
Before an ES starts to send inter-subnet traffic data, it should
acquire it's gateway's MAC through ARP/ND process. Local connecting
edge RBridge always respond with the gateway MAC address when
Hao & Li Expires December 9, 2014 [Page 7]
Internet-Draft TRILL Distributed Gateway Solution June 2014
receiving ARP/ND request for the gateway IP. Through the ARP/ND
process, the edge RBridge can learn IP and MAC correspondence of
local layer 2 connecting ES and then generates local IP routing
entries for the ES in corresponding routing domain.
If an ES is located in an external IP network, the ES also can be
connected to TRILL campus through a TRILL edge RBridge. The TRILL
edge RBridge runs unified routing protocol with external IP network
for each routing domain. The edge RBridge learns the IP prefix
corresponding to the ES through the IP routing protocol, then the
RBridge generates local IP routing entries in corresponding routing
domain.
5.2. Local routing information synchronization
Each edge RBridge should announce its own tenant gateway MAC to
TRILL campus. Tenant gateway MAC is to differentiate inter-subnet
layer 3 traffic or intra-subnet layer 2 traffic on egress RB,
ingress RB will use the tenant gateway MAC announced by egress RB as
inner destination MAC for inter-subnet traffic TRILL encapsulation.
All tenants on a RB can share same tenant gateway MAC for inter-
subnet traffic purpose, the MAC normally is the RB's system MAC.
When a routing instance is created on an edge RBridge, globally
tenant ID, tenant VLAN or FGL should be specified. The
correspondence between tenant ID and tenant VLAN or FGL should be
synchronized to other edge RBridges. Ingress RB uses the VLAN or FGL
of egress RB as inner VLAN(or FGL) when it performs inter-subnet
traffic TRILL encapsulation. The egress RBridge relies on tenant
VLAN or FGL to find local VRF for IP forwarding process when
receiving inter-subnet traffic from TRILL campus, the role of tenant
VLAN is akin to MPLS VPN Label in MPLS IP/MPLS VPN network. Tenant
VLANs are independently allocated on each edge RBridge for each
routing domain, an edge RBridge can pick up an access VLAN in a
routing domain to act as inter-subnet VLAN, or the edge RBridge can
use a different VLAN from any access VLANs to act as tenant VLAN,
it's implementation dependant and there is no restriction on this.
When a local prefix is learned in a routing instance on an edge
RBridge, the edge RBridge should synchronize the prefix information
of the routing instance to other edge RBridges to generate IP
routing entries, global unique tenant ID also should be carried to
differentiate IP prefix between different tenant, because IP address
space among different tenant can be overlapped.
TRILL LSP extension can be used for IP routing information
synchronization in each routing domain among edge RBridges. Based on
Hao & Li Expires December 9, 2014 [Page 8]
Internet-Draft TRILL Distributed Gateway Solution June 2014
the synchronized information from other edge RBridges, each edge
RBridge generate remote IP routing entries in each routing domain.
Through this solution, intra-subnet bridging function and inter-
subnet IP routing function are integrated in only one protocol,
network management and deployment will be greatly simplified.
5.3. Data traffic forwarding process
After a layer 2 connected ES1 of VLAN-x acquires its gateway's MAC,
it can start inter-subnet data traffic process to ES2 of VLAN-y.
When the local connecting edge RBridge receives inter-subnet traffic
from ES1, the RBridge performs layer 2 header termination, then it
gets local VRF corresponding to VLAN-x and performs IP forwarding
process in the VRF.
If destination ES2 is also attached to the ingress RBridge, the
traffic will be locally forwarded to ES2 on the ingress RB.
Comparing to the centralized gateway solution, forwarding path is
optimal and traffic detour is avoided.
If ES2 is attached to a remote edge RBridge, the remote edge RBridge
is IP next hop, inter-subnet traffic is forwarded to the IP next hop
through TRILL encapsulation. If there are multiple equal cost
shortest path between ingress RBridge and egress RBridge, all these
path can be used for inter-subnet traffic forwarding, so pair-wise
forwarding can be achieved for inter-subnet traffic.
When the remote RBridge receives the inter-subnet TRILL
encapsulation traffic, the RBridge decapsulates the TRILL
encapsulation and checks inner destination MAC, if the MAC equals to
local gateway MAC corresponding to inner VLAN or FGL, inner VLAN or
FGL will be used to find corresponding local VRF, then IP forwarding
process in the VRF will be performed, the traffic will be locally
forwarded to the destination ES2.
In summary, through this solution, traffic detour is avoided, both
inter-subnet and intra-subnet traffic can be forwarded along pair-
wise shortest path, network bandwidth can be greatly saved.
Hao & Li Expires December 9, 2014 [Page 9]
Internet-Draft TRILL Distributed Gateway Solution June 2014
6. Distributed layer 3 gateway process example
----------- -----------
| RB3 | | RB4 |
----------- -----------
# # * *
# # **************************
########################### *
# * # *
# * # *
# * # *
------------ -------------
| RB1 | | RB2 |
------------ -------------
| |
| |
____ ____
|E | |E |
|S1| |S2|
---- ----
Figure 3 Distributed gateway scenario
In figure 3 above, RB1 and RB2 support distribution gateway function,
ES1 connects to RB1, ES2 connects to RB2. ES1 and ES2 belongs to
Tenant1, but in different subnet.
The IP address, VLAN and subnet information of ES1 and ES2 are as
follows.
+-----+---------+----------------------+-----------------+--------------+
| ES | Tenant | IP Address | Subnet | VLAN |
+-----+---------+----------------------+-----------------+--------------+
| ES1 | Tenant1 | 10.1.1.2 | 10.1.1.1/32 | 10 |
+-----+---------+----------------------+-----------------+--------------+
| ES2 | Tenant2 | 20.1.1.2 | 20.1.1.1/32 | 20 |
+-----+---------+----------------------+-----------------+--------------+
Figure 4 ES information
The nickname, VRF, tenant VLAN, tenant gateway MAC for tenant1 on
RB1 and RB2 are as follows:
Hao & Li Expires December 9, 2014 [Page 10]
Internet-Draft TRILL Distributed Gateway Solution June 2014
+-----+---------+-----------+-----------+----------------+-----------------+
| RB | Nickname| Tenant | VRF | Tenant VLAN | Gateway MAC |
+-----+---------+-----------+-----------+----------------+-----------------+
| RB1 | nick1 | Tenant1 | VRF1 | 100 | MAC1 |
+-----+---------+-----------+-----------+----------------+-----------------+
| RB2 | nick2 | Tenant1 | VRF2 | 100 | MAC2 |
+-----+---------+-----------+-----------+----------------+-----------------+
Figure 5 RB information
6.1. Control plane process
RB1 announces the following local routing information to TRILL
campus:
Tenant gateway MAC: MAC1.
Tenant VLAN for Tenant1: VLAN 100.
IP prefix in Tenant1: 10.1.1.2/32.
RB2 announces the following local routing information to TRILL
campus:
Tenant gateway MAC: MAC2.
Tenant VLAN for Tenant1: VLAN 100.
IP prefix in Tenant1: 20.1.1.2/32.
Relying on the routing information from RB2, remote routing entries
on RB1 are generated as follows:
+----------------------+------------------------+-----------------------+----------------------------+
| Prefix/Mask | inner dest MAC | inner VLAN | egress nickname |
+----------------------+------------------------+-----------------------+----------------------------+
| 20.1.1.2/32 | MAC2 | 100 | nick2 |
+----------------------+------------------------+-----------------------+----------------------------+
Figure 6 Tenant 1 remote routing table on RB1
Similarly, relying on the routing information from RB1, remote
routing entries on RB2 are generated as follows:
Hao & Li Expires December 9, 2014 [Page 11]
Internet-Draft TRILL Distributed Gateway Solution June 2014
+----------------------+------------------------+-----------------------+----------------------------+
| Prefix/Mask | inner dest MAC | inner VLAN | egress nickname |
+----------------------+------------------------+-----------------------+----------------------------+
| 10.1.1.2/32 | MAC1 | 100 | nick1 |
+----------------------+------------------------+-----------------------+----------------------------+
Figure 7 Tenant 1 remote routing table on RB1
6.2. Data plane process
Assuming ES1 sends unicast inter-subnet traffic to ES4, the traffic
forwarding process is as follows:
1. ES1 sends unicast inter-subnet traffic to RB1, the destination
MAC is gateway's MAC.
2. Ingress RB(RB1) forwarding process:
RB1 checks the destination MAC, if the destination MAC equals to
local gateway MAC, the GW will terminate layer 2 header and
perform L3 forwarding process.
RB1 looks up IP forwarding table by destination IP to get IP next
hop information, which includes egress RBridge's gateway
MAC(MAC2), tenant VLAN(VLAN 100) and egress nickname(nick2).
Relying on these information, RB1 will perform inner Ethernet
header encapsulation and TRILL encapsulation. RB1 will use MAC2
as inner destination MAC, MAC1(RB1's own gateway MAC) as inner
source MAC, VLAN 100 as inner VLAN, nick2 as egress nickname and
nick1 as ingress nickname.
RB1 looks up TRILL forwarding table by egress nickname and
forwards the traffic to TRILL next hop as per RFC 6325. The
traffic will be forwarded to RB3 or RB4 as result of load
balancing.
Assuming the traffic is forwarded to RB3.
3. Transit RB(RB3) forwarding process:
Hao & Li Expires December 9, 2014 [Page 12]
Internet-Draft TRILL Distributed Gateway Solution June 2014
RB3 looks up TRILL forwarding table by egress nickname and
forwards the traffic to RB2 as per RFC 6325.
4. Egress RB forwarding process:
As the egress nickname is RB2's own nickname, so RB2 performs
TRILL decapsulation. Then it checks inner destination MAC,
because the MAC is equal to local gateway MAC, inner Ethernet
header termination is performed. Relying on inner VLAN, RB2 find
local corresponding VRF and looks up the VRF's IP forwarding
table. The traffic will be locally forwarded to ES2.
7. TRILL protocol extension
If a edge RBridge RB1 participates distributed gateway function,
it should announce its tenant gateway MAC, tenant VLAN and
IPv4/IPv6 prefix to TRILL campus through the tenant gateway MAC
sub-TLV, tenant VLAN sub-TLV and IPv4/IPv6 prefix sub-TLV. Other
edge RBridges belonging to same routing domain leverage these
information to generate IP routing entries in corresponding
routing domain. Ingress RB use the tenant gateway MAC and tenant
VLAN of egress RB to perform inter-subnet traffic TRILL
encapsulation when it receives inter-subnet traffic from local ES,
tenant gateway MAC is used as inner destination MAC, tenant VLAN
is used as inner destination VLAN.
7.1. The tenant gateway MAC sub-TLV
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant gateway MAC | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability sub-TLV type, TBD (Inter-Subnet MAC
sub-TLV).
o Length:6.
o Tenant gateway MAC: This identifies local tenant gateway MAC
for inter-subnet traffic forwarding.
Hao & Li Expires December 9, 2014 [Page 13]
Internet-Draft TRILL Distributed Gateway Solution June 2014
7.2. The tenant VLAN sub-TLV
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant ID | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|Resv| Label1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv2| Label2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability sub-TLV type, TBD (Next Hop sub-TLV).
o Length: If Label1 field is used to represent VLAN, the value of
the length field is 12. If Label1 and Label2 field are used to
represent FGL, the value of the length field is 14.
o Tenant ID: This identifies a global tenant ID.
o L: 1 bit. When Label1 and Label2 field are used to identify FGL,
it is set to 1. When Label1 field is used to identify VLAN, it is
set to 0.
o Resv: 3 bits that MUST be sent as zero and ignored on receipt.
o Resv2: 4 bits that MUST be sent as zero and ignored on receipt.
o Label1: If the value of length field is 12, the field is to
identify tenant VLAN ID. If the value of length field is 14, the
field is to identify higher 12 bits of tenant FGL.
o Label2: Only when the value of length field is 14, the field
has significance. It is to identify lower 12 bits of tenant FGL.
Hao & Li Expires December 9, 2014 [Page 14]
Internet-Draft TRILL Distributed Gateway Solution June 2014
7.3. The IPv4 Prefix sub-TLV
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| Tenant ID |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| Prefix(1) |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| Mask(1) |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| ..... |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| ..... |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| Prefix(N) |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
| Mask(N) |(4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+--+--+-+-+-+-+-+-+-+-+-+-+--+
o Type: Router Capability sub-TLV type, TBD (IPv4 Prefix sub-TLV).
o Length: 4+8*n bytes, where there are n prefix and mask .
o Tenant ID: This identifies a global tenant ID.
o Prefix: This identifies a IPv4 prefix.
o Mask: This identifies a IPv4 mask.
8. Security Considerations
For general TRILL Security Considerations, see [RFC6325].
9. IANA Considerations
This document requires no IANA actions. RFC Editor: Please remove
this section before publication.
10. Normative References
[1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Hao & Li Expires December 9, 2014 [Page 15]
Internet-Draft TRILL Distributed Gateway Solution June 2014
Requirement Levels", BCP 14, RFC 2119, March 1997.
11. Informative References
[1] [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S.,
and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[2] [rfc6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman,
R., and A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-
isisrfc6326bis-00.txt, work in progress.
[3] [RFC6165] Banerjee,A., Ward, D., Dutt, D.,
, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April
2011.
[4] [RFC7172] Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D.
Dutt, "TRILL (Transparent Interconnection of Lots of Links):
Fine-Grained Labeling", RFC7172, May 2014.
12. Acknowledgments
The authors wish to acknowledge the important contributions of
Guangrui Wu, Zhenbin Li.
Hao & Li Expires December 9, 2014 [Page 16]
Internet-Draft TRILL Distributed Gateway Solution June 2014
Authors' Addresses
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Donald E. Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Liang Xia(Frank)
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56624539
Email: frank.xialiang@huawei.com
Hao & Li Expires December 9, 2014 [Page 17]