Internet DRAFT - draft-zhang-trill-vlan-assign
draft-zhang-trill-vlan-assign
INTERNET-DRAFT Mingui Zhang
Intended Status: Informational Dacheng Zhang
Expires: April 18, 2014 Huawei
October 15, 2013
Adaptive VLAN Assignment for Data Center RBridges
draft-zhang-trill-vlan-assign-06.txt
Abstract
If RBridges are casually assigned as Appointed Forwarders for VLANs
without considering the number of MAC addresses and traffic load of
these VLANs, it may overload some of the RBridges while leave other
RBridges lightly loaded, which reduces the scalability of a RBridge
network and undermines its performance.
A new mechanism is designed in this document to support the adaptive
VLAN assignment (or Appointed Forwarder selection) based on the
forwarders' reporting of their usage of MAC tables and available
bandwidth.
Status of this Memo
This Internet-Draft is submitted to IETF 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Mingui Zhang Expires April 18, 2014 [Page 1]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Data Center RBridge . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. East-West Capacity Increase . . . . . . . . . . . . . . . . 4
2.3. Virtualization . . . . . . . . . . . . . . . . . . . . . . 5
3. MAC Entries Usage . . . . . . . . . . . . . . . . . . . . . . . 5
4. Load Distribution . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Egress Traffic . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Ingress Traffic . . . . . . . . . . . . . . . . . . . . . . 7
5. Feedback Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. MAC Entries Report Sub-TLV . . . . . . . . . . . . . . . . 8
5.2. Traffic Bit Rate Report Sub-TLV . . . . . . . . . . . . . . 9
6. Adaptive VLAN Assignment . . . . . . . . . . . . . . . . . . . 10
7. Partial VLANs Appointment . . . . . . . . . . . . . . . . . . . 11
7.1 Partial Appointed Forwarder Sub-TLV . . . . . . . . . . . . 12
7.2 Partial VLANs Appointing Sub-TLV . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Mingui Zhang Expires April 18, 2014 [Page 2]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
1. Introduction
The scales of Data Center Networks (DCNs) are expanding rapidly these
years. In DCNs, Ethernet switches and bridges are abundantly used for
the interconnection of servers. The plug-and-play feature and the
simple management and configuration of Ethernet are appealing to DCN
providers. A whole DCN can be a simple large layer 2 Ethernet which
is either built on a real network or on a virtual platform.
Cloud Computing is growing up from DCNs which can be regarded as a
virtual platform that provides the reuse of the network resources of
DCNs. A lot of cloud applications have been developed by DCN
providers, such as Amazon's Elastic Compute Cloud (EC2), Akamai's
Application Delivery Network (ADN) and Microsoft's Azure. Cloud
Computing clearly brings new challenges to the traditional Ethernet.
The scales of the DCNs are becoming too large to be carried on the
traditional Ethernet. The valuable MAC-tables of the bridges are
running out of use for storing millions of MAC addresses. The
broadcast of ARP messages consumes too much bandwidth and computing
resources. The mobility of end stations brings dynamics to the
network which can become a heavy burden if the management and
configuration of the network involves too much manpower. The Spanning
Tree Protocol used in the traditional Ethernet is becoming outdated
since there is only a single viable path on the tree for a node pair
and this path is not always the best path (e.g., shortest path).
RBridges are designed to improve the shortcomings of the traditional
Ethernet. To make use of the rich connections, RBridges introduce
multi-pathing to the Ethernet to break the single-path constraint of
STP. Multiple points of attachment is a basic feature supported by
RBridges and common for Data Center Bridges. This feature not only
increases the "east-west" capacity but also greatly enhances the
reliability of DCNs [VL2] [SAN]. If several RBridges are attached to
a bridged LAN link at the same time, the DRB is responsible for the
assignment of a VLAN to one of the RBridges as the Appointed
forwarder. However, VLAN assignment is currently done in an one-way
manner. The DRB casually assigns a VLAN to an RBridge attached to the
local link without knowing its available MAC-table entries or
bandwidth. The appointed forwarder does not feedback the utilization
of its MAC-table or bandwidth either.
This document proposes to balance the load among VLANs. Two types of
sub-TLVs are defined, with which a forwarder can report its MAC
entries and traffic bit rate respectively. By gathering these report
messages, the VLAN assignment can be done in a way that the usage of
the MAC tables and bandwidth of the attached RBridges are balanced
among VLANs.
Mingui Zhang Expires April 18, 2014 [Page 3]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
1.1. Terminology
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].
2. Data Center RBridge
Data Center Networks grow rapidly. Ethernet is widely used in data
centers because of its simple management and plug-and-play features.
However, there are shortcomings of Ethernet. RBridges are designed to
improve these shortcomings. In this section, we analyze the
characteristics of DCNs that impact the design of RBridges and reveal
why the adaptive VLAN assignment is important for RBridges to be used
in DCNs.
2.1. Scalability
In the past years, a large DCN is typically composed of tens of
thousands servers interconnected through switches. In the cloud
computing era, there can be as many as millions of servers in one
DCN. The management of the massive MAC addresses of the servers on
the layer2 devices will become more and more complex. RBridges are
used to replace the traditional bridges.
Valuable CAM-tables on RBridges can easily be used up if they are not
used reasonably [CAMtbl]. For RBridges to be widely used in DCNs, the
VLANs should be assigned to the RBridges in a manner that MAC entries
of VLANs on RBridges are balanced.
2.2. East-West Capacity Increase
The Spanning Tree Protocol (STP) in the traditional LAN blocks some
ports of bridges for the purpose of loop avoidance. The side-effects
of STP are obvious. The link bandwidth attached to the blocked ports
are not utilized which greatly wastes the capacity of the network. On
the tree topology, the communication between the bridges of the left
branch and right branch must transit the single root bridge, which
forms a "hair-pin turn".
With the rapid increase of the amount of servers in DCNs and their
traffic demand, it is urgent to break the constraint of STP and
enhance the "east-west" capacity of DCNs which are always richly
connected. RBridges use the multi-path routing to set up the data
plane of a TRILL campus. Multiple RBridges may be attached to a same
LAN link, which offers multiple access points to the LAN link. The
hosts on this LAN link is therefore multi-homed to a TRILL campus.
All the attached RBridges can act as packet forwarders for VLANs
Mingui Zhang Expires April 18, 2014 [Page 4]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
carried on this LAN link. In the worst case, all the VLANs are
assigned to a single RBridge. Under this scenario, the ingress
capacity on other RBridges is wasted. It is necessary to balance the
traffic load of VLANs among these RBridges through the assignment of
VLANs.
2.3. Virtualization
Virtualization is important for increasing the utilization of network
resources in DCNs. For example, the VPNs can be used to separate the
traffic from different services therefore they can be carried on the
same pool of resources. When the VPNs is carried over a TRILL campus,
RBridges can use a VLAN tag to identify each VPN. However, the use of
VLANs multiplies the entries in the MAC table of RBridges.
Virtual Machines (VM) are widely used in DCNs. A physical host can
support tens of VMs and each VM has to be identified by one MAC
address that is need to be stored in MAC tables of RBridges. This
seriously increases the number of MAC entries in RBridges. Moreover,
the number of VMs in a VLAN is not necessarily equal to the number of
physical hosts. VMs are spawned or destroyed based on the demand of
applications. They can also migrate from one location to another,
which may be either an in-service or out-of-service move. VMs bring
about the volatility of the size of VLANs. It is hard to provide one
static VLAN assignment for a TRILL campus based on the numbers of
physical hosts of VLANs that is proper for all applications all the
time.
3. MAC Entries Usage
A CAM-table on a switch is expensive, which is a major constraint on
the scalability of Ethernet [CAMtable]. When an RBridge is used to
connect lots of hosts in large Data Center Networks, the entries of
the CAM-table can easily be used up. The network should be tactically
interconnected and valuable MAC table entries should be used
economically.
RBridges support multiple points of attachment [RFC6325]. When
RBridges are used in a DCN to form a TRILL campus, a LAN link MAY
have multiple access points to this campus. All these access RBridges
are able to act as the packet forwarder of VLANs carried on this LAN
link. The DRB of this LAN link is responsible to pick out one RBridge
attached to this LAN link as the appointed forwarder for each VLAN-x.
In other words, the DRB assigns VLAN-x to one of the RBridge. For an
assigned VLAN, its forwarder is not only responsible for forwarding
the packets for this VLAN but also need to store active MAC addresses
of hosts on this VLAN.
Mingui Zhang Expires April 18, 2014 [Page 5]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
If VLANs on a LAN link are not appointed properly, some RBridges's
MAC tables are easily to be used up while other RBridges are left
idle. Take Figure 3.1 as an example, there are four VLANs carried on
the LAN link: w, x, y and z. There are two hosts in both VLAN-w and
VLAN-x and one host in both VLAN-y and VLAN-z. RB1 and RB2 are both
attached to this LAN link. RB1 is elected as the Designated RBridge
who is responsible to choose appointed forwarders for the above
VLANs. In the figure, VLAN-w,x are assigned to RB1 and VLAN-y,z are
assigned to RB2. Obviously, this assignment is not balanced, since
the MAC table of RB1 has four entries while the MAC table of RB2 only
has two entries. If the DRB can reassign VLAN-w to RB2 and reassign
VLAN-y to RB1, both RBridges will have three MAC entries, therefore a
more balanced assignment is achieved.
MAC Entries
+-----+
| w |
+-----+
| w | MAC Entries
+-----+ >---+ +-----+
| x | | | y |
+-----+ | +---< +-----+
| x | | | | z |
+-----+ | | +-----+
| |
DRB&AF:w,x | | AF:y,z
+-----+ | | +-----+
| RB1 |-----+ +-----| RB2 |
+-----+ +-----+
| |
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ @
@ +-------+ +-------+ +-------+ +-------+ @
@ |[H] [H]| |[H] [H]| | [H] | | [H] | @
@ +-------+ +-------+ +-------+ +-------+ @
@ VLAN-w VLAN-x VLAN-y VLAN-z @
@ @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
LAN link
Figure 3.1: Unbalanced assignment among VLANs
In order to assign the VLANs in a balanced way, the DRB need to know
the usage of MAC tables of its appointed forwarders. Since RBridges
only store active MAC addresses and a virtual machine can move from
one location to another, MAC entries that a VLAN occupies on an
RBridge varies from time to time. The assignment of VLANs cannot be
done once for all. It is necessary for the DRB to do the assignment
Mingui Zhang Expires April 18, 2014 [Page 6]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
adaptively taking the usage of MAC tables of its appointed forwarders
into consideration.
In Section 5.1, the MAC Entries Report sub-TLV is defined to deliver
this kind of information from a forwarder to a DRB.
4. Load Distribution
The traffic from the TRILL campus to the local LAN link is the
egressing traffic while the traffic from the local LAN link to the
TRILL campus is the ingressing traffic. A forwarder RBridge acts as
both the ingress and egress point of a VLAN's traffic. The assignment
of the appointed forwarder for each VLAN affects both the egress and
ingress traffic load distribution.
4.1. Egress Traffic
One RBridge MAY have multiple ports attached to the same local LAN
link. These ports are called "port group" [RFC6325]. When a DRB
assigns a VLAN to an RBridge, its total available egress bandwidth of
the port group needs to be taken into consideration.
After VLAN-x has been assigned to an RBridge, the forwarding port
assignment of one of the port group to VLAN-x as the forwarding port
is entirely a local matter. Since a LAN link is a STP domain, more
than one forwarding port for one VLAN will cause a loop. The
forwarder MUST assign one and only one port for each VLAN. Load
balancing among multiple ports on the same link can be realized
through splitting the load among different VLANs as suggested in
Section 4.4.4 of [RFC6325].
4.2. Ingress Traffic
After packets enter a TRILL campus from the ingress RBridge, they are
sent through the paths starting at this ingress point. Since the DRB
knows the whole topology of the TRILL campus, it can figure out these
paths as well. Therefore, the DRB should take the available bandwidth
of these paths into consideration when assigning the appointed
forwarder of a VLAN. Any assignment that is possible to congest an
already busy ingress point or a path should be avoided.
Traffic Matrices are usually taken as the input to the traffic
engineering methods [TE]. VLAN assignment actually changes the
Traffic Matrix of a TRILL campus. Therefore, our adaptive VLAN
assignment can work together with traffic engineering methods to
achieve a balanced traffic distribution of the whole network.
However, the design of this kind of cooperative mechanism is out the
scope of this document.
Mingui Zhang Expires April 18, 2014 [Page 7]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
With the TLV defined in Section 5.2, the egressing and ingressing
traffic of an appointed forwarder are reported to its DRB.
5. Feedback Sub-TLVs
The Appointed Forwarders TLV has already been defined in [RFC6326].
With this TLV, the DRB can appoint an RBridge on the local link to be
the forwarder for each VLAN. However, there is no feedback from the
appointed forwarder to notify the DRB whether the assignment is
reasonable. Two sub-TLVs are defined in this section to open the
passageway of feedback.
5.1. MAC Entries Report Sub-TLV
Appointed forwarders use MAC Entries Report sub-TLV to report the
usage of their MAC tables to the DRB. It has the following format:
+-+-+-+-+-+-+-+-+
|Type=MACEtrRep | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DRB Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum MAC Entries | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available MAC Entries | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Entries of VLAN Range (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Entries of VLAN Range (n) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each "MAC Entries of VLAN Range" is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The Number of MAC Entries | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: MAC Entries Report sub-TLV.
o Length: 6+6n bytes, where n is the number of VLANs that the
Mingui Zhang Expires April 18, 2014 [Page 8]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
appointed forwarder selects to report.
o DRB Nickname: The nickname of the Designated RBridge of the local
link.
o Maximum MAC Entries: The maximum number of the entries of the MAC
table of the appointed forwarder.
o Available MAC Entries: The number of available entries of the
appointed forwarder's MAC table.
o RESV: These bits MUST be sent as zero and ignored on receipt.
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
appointment range, inclusive. To specify a single VLAN, the VLAN's
ID appears as both the start and end VLAN [RBissib].
o The Number of MAC Entries: The number of MAC entries occupied by
the given VLAN range. These MAC entries does not only contain the
MAC addresses of hosts on the local link but also includes the MAC
addresses on the remote link in the same VLAN range.
5.2. Traffic Bit Rate Report Sub-TLV
Appointed forwarders use Traffic Bit Rate Report sub-TLV to report
the bandwidth utilization of their ports (or port groups) to the DRB.
This sub-TLV has the following format:
+-+-+-+-+-+-+-+-+
|Type=TrafficRep| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DRB Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Link Bandwidth | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Link Bandwidth | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Bit Rate of VLAN Range (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Bit Rate of VLAN Range (n) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each "Traffic Bit Rate of VLAN Range" is of the form:
Mingui Zhang Expires April 18, 2014 [Page 9]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV|D| Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Bit Rate | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Traffic Bit Rate Report sub-TLV.
o Length: 6+6n bytes, where n is the number of VLANs that the
appointed forwarder selects to report.
o DRB Nickname: The nickname of the Designated RBridge of the local
link.
o Maximum Link Bandwidth: The maximum bandwidth of the port (or port
group) attached to the local link.
o Available Link Bandwidth: The available bandwidth of the port (or
port group) attached to the local link.
o RESV: These bits MUST be sent as zero and ignored on receipt.
o D: The direction of the traffic. Value "0" denotes the egressing
traffic volume and value "1" denotes the ingressing traffic
volume.
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
appointment range, inclusive. To specify a single VLAN, the VLAN's
ID appears as both the start and end VLAN [RBissib].
o Traffic Bit Rate: The traffic bit rate of the given VLAN range
from/to the local link through the attaching ports group of the
appointed forwarder.
6. Adaptive VLAN Assignment
Appointed forwarders MAY advertise the MAC Entries Report Sub-TLV and
Traffic Bit Rate Report Sub-TLV included in Multi-Topology-Aware Port
Capability TLV in LSPs to their DRBs. The number of VLANs in these
TLVs is constrained by the maximum size of HELLO messages which is
1470 octets [RFC6325]. If it is not big enough to hold the
information for all VLANs, appointed forwarders choose VLANs in the
order of most MAC entries first and highest load first to report to
the DRB. An appointed forwarder SHOULD report these two sub-TLVs to
its DRB each time the DRB assigns a VLAN to it. Its adjacency to the
DRB MUST be in Report state [RFC6327]. In order to relieve the burden
Mingui Zhang Expires April 18, 2014 [Page 10]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
of feedback, thresholds MAY be imposed on the report of these sub-
TLVs. For example, when the usage of MAC table increases by 10
percent, the Appointed Forwarder reports the MAC Entries Report Sub-
TLV to its DRB.
The usage of the MAC table and the utilization of bandwidth of this
appointed forwarder is calculated on the DRB. The DRB SHOULD choose
an appointed forwarder for the local link based on Least
Usage/Utilization First (LUF) policy. If an RBridge on the local link
is already overloaded, the DRB should refrain from assigning
additional VLANs to it.
An Appointed Forwarder may fail or get overloaded [RBclear]. The
usage of MAC tables and bandwidth of Appointed Forwarders attached to
a LAN link changes with time elapses and a balanced VLAN assignment
may become unbalanced. For example, the bandwidth of an Appointed
Forwarder may run out of use due to the increase of traffic demand.
The usage of the MAC table of an Appointed Forwarder may change
greatly due to host mobility. In such situations, the DRB need to
modify the appointment of VLANs on a LAN link. The change of
Appointed Forwarder of a VLAN brings service interruption to this
VLAN, therefore the reassignment of VLANs from existing Appointed
Forwarder to a new Appointed Forwarder should be limited.
It has been a common practice to collect MAC table usage in bridge
networks. Through the collection of the above two sub-TLVs (e.g.,
stored in MIB), operators will have a vision of the MAC table usage
and bandwidth utilization of the RBridges on the LAN link. Based on
this vision, operators can easily recognize the hot spot of the TRILL
campus, which facilitates the trouble shooting.
7. Partial VLANs Appointment
[RFC6349] indicates that the appointed VLAN list for one appointed
forwarder sent in an Appointed Forwarders Sub-TLV should be
contiguous. In particular, when the designated VLAN falls in the
range of the appointed VLANs list, the DRB should have two
appointments with contiguous appointed VLAN ranges for one appointed
forwarder. However, on a LAN link, a DRB can flexibly appoint any
VLAN to any appointed forwarder. This flexibility creates the
necessity to allow DRB to have discrete appointments to one appointed
forwarder. The following example shows this necessity and reveals the
issue caused by discrete VLAN appointment.
When enabled VLANs of two RBriges attached to the same link have
intersections, DRB SHOULD guarantee that the sets of VLANs appointed
to these two RBridges do not overlap. With the adaptive VLAN
assignment method defined in this document, the DRB is probably to
Mingui Zhang Expires April 18, 2014 [Page 11]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
discretely assign VLANs of this intersection to achieve load balance
among these two RBridges. Suppose both RB1 and RB2 have enabled the
VLANs from 2 through 4094 on the local link. VLAN 1 is the Designated
VLAN for this link. Suppose RB1 gets all the odd numbered VLANs while
RB2 gets all the even numbered VLANs. The DRB has to use 2046
appointments for RB1 and 2047 appointments for RB2. Since one
appointment consumes 6 octets [RBisisb] and a TRILL-HELLO message
MUST NOT exceed 1470 octets [RFC6325]. Even these octets are all used
for VLAN appointments, a TRILL-HELLO at most contains 245
appointments. The 4093 appointments obviously exceeds the maximum
number of appointments that one TRILL-HELLO can have.
The following two sub-TLVs are defined to enable the DRB to send out
a appointed VLANs list to its appointed forwarders in multiple TRILL-
HELLOs, which is similar as the TRILL Neighbor TLV [RBisisb].
7.1 Partial Appointed Forwarder Sub-TLV
This section defines a sub-TLV adapted from the Appointed Forwarders
sub-TLV [RBisisb]. This sub-TLV can appear in MT-PORT-CAP TLVs of
multiple TRILL-HELLOs.
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|E| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each appointment is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mingui Zhang Expires April 18, 2014 [Page 12]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
o Type: sub-TLV type, set to MT-PORT-CAP ParAppFwdr Sub-TLV TBD.
o Length: 1+6n bytes, where there are n appointments.
o Appointee Nickname: The nickname of the IS being appointed a
forwarder.
o S: Start flag. If this bit is a one, then the first Appointment
Information of this sub-TLV is the first appointment of the
appointed VLANs list sent by the DRB.
o E: End flag. If this bit is a one, then the last Appointment
Information of this sub-TLV is the last appointment of the
appointed VLANs list sent by the DRB.
o R, RESV: These bits are reserved and MUST be sent as zero and
ignored on receipt.
o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
appointment range, inclusive. To specify a single VLAN, the VLAN's
ID appears as both the start and end VLAN. As specified in
[RFC6439], appointing an IS forwarder on a port for a VLAN not
enabled on that port has no effect.
This sub-TLV enables the DRB to send VLAN appointment information in
multiple TRILL-HELLOs without the constraint of the size of a single
TRILL-HELLO. An IS's nickname can occur as an appointed forwarder for
multiple VLAN ranges by occurrences of this sub-TLV within the MT
Port Capability TLV [RBisisb]. However, an IS's nickname SHOULD only
occur as an appointed forwarder within the same TRILL-HELLO.
7.2 Partial VLANs Appointing Sub-TLV
This section defines another sub-TLV adapted from the VLANs Appointed
sub-TLV [RBisisb], which allows DRB to assign lots of VLANs to one
appointed forwarder in a bitmap format. This sub-TLV can appear in
MT-PORT-CAP sub-TLVs of multiple TRILL-HELLOs as well.
Mingui Zhang Expires April 18, 2014 [Page 13]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|S|E| RESV | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-PORT-CAP ParVLANApp Sub-TLV TBD.
o Length: Variable, minimum 6.
o Appointee Nickname: The nickname of the IS being appointed a
forwarder.
o S: Start flag. If this bit is a one, then this is the first
appointment of the appointed VLANs list sent by the DRB.
o E: End flag. If this bit is a one, then this is the last
appointment of the appointed VLANs list sent by the DRB.
o R, RESV: These bits are reserved and MUST be sent as zero and
ignored on receipt.
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high
order bit of the first byte of the VLAN bit-map.
o VLAN bit-map: The highest order bit indicates the VLAN equal to
the start VLAN ID, the next highest bit indicates the VLAN equal
to start VLAN ID + 1, continuing to the end of the VLAN bit-map
field.
In [RBisisb], an appointed forwarder sends the VLANs Appointed Sub-
TLV to its neighbors including the DRB. In this document, the
Partial VLANs Appointing sub-TLV is used by the DRB to assign
multiple discrete VLANs to an appointed forwarder.
A DRB can alternatively pick one of the above two sub-TLVs to send
appointment information to a specific appointed forwarder. However,
it is recommended that the DRB choose the option consuming less
octets in the TRILL-HELLO. In the above example, if the DRB sends out
the appointment using the Partial Appointed Forwarder Sub-TLV, RB1
Mingui Zhang Expires April 18, 2014 [Page 14]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
has 2047 appointments which consumes 2047*6 = 12276 octets. Instead,
if the DRB uses the Partial VLANs Appointing Sub-TLV, it only
consumes 512 octets.
An appointed forwarder begins to accumulate VLAN appointments when it
receives either of the above two sub-TLVs whose first Appointment
Information sets the Start flag to a one. This appointed forwarder
will wait its Holding Time for either a Partial Appointed Forwarders
Sub-TLV or a Partial VLANs Appointing Sub-TLV whose End flag is set
to a one. If that sub-TLV is received before the Holding Timer
expires, the appointed forwarder will issue the accumulated VLAN
appointments. If the sub-TLV whose End flag is a one is not received
before the Holding Timer expires, all these accumulated VLAN
appointments will be discarded.
8. Security Considerations
This document raises no new security issues for IS-IS.
9. IANA Considerations
This document suggests to specify four new Sub-TLVs from existing
sub-TLV sequences -- namely MACEtrRep, TrafficRep, ParAppFwdr and
ParVLANApp.
Section Sub- MT Port Router Extended NUM
TLV# Capabil. Capabil. IS Reach
MACEtrRep 5.1 TBD X - - *
TrafficRep 5.2 TBD X - - *
ParAppFwdr 7.1 TBD X - - *
ParVLANApp 7.1 TBD X - - *
10. Acknowledgements
The authors would like to thank Somnath Chatterjee and Weiguo Hao for
their comments.
11. References
11.1. Normative References
[RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol
Specification", RFC 6325, July 2011.
[RFC6326] D. Eastlake, A. Banerjee, et al, "Transparent
Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC
6326, July 2011.
Mingui Zhang Expires April 18, 2014 [Page 15]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
[RBisisb] D. Eastlake, T. Senevirathne, et al., "Transparent
Interconnection of Lots of Links (TRILL) Use of IS-IS",
draft-ietf-isis-rfc6326bis-01.txt, work in Progress.
[RFC6327] D. Eastlake, R. Perlman, et al, "Routing Bridges
(RBridges): Adjacency", RFC 6327, July 2011.
[RBclear] D. Eastlake, M. Zhang, et al, "TRILL: Clarifications,
Corrections, and Updates", draft-ietf-trill-clear-correct-
06.txt, working in progress.
11.2. Informative References
[CAMtbl] B. Hedlund, "Evolving Data Center Switching",
http://internetworkexpert.s3.amazonaws.com/2010/trill1/
TRILL-intro-part1.pdf
[SAN] "Configuring an iSCSI Storage Area Network Using Brocade
FCX Switches", Brocade CONFIGURATION GUIDE, 2010.
[VL2] A. Greenberg, J.R. Hamilton, et al, "VL2: A scalable and
flexible data center network", in Proceedings of ACM
SIGCOMM, 2009.
[TE] M. Roughan, M. Throup, and Y. Zhang, "Traffic Engineering
with Estimated Traffic Matrices" , in Proceedings of ACM
IMC, 2003.
Mingui Zhang Expires April 18, 2014 [Page 16]
INTERNET-DRAFT Adaptive VLAN Assignment October 15, 2013
Author's Addresses
Mingui Zhang
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.
Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
Beijing 100095 P.R. China
Email: zhangmingui@huawei.com
Dacheng Zhang
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.
Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
Beijing 100095 P.R. China
Email: zhangdacheng@huawei.com
Mingui Zhang Expires April 18, 2014 [Page 17]
