idnits 2.17.1 draft-mackcrane-armd-ipv6-nd-scaling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 12, 2010) is 4943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ADDRCONF' is mentioned on line 228, but not defined == Unused Reference: 'RFC4861' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 341, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group B. Mack-Crane 2 Internet Draft L. Dunbar 3 Intended status: Informational S. Hares 4 Expires: April 2011 Huawei 6 October 12, 2010 8 IPv6 Neighbor Discovery Scalability for Large Data Centers 9 draft-mackcrane-armd-ipv6-nd-scaling-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 12, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the BSD License. 49 Abstract 51 Server virtualization allows one physical server to support many 52 virtual machines (VMs) so that multiple hosts (20, 30, or hundreds) 53 can be running from one physical platform. As virtual machines are 54 introduced into a Data Center, the number of hosts within the data 55 center can grow dramatically, which can have tremendous impact on the 56 network and hosts. 58 This document provides an analysis of the scalability of IPv6 59 Neighbor Discovery (RFC 4861) in data centers with a large number of 60 virtual machines. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC-2119 0. 68 Table of Contents 70 1. Introduction................................................3 71 2. Network functions provided by IPv6 Neighbor Discovery.........3 72 3. Basic ND protocol message use................................4 73 3.1. Router Solicitation.....................................4 74 3.2. Router Advertisement....................................4 75 3.3. Neighbor Solicitation...................................5 76 3.4. Neighbor Advertisement..................................5 77 3.5. Redirect...............................................5 78 4. Some additional protocol activities..........................5 79 4.1. Duplicate Address Detection.............................5 80 4.2. Anycast and Proxy address resolution....................6 81 4.3. Neighbor unreachability detection.......................6 82 4.4. Host-based Load Spreading...............................6 83 4.5. Router-based Load Spreading.............................6 84 4.6. Holding packets while address resolution occurs..........7 85 5. Summary and conclusions......................................7 86 6. Manageability Considerations.................................7 87 7. Security Considerations......................................7 88 8. IANA Considerations.........................................8 89 9. Acknowledgments.............................................8 90 10. References.................................................8 91 Authors' Addresses.............................................8 92 Intellectual Property Statement.................................9 93 Disclaimer of Validity.........................................9 95 1. Introduction 97 Server virtualization allows the sharing of the underlying physical 98 machine (server) resources among multiple virtual machines (VMs), 99 each running its own operating system. While Server Virtualization is 100 a great technology for flexible management of server resources, it 101 does impose great challenges to networks which interconnect all the 102 servers in data center(s). Large data centers may grow to support 103 hundreds of thousands or even millions of hosts (VMs). Even though 104 there may be enough link bandwidth to support the traffic volume from 105 all those VMs, other issues associated with Layer 2, like frequent 106 ARP broadcast by hosts, broadcast unknown, etc., can create problems 107 for the network and hosts. 109 This document presents an initial analysis of the scalability of IPv6 110 Neighbor Discovery (RFC 4861) protocols in the context of a large 111 data center network. Two network cases are considered: 1) a single 112 L2 VLAN connecting a very large number of hosts and a relatively 113 small number of routers, and 2) a core VLAN connecting a large number 114 of routers and few, if any, hosts. The analysis presented here is a 115 rough assessment of which protocol behaviors should scale well and 116 which may present some concern. It does not provide hard numbers and 117 is not based on any measurements in live networks. 119 2. Network functions provided by IPv6 Neighbor Discovery 121 The protocols described in RFC 4861 provide a variety of network 122 functions used by IPv6 nodes to: 124 - find routers and discover link and network parameters, 126 - discover each other's presence, 128 - determine each other's link-layer addresses, and 130 - maintain information about the paths to active neighbors. 132 These functions are accomplished using five ICMP messages: 134 - Router Solicitation, 136 - Router Advertisement, 138 - Neighbor Solicitation, 139 - Neighbor Advertisement, and 141 - Redirect. 143 The first part of the analysis considers the basic ND protocol 144 activities and how often each message is sent and to what L2 145 destination address to determine whether there is any concern that ND 146 messages could take too much bandwidth or tax host processors with 147 unnecessary work. 149 The second part of the analysis considers whether there may be 150 scalability concerns related to other protocol behaviors mentioned in 151 RFC 4861 for ancillary purposes, for example duplicate address 152 detection. 154 3. Basic ND protocol message use 156 3.1. Router Solicitation 158 The Router Solicitation message is sent by nodes to discover routers 159 on the LAN, effectively requesting routers to respond to the node 160 with a Router Advertisement message. This message is sent to the 161 all-routers multicast address and so is not seen by other hosts on 162 the LAN. 164 A Router Solicitation message is generally sent when a node is first 165 attached to (or comes up on) the LAN. The frequency of these events 166 should be low and so both the traffic and processing load for Router 167 Solicitation messages is expected to be negligible. 169 3.2. Router Advertisement 171 Router Advertisement messages are sent by routers periodically to the 172 all-nodes multicast address to announce their presence on the LAN and 173 advertise some link parameters. As long as there are not very many 174 routers on the LAN this should not present much traffic or processing 175 load. In the core case where the LAN is connecting many routers the 176 traffic and processing load will increase with the number of routers 177 and some measures may be needed to limit the traffic, either by 178 reducing the transmission rate or disabling the protocol (if it is 179 not needed in an all-router environment). 181 Router Advertisement is also unicast to the requesting node in 182 response to a Router Solicitation message and, as noted above, this 183 should not present a significant load. 185 3.3. Neighbor Solicitation 187 A Neighbor Solicitation message is sent by a node when that node has 188 no (or a stale) cache entry for the L2 address for a particular next 189 hop IPv6 address. This message is sent to a solicited-node multicast 190 address which is manufactured from the next hop IPv6 address. A 191 great advantage of using a solicited-node multicast address is that 192 only the solicited neighbor node (or perhaps a very few more) will be 193 subscribed to this address. Therefore the processing load for this 194 message is restricted to a small number of nodes and is not likely to 195 present a significant burden. 197 In general the frequency of Neighbor Solicitation messages will be 198 related to the number of each node's communicating peers on the LAN. 199 Since this number is directly related to the amount of traffic the 200 LAN must support for communications in general the fraction consumed 201 by Neighbor Solicitation should be very small. 203 3.4. Neighbor Advertisement 205 Neighbor Advertisement messages are sent in response to Neighbor 206 Solicitation messages. They are unicast to the originator of the 207 Neighbor Solicitation message and so the load presented in this case 208 should, as with Neighbor Solicitation, be a small fraction of the 209 traffic that must be supported on the LAN. 211 Unsolicited Neighbor Advertisement messages may also be sent to the 212 all-nodes multicast address; however, as this may be done when a 213 nodes L2 address changes the frequency of these messages should be 214 extremely low. 216 3.5. Redirect 218 Redirect messages are sent by routers to nodes to change the next hop 219 that node is using to reach a particular destination. Although the 220 likelihood of redirect depends on the network topology and other 221 factors, it is not expected to present a significant load on either 222 the network or hosts. 224 4. Some additional protocol activities 226 4.1. Duplicate Address Detection 228 Duplicate address detection as described in [ADDRCONF] involves 229 sending a number of Neighbor Solicitation messages for the address to 230 be checked (to that address's solicited-node multicast address). 231 This is done before attempting to join the LAN using the address 232 being checked. Since this is an initialization procedure it is not 233 expected to present a significant traffic or processing load during 234 normal operation. It is also possible that address autoconfiguration 235 will not be used in very large data centers. 237 4.2. Anycast and Proxy address resolution 239 Address resolution for Anycast addresses or addresses for which nodes 240 are acting as a Proxy may solicit multiple Neighbor Advertisement 241 messages in response. In this case of Anycast addresses the 242 responses are sent with random delay do that the requesting node does 243 not see an unmanageable burst of responses. The response traffic in 244 this case may be greater but not likely a problem, and the additional 245 processing load is only on the requesting node (which is in control 246 of the rate of solicitation). 248 In a multi-site data center network it may be desirable to restrict 249 the propagation of Anycast address resolution messages if it is 250 desired that only responses local to the requesting node's site be 251 delivered. 253 4.3. Neighbor unreachability detection 255 Neighbor unreachability detection relies on hints from higher layers 256 to determine whether or not a given neighbor is still reachable. In 257 some cases when connectivity is suspect and no higher layer hints are 258 available, a Neighbor Solicitation message may be used to verify 259 continued connectivity. This is not expected to be a common 260 occurrence between hosts or hosts and routers (since higher layer 261 hints are most likely available). Between routers there may not be 262 higher layer hints available but there are likely other means to 263 detect connectivity to router peers across the LAN making use of 264 Neighbor Solicitation messages unnecessary. 266 4.4. Host-based Load Spreading 268 Host-based load spreading (e.g. RFC 4311) affects the selection of 269 next hop router for particular packets. This may increase the number 270 of routers a given host communicates with, but it is not expected to 271 add significantly to neighbor discovery traffic or processing load. 273 4.5. Router-based Load Spreading 275 Router-based load spreading (i.e. the use of a NULL SA in a Router 276 Advertisement message) requires hosts to solicit a next hop router 277 address. This increases the number of solicitations for router 278 addresses, but this should not be significant if the number of 279 routers on the LAN is small. This mechanism may be inappropriate 280 (and unneeded) in a core LAN interconnecting a large number of 281 routers and therefore not a concern in that case either. 283 4.6. Holding packets while address resolution occurs 285 In multi-site networks or virtualized networks in which the edge-to- 286 edge delay may be increased over that in a normal (local) LAN, hold 287 time for packets awaiting address resolution may increase 288 significantly. This may be a concern depending on the percentage of 289 packets that must wait for address resolution before being forwarded 290 on the LAN. 292 5. Summary and conclusions 294 The following summarizes the analysis presented: 296 - IPv6 ND looks like it will scale well for the case of a large 297 LAN with 1000s of hosts and a relatively small number of 298 routers. 300 - For the case of a core LAN connecting a large number of routers 301 there are some ND protocol behaviors that may not scale well but 302 these are either optional or not needed between routers (i.e., 303 there are other mechanisms available to the routers to 304 accomplish the same end). 306 - Multi-site L2 networks may provide challenges for both holding 307 time for packets while address resolution is carried out and 308 address resolution for Anycast addresses (for example, if these 309 are expected to select only local servers). 311 - The impact of network virtualization (many VLANs and virtual 312 routers) on platforms that support many virtual networks has not 313 been analyzed and may present additional scaling challenges. 315 6. Manageability Considerations 317 This document has no manageability considerations. 319 7. Security Considerations 321 This document adds no security considerations since it does not 322 define any new protocol behaviors. However, it may be worthwhile to 323 consider whether or not the size of an L2 network (as discussed here) 324 presents any new security challenges. No analysis in this area is 325 provided in this draft. 327 8. IANA Considerations 329 This document has no IANA considerations. 331 9. Acknowledgments 333 This document was prepared using 2-Word-v2.0.template.dot. 335 10. References 337 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 338 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 339 September 2007. 341 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 342 Address Autoconfiguration", RFC 4862, September 2007. 344 Authors' Addresses 346 Ben Mackcrane 347 Huawei Technologies 348 1700 Alma Drive, Suite 500 349 Plano, TX 75075, USA 350 Phone: (630) 810 1132 351 Email: tmackcrane@huawei.com 353 Linda Dunbar 354 Huawei Technologies 355 1700 Alma Drive, Suite 500 356 Plano, TX 75075, USA 357 Phone: (972) 543 5849 358 Email: ldunbar@huawei.com 359 Sue Hares 360 Huawei Technologies 361 2330 Central Expressway, 362 Santa Clara, CA 95050, USA 363 Phone: 364 Email: shares@huawei.com 366 Intellectual Property Statement 368 The IETF Trust takes no position regarding the validity or scope of 369 any Intellectual Property Rights or other rights that might be 370 claimed to pertain to the implementation or use of the technology 371 described in any IETF Document or the extent to which any license 372 under such rights might or might not be available; nor does it 373 represent that it has made any independent effort to identify any 374 such rights. 376 Copies of Intellectual Property disclosures made to the IETF 377 Secretariat and any assurances of licenses to be made available, or 378 the result of an attempt made to obtain a general license or 379 permission for the use of such proprietary rights by implementers or 380 users of this specification can be obtained from the IETF on-line IPR 381 repository at http://www.ietf.org/ipr 383 The IETF invites any interested party to bring to its attention any 384 copyrights, patents or patent applications, or other proprietary 385 rights that may cover technology that may be required to implement 386 any standard or specification contained in an IETF Document. Please 387 address the information to the IETF at ietf-ipr@ietf.org. 389 Disclaimer of Validity 391 All IETF Documents and the information contained therein are provided 392 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 393 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 394 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 395 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 396 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 397 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 398 FOR A PARTICULAR PURPOSE. 400 Acknowledgment 402 Funding for the RFC Editor function is currently provided by the 403 Internet Society.