idnits 2.17.1 draft-zhang-trill-vlan-assign-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2013) is 3844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 139, but not defined == Missing Reference: 'CAMtable' is mentioned on line 213, but not defined == Missing Reference: 'H' is mentioned on line 263, but not defined == Missing Reference: 'RBissib' is mentioned on line 453, but not defined == Missing Reference: 'RFC6349' is mentioned on line 504, but not defined == Missing Reference: 'RFC6439' is mentioned on line 587, but not defined ** Obsolete undefined reference: RFC 6439 (Obsoleted by RFC 8139) ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) == Outdated reference: A later version (-03) exists of draft-ietf-isis-rfc6326bis-01 ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Informational Dacheng Zhang 4 Expires: April 18, 2014 Huawei 5 October 15, 2013 7 Adaptive VLAN Assignment for Data Center RBridges 8 draft-zhang-trill-vlan-assign-06.txt 10 Abstract 12 If RBridges are casually assigned as Appointed Forwarders for VLANs 13 without considering the number of MAC addresses and traffic load of 14 these VLANs, it may overload some of the RBridges while leave other 15 RBridges lightly loaded, which reduces the scalability of a RBridge 16 network and undermines its performance. 18 A new mechanism is designed in this document to support the adaptive 19 VLAN assignment (or Appointed Forwarder selection) based on the 20 forwarders' reporting of their usage of MAC tables and available 21 bandwidth. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Data Center RBridge . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. East-West Capacity Increase . . . . . . . . . . . . . . . . 4 66 2.3. Virtualization . . . . . . . . . . . . . . . . . . . . . . 5 67 3. MAC Entries Usage . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Load Distribution . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. Egress Traffic . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. Ingress Traffic . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Feedback Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. MAC Entries Report Sub-TLV . . . . . . . . . . . . . . . . 8 73 5.2. Traffic Bit Rate Report Sub-TLV . . . . . . . . . . . . . . 9 74 6. Adaptive VLAN Assignment . . . . . . . . . . . . . . . . . . . 10 75 7. Partial VLANs Appointment . . . . . . . . . . . . . . . . . . . 11 76 7.1 Partial Appointed Forwarder Sub-TLV . . . . . . . . . . . . 12 77 7.2 Partial VLANs Appointing Sub-TLV . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 15 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 84 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 The scales of Data Center Networks (DCNs) are expanding rapidly these 89 years. In DCNs, Ethernet switches and bridges are abundantly used for 90 the interconnection of servers. The plug-and-play feature and the 91 simple management and configuration of Ethernet are appealing to DCN 92 providers. A whole DCN can be a simple large layer 2 Ethernet which 93 is either built on a real network or on a virtual platform. 95 Cloud Computing is growing up from DCNs which can be regarded as a 96 virtual platform that provides the reuse of the network resources of 97 DCNs. A lot of cloud applications have been developed by DCN 98 providers, such as Amazon's Elastic Compute Cloud (EC2), Akamai's 99 Application Delivery Network (ADN) and Microsoft's Azure. Cloud 100 Computing clearly brings new challenges to the traditional Ethernet. 101 The scales of the DCNs are becoming too large to be carried on the 102 traditional Ethernet. The valuable MAC-tables of the bridges are 103 running out of use for storing millions of MAC addresses. The 104 broadcast of ARP messages consumes too much bandwidth and computing 105 resources. The mobility of end stations brings dynamics to the 106 network which can become a heavy burden if the management and 107 configuration of the network involves too much manpower. The Spanning 108 Tree Protocol used in the traditional Ethernet is becoming outdated 109 since there is only a single viable path on the tree for a node pair 110 and this path is not always the best path (e.g., shortest path). 112 RBridges are designed to improve the shortcomings of the traditional 113 Ethernet. To make use of the rich connections, RBridges introduce 114 multi-pathing to the Ethernet to break the single-path constraint of 115 STP. Multiple points of attachment is a basic feature supported by 116 RBridges and common for Data Center Bridges. This feature not only 117 increases the "east-west" capacity but also greatly enhances the 118 reliability of DCNs [VL2] [SAN]. If several RBridges are attached to 119 a bridged LAN link at the same time, the DRB is responsible for the 120 assignment of a VLAN to one of the RBridges as the Appointed 121 forwarder. However, VLAN assignment is currently done in an one-way 122 manner. The DRB casually assigns a VLAN to an RBridge attached to the 123 local link without knowing its available MAC-table entries or 124 bandwidth. The appointed forwarder does not feedback the utilization 125 of its MAC-table or bandwidth either. 127 This document proposes to balance the load among VLANs. Two types of 128 sub-TLVs are defined, with which a forwarder can report its MAC 129 entries and traffic bit rate respectively. By gathering these report 130 messages, the VLAN assignment can be done in a way that the usage of 131 the MAC tables and bandwidth of the attached RBridges are balanced 132 among VLANs. 134 1.1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Data Center RBridge 142 Data Center Networks grow rapidly. Ethernet is widely used in data 143 centers because of its simple management and plug-and-play features. 144 However, there are shortcomings of Ethernet. RBridges are designed to 145 improve these shortcomings. In this section, we analyze the 146 characteristics of DCNs that impact the design of RBridges and reveal 147 why the adaptive VLAN assignment is important for RBridges to be used 148 in DCNs. 150 2.1. Scalability 152 In the past years, a large DCN is typically composed of tens of 153 thousands servers interconnected through switches. In the cloud 154 computing era, there can be as many as millions of servers in one 155 DCN. The management of the massive MAC addresses of the servers on 156 the layer2 devices will become more and more complex. RBridges are 157 used to replace the traditional bridges. 159 Valuable CAM-tables on RBridges can easily be used up if they are not 160 used reasonably [CAMtbl]. For RBridges to be widely used in DCNs, the 161 VLANs should be assigned to the RBridges in a manner that MAC entries 162 of VLANs on RBridges are balanced. 164 2.2. East-West Capacity Increase 166 The Spanning Tree Protocol (STP) in the traditional LAN blocks some 167 ports of bridges for the purpose of loop avoidance. The side-effects 168 of STP are obvious. The link bandwidth attached to the blocked ports 169 are not utilized which greatly wastes the capacity of the network. On 170 the tree topology, the communication between the bridges of the left 171 branch and right branch must transit the single root bridge, which 172 forms a "hair-pin turn". 174 With the rapid increase of the amount of servers in DCNs and their 175 traffic demand, it is urgent to break the constraint of STP and 176 enhance the "east-west" capacity of DCNs which are always richly 177 connected. RBridges use the multi-path routing to set up the data 178 plane of a TRILL campus. Multiple RBridges may be attached to a same 179 LAN link, which offers multiple access points to the LAN link. The 180 hosts on this LAN link is therefore multi-homed to a TRILL campus. 181 All the attached RBridges can act as packet forwarders for VLANs 182 carried on this LAN link. In the worst case, all the VLANs are 183 assigned to a single RBridge. Under this scenario, the ingress 184 capacity on other RBridges is wasted. It is necessary to balance the 185 traffic load of VLANs among these RBridges through the assignment of 186 VLANs. 188 2.3. Virtualization 190 Virtualization is important for increasing the utilization of network 191 resources in DCNs. For example, the VPNs can be used to separate the 192 traffic from different services therefore they can be carried on the 193 same pool of resources. When the VPNs is carried over a TRILL campus, 194 RBridges can use a VLAN tag to identify each VPN. However, the use of 195 VLANs multiplies the entries in the MAC table of RBridges. 197 Virtual Machines (VM) are widely used in DCNs. A physical host can 198 support tens of VMs and each VM has to be identified by one MAC 199 address that is need to be stored in MAC tables of RBridges. This 200 seriously increases the number of MAC entries in RBridges. Moreover, 201 the number of VMs in a VLAN is not necessarily equal to the number of 202 physical hosts. VMs are spawned or destroyed based on the demand of 203 applications. They can also migrate from one location to another, 204 which may be either an in-service or out-of-service move. VMs bring 205 about the volatility of the size of VLANs. It is hard to provide one 206 static VLAN assignment for a TRILL campus based on the numbers of 207 physical hosts of VLANs that is proper for all applications all the 208 time. 210 3. MAC Entries Usage 212 A CAM-table on a switch is expensive, which is a major constraint on 213 the scalability of Ethernet [CAMtable]. When an RBridge is used to 214 connect lots of hosts in large Data Center Networks, the entries of 215 the CAM-table can easily be used up. The network should be tactically 216 interconnected and valuable MAC table entries should be used 217 economically. 219 RBridges support multiple points of attachment [RFC6325]. When 220 RBridges are used in a DCN to form a TRILL campus, a LAN link MAY 221 have multiple access points to this campus. All these access RBridges 222 are able to act as the packet forwarder of VLANs carried on this LAN 223 link. The DRB of this LAN link is responsible to pick out one RBridge 224 attached to this LAN link as the appointed forwarder for each VLAN-x. 225 In other words, the DRB assigns VLAN-x to one of the RBridge. For an 226 assigned VLAN, its forwarder is not only responsible for forwarding 227 the packets for this VLAN but also need to store active MAC addresses 228 of hosts on this VLAN. 230 If VLANs on a LAN link are not appointed properly, some RBridges's 231 MAC tables are easily to be used up while other RBridges are left 232 idle. Take Figure 3.1 as an example, there are four VLANs carried on 233 the LAN link: w, x, y and z. There are two hosts in both VLAN-w and 234 VLAN-x and one host in both VLAN-y and VLAN-z. RB1 and RB2 are both 235 attached to this LAN link. RB1 is elected as the Designated RBridge 236 who is responsible to choose appointed forwarders for the above 237 VLANs. In the figure, VLAN-w,x are assigned to RB1 and VLAN-y,z are 238 assigned to RB2. Obviously, this assignment is not balanced, since 239 the MAC table of RB1 has four entries while the MAC table of RB2 only 240 has two entries. If the DRB can reassign VLAN-w to RB2 and reassign 241 VLAN-y to RB1, both RBridges will have three MAC entries, therefore a 242 more balanced assignment is achieved. 244 MAC Entries 245 +-----+ 246 | w | 247 +-----+ 248 | w | MAC Entries 249 +-----+ >---+ +-----+ 250 | x | | | y | 251 +-----+ | +---< +-----+ 252 | x | | | | z | 253 +-----+ | | +-----+ 254 | | 255 DRB&AF:w,x | | AF:y,z 256 +-----+ | | +-----+ 257 | RB1 |-----+ +-----| RB2 | 258 +-----+ +-----+ 259 | | 260 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 261 @ @ 262 @ +-------+ +-------+ +-------+ +-------+ @ 263 @ |[H] [H]| |[H] [H]| | [H] | | [H] | @ 264 @ +-------+ +-------+ +-------+ +-------+ @ 265 @ VLAN-w VLAN-x VLAN-y VLAN-z @ 266 @ @ 267 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 268 LAN link 270 Figure 3.1: Unbalanced assignment among VLANs 272 In order to assign the VLANs in a balanced way, the DRB need to know 273 the usage of MAC tables of its appointed forwarders. Since RBridges 274 only store active MAC addresses and a virtual machine can move from 275 one location to another, MAC entries that a VLAN occupies on an 276 RBridge varies from time to time. The assignment of VLANs cannot be 277 done once for all. It is necessary for the DRB to do the assignment 278 adaptively taking the usage of MAC tables of its appointed forwarders 279 into consideration. 281 In Section 5.1, the MAC Entries Report sub-TLV is defined to deliver 282 this kind of information from a forwarder to a DRB. 284 4. Load Distribution 286 The traffic from the TRILL campus to the local LAN link is the 287 egressing traffic while the traffic from the local LAN link to the 288 TRILL campus is the ingressing traffic. A forwarder RBridge acts as 289 both the ingress and egress point of a VLAN's traffic. The assignment 290 of the appointed forwarder for each VLAN affects both the egress and 291 ingress traffic load distribution. 293 4.1. Egress Traffic 295 One RBridge MAY have multiple ports attached to the same local LAN 296 link. These ports are called "port group" [RFC6325]. When a DRB 297 assigns a VLAN to an RBridge, its total available egress bandwidth of 298 the port group needs to be taken into consideration. 300 After VLAN-x has been assigned to an RBridge, the forwarding port 301 assignment of one of the port group to VLAN-x as the forwarding port 302 is entirely a local matter. Since a LAN link is a STP domain, more 303 than one forwarding port for one VLAN will cause a loop. The 304 forwarder MUST assign one and only one port for each VLAN. Load 305 balancing among multiple ports on the same link can be realized 306 through splitting the load among different VLANs as suggested in 307 Section 4.4.4 of [RFC6325]. 309 4.2. Ingress Traffic 311 After packets enter a TRILL campus from the ingress RBridge, they are 312 sent through the paths starting at this ingress point. Since the DRB 313 knows the whole topology of the TRILL campus, it can figure out these 314 paths as well. Therefore, the DRB should take the available bandwidth 315 of these paths into consideration when assigning the appointed 316 forwarder of a VLAN. Any assignment that is possible to congest an 317 already busy ingress point or a path should be avoided. 319 Traffic Matrices are usually taken as the input to the traffic 320 engineering methods [TE]. VLAN assignment actually changes the 321 Traffic Matrix of a TRILL campus. Therefore, our adaptive VLAN 322 assignment can work together with traffic engineering methods to 323 achieve a balanced traffic distribution of the whole network. 324 However, the design of this kind of cooperative mechanism is out the 325 scope of this document. 327 With the TLV defined in Section 5.2, the egressing and ingressing 328 traffic of an appointed forwarder are reported to its DRB. 330 5. Feedback Sub-TLVs 332 The Appointed Forwarders TLV has already been defined in [RFC6326]. 333 With this TLV, the DRB can appoint an RBridge on the local link to be 334 the forwarder for each VLAN. However, there is no feedback from the 335 appointed forwarder to notify the DRB whether the assignment is 336 reasonable. Two sub-TLVs are defined in this section to open the 337 passageway of feedback. 339 5.1. MAC Entries Report Sub-TLV 341 Appointed forwarders use MAC Entries Report sub-TLV to report the 342 usage of their MAC tables to the DRB. It has the following format: 344 +-+-+-+-+-+-+-+-+ 345 |Type=MACEtrRep | (1 byte) 346 +-+-+-+-+-+-+-+-+ 347 | Length | (1 byte) 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | DRB Nickname | (2 bytes) 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Maximum MAC Entries | (2 bytes) 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Available MAC Entries | (2 bytes) 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | MAC Entries of VLAN Range (1) | (6 bytes) 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | ...... | (6 bytes) 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | MAC Entries of VLAN Range (n) | (6 bytes) 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 where each "MAC Entries of VLAN Range" is of the form: 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | RESV | Start.VLAN | (2 bytes) 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | RESV | End.VLAN | (2 bytes) 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | The Number of MAC Entries | (2 bytes) 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 o Type: MAC Entries Report sub-TLV. 374 o Length: 6+6n bytes, where n is the number of VLANs that the 375 appointed forwarder selects to report. 377 o DRB Nickname: The nickname of the Designated RBridge of the local 378 link. 380 o Maximum MAC Entries: The maximum number of the entries of the MAC 381 table of the appointed forwarder. 383 o Available MAC Entries: The number of available entries of the 384 appointed forwarder's MAC table. 386 o RESV: These bits MUST be sent as zero and ignored on receipt. 388 o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 389 appointment range, inclusive. To specify a single VLAN, the VLAN's 390 ID appears as both the start and end VLAN [RBissib]. 392 o The Number of MAC Entries: The number of MAC entries occupied by 393 the given VLAN range. These MAC entries does not only contain the 394 MAC addresses of hosts on the local link but also includes the MAC 395 addresses on the remote link in the same VLAN range. 397 5.2. Traffic Bit Rate Report Sub-TLV 399 Appointed forwarders use Traffic Bit Rate Report sub-TLV to report 400 the bandwidth utilization of their ports (or port groups) to the DRB. 401 This sub-TLV has the following format: 403 +-+-+-+-+-+-+-+-+ 404 |Type=TrafficRep| (1 byte) 405 +-+-+-+-+-+-+-+-+ 406 | Length | (1 byte) 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | DRB Nickname | (2 bytes) 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Maximum Link Bandwidth | (2 bytes) 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Available Link Bandwidth | (2 bytes) 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Traffic Bit Rate of VLAN Range (1) | (6 bytes) 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | ...... | (6 bytes) 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Traffic Bit Rate of VLAN Range (n) | (6 bytes) 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where each "Traffic Bit Rate of VLAN Range" is of the form: 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | RESV|D| Start.VLAN | (2 bytes) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | RESV | End.VLAN | (2 bytes) 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Traffic Bit Rate | (2 bytes) 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 o Type: Traffic Bit Rate Report sub-TLV. 433 o Length: 6+6n bytes, where n is the number of VLANs that the 434 appointed forwarder selects to report. 436 o DRB Nickname: The nickname of the Designated RBridge of the local 437 link. 439 o Maximum Link Bandwidth: The maximum bandwidth of the port (or port 440 group) attached to the local link. 442 o Available Link Bandwidth: The available bandwidth of the port (or 443 port group) attached to the local link. 445 o RESV: These bits MUST be sent as zero and ignored on receipt. 447 o D: The direction of the traffic. Value "0" denotes the egressing 448 traffic volume and value "1" denotes the ingressing traffic 449 volume. 451 o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 452 appointment range, inclusive. To specify a single VLAN, the VLAN's 453 ID appears as both the start and end VLAN [RBissib]. 455 o Traffic Bit Rate: The traffic bit rate of the given VLAN range 456 from/to the local link through the attaching ports group of the 457 appointed forwarder. 459 6. Adaptive VLAN Assignment 461 Appointed forwarders MAY advertise the MAC Entries Report Sub-TLV and 462 Traffic Bit Rate Report Sub-TLV included in Multi-Topology-Aware Port 463 Capability TLV in LSPs to their DRBs. The number of VLANs in these 464 TLVs is constrained by the maximum size of HELLO messages which is 465 1470 octets [RFC6325]. If it is not big enough to hold the 466 information for all VLANs, appointed forwarders choose VLANs in the 467 order of most MAC entries first and highest load first to report to 468 the DRB. An appointed forwarder SHOULD report these two sub-TLVs to 469 its DRB each time the DRB assigns a VLAN to it. Its adjacency to the 470 DRB MUST be in Report state [RFC6327]. In order to relieve the burden 471 of feedback, thresholds MAY be imposed on the report of these sub- 472 TLVs. For example, when the usage of MAC table increases by 10 473 percent, the Appointed Forwarder reports the MAC Entries Report Sub- 474 TLV to its DRB. 476 The usage of the MAC table and the utilization of bandwidth of this 477 appointed forwarder is calculated on the DRB. The DRB SHOULD choose 478 an appointed forwarder for the local link based on Least 479 Usage/Utilization First (LUF) policy. If an RBridge on the local link 480 is already overloaded, the DRB should refrain from assigning 481 additional VLANs to it. 483 An Appointed Forwarder may fail or get overloaded [RBclear]. The 484 usage of MAC tables and bandwidth of Appointed Forwarders attached to 485 a LAN link changes with time elapses and a balanced VLAN assignment 486 may become unbalanced. For example, the bandwidth of an Appointed 487 Forwarder may run out of use due to the increase of traffic demand. 488 The usage of the MAC table of an Appointed Forwarder may change 489 greatly due to host mobility. In such situations, the DRB need to 490 modify the appointment of VLANs on a LAN link. The change of 491 Appointed Forwarder of a VLAN brings service interruption to this 492 VLAN, therefore the reassignment of VLANs from existing Appointed 493 Forwarder to a new Appointed Forwarder should be limited. 495 It has been a common practice to collect MAC table usage in bridge 496 networks. Through the collection of the above two sub-TLVs (e.g., 497 stored in MIB), operators will have a vision of the MAC table usage 498 and bandwidth utilization of the RBridges on the LAN link. Based on 499 this vision, operators can easily recognize the hot spot of the TRILL 500 campus, which facilitates the trouble shooting. 502 7. Partial VLANs Appointment 504 [RFC6349] indicates that the appointed VLAN list for one appointed 505 forwarder sent in an Appointed Forwarders Sub-TLV should be 506 contiguous. In particular, when the designated VLAN falls in the 507 range of the appointed VLANs list, the DRB should have two 508 appointments with contiguous appointed VLAN ranges for one appointed 509 forwarder. However, on a LAN link, a DRB can flexibly appoint any 510 VLAN to any appointed forwarder. This flexibility creates the 511 necessity to allow DRB to have discrete appointments to one appointed 512 forwarder. The following example shows this necessity and reveals the 513 issue caused by discrete VLAN appointment. 515 When enabled VLANs of two RBriges attached to the same link have 516 intersections, DRB SHOULD guarantee that the sets of VLANs appointed 517 to these two RBridges do not overlap. With the adaptive VLAN 518 assignment method defined in this document, the DRB is probably to 519 discretely assign VLANs of this intersection to achieve load balance 520 among these two RBridges. Suppose both RB1 and RB2 have enabled the 521 VLANs from 2 through 4094 on the local link. VLAN 1 is the Designated 522 VLAN for this link. Suppose RB1 gets all the odd numbered VLANs while 523 RB2 gets all the even numbered VLANs. The DRB has to use 2046 524 appointments for RB1 and 2047 appointments for RB2. Since one 525 appointment consumes 6 octets [RBisisb] and a TRILL-HELLO message 526 MUST NOT exceed 1470 octets [RFC6325]. Even these octets are all used 527 for VLAN appointments, a TRILL-HELLO at most contains 245 528 appointments. The 4093 appointments obviously exceeds the maximum 529 number of appointments that one TRILL-HELLO can have. 531 The following two sub-TLVs are defined to enable the DRB to send out 532 a appointed VLANs list to its appointed forwarders in multiple TRILL- 533 HELLOs, which is similar as the TRILL Neighbor TLV [RBisisb]. 535 7.1 Partial Appointed Forwarder Sub-TLV 537 This section defines a sub-TLV adapted from the Appointed Forwarders 538 sub-TLV [RBisisb]. This sub-TLV can appear in MT-PORT-CAP TLVs of 539 multiple TRILL-HELLOs. 541 +-+-+-+-+-+-+-+-+ 542 | Type | (1 byte) 543 +-+-+-+-+-+-+-+-+ 544 | Length | (1 byte) 545 +-+-+-+-+-+-+-+-+ 546 |S|E| RESV | (1 byte) 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Appointment Information (1) | (6 bytes) 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Appointment Information (2) | (6 bytes) 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | ................. | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Appointment Information (N) | (6 bytes) 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 where each appointment is of the form: 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Appointee Nickname | (2 bytes) 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | RESV | Start.VLAN | (2 bytes) 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | RESV | End.VLAN | (2 bytes) 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 o Type: sub-TLV type, set to MT-PORT-CAP ParAppFwdr Sub-TLV TBD. 568 o Length: 1+6n bytes, where there are n appointments. 570 o Appointee Nickname: The nickname of the IS being appointed a 571 forwarder. 573 o S: Start flag. If this bit is a one, then the first Appointment 574 Information of this sub-TLV is the first appointment of the 575 appointed VLANs list sent by the DRB. 577 o E: End flag. If this bit is a one, then the last Appointment 578 Information of this sub-TLV is the last appointment of the 579 appointed VLANs list sent by the DRB. 581 o R, RESV: These bits are reserved and MUST be sent as zero and 582 ignored on receipt. 584 o Start.VLAN, End.VLAN: These fields are the VLAN IDs of the 585 appointment range, inclusive. To specify a single VLAN, the VLAN's 586 ID appears as both the start and end VLAN. As specified in 587 [RFC6439], appointing an IS forwarder on a port for a VLAN not 588 enabled on that port has no effect. 590 This sub-TLV enables the DRB to send VLAN appointment information in 591 multiple TRILL-HELLOs without the constraint of the size of a single 592 TRILL-HELLO. An IS's nickname can occur as an appointed forwarder for 593 multiple VLAN ranges by occurrences of this sub-TLV within the MT 594 Port Capability TLV [RBisisb]. However, an IS's nickname SHOULD only 595 occur as an appointed forwarder within the same TRILL-HELLO. 597 7.2 Partial VLANs Appointing Sub-TLV 599 This section defines another sub-TLV adapted from the VLANs Appointed 600 sub-TLV [RBisisb], which allows DRB to assign lots of VLANs to one 601 appointed forwarder in a bitmap format. This sub-TLV can appear in 602 MT-PORT-CAP sub-TLVs of multiple TRILL-HELLOs as well. 604 +-+-+-+-+-+-+-+-+ 605 | Type | (1 byte) 606 +-+-+-+-+-+-+-+-+ 607 | Length | (1 byte) 608 +-+-+-+-+-+-+-+-+ 609 |S|E| RESV | (1 byte) 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Appointee Nickname | (2 bytes) 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | RESV | Start VLAN ID | (2 bytes) 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | VLAN bit-map.... 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 o Type: sub-TLV type, set to MT-PORT-CAP ParVLANApp Sub-TLV TBD. 620 o Length: Variable, minimum 6. 622 o Appointee Nickname: The nickname of the IS being appointed a 623 forwarder. 625 o S: Start flag. If this bit is a one, then this is the first 626 appointment of the appointed VLANs list sent by the DRB. 628 o E: End flag. If this bit is a one, then this is the last 629 appointment of the appointed VLANs list sent by the DRB. 631 o R, RESV: These bits are reserved and MUST be sent as zero and 632 ignored on receipt. 634 o Start VLAN ID: The 12-bit VLAN ID that is represented by the high 635 order bit of the first byte of the VLAN bit-map. 637 o VLAN bit-map: The highest order bit indicates the VLAN equal to 638 the start VLAN ID, the next highest bit indicates the VLAN equal 639 to start VLAN ID + 1, continuing to the end of the VLAN bit-map 640 field. 642 In [RBisisb], an appointed forwarder sends the VLANs Appointed Sub- 643 TLV to its neighbors including the DRB. In this document, the 644 Partial VLANs Appointing sub-TLV is used by the DRB to assign 645 multiple discrete VLANs to an appointed forwarder. 647 A DRB can alternatively pick one of the above two sub-TLVs to send 648 appointment information to a specific appointed forwarder. However, 649 it is recommended that the DRB choose the option consuming less 650 octets in the TRILL-HELLO. In the above example, if the DRB sends out 651 the appointment using the Partial Appointed Forwarder Sub-TLV, RB1 652 has 2047 appointments which consumes 2047*6 = 12276 octets. Instead, 653 if the DRB uses the Partial VLANs Appointing Sub-TLV, it only 654 consumes 512 octets. 656 An appointed forwarder begins to accumulate VLAN appointments when it 657 receives either of the above two sub-TLVs whose first Appointment 658 Information sets the Start flag to a one. This appointed forwarder 659 will wait its Holding Time for either a Partial Appointed Forwarders 660 Sub-TLV or a Partial VLANs Appointing Sub-TLV whose End flag is set 661 to a one. If that sub-TLV is received before the Holding Timer 662 expires, the appointed forwarder will issue the accumulated VLAN 663 appointments. If the sub-TLV whose End flag is a one is not received 664 before the Holding Timer expires, all these accumulated VLAN 665 appointments will be discarded. 667 8. Security Considerations 669 This document raises no new security issues for IS-IS. 671 9. IANA Considerations 673 This document suggests to specify four new Sub-TLVs from existing 674 sub-TLV sequences -- namely MACEtrRep, TrafficRep, ParAppFwdr and 675 ParVLANApp. 677 Section Sub- MT Port Router Extended NUM 678 TLV# Capabil. Capabil. IS Reach 679 MACEtrRep 5.1 TBD X - - * 680 TrafficRep 5.2 TBD X - - * 681 ParAppFwdr 7.1 TBD X - - * 682 ParVLANApp 7.1 TBD X - - * 684 10. Acknowledgements 686 The authors would like to thank Somnath Chatterjee and Weiguo Hao for 687 their comments. 689 11. References 691 11.1. Normative References 693 [RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol 694 Specification", RFC 6325, July 2011. 696 [RFC6326] D. Eastlake, A. Banerjee, et al, "Transparent 697 Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 698 6326, July 2011. 700 [RBisisb] D. Eastlake, T. Senevirathne, et al., "Transparent 701 Interconnection of Lots of Links (TRILL) Use of IS-IS", 702 draft-ietf-isis-rfc6326bis-01.txt, work in Progress. 704 [RFC6327] D. Eastlake, R. Perlman, et al, "Routing Bridges 705 (RBridges): Adjacency", RFC 6327, July 2011. 707 [RBclear] D. Eastlake, M. Zhang, et al, "TRILL: Clarifications, 708 Corrections, and Updates", draft-ietf-trill-clear-correct- 709 06.txt, working in progress. 711 11.2. Informative References 713 [CAMtbl] B. Hedlund, "Evolving Data Center Switching", 714 http://internetworkexpert.s3.amazonaws.com/2010/trill1/ 715 TRILL-intro-part1.pdf 717 [SAN] "Configuring an iSCSI Storage Area Network Using Brocade 718 FCX Switches", Brocade CONFIGURATION GUIDE, 2010. 720 [VL2] A. Greenberg, J.R. Hamilton, et al, "VL2: A scalable and 721 flexible data center network", in Proceedings of ACM 722 SIGCOMM, 2009. 724 [TE] M. Roughan, M. Throup, and Y. Zhang, "Traffic Engineering 725 with Estimated Traffic Matrices" , in Proceedings of ACM 726 IMC, 2003. 728 Author's Addresses 730 Mingui Zhang 731 Huawei Technologies Co.,Ltd 732 Huawei Building, No.156 Beiqing Rd. 733 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 734 Beijing 100095 P.R. China 736 Email: zhangmingui@huawei.com 738 Dacheng Zhang 739 Huawei Technologies Co.,Ltd 740 Huawei Building, No.156 Beiqing Rd. 741 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 742 Beijing 100095 P.R. China 744 Email: zhangdacheng@huawei.com