idnits 2.17.1 draft-ietf-capwap-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2004) is 7361 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 166, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CAPWAP Working Group P. Calhoun 3 Internet-Draft B. O'Hara 4 Expires: August 2, 2004 Airespace 5 J. Kempf 6 Docomo Labs USA 7 February 2, 2004 9 CAPWAP Problem Statement 10 draft-ietf-capwap-problem-statement-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-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 http:// 27 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 August 2, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes the Configuration and Provisioning for 41 Wireless Access Points (CAPWAP) problem statement. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 47 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 48 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 50 Intellectual Property and Copyright Statements . . . . . . . . . 8 52 1. Introduction 54 With the approval of the 802.11 standard by the IEEE in 1997, 55 wireless LANs (WLANs) began a slow entry into enterprise networks. 56 The limited data rates of the original 802.11 standard, only 1- and 57 2-Mbps, limited widespread adoption of the technology. 802.11 found 58 wide deployment in vertical applications, such as inventory 59 management, point of sale, and transportation management. Pioneering 60 enterprises began to deploy 802.11, mostly for experimentation. 62 In 1999, the IEEE approved the 802.11a and 802.11b amendments to the 63 base standard, increasing the available data rate to 54- and 11-Mbps, 64 respectively, and expanding to a new radio band. This removed one of 65 the significant factors holding back adoption of 802.11 in large, 66 enterprise networks. These large deployments were bound by the 67 definition and functionality of an 802.11 Access Point (AP), as 68 described in the 802.11 standard. The techniques required extensive 69 use of layer 2 bridging and widespread VLANs to ensure the proper 70 operation of higher layer protocols. Deployments of 802.11 WLANs as 71 large as several thousand APs have been described. 73 Large deployments of 802.11 WLANs have introduced several problems 74 that require solutions. The limitations on the scalability of 75 bridging should come as no suprise to the networking community, since 76 similar limitations arose in the early 1980's for wired network 77 bridging during the expansion and interconnection of wired local area 78 networks. This document will describe the problems introduced by the 79 large scale deployment of 802.11 WLANs in enterprise networks. 81 2. Problem Statement 83 The first problem introduced by large WLAN deployments is that each 84 AP is an IP-addressable device requiring management, monitoring, and 85 control. Deployment of a large WLAN will typically double the number 86 of network infrastructure devices that require management, over the 87 devices in the network prior to the addition of the WLAN. This 88 presents a significant additional burden to the network 89 administration resources and is often a hurdle to adoption of 90 wireless technologies, particularly because the configuration of each 91 access point is nearly identical to the next. This near-sameness of 92 configuration from one AP to the next often leads to misconfiguration 93 and improper operation of the WLAN. 95 A second problem introduced by large WLAN deployments is distributing 96 and maintaining a consistent configuration throughout the entire set 97 of access points in the WLAN. Access point configuration consists of 98 both long-term static information, such as addressing and hardware 99 settings, and more dynamic provisioning information, such as 100 individual WLAN settings and security parameters. Large WLAN 101 installations that need to update dyanmic provisioning information in 102 all the APs in the WLAN require a prolonged phase-over time, while 103 each AP is updated and the WLAN does not have a single, consistent, 104 configuration. 106 A third problem introduced by large WLAN deployments is the 107 difficulty in dealing effectively with the dynamic nature of the WLAN 108 medium, itself. Due to the shared nature of the wireless medium, 109 shared with APs in the same WLAN, with APs in other WLANs, and with 110 devices that are not APs at all, parameters controlling the wireless 111 medium on each AP must be monitored frequently and modified in a 112 coordinated fashion to maximize performance for the WLAN to utilize 113 the wireless medium efficiently. This must be coordinated among all 114 the access points, to minimize the interference of one access point 115 with its neighbors. Manually monitoring these metrics and 116 determining a new, optimum configuration for the parameters related 117 to the wireless medium is a task that takes a significant amount of 118 time and effort. 120 A fourth problem introduced by large WLAN deployments is securing 121 access to the network and preventing installation of unauthorized 122 access points. Access points are often difficult to physically 123 secure, since their location must often be outside of a locked 124 network closet or server room. Theft of an access point, with its 125 embedded secrets, allows the thief to obtain access to the resources 126 secured by those secrets. 128 Recently, multiple vendors have begun offering proprietary solutions 129 that combine aspects of network switching, centralized control and 130 management, and distributed wireless access in a variety of new 131 architectures to adress some, or all, of the above mentioned 132 problems. Since interoperable solutions allow enterprises and service 133 providers a broader choice, a standardized, interoperable interface 134 between access points and a centralized controller addressing the 135 above mentioned problems seems desirable. 137 The physical portions of this network system, in currently fielded 138 devices, are one or more 802.11 access points (APs) and one or more 139 central control devices, alternatively described as controllers (or 140 access controllers, ACs). Ideally, a network designer would be able 141 to choose one or more vendors for the APs and one or more vendors for 142 the central control devices in sufficient numbers to design a network 143 with 802.11 wireless access to meet the designer's requirements. 145 Current implementations are proprietary and not interoperable. A 146 taxonomy of the architectures employed in the existing products in 147 the market will provide the basis of an output document to be 148 provided to the IEEE 802.11 Working Group. This taxonomy will be 149 utilized by the 802.11 Working Group as input to their task of 150 defining the functional architecture of an access point. The 151 functional architecture, including description of detailed functional 152 blocks, interfaces, and information flow, will be reviewed by CAPWAP 153 to determine if further work is needed to apply or develop standard 154 protocols providing for multi-vendor interoperable implementations of 155 WLANs built from devices that adhere to the newly appearing 156 hierarchical architecture utilizing a functional split between an 157 access point and an access controller. 159 3. Security Considerations 161 To the extent of our knowledge, this problem statement does not 162 create any security issues to the Internet. 164 References 166 [1] "Mobility Related Terminology", April 2003, . 169 Authors' Addresses 171 Pat R. Calhoun 172 Airespace 173 110 Nortech Parkway 174 San Jose, CA 95134 176 Phone: +1 408-635-2000 177 EMail: pcalhoun@airespace.com 179 Bob O'Hara 180 Airespace 181 110 Nortech Parkway 182 San Jose, CA 95134 184 Phone: +1 408-635-2025 185 EMail: bob@airespace.com 187 James Kempf 188 Docomo Labs USA 189 181 Metro Drive, Suite 300 190 San Jose, CA 95110 192 Phone: +1 408 451 4711 193 EMail: kempf@docomolabs-usa.com 195 Intellectual Property Statement 197 The IETF takes no position regarding the validity or scope of any 198 intellectual property or other rights that might be claimed to 199 pertain to the implementation or use of the technology described in 200 this document or the extent to which any license under such rights 201 might or might not be available; neither does it represent that it 202 has made any effort to identify any such rights. Information on the 203 IETF's procedures with respect to rights in standards-track and 204 standards-related documentation can be found in BCP-11. Copies of 205 claims of rights made available for publication and any assurances of 206 licenses to be made available, or the result of an attempt made to 207 obtain a general license or permission for the use of such 208 proprietary rights by implementors or users of this specification can 209 be obtained from the IETF Secretariat. 211 The IETF invites any interested party to bring to its attention any 212 copyrights, patents or patent applications, or other proprietary 213 rights which may cover technology that may be required to practice 214 this standard. Please address the information to the IETF Executive 215 Director. 217 Full Copyright Statement 219 Copyright (C) The Internet Society (2004). All Rights Reserved. 221 This document and translations of it may be copied and furnished to 222 others, and derivative works that comment on or otherwise explain it 223 or assist in its implementation may be prepared, copied, published 224 and distributed, in whole or in part, without restriction of any 225 kind, provided that the above copyright notice and this paragraph are 226 included on all such copies and derivative works. However, this 227 document itself may not be modified in any way, such as by removing 228 the copyright notice or references to the Internet Society or other 229 Internet organizations, except as needed for the purpose of 230 developing Internet standards in which case the procedures for 231 copyrights defined in the Internet Standards process must be 232 followed, or as required to translate it into languages other than 233 English. 235 The limited permissions granted above are perpetual and will not be 236 revoked by the Internet Society or its successors or assignees. 238 This document and the information contained herein is provided on an 239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 245 Acknowledgment 247 Funding for the RFC Editor function is currently provided by the 248 Internet Society.