TRILL Working Group Yizhou Li
Internet Draft Weiguo Hao
Intended status: Standards Track Huawei Technologies
Radia Perlman
Intel Labs
Naveen Nimmu
Broadcom
S. Chatterjee
IP Infusion
Sunny Rajagopalan
IBM
Expires: July 2013 January 15, 2013
VLAN based Tree Selection for Multi-destination Frames
draft-yizhou-trill-tree-selection-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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."
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 July 15, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires July 15, 2013 [Page 1]
Internet-Draft VLAN based Tree Selection January 2013
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.
Abstract
TRILL uses the distribution trees to deliver multi-destination frames.
Multiple trees can be used by an ingress RBridge for different flow
based on VLAN and/or multicast group. Different ingress RBridges may
choose different distribution trees for the same VLAN and/or
multicast group traffic. Distribution trees are normally pruned based
on VLAN.
For any RBridge RBn, if RBn has downstream receivers of VLAN x in a
distribution tree t, there will be an entry of (t, x, port list) in
the multicast forwarding table on RBn. If there are n trees and m
VLANs, the multicast forwarding table size on RBn is typically n*m
entries. The value of m is up to 4096 and n is the total number of
distribution trees in the campus. If fine grained labeling is
implemented or finer granularity filtering such as VLAN plus L2/L3
multicast address is used for pruning, the multicast forwarding table
size further increases dramatically. TRILL multicast forwarding table
size is limited by hardware and L3 multicasting may share the same
table with it in hardware implementations. Therefore multicast table
entry is a precious resource. This document specifies a VLAN based
tree selection mechanism to reduce the TRILL multicast forwarding
table size on RBridge.
Table of Contents
1. Introduction ................................................ 3
1.1. Background ............................................. 3
1.2. Motivations ............................................ 4
2. Conventions used in this document............................ 6
3. VLAN based Tree Selection.................................... 6
3.1. Overview ............................................... 6
3.2. Sub-TLVs for the Router Capability TLV ................. 8
3.2.1. The Tree Identifier and VLANs Sub-TLV ............. 8
3.2.2. The Tree and VLANs Used Sub-TLV ................... 9
3.3. Detailed Processing..................................... 9
Li, et al. Expires July 15, 2013 [Page 2]
Internet-Draft VLAN based Tree Selection January 2013
3.4. Failure Handling....................................... 10
3.5. Extensions ............................................ 11
4. Backward Compatibility...................................... 12
5. Aggregated Tree Nickname.................................... 13
6. Security Considerations..................................... 14
7. IANA Considerations ........................................ 14
8. References ................................................. 15
8.1. Normative References................................... 15
8.2. Informative References................................. 15
9. Acknowledgments ............................................ 15
1. Introduction
1.1. Background
One or more distribution trees can be used to distribute multi-
destination frames in a TRILL campus. The RBridge having the highest
tree root priority announces the total number of trees that should be
computed for the campus. It may also specify the ordered list of tree
root nicknames that the other RBridges need to compute in the Tree
Identifiers (TREE-RT-IDs) sub-TLV [RFC6326]. Every RBridge specifies
the trees it wants to use in the Trees Used Identifiers (TREE-USE-IDs)
sub-TLV and the VLAN it is interested in the Interested VLANs and
Spanning Tree Roots (INT-VLAN) sub-TLV [RFC6326]. It is recommended
that, by default, the ingress RBridge chooses the tree whose root is
the closest[RFC6325]. Trees Used Identifiers sub-TLV is used to build
the RPF table which is used for reverse path forwarding check;
Interested VLANs sub-TLV is used for distribution tree pruning and
the multicast forwarding table with pruning info is built based on
that. Each distribution tree SHOULD be pruned per VLAN, eliminating
branches that have no potential receivers downstream [RFC6325].
Further pruning based on L2/L3 multicast address is also possible.
It is implementation dependant that how many trees to calculate,
where the tree roots are located and which tree(s) to be used by an
ingress RBridge. With the increasing demand to use TRILL in data
center network, there are some features we can explore for multi-
destination frames in the data center use case. In order to achieve
non-blocking data forwarding, a fat tree structure is often used.
Figure 1 shows a typical fat tree structure based data center network.
RB1&RB2 are aggregation switches and RB11 to RB14 are access switches.
It is a common practice to choose the tree roots to be at the
aggregation switches for more efficient traffic transportation. All
the ingress RBridges which are access switches have the same distance
to all the tree roots.
Li, et al. Expires July 15, 2013 [Page 3]
Internet-Draft VLAN based Tree Selection January 2013
+-----+ +-----+
| RB1 | | RB2 |
+-----+ +-----+
/ | \\ / /|\
/ | \ \ / / | \
/ | \ / / | \-----+
/ | \/ /\ | |
/ | /\/ \| |
/ /---+---/ /\ |\ |
/ / | / \ | \ |
/ / | / \ | \ |
/ / | / \ | \ |
+-----+ +-----+ +-----+ +-----+
| RB11| | RB12| | RB13| | RB14|
+-----+ +-----+ +-----+ +-----+
Figure 1 Fat Tree Structure based TRILL network
1.2. Motivations
In the structure of figure 1, if we choose to put the tree root at
RB1 and RB2, the ingress RBridge (e.g. RB11) would find more than one
closest tree root (i.e. RB1 & RB2). Then an ingress RBridge has two
options to select the tree root for multi-destination frames: choose
one and only one as distribution tree root or use ECMP-like algorithm
to balance the traffic among the multiple trees whose roots are at
the same distance. For the former, single used tree per ingress
RBridge, has the obvious problem of inefficient link usage. For
example, if RB11 chooses the tree1 which is rooted at RB1 as the
distribution tree, the link between RB11 and RB2 will never be used
to ingress the multi-destination frame by RB11. For the latter, ECMP
based tree selection results in a linear increase in multicast
forwarding table size with the number of trees as explained in the
next paragraph.
A multicast forwarding table on an RBridge is normally used to map
the key of (tree nickname + VLAN) to an index to a list of ports for
multicast frame replication. The key used for mapping is simply the
tree nickname when the RBridge does not prune the tree and the key
could be (tree nickname + VLAN + L2/L3 multicast address) when the
RBridge was programmed by control plane with L2/L3 multicast pruning
information.
For any RBridge RBn, for each VLAN x, if RBn is in a distribution
tree t for VLAN x, there will be an entry of (t, x, port list) in the
Li, et al. Expires July 15, 2013 [Page 4]
Internet-Draft VLAN based Tree Selection January 2013
multicast forwarding table on RBn. Each entry contains a distinct
combination of (tree nickname, VLAN) as the lookup key. If there are
n such trees and m such VLANs, the multicast forwarding table size on
RBn is n*m entries. If fine-grained label is used [TrillFGL] and/or
finer pruning is used(e.g. VLAN + multicast group address is used for
pruning), the value of m increases. In the larger scale data center,
more trees would be necessary for better load balancing purpose and
it results in the increasing of value n. In either case, the number
of table entries n*m will increase dramatically.
Figure 2 left table shows an example of the multicast forwarding
table on RB11 in figure 1 topology with 2 distribution trees in
campus. The number of entries is approximately 2 * 4K in this case.
If 4 distribution trees are used in a TRILL campus and RBn has 4K
VLANs with downstream receivers, it consumes 16K table entries. TRILL
multicast forwarding table has a limited size in hardware
implementation. The table entry is a precious resource. In some
implementations, it shares with L3 IP multicast for a total of 16K or
8K table entries. Therefore we want to save the table size consumed
as much as possible and at the same time to maintain the load
balancing among trees.
A straightforward way to alleviate the limited table entries problem
is not to prune the distribution tree. However it can only be used in
the restricted scenarios for the following reasons,
- Unnecessary bandwidth waste for multi-destination frame. There is
broadcast traffic in each VLAN, like ARP and unknown unicast. In
addition, if there is huge L3 multicast traffic in some VLAN, no
pruning may result in worse consequence of L3 user data
unnecessarily flooded over the campus. The volume could be huge if
certain application like IPTV is supported. Finer pruning like
pruning based on multicast group may be desirable in this case.
- Only useful at the pure transit nodes. Edge nodes always need to
maintain the multicast forwarding table with the key of (tree
nickname + VLAN) since the edge node needs to decide whether and
how to replicate the frame to local access ports based on VLAN
precisely. It is very likely that edge nodes are relatively low
scale switches with the smaller shared table size, say 4K,
available.
- Security concerns. VLAN based traffic isolation is a basic
requirement in some scenarios. No pruning may result in the
unnecessary leak of the traffic. Misbehaved RBridge may take
advantage of this.
Li, et al. Expires July 15, 2013 [Page 5]
Internet-Draft VLAN based Tree Selection January 2013
In addition to the multicast table size concern, some silicon does
not support hashing based tree nickname selection at the ingress
RBridge currently. VLAN based tree selection is used instead. Control
plane of ingress RBridge maps the incoming VLAN x to a tree nickname
t. Then data plane will always use tree t for VLAN x multi-
destination frames. Though an ingress RB may choose multiple trees to
be used for load sharing, it can use one and only one tree for single
VLAN. If we make sure all ingress RBridges campus-wide send VLAN x
multi-destination frames only using tree t, then there would be no
need to store the multicast table entry with the key of (tree-other-
than-t, x) on any RBridge.
This document describes the control plane support for VLAN based tree
selection mechanism to reduce the multicast forwarding table size. It
consists with the silicon implementation mentioned in the previous
paragraph. Here VLAN based tree selection is a general term which
also includes finer granularity case, e.g. VLAN + L2/L3 multicast
group based selection.
2. Conventions used in this document
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].
3. VLAN based Tree Selection
VLAN based tree selection can be used as a complementary distribution
tree selection mechanism, especially when the multicast forwarding
table size is a concern.
3.1. Overview
The tree root with the highest priority announces the tree nicknames
and the VLANs allowed on each tree. Such tree-VLAN correspondence
announcement can be based on static configuration or some predefined
algorithm. Ingress RBridge selects the tree-VLAN correspondence it
wishes to use from the list announced by the highest priority tree
root. It should not transmit VLAN x frame on tree y if the highest
priority tree root does not say VLAN x is allowed on tree y.
If we make sure one VLAN is allowed on one and only one tree, we can
keep the number of multicast forwarding table entries on any RBridge
fixed at 4K maximum (or up to 16M in case of fine grained label).
Take Figure 1 as example, two trees rooted at RB1 and RB2
respectively. The highest priority tree root appoints the tree1 to
carry VLAN 1-2000 and tree2 to carry VLAN 2001-4095. With such
Li, et al. Expires July 15, 2013 [Page 6]
Internet-Draft VLAN based Tree Selection January 2013
announcement by the highest priority tree root, every RBridge which
understands the announcement will not send the VLAN 2001-4095 on
tree1 or send the VLAN 1-2000 on tree2. Then no RBridge would need to
store the entries for tree1/VLAN2001-4095 or tree2/VLAN1-2000. Figure
2 shows the multicast forwarding table on an RBridge before and after
we perform the VLAN based tree selection. The number of entries is
reduced by a factor f , f being the number of trees used in the
campus. In this example, it is reduced from 2*4095 to 4095. This
affects both transit nodes and edge nodes. Data plane does not change.
+--------------+-----+---------+ +--------------+-----+---------+
|tree nickname |VLAN |port list| |tree nickname |VLAN |port list|
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 1 | | | tree 1 | 1 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 2 | | | tree 1 | 2 | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 1999| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | ... | | | tree 1 | 2000| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4094| | | tree 2 | 2001| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 1 | 4095| | | tree 2 | 2002| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 1 | | | tree 2 | ... | |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | 2 | | | tree 2 | 4094| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | | | tree 2 | 4095| |
+--------------+-----+---------+ +--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | ... | |
+--------------+-----+---------+
| tree 2 | 4094| |
+--------------+-----+---------+
| tree 2 | 4095| |
+--------------+-----+---------+
Figure 2 Multicast forwarding table before (left) & after (right)
Li, et al. Expires July 15, 2013 [Page 7]
Internet-Draft VLAN based Tree Selection January 2013
3.2. Sub-TLVs for the Router Capability TLV
Two new sub-TLVs that can be carried in the Router Capability TLV for
TRILL are defined below. They can be considered as analog of finer
granularity version of the Tree Identifiers Sub-TLV and the Trees
Used Identifiers Sub-TLV in [RFC6326].
3.2.1. The Tree Identifier and VLANs Sub-TLV
The tree identifiers and VLAN (TREE-VLANs) sub-TLV is used to
announce the VLANs allowed on each tree by the IS that has the
highest priority tree root. Multiple instances of this sub-TLV may be
carried. Same tree nickname may occur in the multiple Tree-VLAN
Records within the same or across multiple sub-TLVs. The sub-TLV
format is as follows:
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-VLAN Record (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-VLAN Record (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each Tree-VLAN Record is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability sub-TLV type, set to 20 (TREE-VLANs).
o Length: 6*n bytes, where there are n Tree-VLAN Records.
Li, et al. Expires July 15, 2013 [Page 8]
Internet-Draft VLAN based Tree Selection January 2013
o Tree Nickname: The nickname at which a distribution tree is
rooted.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the allowed
VLAN range on the tree, inclusive. To specify a single VLAN, the
VLAN's ID appears as both the start and end VLAN.
3.2.2. The Tree and VLANs Used Sub-TLV
This sub-TLV has the same structure as the Tree Identifiers and VLAN
sub-TLV (TREE-VLANs) specified in Section 3.2.2. The only difference
is that its sub-TLV type is set to 21 (TREE-VLAN-USE), and the Tree-
VLAN record listed are those the originating IS allows.
3.3. Detailed Processing
The highest priority tree root includes all the necessary tree
related sub-TLVs defined in [RFC6326] as usual and MAY optionally
include the Tree Identifier and VLANs Sub-TLV (Tree-VLANs) in its LSP.
The highest priority tree root may decide that each VLAN is only
allowed on one and only one tree to maximize the saving in the
multicast forwarding table size.
Ingress RBridge that understands the Tree-VLANs Sub-TLV should select
the tree-VLAN correspondences it wishes to use and put them in TREE-
VLAN-USE sub-TLV. If there were multiple tree nicknames announced in
Tree-VLANs Sub-TLV for a VLAN x, ingress RBridge must choose one of
them. Ingress RB may choose the minimum distance root from them. How
to make such choice is out of the scope of this document. It may be
desirable to have some fixed algorithm to make sure all ingress RBs
choose the same tree for VLAN x in this case. Any single VLAN that
the ingress RBridge is interested in should be related to one and
only one tree ID in TREE-VLAN-USE to minimize the multicast
forwarding table size on other RBridges.
When ingress RBridge tries to encapsulate a multi-destination frame
for VLAN x, it should use the tree nickname that it selected
previously in TREE-VLAN-USE for VLAN x.
If RBridge RBn does not perform pruning at all, it builds the
multicast forwarding table exactly same as that in [RFC6325].
If RBn prunes the distribution tree based on VLANs, RBn uses the
information received in TREE-VLAN-USE sub-TLV to mark the set of
Li, et al. Expires July 15, 2013 [Page 9]
Internet-Draft VLAN based Tree Selection January 2013
VLANs reachable downstream for each adjacency and for each related
tree.
Logically, ingress RBridge that does not support VLAN based tree
selection is equivalent to the one that supports it and announces all
the combination pair of tree-id-used and interested-vlan as TREE-
VLAN-USE.
3.4. Failure Handling
Failure of a tree root: It is the responsibility of the highest
priority tree root to inform others the change of the allowed tree-
VLAN correspondence. When the highest priority tree root learns the
root of tree t fails, it should re-assign the VLANs allowed on tree t
to other trees or to a tree replacing the failed one.
Failure of the highest priority tree root: It is recommended to pre-
configure the second highest priority tree root with the proper
knowledge of the tree-VLAN correspondence allowed when the highest
priority tree root fails. The information announced by the second
priority tree root would be stored by all RBridges but would not take
effect unless the RBridge noticed the failure of the highest priority
tree root. When the highest priority tree root fails, the original
second priority tree root will become the highest priority tree root
of the campus. When an RBridge notices the failure of the original
highest priority tree root, it can immediately use the stored
information announced by the original second priority tree root. It
is recommended to pre-configure the tree-VLAN correspondence
information on the second highest priority tree root same as that on
the highest priority tree root for the trees other than the highest
priority tree itself. This can make the change of multicast
forwarding table minimum in case of the highest priority tree root
failure.
In some transient moment or misbehave of the highest priority tree
root, an ingress RBridge may encounter the following scenarios:
- No tree has been announced to allow VLAN x frames
- An ingress RBridge is supposed to transmit VLAN x frames on tree t,
but root of tree t is no longer reachable.
For the second case, an ingress RBridge may choose another reachable
tree root which allows VLAN x by the highest priority tree root
announcement. If there is no such tree available, then it is same as
the first case above. Then the ingress RBridge should be 'downgraded'
to a conventional BRridge in [RFC6325]. A timer should be set to
Li, et al. Expires July 15, 2013 [Page 10]
Internet-Draft VLAN based Tree Selection January 2013
allow the temporary transient stage completion before the change of
responsive tree or 'downgrade' takes effect. The value of timer
should at least be set to the LSP flooding time in campus.
3.5. Extensions
VLAN based tree selection can be easily extended to (VLAN+L2/L3
multicast group) based tree selection. For example, we can appoint
multicast group 1 in VLAN 10 to tree1 and appoint group 2 in VLAN 10
to tree2 for better load sharing. New sub-TLVs are specified below
for this purpose.
+-+-+-+-+-+-+-+-+
|Type= | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=4 for group
IPv4 address and k=6 for group MAC address and k=16 for group IPv6
address:
Li, et al. Expires July 15, 2013 [Page 11]
Internet-Draft VLAN based Tree Selection January 2013
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. Backward Compatibility
RBridge should include the TREE-USE-IDs and INT-VLAN sub-TLVs when
necessary as per RFC6325 no matter if it supports the new TREE-VLAN-
USE sub-TLV specified by this draft.
RBridge that understands new TREE-VLAN-USE sub-TLV sent from another
RBridge RBn should use it to build the multicast forwarding table and
ignore the TREE-USE-IDs and INT-VLAN sub-TLVs sent from the same
RBridge. It should be noted that TREE-USE-IDs and INT-VLAN sub-TLVs
are still useful for some purposes other than building multicast
forwarding table, e.g. RPF table building, spanning tree root
notification, etc. If the RBridge does not receive TREE-VLAN-USE sub-
TLV from RBn, it uses the conventional way described in [RFC6325] to
build the multicast forwarding table.
For example, there are two distribution trees, tree1 & tree2 in the
campus. RB1&RB2 are new RBridges which use the new sub-TLVs described
in this document. RB3 is an old RBridge which is compatible with
[RFC6325]. Assume RB2 is interested in VLAN 10&11 and RB3 is
interested in VLAN 100&101. Hence RB1 receives ((tree1,
VLAN10),(tree2, VLAN11)) as TREE-VLAN-USE sub-TLV and (tree1, tree2)
as TREE-USE-IDs sub-TLV from RB2 on port x. And RB1 receives (tree1)
as TREE-USE-IDs sub-TLV and no TREE-VLAN-USE sub-TLV from RB3 on port
y. RB2 & RB3 announce their interested VLANs in INT-VLAN sub-TLV as
usual. Then RB1 will build the entry of (tree1, VLAN10, port x) and
(tree2, VLAN11, port x) based on RB2's LSP and mechanism specified
in this document. RB1 also builds entry of (tree1, VLAN100, port y),
(tree1, VLAN101, port y), (tree2, VLAN100, port y), (tree2, VLAN101,
port y) based on RB3's LSP in conventional way. The multicast
forwarding table on RB1 with merged entry would be like the following.
Li, et al. Expires July 15, 2013 [Page 12]
Internet-Draft VLAN based Tree Selection January 2013
+--------------+-----+---------+
|tree nickname |VLAN |port list|
+--------------+-----+---------+
| tree 1 | 10 | x |
+--------------+-----+---------+
| tree 1 | 100 | y |
+--------------+-----+---------+
| tree 1 | 101 | y |
+--------------+-----+---------+
| tree 2 | 11 | x |
+--------------+-----+---------+
| tree 2 | 100 | y |
+--------------+-----+---------+
| tree 2 | 101 | y |
+--------------+-----+---------+
It is expected that the table is not shrunk as small as the one where
every RB supports the new TREE-VLAN-USE sub-TLVs. The worst case in a
hybrid campus is the number of entries equal to the number in current
practice which does not support VLAN based tree selection. Such
extreme case happens when the interested VLAN set from the new
RBridges is a subset of the interested VLAN set from the old RBridges.
VLAN based tree selection is compatibility with the current practice.
Its effectiveness increases with more RBridge supporting this feature
in the TRILL campus.
5. Aggregated Tree Nickname
VLAN based tree selection needs control plane enhancement. This
section illustrates another data plane mechanism to solve the
multicast forwarding table size limitation problem.
The idea is to aggregate the multicast forwarding table entries based
on VLAN for all trees. If there are two trees, tree1 and tree2 in the
campus, RBridge RBn may have two entries for VLAN x which are (tree1,
VLAN-x, port-list-1) and (tree2, VLAN-x, port-list-2). After
aggregation on tree nickname, the entry becomes (tree = wildcard/*,
VLAN-x, port-list-1 UNION port-list-2).
The multi-destination frames received by RBn for VLAN x will be
replicated to both tree1 and tree2 outgoing ports. The next hop
RBridge will perform the RPF checks. If a port is part of one tree
but not the other, the next hop RBridge won't have an entry for the
(source_RBridge, treeid) pointing to that incoming port in RPF
checking table. Therefore next hop RBridge will drop those frames
Li, et al. Expires July 15, 2013 [Page 13]
Internet-Draft VLAN based Tree Selection January 2013
received on the wrong incoming ports. So this is a one-hop-delayed
pruning. In some circumstances, the pruning may be delayed more than
one hop. It happens when an RBridge located in multiple trees has the
same incoming port for a RPF check.
The following table gives some simple comparison on two approaches.
+-------------+--------------------------+------------------------+
| |VLAN based tree selection | aggr tree nickname |
+-------------+--------------------------+------------------------+
| | |depends.Hardware should |
|data plane | no |be capable to support |
|change req? | |tree nickname aggre |
| | |searching |
+-------------+--------------------------+------------------------+
|ctrl plane | Yes. Needs new sub-TLV | |
|change req? | and new handlings | no |
+-------------+--------------------------+------------------------+
| |inter-vlan multipathing. |allow intra-VLAN tree |
|multipathing |Single VLAN uses single |based multipathing. |
| |designated tree campus |Better load balancing |
| |wide |within the VLAN |
+-------------+--------------------------+------------------------+
|optimal | yes |slightly less than |
|pruning? | |optimal in certain case |
+-------------+--------------------------+------------------------+
The co-authors would like to seek comments and opinions on both
approaches and their applicable scenarios.
6. Security Considerations
This document does not change the general RBridge security
considerations of the TRILL base protocol. See Section 6 of
[RFC6325].
7. IANA Considerations
IANA is requested to allocate the new sub-TLV type code as specified
in Section 3.
Li, et al. Expires July 15, 2013 [Page 14]
Internet-Draft VLAN based Tree Selection January 2013
8. References
8.1. Normative References
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.
[6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS'', draft-eastlake-isis-
rfc6326bis-07.txt, Work in Progress, December 2011.
[RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC
6439, November 2011.
8.2. Informative References
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
6327, July 2011
[TrillFGL] Eastlake 3rd, D., Zhang, M., Agarwal, P., Dutt, D., and
Perlman, R., ''TRILL: Fine-Grained Labeling'', draft-ietf-
trill-fine-labeling-00.txt, December 2011
9. Acknowledgments
Authors wish to thank David M Bond, Donald Eastlake, Liangliang Ma,
Rakesh Kumar R for the valuable comments (names in alphabet order).
This document was prepared using 2-Word-v2.0.template.dot.
Li, et al. Expires July 15, 2013 [Page 15]
Internet-Draft VLAN based Tree Selection January 2013
Authors' Addresses
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Naveen Nimmu
Broadcom
9th Floor, Building no 9, Raheja Mind space
Hi-Tec City, Madhapur,
Hyderabad - 500 081, INDIA
Phone: +1-408-218-8893
Email: naveen@broadcom.com
Li, et al. Expires July 15, 2013 [Page 16]
Internet-Draft VLAN based Tree Selection January 2013
Somnath Chatterjee
IP Infusion
RMZ Centennial, Block D
Doddanakundi Industrial Area,
Kundanahalli Main Road,Mahadevapura Post,
Bangalore - - 560 048 Karnataka, India
Email: somnath.chatterjee01@gmail.com
Sunny Rajagopalan
IBM
Email: sunny.rajagopalan@us.ibm.com
Li, et al. Expires July 15, 2013 [Page 17]