idnits 2.17.1 draft-ietf-capwap-arch-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1780. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 856 has weird spacing: '...is done respe...' == Line 1622 has weird spacing: '...iety of mecha...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (November 16, 2004) is 7101 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAPWAP Working Group L. Yang (Editor) 2 Internet-Draft Intel Corp. 3 Expires: May 17, 2005 P. Zerfos 4 UCLA 5 E. Sadot 6 Avaya 7 November 16, 2004 9 Architecture Taxonomy for Control and Provisioning of Wireless Access 10 Points(CAPWAP) 11 draft-ietf-capwap-arch-06 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 17, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document provides a taxonomy of the architectures employed in 47 the existing IEEE 802.11 products in the market, by analyzing WLAN 48 (Wireless LAN) functions and services and describing the different 49 variants in distributing these functions and services among the 50 architectural entities. 52 Table of Contents 54 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . . 4 57 2.2 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 6 58 2.3 WLAN Architecture Proliferation . . . . . . . . . . . . . 8 59 2.4 Taxonomy Methodology and Document Organization . . . . . . 9 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 3.1 IEEE 802.11 Definitions . . . . . . . . . . . . . . . . . 11 62 3.2 Terminology Used in this Document . . . . . . . . . . . . 12 63 3.3 Terminology Used Historically but Not Recommended . . . . 14 64 4. Autonomous Architecture . . . . . . . . . . . . . . . . . . . 15 65 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 5. Centralized WLAN Architecture . . . . . . . . . . . . . . . . 17 68 5.1 Interconnection between WTPs and ACs . . . . . . . . . . . 18 69 5.2 Overview of Three Centralized WLAN Architecture 70 Variants . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 5.3 Local MAC . . . . . . . . . . . . . . . . . . . . . . . . 21 72 5.4 Split MAC . . . . . . . . . . . . . . . . . . . . . . . . 24 73 5.5 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 29 74 5.6 Comparisons of Local MAC, Split MAC and Remote MAC . . . . 30 75 5.7 Communication Interface between WTPs and ACs . . . . . . . 31 76 5.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . 32 77 5.8.1 Client Data Security . . . . . . . . . . . . . . . . . 32 78 5.8.2 Security of Control Channel between the WTP and AC . . 33 79 5.8.3 Physical Security of WTPs and ACs . . . . . . . . . . 33 80 6. Distributed Mesh Architecture . . . . . . . . . . . . . . . . 35 81 6.1 Common Characteristics . . . . . . . . . . . . . . . . . . 35 82 6.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 36 83 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 37 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 86 10. Normative References . . . . . . . . . . . . . . . . . . . . 42 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43 88 Intellectual Property and Copyright Statements . . . . . . . . 44 90 1. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [3]. 96 2. Introduction 98 As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale 99 deployment of WLAN networks is highlighting certain technical 100 challenges. As outlined in [2], management, monitoring and control 101 of large number of Access Points (APs) in the network may prove to be 102 a significant network administration burden. Distributing and 103 maintaining a consistent configuration throughout the entire set of 104 APs in the WLAN is a difficult task. The shared and dynamic nature 105 of the wireless medium also demands effective coordination among the 106 APs to minimize radio interference and maximize network performance. 107 Network security issues, which have always been a concern in WLAN's, 108 present even more challenges in large deployments and new 109 architectures. 111 Recently many vendors have begun offering partially proprietary 112 solutions to address some or all of the above mentioned problems. 113 Since interoperable solutions allow for a broader choice, a 114 standardized interoperable solution addressing the aforementioned 115 problems is desirable. As the first step toward establishing 116 interoperability in the market place, this document attempts to 117 provide a taxonomy of the architectures employed in existing WLAN 118 products. We hope to provide a cohesive understanding of the market 119 practices for the standard bodies involved (including the IETF and 120 IEEE 802.11). This document may be reviewed and utilized by the IEEE 121 802.11 Working Group as input to their task of defining the 122 functional architecture of an access point. 124 2.1 IEEE 802.11 WLAN Functions 126 The IEEE 802.11 specifications are wireless standards that specify an 127 "over-the-air" interface between a wireless client (STA) and an 128 Access Point (AP), and also among wireless clients. 802.11 also 129 describes how mobile devices can associate together into a basic 130 service set (BSS). A BSS is identified by a basic service set 131 identifier (BSSID) or name. The WLAN architecture can be considered 132 as a type of 'cell' architecture where each cell is the Basic Service 133 Set (BSS) and each BSS is controlled by the Access Point (AP). When 134 two, or more APs are connected via a broadcast layer 2 network and 135 all are using the same SSID, an extended service set (ESS) is 136 created. 138 The architectural component used to interconnect BSSs is the 139 distribution system (DS). An access point (AP) is a STA that 140 provides access to the DS by providing DS services in addition to 141 acting as a STA. Another logical architectural component -- portal 142 -- is introduced to integrate the IEEE 802.11 architecture with a 143 traditional wired LAN. It is possible for one device to offer both 144 the functions of an AP and a portal. 146 IEEE 802.11 explicitly does not specify the details of DS 147 implementations. Instead, the 802.11 standard defines services that 148 provide the functions that the LLC layer requires for sending MAC 149 Service Data Units (MSDUs) between two entities on the network. 150 These services can be classified into two categories: the station 151 service (SS) and the distribution system service (DSS). Both 152 categories of service are used by the IEEE 802.11 MAC sublayer. 153 Station services consist of the following four services: 154 o Authentication: The service used to establish the identity of one 155 station as a member of the set of stations authorized to associate 156 with another station. 157 o Deauthentication: The service that voids an existing 158 authentication relationship. 159 o Confidentiality: The service used to prevent the content of 160 messages from being read by other than the intended recipients. 161 o MSDU Delivery: The service to deliver the MAC service data unit 162 (MSDU) for the Stations. 164 Distribution system services consist of the following five services: 165 o Association: The service used to establish access point/station 166 (AP/STA) mapping and enable STA invocation of the distribution 167 system services. 168 o Disassociation: The service that removes an existing association. 169 o Reassociation: The service that enables an established association 170 [between access point (AP) and station (STA)] to be transferred 171 from one AP to another (or the same) AP. 172 o Distribution: The service that provides MSDU forwarding by APs for 173 the STAs associated with them. MSDUs can be either forwarded to 174 the Wireless destination or to the Wired (Ethernet) destination 175 (or both) using the "Distribution System" concept of 802.11. 176 o Integration: The service that is used to translate the MSDU 177 received from the Distribution System to a non-802.11 format and 178 vice versa. Any MSDU that is received from the DS invokes the 179 "Integration" services of the DSS before the 'Distribution' 180 services are invoked. The point of connection of the DS to the 181 wired LAN is termed as 'portal'. 183 Apart from these services the IEEE 802.11 also defines additional MAC 184 services that must be implemented by the APs in the WLAN. For 185 example: 186 o Beacon Generation 187 o Probe Response/Transmission 188 o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK 189 o Synchronization 190 o Retransmissions 191 o Transmission Rate Adaptation 192 o Privacy: 802.11 Encryption/Decryption 194 In addition to the services offered by the 802.11, the IEEE 802.11 WG 195 is also developing technologies to support Quality of Service 196 (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or 197 802.11F -- recommended practice) to update APs when a STA roams from 198 one BSS to the other, Radio Resource Management (802.11k) etc. 200 IEEE 802.11 does not exactly specify how all these functions get 201 implemented, nor does it specify that these functions be implemented 202 all in one physical device. Conceptually, all it requires is that 203 the APs and the rest of the DS together implement all these services. 204 Typically, vendors implement not only the services defined in the 205 IEEE 802.11 standard, but also a variety of value-added services or 206 functions, such as load balancing support, QoS, station mobility 207 support, rogue AP detection, etc. What will become clear from the 208 rest of this document is that vendors do take advantage of the 209 flexibility in the 802.11 architecture, and have come up with many 210 different flavors of architectures and implementations of the WLAN 211 services. 213 Because many vendors choose to implement these WLAN services across 214 multiple network elements, we want to make a clear distinction 215 between the logical WLAN access network functions, and the individual 216 physical devices, by adopting different terminology from now on. We 217 use "AP" to refer to the logical entity that provides access to the 218 distribution services, and "WTP" (Wireless Termination Point) to the 219 physical device that features RF antenna and 802.11 PHY to transmit 220 and receive station traffic in the BSS network. In one of the 221 architectures discussed later, namely, Centralized Architecture, the 222 combination of WTPs with AC (Access Controller) together implements 223 the logical functions. Each of these physical devices (WTP or AC) 224 may implement only part of the logical functions. But the DS 225 including all the physical devices as a whole implements all, or most 226 of the functions. 228 2.2 CAPWAP Functions 230 In order to address the four problems identified in the [2] 231 (management, consistent configuration, RF control, security) 232 additional functions, especially in the control plane and management 233 plane, are typically offered by vendors to assist better coordination 234 and control across the entire ESS network. Such functions are 235 especially important when the IEEE 802.11 WLAN functions are 236 implemented across a large scale network of multiple entities, 237 instead of within a single entity. Such functions include: 239 o RF monitoring, such as Radar detection, noise and interference 240 detection and measurement. 241 o RF configuration, e.g., for retransmission, channel selection, 242 transmission power adjustment, etc. 243 o WTP configuration, e.g., for SSID, etc. 244 o WTP firmware loading, e.g., automatic loading and upgrading of WTP 245 firmware for network wide consistency. 246 o Network-wide STA state information database, including the 247 information needed to support value-added services, such as 248 mobility, load balancing etc. 249 o Mutual authentication between network entities, e.g., for AC and 250 WTP authentication in a Centralized WLAN Architecture. 252 The services listed are concerned with configuration and control of 253 the radio resource ('RF Monitoring' and 'RF Configuration'), 254 management and configuration of the WTP device ('WTP Configuration', 255 'WTP Firmware upgrade'), and also security regarding the registration 256 of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the 257 device from which other services such as mobility management across 258 subnets, and load balancing can obtain state information regarding 259 the STA(s) associated with the wireless network, is also reported as 260 a service ('STA state info database'). 262 The above list of CAPWAP functions does not attempt to be an 263 exhaustive enumeration of all additional services offered by vendors. 264 Instead, we included only those functions that are commonly 265 represented in the survey data, and are also pertinent to the 266 understanding of the central problem of interoperability. 268 Most of these functions are not explicitly specified by IEEE 802.11, 269 but some of the functions are. For example, control and management 270 of the radio-related functions of an AP are described implicitly in 271 the MIB, such as: 272 o Channel Assignment 273 o Transmit Power Control 274 o Radio Resource Measurement (work currently under way in IEEE 275 802.11k) 277 The 802.11h [5] amendment to the base 802.11 standard specifies the 278 operation of a MAC management protocol to accomplish the requirements 279 of some regulatory bodies (principally in Europe, but expanding to 280 others) in these areas: 281 o RADAR detection 282 o Transmit Power Control 283 o Dynamic Channel Selection 285 2.3 WLAN Architecture Proliferation 287 This document provides a taxonomy of the WLAN network architectures 288 developed by the vendor community in an attempt to address some or 289 all of the problems outlined in [2]. As the IEEE 802.11 standard 290 purposely avoids to specify the details of DS implementations, 291 different architectures have proliferated in the market. While all 292 these different architectures conform to the IEEE 802.11 standard as 293 a whole, their individual functional components are not standardized. 294 The interfaces between the network architecture components are mostly 295 proprietary, and there is no guarantee of cross-vendor 296 interoperability of products, even within the same architecture 297 family. 299 In order to achieve interoperability in the market place, the IETF 300 CAPWAP working group is taking on the first logical task of 301 documenting both the functions and the network architectures offered 302 by the existing WLAN vendors today. The end result of this task is 303 this taxonomy document. 305 After analyzing more than a dozen different vendors' architectures, 306 we believe that the existing 802.11 WLAN access network architectures 307 can be broadly categorized into three distinct families, based on the 308 characteristics of the Distribution Systems that are employed to 309 provide the 802.11 functions. 310 o Autonomous WLAN Architecture: The first architecture family is the 311 traditional autonomous WLAN architecture, where each WTP is a 312 single physical device that implements all the 802.11 services, 313 including both the distribution and integration services, and the 314 portal function. Such an AP architecture is called Autonomous 315 WLAN Architecture because each WTP is autonomous in its 316 functionality, and no explicit 802.11 support is needed from 317 devices other than the WTP. The WTP in such architecture is 318 typically configured and controlled individually, and can be 319 monitored and managed via typical network management protocols 320 like SNMP. The WTPs in this architecture are the traditional 321 Access Points most people are familiar with. Sometimes such WTPs 322 are referred to as "Fat APs" or "Standalone APs". 323 o Centralized WLAN Architecture: The second WLAN architecture family 324 is an emerging hierarchical architecture utilizing one or more 325 centralized controllers for managing a large number of WTP 326 devices. The centralized controller is commonly referred to as an 327 Access Controller (AC), whose main function is to manage, control 328 and configure the WTP devices that are present in the network. In 329 addition to being a centralized entity for the control and 330 management plane, it may also become a natural aggregation point 331 for the data plane, since it is typically situated in a 332 centralized location in the wireless access network. The AC is 333 often co-located with an L2 bridge, a switch, or an L3 router, and 334 hence may be referred to as Access Bridge, or Access Router in 335 those particular cases. Therefore, an Access Controller could be 336 either an L3 or L2 device, and Access Controller is the generic 337 terminology we use throughout this document. It is also possible 338 that multiple ACs are present in a network for purposes of 339 redundancy, load balancing, etc. This architecture family has 340 several distinct characteristics that are worth noting. First, 341 the hierarchical architecture and the centralized AC afford much 342 better manageability for the large scale networks. Second, since 343 the IEEE 802.11 functions and the CAPWAP control functions are 344 provided by the WTP devices and the AC together, the WTP devices 345 themselves may not implement the full 802.11 functions as defined 346 in the standards any more. Therefore, it can be said that the 347 full 802.11 functions are implemented across multiple physical 348 network devices, namely, the WTPs and ACs. Since the WTP devices 349 only implement a portion of the functions that standalone APs 350 implement, WTP devices in this architecture are sometimes referred 351 to as light weight or thin APs by some vendors. 352 o Distributed WLAN Architecture: The third emerging WLAN 353 architecture family is the distributed architecture in which the 354 participating wireless nodes are capable of forming a distributed 355 network among themselves, via either wired or wireless media. A 356 wireless mesh network is one example in the distributed 357 architecture family, where the nodes themselves form a mesh 358 network, and connect with neighboring mesh nodes via 802.11 359 wireless links. Some of these nodes also have wired Ethernet 360 connections, acting as gateways to the external network. 362 2.4 Taxonomy Methodology and Document Organization 364 Before the IETF CAPWAP working group started documenting the various 365 WLAN architectures, we conducted an open survey soliciting WLAN 366 architecture description contributions via the IETF CAPWAP mailing 367 list. We provided the interested parties with a common template that 368 included a number of questions about their WLAN architectures. We 369 received 16 contributions in the form of short text descriptions 370 answering those questions. 15 of them are from WLAN vendors 371 (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems, 372 Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic, 373 Trapeze, Instant802, Strix Systems, Symbol) and one from the academic 374 research community (UCLA). Out of the 16 contributions, one 375 describes an Autonomous WLAN Architecture, three are Distributed Mesh 376 Architectures, while the rest twelve entries represent architectures 377 that fall into the family of Centralized WLAN Architecture. 379 The main objective of this survey is to identify the general 380 categories and trends in WLAN architecture evolution, discover their 381 common characteristics, determine what is performed differently among 382 them, and why. In order to represent the survey data in a compact 383 format, a "Functional Distribution Matrix" is used in this document, 384 mostly in the Centralized WLAN architecture section, to tabulate the 385 various services and functions in the vendors' offerings. These 386 services and functions are classified into three main categories: 387 o Architecture Considerations: the choice of the connectivity 388 between the AC and the WTP; the design choices regarding the 389 physical device on which processing of management, control, and 390 data frames of the 802.11 takes place. 391 o 802.11 Functions: as described in Section 2.1. 392 o CAPWAP Functions: as described in Section 2.2. 394 For each one of these categories, the mapping of each individual 395 function to network entities implemented by each vendor is shown in 396 tabular form. The rows in the Functional Distribution Matrix 397 represent the individual functions that are organized into the above 398 mentioned three categories, while each column of the Matrix 399 represents one vendor's architecture offering in the survey data. 400 See Figure 7 as an example of the Matrix. 402 This Functional Distribution Matrix is intended for the sole purpose 403 of organizing the architecture taxonomy data, and represents the 404 contributors' view of their architectures, from an engineering 405 perspective. It does not necessarily imply an existing product, 406 shipping or not, nor an intent by the vendor to build such a product. 408 The next section provides a list of definitions used in this 409 document, some defined by IEEE 802.11 while others by this document. 410 The rest of this document is organized around the three broad WLAN 411 architecture families that were introduced in Section 2.3. Each 412 architecture family is discussed in a separate section. The section 413 on Centralized Architecture contains more in-depth details than the 414 other two families, largely due to the large number of the survey 415 data (12 out of 16) collected that fall into the Centralized 416 Architecture category. Summary and conclusions are provided at the 417 end of the document to highlight the basic findings from this 418 taxonomy exercise. 420 3. Definitions 422 3.1 IEEE 802.11 Definitions 424 Station (STA): A device that contains an IEEE 802.11 conformant 425 medium access control (MAC) and physical layer (PHY) interface to the 426 wireless medium (WM). 428 Access Point (AP): An entity that has station functionality and 429 provides access to distribution services, via the wireless medium 430 (WM) for associated stations. 432 Basic Service Set (BSS): A set of stations controlled by a single 433 coordination function. 435 Station Service (SS): The set of services that support transport of 436 medium access control (MAC) service data units (MSDUs) between 437 stations, within a basic service set (BSS). 439 Distribution System (DS): A system used to interconnect a set of 440 basic service sets (BSSs) and integrated local area networks (LANs) 441 to create an extended service set (ESS). 443 Extended Service Set (ESS): A set of one or more interconnected basic 444 service sets (BSSs) with the same SSID and integrated local area 445 networks (LANs), which appears as a single BSS to the logical link 446 control layer at any station associated with one of those BSSs. 448 Portal: The logical point at which medium access control (MAC) 449 service data units (MSDUs) from a non-IEEE 802.11 local area network 450 (LAN) enter the distribution system (DS) of an extended service set 451 (ESS). 453 Distribution System Service (DSS): The set of services provided by 454 the distribution system (DS) that enable the medium access control 455 (MAC) layer to transport MAC service data units (MSDUs) between 456 stations that are not in direct communication with each other, over a 457 single instance of the wireless medium (WM). These services include 458 transport of MSDUs between the access points (APs) of basic service 459 sets (BSSs) within an extended service set (ESS), transport of MSDUs 460 between portals and BSSs within an ESS, and transport of MSDUs 461 between stations in the same BSS in cases where the MSDU has a 462 multicast or broadcast destination address, or where the destination 463 is an individual address, but the station sending the MSDU chooses to 464 involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs. 466 Integration: The service that enables delivery of medium access 467 control (MAC) service data units (MSDUs) between the distribution 468 system (DS) and an existing, non-IEEE 802.11 local area network (via 469 a portal). 471 Distribution: The service that, by using association information, 472 delivers medium access control (MAC) service data units (MSDUs) 473 within the distribution system (DS). 475 3.2 Terminology Used in this Document 477 One of the motivations in defining new terminology in this document 478 is to clarify some of the ambiguity and confusion surrounding some 479 conventional terms. One such term is "Access Point (AP)". Typically 480 ,when people talk about "AP", they refer to the physical entity (box) 481 that has an antenna, implements 802.11 PHY and receives/transmits the 482 station (STA) traffic over the air. However, the 802.11 Standard [1] 483 describes the AP mostly as a logical entity that implements a set of 484 logical services so that station traffic can be received and 485 transmitted effectively over the air. So when people refer to "AP 486 functions", they usually mean the logical functions the whole WLAN 487 access network supports, and not just the subset of functions 488 supported by the physical entity (box) that the STAs communicate to 489 directly. Such confusion can be especially acute when the logical 490 functions is implemented across a network instead of within a single 491 physical entity. So to avoid further confusion, we define the 492 following terminology used in this document: 494 CAPWAP: Control and Provisioning of Wireless Access Points. 496 IEEE 802.11 WLAN Functions: a set of logical functions defined by the 497 IEEE 802.11 Working Group, including all the MAC services, Station 498 Services, and Distribution Services. These logical functions are 499 required to be implemented in the IEEE 802.11 Wireless LAN (WLAN) 500 access networks by the IEEE 802.11 Standard[1]. 502 CAPWAP Functions: a set of WLAN control functions that are not 503 directly defined by IEEE 802.11 Standards, but deemed essential for 504 effective control, configuration and management of 802.11 WLAN access 505 networks. 507 Wireless Termination Point (WTP): the physical or network entity that 508 contains RF antenna and 802.11 PHY to transmit and receive station 509 traffic for the IEEE 802.11 WLAN access networks. Such physical 510 entities are often called "Access Points" (AP) previously, but "AP" 511 can also be used to refer to the logical entity that implements 512 802.11 services. So we recommend "WTP" as the generic term used to 513 explicitly refer to the physical entity with the above property (i.e. 514 featuring an RF antenna and 802.11 PHY), applicable to network 515 entities of both Autonomous and Centralized WLAN Architecture (see 516 below). 518 Autonomous WLAN Architecture: the WLAN access network architecture 519 family in which all the logical functions, including both IEEE 802.11 520 and CAPWAP functions (wherever applicable), are implemented within 521 each Wireless Termination Point (WTP) in the network. The WTPs in 522 such networks are also called standalone APs, or fat APs, because 523 these devices implement the full set of functions that enable the 524 devices to operate without any other support from the network. 526 Centralized WLAN Architecture: the WLAN access network architecture 527 family in which the logical functions, including both IEEE 802.11 and 528 CAPWAP functions (wherever applicable), are implemented across a 529 hierarchy of network entities. At the low level of such hierarchy 530 are the WTPs while at the higher level are the Access Controllers 531 (ACs), which are responsible to control, configure and manage the 532 entire WLAN access networks. 534 Distributed WLAN Architecture: the WLAN access network architecture 535 family in which some of the control functions (e.g., CAPWAP 536 functions) are implemented across a distributed network consisting of 537 peer entities. A wireless mesh network can be considered as an 538 example of such an architecture. 540 Access Controller (AC): The network entity in the Centralized WLAN 541 architectures that provides WTPs access to the centralized 542 hierarchical network infrastructure, either in the data plane, 543 control plane, management plane, or a combination therein. 545 Standalone WTP: referred to the WTP in Autonomous WLAN Architecture. 547 Controlled WTP: referred to the WTP in Centralized WLAN Architecture. 549 Split MAC Architecture: A sub-group of the Centralized WLAN 550 Architecture, with the characteristic that WTPs in such WLAN access 551 networks only implement the delay sensitive MAC services (including 552 all control frames and some management frames) for IEEE 802.11, while 553 tunneling all the remaining management and data frames to AC for 554 centralized processing. The IEEE 802.11 MAC, as defined by IEEE 555 802.11 Standards in [1], is effectively split between the WTP and AC. 557 Remote MAC Architecture: A sub-group of the Centralized WLAN 558 Architecture, where the entire set of 802.11 MAC functions (including 559 delay-sensitive functions) is implemented at the AC. The WTP 560 terminates the 802.11 PHY functions. 562 Local MAC Architecture: A sub-group of the Centralized WLAN 563 Architecture, where the majority or entire set of 802.11 MAC 564 functions (including most of the 802.11 management frame processing) 565 are implemented at the WTP. Therefore, the 802.11 MAC stays intact 566 and local in the WTP, along with PHY. 568 3.3 Terminology Used Historically but Not Recommended 570 While some terminology has been used by vendors historically to 571 describe "Access Points", we recommend to defer its use, in order to 572 avoid further confusion. A list of such terms and the recommended 573 new terminology is provided below: 575 Split WLAN Architecture: use Centralized WLAN Architecture. 577 Hierarchical WLAN Architecture: use Centralized WLAN Architecture. 579 Standalone Access Point: use Standalone WTP. 581 Fat Access Point: Use Standalone WTP. 583 Thin Access Point: use Controlled WTP. 585 Light weight Access Point: Use Controlled WTP. 587 Split AP Architecture: use Local MAC Architecture. 589 Antenna AP Architecture: use Remote MAC Architecture. 591 4. Autonomous Architecture 593 4.1 Overview 595 Figure 1 shows an example network of the Autonomous WLAN 596 Architecture. This architecture implements all the 802.11 597 functionality in a single physical device, the Wireless Termination 598 Point (WTP). A common embodiment of this architecture is a WTP that 599 translates between 802.11 frames to/from its radio interface and 600 802.3 frames to/from an Ethernet interface. An 802.3 infrastructure 601 that interconnects the Ethernet interfaces of different WTPs together 602 provides the distribution system. It can also provide portals for 603 integrated 802.3 LAN segments. 605 +---------------+ +---------------+ +---------------+ 606 | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | 607 | ... | | ... | | ... | 608 | +-----+ | | +-----+ | | +-----+ | 609 +----| WTP |----+ +----| WTP |----+ +----| WTP |----+ 610 +--+--+ +--+--+ +--+--+ 611 |Ethernet | | 612 +------------------+ | +------------------+ 613 | | | 614 +---+--+--+---+ 615 | Ethernet | 616 802.3 LAN --------------+ Switch +-------------- 802.3 LAN 617 segment 1 | | segment 2 618 +------+------+ 620 Figure 1: Example of Autonomous WLAN Architecture 622 A single physical WTP can optionally be provisioned as multiple 623 virtual WTPs, by supporting multiple SSIDs to which 802.11 clients 624 may associate. In some cases, this will also involve putting a 625 corresponding 802.1Q VLAN tag on each packet forwarded to the 626 Ethernet infrastructure and removal of 802.1Q tags prior to 627 forwarding the packets to the wireless medium. 629 The scope of the ESS(s) created by interconnecting the WTPs will be 630 confined by the constraints imposed by the Ethernet infrastructure. 632 Authentication of 802.11 clients may be performed locally by the WTP 633 or by using a centralized authentication server. 635 4.2 Security 637 Since both the 802.11 and CAPWAP functionality is tightly integrated 638 into a single physical device, security issues with this architecture 639 are confined to the WTP. There are no extra implications from the 640 client authentication and encryption/decryption perspective as the 641 AAA interface is integrated into the WTP, so is the key generation 642 mechanisms required for 802.11i encryption/decryption. 644 One of the security issues in this architecture is the need for 645 mutual authentication between the WTP and the Ethernet 646 infrastructure. This can be ensured by existing mechanisms such as 647 802.1X between the WTP and the Ethernet switch it connects to. 648 Another critical security issue with this architecture is the very 649 fact that the WTP is most likely not under lock and key, but does 650 contain secret information in order to communicate with the backend 651 systems, such as AAA, SNMP, etc. Due to the common management method 652 used by IT personnel of pushing a "template" to all devices, theft of 653 such a device would potentially compromise the wired network. 655 5. Centralized WLAN Architecture 657 Centralized WLAN Architecture is an emerging architecture family in 658 the WLAN market. Contrary to the Autonomous WLAN Architecture where 659 the 802.11 functions and network control functions are all 660 implemented within each Wireless Termination Point (WTP), the 661 Centralized WLAN Architecture employs one or multiple centralized 662 controllers, called Access Controller(s), to enable network-wide 663 monitoring, improve management scalability, and facilitate dynamic 664 configurability. 666 The following figure shows schematically the Centralized WLAN 667 Architecture network diagram, where the Access Controller (AC) 668 connects to multiple Wireless Termination Points (WTPs) via an 669 interconnection medium. This can be either a direct connection, an 670 L2-switched, or an L3-routed network as described in Section 5.1. 671 The AC exchanges configuration and control information with the WTP 672 devices, allowing the management of the network from a centralized 673 point. Also, designs of the Centralized WLAN Architecture family do 674 not presume (as the diagram might suggest to some readers) that the 675 AC necessarily intercedes in the data plane to/from the WTP(s). More 676 details are provided later in this section. 678 +---------------+ +---------------+ +---------------+ 679 | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | 680 | ... | | ... | | ... | 681 | +-------+ | | +-------+ | | +-------+ | 682 +----| WTP |--+ +----| WTP |--+ +----| WTP |--+ 683 +---+---+ +---+---+ +---+---+ 684 | | | 685 +------------------+ | +-----------------+ 686 | |...| 687 +----+--+---+--------+ 688 | Interconnection | 689 +-------+------------+ 690 | 691 | 692 +-----+----+ 693 | AC | 694 +----------+ 696 Figure 2: Centralized WLAN Architecture Diagram 698 In the diagram above, the AC is shown as a single physical entity 699 that provides all of the CAPWAP functions listed in section 2.2. But 700 that may not be always the case. Closer examination of the functions 701 reveals that their different resource requirements (e.g. CPU, 702 memory, storage) may lend themselves to being distributed across 703 different devices. For instance, complex radio control algorithms 704 can be CPU intensive. Storing and downloading images and 705 configurations can be storage intensive. Therefore different CAPWAP 706 functions might be implemented on different physical devices due to 707 the different nature of their resource requirements. The network 708 entity marked 'AC' in the diagram above should accordingly be thought 709 of as a multiplicity of logical functions, and not necessarily as a 710 single physical device. The AC(s) may also choose to implement some 711 of the control functions locally while providing interfaces to access 712 other global network management functions which are typically 713 implemented on separate boxes, such as a SNMP Network Management 714 Station and an AAA backend server (e.g., Radius Authentication 715 Server). 717 5.1 Interconnection between WTPs and ACs 719 There are several connectivity options which can be considered 720 between the AC(s) and the WTPs, including direct connection, L2 721 switched connection, or L3 routed connection, as shown in Figure 3, 722 Figure 4, and Figure 5. 724 -------+------ LAN 725 | 726 +-------+-------+ 727 | AC | 728 +----+-----+----+ 729 | | 730 +---+ +---+ 731 | | 732 +--+--+ +--+--+ 733 | WTP | | WTP | 734 +--+--+ +--+--+ 736 Figure 3: Directly Connected 737 -------+------ LAN 738 | 739 +-------+-------+ 740 | AC | 741 +----+-----+----+ 742 | | 743 +---+ +---+ 744 | | 745 +--+--+ +-----+-----+ 746 | WTP | | Switch | 747 +--+--+ +---+-----+-+ 748 | | 749 +-----+ +-----+ 750 | WTP | | WTP | 751 +-----+ +-----+ 753 Figure 4: Switched Connections 755 +-------+-------+ 756 | AC | 757 +-------+-------+ 758 | 759 --------+------ LAN 760 | 761 +-------+-------+ 762 | router | 763 +-------+-------+ 764 | 765 -----+--+--+--- LAN 766 | | 767 +---+ +---+ 768 | | 769 +--+--+ +--+--+ 770 | WTP | | WTP| 771 +--+--+ +--+--+ 773 Figure 5: Routed Connections 775 5.2 Overview of Three Centralized WLAN Architecture Variants 777 While dynamic and consistent network management is one of the primary 778 motivations for the Centralized Architecture, the survey data from 779 vendors also shows that different varieties of this architecture 780 family have emerged to meet a complex set of different requirements 781 for possibly different deployment scenarios. This is also a direct 782 result of the inherent flexibility in the 802.11 standard [1] 783 regarding the implementation of the logical functions that are 784 broadly described under the term "Access Point (AP)". As there is no 785 standard mapping of these AP functions to physical network entities, 786 several design choices have been made by vendors that offer related 787 products. Moreover, the increased demand for monitoring and 788 consistent configuration of large wireless networks has resulted into 789 a set of 'value-added' services provided by the various vendors, most 790 of which share common design properties and service goals. 792 In the following, we describe the three main variants observed from 793 the survey data within the family of Centralized WLAN Architecture, 794 namely the Local MAC, Split MAC, and Remote MAC approaches. For 795 each approach we provide the mapping characteristics of the various 796 functions into the network entities from each vendor. The naming of 797 Local MAC, Split MAC and Remote MAC reflects how the functions, and 798 especially the 802.11 MAC functions, are mapped onto the network 799 entities. Local MAC indicates that the MAC functions stay intact and 800 local to WTPs, while Remote MAC denotes that the MAC is moved away 801 from the WTP to a remote AC in the network. Split MAC shows the MAC 802 being split between the WTPs and ACs, largely along the line of real 803 time sensitivity. Typically, Split MAC vendors choose to put real 804 time functions on the WTPs while leaving non-real time functions to 805 the ACs. 802.11 does not clearly specify what constitutes real-time 806 functions versus non-real-time functions, and so there does not exist 807 such a clear and definitive line among them. As shown in Section 808 5.4, each vendor has its own interpretation on this and so there 809 exists some discrepancy in where to draw the line between real time 810 However, vendors also manage to agree on the characterization of the 811 majority of the MAC functions. For example, every vendor classifies 812 the DCF as a real-time function. 814 The differences among Local MAC, Split MAC and Remote MAC 815 architectures are shown graphically in the following figure: 817 +--------------+--- +---------------+--- +--------------+--- 818 | CAPWAP | | CAPWAP | | CAPWAP | 819 | functions |AC | functions |AC | functions | 820 |==============|=== |---------------| |--------------| 821 | | | non RT MAC | | |AC 822 | 802.11 MAC | |===============|=== | 802.11 MAC | 823 | |WTP | Real Time MAC | | | 824 |--------------| |---------------|WTP |==============|=== 825 | 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP 826 +--------------+--- +---------------+--- +--------------+--- 828 (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" 830 Figure 6: Three Architectural Variants within Centralized WLAN 831 Architecture Family 833 5.3 Local MAC 835 The main motivation of Local MAC architecture model, as shown in 836 Figure 6.(a), is to offload network access policies and management 837 functions (CAPWAP functions described in Section 2.2) to the AC, 838 without splitting the 802.11 MAC functionality between WTPs and AC. 839 The whole 802.11 MAC resides on the WTPs locally, including all the 840 802.11 management and control frame processing for the STAs; on the 841 other hand, information related to management and configuration of 842 the WTP devices is communicated with a centralized AC, to facilitate 843 management of the network, and maintain a consistent network-wide 844 configuration for the WTP devices. 846 Figure 7 offers a tabular representation of the design choices made 847 by the six vendors in the survey that follow the Local MAC approach 848 with respect to the aforementioned architecture considerations. 849 "WTP-AC connectivity" shows the type of connectivity between WTPs and 850 AC every vendor's architecture can support. It is clear that all the 851 vendors can support L3 routed network connectivity between WTPs and 852 the AC, which implies that direct connections and L2 switched 853 networks are also supported by all vendors. By '802.11 mgmt 854 termination', and '802.11 control termination' we denote the physical 855 network device on which processing of the 802.11 management and 856 control frames is done respectively. All the vendors here choose to 857 terminate 802.11 management and control frames at the WTPs. The last 858 row of the table, '802.11 data aggregation', refers to the device on 859 which aggregation and delivery of 802.11 data frames from one STA to 860 another (possibly through a DS) is performed. As we can see from the 861 table, vendors make different choices as whether or not all the 862 802.11 data traffic is aggregated and routed through the AC. The 863 survey data shows that some vendors choose to tunnel or encapsulate 864 all the station traffic to or from the ACs, implying the AC also acts 865 as the access router for this WLAN access network; other vendors 866 choose to separate the control plane and data plane by letting the 867 station traffic being bridged or routed locally while keeping the 868 centralized control at the AC. 870 Arch7 Arch8 Arch9 Arch10 Arch11 871 ----- ----- ----- ------ ------ 873 WTP-AC 874 connectivity L3 L3 L3 L3 L3 876 802.11 mgmt 877 termination WTP WTP WTP WTP WTP 879 802.11 control 880 termination WTP WTP WTP WTP WTP 882 802.11 data 883 aggregation AC AC WTP AC WTP 885 Figure 7: Architecture Considerations for Local MAC Architecture 887 Figure 8 shows that most of the CAPWAP functions as described in 888 Section 2.2 are implemented at the AC, with help from WTPs to monitor 889 RF channels, and collect statistics and state information from the 890 STAs, as the AC offers the advantages of network-wide visibility, 891 which is essential for many of the control, configuration and 892 value-added services. 894 Arch7 Arch8 Arch9 Arch10 Arch11 895 ----- ----- ----- ------ ------ 897 RF 898 Monitoring WTP WTP AC/WTP WTP WTP 900 RF 901 Config. AC AC AC AC AC 903 WTP config. AC AC AC AC AC 905 WTP 906 Firmware AC AC AC AC AC 908 STA state 909 info 910 database AC AC/WTP AC/WTP AC/WTP AC 912 AC/WTP 913 mutual 914 authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP 916 Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture 918 The matrix shown in Figure 9 shows that most of the 802.11 functions 919 are implemented at the WTPs for Local MAC Architecture, with some 920 minor differences among the vendors with regard to distribution 921 service, 802.11e scheduling and 802.1X/EAP authentication. The 922 difference in distribution service is consistent with the difference 923 described earlier with regard to "802.11 data aggregation" in Figure 924 7. 926 Arch7 Arch8 Arch9 Arch10 Arch11 927 ----- ----- ----- ------ ------ 929 Distribution 930 Service AC AC WTP AC WTP 932 Integration 933 Service WTP WTP WTP WTP WTP 935 Beacon 936 Generation WTP WTP WTP WTP WTP 938 Probe 939 Response WTP WTP WTP WTP WTP 940 Power mgmt 941 Packet 942 Buffering WTP WTP WTP WTP WTP 944 Fragmentation/ 945 Defragment. WTP WTP WTP WTP WTP 947 Association 948 Disassoc. 949 Reassociation AC WTP WTP WTP WTP 951 WME/11e 952 -------------- 953 classifying AC WTP 955 scheduling WTP AC/WTP WTP WTP WTP 957 queuing WTP WTP WTP WTP 959 Authentication 960 and Privacy 961 -------------- 962 802.1X/EAP AC AC AC/WTP AC AC/WTP 964 Keys 965 Management AC AC WTP AC AC 967 802.11 968 Encryption/ 969 Decryption WTP WTP WTP WTP WTP 971 Figure 9: Mapping of 802.11 Functions for Local MAC Architecture 973 From Figure 7, Figure 8 and Figure 9, it is clear that differences 974 among vendors in the Local MAC Architecture are relatively minor, and 975 most of the functional mapping appears to be common across vendors. 977 5.4 Split MAC 979 As shown in Figure 6.(b), the main idea behind the Split MAC 980 architecture is to implement part of the 802.11 MAC functionality on 981 a centralized AC instead of the WTPs, in addition to the services 982 required for managing and monitoring the WTP devices. Usually, the 983 decision of which functions of the 802.11 MAC need to be provided by 984 the AC is based on the time-criticality of the services considered. 986 In the Split MAC architecture, the WTP terminates the infrastructure 987 side of the wireless physical link, provides radio-related 988 management, and also implements all time-critical functionality of 989 the 802.11 MAC. In addition, the non real-time management functions 990 are handled by a centralized AC, along with higher-level services, 991 such as configuration, QoS, policies for load-balancing, access 992 control lists, etc. The subtle but key distinction between Local MAC 993 and Split MAC relates to the non real-time functions: in Split MAC 994 architecture, the AC terminates 802.11 non real-time functions, 995 whereas in Local MAC architecture the WTP terminates the 802.11 non 996 real-time functions and consequently sends appropriate messages to 997 the AC. 999 There are several motivations for taking the Split MAC approach. The 1000 first is to offload to the WTP functionality that is specific and 1001 relevant only to the locality of each BSS, in order to allow the AC 1002 to scale to a large number of 'light weight' WTP devices. Moreover, 1003 real-time functionality is subject to latency constraints and cannot 1004 tolerate delays due to transmission of 802.11 Control frames (or 1005 other real-time information) over multiple-hops. The latter would 1006 limit the available choices for the connectivity between the AC and 1007 the WTP, hence the real-time criterion is usually employed to 1008 separate MAC services between the devices. Another consideration is 1009 cost reduction of the WTP to make it as cheap and simple as possible. 1010 Last but not least, moving functions like encryption and decryption 1011 to the AC reduces vulnerabilities from a compromised WTP, since user 1012 encryption keys no longer reside on the WTP. As a result, any 1013 advancements in security protocols and algorithms design do not 1014 necessarily obsolete the WTPs; the ACs implement the new security 1015 schemes instead, and the management and update task is therefore 1016 simplified. Additionally, the network is protected against LAN-side 1017 eavesdropping. 1019 Since there is no clear definition in the 802.11 specification as to 1020 which 802.11 MAC functions are considered "real time", each vendor 1021 has taken the liberty to interpret that in his own way. Most vendors 1022 agree that the following services of 802.11 MAC are examples of real 1023 time services and so are chosen to be implemented on the WTPs. 1024 o Beacon Generation 1025 o Probe Response/Transmission 1026 o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK 1027 o Synchronization 1028 o Retransmissions 1029 o Transmission Rate Adaptation 1031 The following list includes examples of non-real-time MAC functions 1032 as interpreted by most vendors: 1033 o Authentication/Deauthentication 1034 o Association/Disassociation/Reassociation/Distribution 1035 o Integration Services: bridging between 802.11 and 802.3 1036 o Privacy: 802.11 Encryption/Decryption 1037 o Fragmentation/Defragmentation 1039 However, some vendors may choose to classify some of the above 1040 "non-real time" functions as real-time functions, in order to support 1041 specific applications with strict QoS requirements. For example 1042 Reassociation is sometimes implemented as "real-time" function in 1043 order to support VoIP applications. 1045 The non-real-time aspects of the 802.11 MAC are handled by the AC, 1046 through the processing of raw 802.11 management frames (Split MAC). 1047 The following matrix in Figure 10 offers a tabular representation of 1048 the design choices made by the six vendors that follow the Split MAC 1049 design with respect to the architecture considerations. While most 1050 vendors support L3 connectivity between WTPs and ACs, some vendors 1051 can only support L2 switched connections, due to the tighter delay 1052 constraint resulting from splitting MAC between two physical entities 1053 across a network. Comparing to Figure 7, it is clear that the 1054 commonality between Split MAC and Local MAC is that the 802.11 1055 control frames are all processed by the WTP, while the difference 1056 lies in the termination point for 802.11 management frames. Local 1057 MAC terminates 802.11 management frames at WTP, while at least some 1058 of the 802.11 management frames are terminated at the AC for the 1059 Split MAC Architecture. In most cases, since WTP devices are 1060 IP-addressable, any of the direct connection, L2-switched, or 1061 L3-routed connections of Section 2.2 can be used. In the case where 1062 only Ethernet-encapsulation is performed (e.g., as in Architecture 4) 1063 then only direct connection and L2-switched connections are 1064 supported. 1066 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 1067 ----- ----- ----- ----- ----- ----- 1069 WTP-AC 1070 connectivity L3 L3 L3 L2 L3 L3 1072 802.11 mgmt 1073 termination AC AC AC AC AC/WTP AC 1075 802.11 control 1076 termination WTP WTP WTP WTP WTP WTP 1078 802.11 data 1079 aggregation AC AC AC AC AC AC 1081 Figure 10: Architecture Considerations for Split MAC Architecture 1083 Similar to the Local MAC Architecture, the following matrix in Figure 1084 11 shows that most of the CAPWAP control functions are implemented at 1085 the AC, with the exception of RF monitoring and in some cases RF 1086 configuration being done locally at the WTPs. 1088 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 1089 ----- ----- ----- ----- ----- ----- 1090 RF 1091 Monitoring WTP WTP WTP WTP WTP WTP 1093 RF 1094 Config. AC/WTP AC/WTP AC AC AC 1096 WTP config. AC AC AC AC AC 1098 WTP 1099 Firmware AC AC AC AC AC 1101 STA state 1102 info 1103 database AC AC AC AC AC 1105 AC/WTP 1106 mutual 1107 authent. AC/WTP AC/WTP AC/WTP AC/WTP 1109 Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture 1111 The most interesting matrix for Split MAC Architecture is the 1112 Functional Distribution Matrix for 802.11 functions, as shown below 1113 in Figure 12. There exists certain regularity in how the vendors map 1114 the functions onto the WTPs and AC. For example, all vendors choose 1115 to implement Distribution, Integration Service at the AC, along with 1116 802.1X/EAP authentication and keys management. All vendors also 1117 choose to implement beacon generation at WTPs. On the other hand, it 1118 is also clear that vendors choose to map many of the other functions 1119 differently. Therefore, Split MAC Architectures are not consistent 1120 regarding the exact way the MAC is split. 1122 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 1123 ----- ----- ----- ------ ----- ----- 1125 Distribution 1126 Service AC AC AC AC AC AC 1128 Integration 1129 Service AC AC AC AC AC AC 1131 Beacon 1132 Generation WTP WTP WTP WTP WTP WTP 1133 Probe 1134 Response WTP AC/WTP WTP WTP WTP WTP 1136 Power mgmt 1137 Packet 1138 Buffering WTP WTP WTP AC AC/WTP WTP 1140 Fragmentation 1141 Defragment. WTP WTP AC AC AC 1143 Association 1144 Disassoc. 1145 Reassociation AC AC AC AC WTP AC 1147 WME/11e 1148 -------------- 1149 classifying AC AC AC AC 1151 scheduling WTP/AC AC WTP AC AC WTP/AC 1153 queuing WTP/AC WTP WTP AC WTP WTP 1155 Authentication 1156 and Privacy 1157 -------------- 1159 802.1X/EAP AC AC AC AC AC AC 1161 Keys 1162 Management AC AC AC AC AC AC 1164 802.11 1165 Encryption/ 1166 Decryption WTP AC WTP AC AC AC 1168 Figure 12: Mapping of 802.11 Functions for Split MAC Architecture 1170 5.5 Remote MAC 1172 One of the main motivations for the Remote MAC Architecture is to 1173 keep the WTPs as light weight as possible, by having only the radio 1174 interfaces on the WTPs and offloading the entire set of 802.11 MAC 1175 functions (including delay-sensitive ones) to the Access Controller. 1176 This leaves all the complexities of the MAC and other CAPWAP control 1177 functions to the centralized controller. 1179 The WTP acts only as a pass-through between the Wireless LAN clients 1180 (STA) and the AC, though they may have an additional feature to 1181 convert the frames from one format (802.11) to the other (Ethernet, 1182 TR, Fiber etc.). The centralized controller provides network 1183 monitoring, management and control, entire set of the 802.11 AP 1184 services, security features, resource management, channel selection 1185 features, guarantees of Quality of Service to the users, etc. 1186 Because the MAC is separated from the PHY, we call this the "Remote 1187 MAC Architecture". Typically such architecture is deployed with 1188 special attention to the connectivity between the WTPs and AC so that 1189 the delay is minimized. The RoF (Radio over Fiber) from Architecture 1190 5 is such an example of Remote MAC Architecture. 1192 5.6 Comparisons of Local MAC, Split MAC and Remote MAC 1194 Two commonalities across all the three Centralized Architectures 1195 (Local MAC, Split MAC and Remote MAC) are: 1196 o Most of the CAPWAP functions related to network control and 1197 configuration reside on the AC. 1198 o IEEE 802.11 PHY resides on the WTP. 1200 The difference between Remote MAC and the other two Centralized 1201 Architectures (namely, Local MAC and Split MAC) is pretty clear, as 1202 the 802.11 MAC is completely separated from the PHY in the former, 1203 while the other two at least keep some portion of the MAC functions 1204 together with PHY at the WTPs. So the implication of PHY and MAC 1205 separation is that it severely limits the kind of interconnection 1206 between WTPs and ACs, so that the 802.11 timing constraints are 1207 satisfied. As pointed out earlier, this usually results in tighter 1208 constraint over the interconnection between WTP and AC for the Remote 1209 MAC Architecture. The advantage of Remote MAC Architecture is that 1210 it offers the lightest possible WTPs for certain deployment 1211 scenarios. 1213 The commonalities and differences between Local MAC and Split MAC are 1214 most clearly seen by comparing Figure 7 and Figure 10. The 1215 commonality between the two is that 802.11 control frames are 1216 terminated at WTPs in both cases. The main difference between Local 1217 MAC and Split MAC is that in the latter the WTP terminates only the 1218 802.11 control frames, while in the former the WTP may terminate all 1219 802.11 frames. An interesting consequence of this difference is that 1220 the Integration Service, which essentially refers to bridging between 1221 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, 1222 but can be part of either the AC or WTP in the Local MAC. 1224 As a second note, the Distribution Service, although usually provided 1225 by the AC, can also be implemented at the WTP in some Local MAC 1226 architectures. The rationale behind this approach is to increase 1227 performance in delivering STAs data traffic by avoiding tunnelling it 1228 to the AC, and also relax the dependency of the WTP from the AC. 1229 Therefore, it is possible that the data and control planes are 1230 separated in the Local MAC Architecture. 1232 Even though all the 802.11 traffic is aggregated at ACs in the case 1233 of Split MAC Architecture, the data plane and control plane can still 1234 be separated by employing multiple ACs. For example, one AC can 1235 implement most of the CAPWAP functions (control plane), while other 1236 ACs can be used for 802.11 frames bridging (data plane). 1238 Each of the three architectural variants may be advantageous in 1239 certain aspects for certain deployment scenarios. While Local MAC 1240 retains most of the STAs' state information at the local WTPs, Remote 1241 MAC centralizes most of the state into the backend AC. Split MAC 1242 sits somewhat in the middle of this spectrum, keeping some state 1243 information locally at the WTPs, and the rest centrally at the AC. 1244 Many factors should be taken into account to determine the exact 1245 balance desired between centralized v.s. decentralized state. The 1246 impact of such balance on network manageability is currently a matter 1247 of dispute within the technical community. 1249 5.7 Communication Interface between WTPs and ACs 1251 Before any messages can be exchanged between an AC and WTP, the WTP 1252 needs to discover, authenticate and register with the AC first, then 1253 download the firmware and establish control channel with the AC. 1254 Message exchanges between the WTP and AC for control and 1255 configuration can happen after that. The following list outlines the 1256 basic operations that are typically performed between the WTP and the 1257 AC in the typical order: 1258 1. Discovery : The WTPs discover the AC with which they will be 1259 bound to and controlled by. The discovery procedure can employ 1260 either static or dynamic configuration. In the latter case, a 1261 protocol is used in order for the WTP to discover candidate 1262 AC(s). 1263 2. Authentication: After discovery, the WTP device authenticates 1264 itself with the AC. However, mutual authentication, in which the 1265 WTP also authenticates the AC, is not always supported since some 1266 vendors strive for zero-configuration on the WTP side. This is 1267 not necessarily secure as it leaves the possible vulnerability of 1268 the WTP being attached to a rogue AC. 1269 3. WTP Association: After successful authentication, an WTP 1270 registers with the AC, in order to start receiving management and 1271 configuration messages. 1272 4. Firmware Download: After successful association, the WTP may 1273 pull, or the AC may push the WTPs firmware, which may be 1274 protected by some manner, such as digital signatures. 1276 5. Control Channel Establishment: The WTP establishes either an 1277 IP-tunnel or performs Ethernet encapsulation with the AC, in 1278 order to transfer data traffic and management frames. 1279 6. Configuration Download: Following the control channel 1280 establishment process, the AC may push configuration parameters 1281 to the WTPs. 1283 5.8 Security 1285 Given the varied distribution of functionalities for the Centralized 1286 Architecture as surveyed in Section 4.3, it is obvious that an extra 1287 network binding is created between the WTP and the AC. This brings 1288 along new and unique security issues and subsequent requirements. 1290 5.8.1 Client Data Security 1292 The survey shows clearly that the termination point for "over the 1293 air" 802.11 encryption [4] can be implemented either in the WTP or in 1294 the AC. Furthermore, the 802.1X/EAP [6] functionality is also 1295 distributed between the WTP and the AC where, in almost all cases, 1296 the AC performs the necessary functions as the authenticator in the 1297 802.1X exchange. 1299 If the STA and AC are the parties in the 4-way handshake (defined in 1300 [4]), and 802.11i traffic encryption terminates at the WTP, then the 1301 PTK (Pairwise Transient Key) has to be transferred from the AC to the 1302 WTP. Since the keying material is part of the control and 1303 provisioning of the WTPs, a secure encrypted tunnel for control 1304 frames is employed to transport the keying material. 1306 The centralized model encourages AC implementations to use one PMK 1307 for many different WTPs. This practice facilitates speedy transition 1308 by a STA from one WTP to another WTP that is connected to the same AC 1309 without establishing a separate PMK. However, this leaves the STA in 1310 a difficult position. The STA cannot distinguish between a 1311 compromised PMK and one that is intentionally being shared. This 1312 issue must be resolved, but the resolution is beyond the scope of the 1313 CAPWAP working group. The venue for this resolution is to be 1314 determined by the IEEE 802 and IETF liaisons. 1316 In the case where the 802.11i encryption/decryption is performed in 1317 the AC, the key exchange and state transitions occur between the AC 1318 and the STA. Therefore, there is no need to transfer any crypto 1319 material between the AC and the WTP. 1321 Regardless of 802.11i termination point, the Centralized WLAN 1322 Architecture records two practices for "over the wire" client data 1323 security. In some cases there is an encrypted tunnel (IPsec or SSL) 1324 between the WTP and AC which assumes the security boundary to be in 1325 the AC. In other cases an end-to-end mutually authenticated secure 1326 VPN tunnel is assumed between the client and AC, other security 1327 gateway or end host entity. 1329 5.8.2 Security of Control Channel between the WTP and AC 1331 In order for the CAPWAP functions to be implemented in the 1332 Centralized WLAN Architecture it is necessary for a control channel 1333 to exist between the WTP and AC. 1335 In order to address potential security threats against the control 1336 channel, existing implementations feature one or more of the 1337 following security mechanisms: 1338 1. Secure discovery of WTP and AC. 1339 2. Authentication of the WTPs to the ACs (and possibly mutual 1340 authentication). 1341 3. Confidentiality, integrity, and replay protection of control 1342 channel frames. 1343 4. Secure management of WTPs and ACs, including mechanisms for 1344 securely setting and resetting secrets and state. 1346 Discovery and authentication of WTPs are addressed in the submissions 1347 by implementing authentication mechanisms that range from X.509 1348 certificates, AAA authentication to pre-shared credential 1349 authentication. In all cases, the issues of confidentiality, 1350 integrity and protection against man-in-the-middle attacks of the 1351 control frames are addressed by a secure encrypted tunnel between WTP 1352 and AC(s), utilizing keys derived from the varied authentication 1353 methods mentioned previously. Finally, one of the motivations for 1354 the Centralized WLAN Architecture is to minimize the storage of 1355 cryptographic and security sensitive information, in addition to 1356 operational configuration parameters within the WTPs. It is for that 1357 reason that the majority of the submissions under the Centralized 1358 Architecture category have employed a post WTP authenticated 1359 discovery phase of configuration provisioning, which in turn protects 1360 against the theft of WTPs. 1362 5.8.3 Physical Security of WTPs and ACs 1364 In order to provide comprehensive radio coverage, WTPs are often 1365 installed in locations that are difficult to secure physically; it is 1366 relatively easier to secure the AC physically. If high-value 1367 secrets, such as a RADIUS shared secret, are stored in the AC instead 1368 of WTPs, then the physical loss of an WTP does not compromise these 1369 secrets. Hence, the Centralized Architecture may reduce the security 1370 consequences of a stolen WTP. 1372 On the other hand, concentrating all of the high-value secrets in one 1373 place makes the AC an attractive target, so strict physical, 1374 procedural and technical controls are needed to protect the secrets. 1376 6. Distributed Mesh Architecture 1378 Out of the 16 architecture survey submissions, 3 belong to the 1379 Distributed Mesh Architecture family. An example of the Distributed 1380 Mesh Architecture is shown in Figure 13, which reflects some of the 1381 common characteristics found in these 3 submissions. 1383 +-----------------+ +-----------------+ 1384 | 802.11 BSS 1 | | 802.11 BSS 2 | 1385 | ... | | ... | 1386 | +---------+ | | +---------+ | 1387 +----|mesh node|--+ +----|mesh node|--+ 1388 +-+---+---+ +-+-+-----+ 1389 | | | | 1390 | | | | +----------+ 1391 | +-----------------------+ | Ethernet | Ethernet | 1392 | 802.11 wireless links | +--------+ Switch | 1393 | +-----------------------+ | | | | 1394 | | | | | +----------+ 1395 +-+---+---+ +-+--+----+ 1396 +----|mesh node|--+ +----|mesh node|--+ 1397 | +---------+ | | +---------+ | 1398 | ... | | ... | 1399 | 802.11 BSS 4 | | 802.11 BSS 3 | 1400 +-----------------+ +-----------------+ 1402 Figure 13: Example of Distributed Mesh Architecture 1404 6.1 Common Characteristics 1406 One of the main characteristics of these mesh architecture 1407 submissions is that mesh nodes in the network may act as APs to the 1408 client stations in their respective BSS, as well as traffic relays to 1409 neighboring mesh nodes via 802.11 wireless links, in order to provide 1410 wider wireless coverage. It is also possible that some of the mesh 1411 nodes in the network may serve only as wireless traffic relays for 1412 other mesh nodes, but not as APs for any client stations. Instead of 1413 pulling Ethernet cable connections to every AP, wireless mesh 1414 networks provide an attractive alternative to relaying backhaul 1415 traffic. 1417 Another key characteristic of these mesh architecture submissions is 1418 that mesh nodes can keep track of the state of their neighboring 1419 nodes, or even nodes beyond their immediate neighborhood, by 1420 exchanging information periodically amongst them; this way, mesh 1421 nodes can be fully aware of the dynamic network topology and RF 1422 conditions around them. Such peer-to-peer communication model allows 1423 mesh nodes to actively coordinate among themselves to achieve 1424 self-configuration and self-healing. This is the major distinction 1425 between this Distributed Architecture family and the Centralized 1426 Architecture -- much of the CAPWAP functions can be implemented 1427 across the mesh nodes in a distributed fashion, without a centralized 1428 entity making all the control decisions. 1430 On the other hand, it is worthwhile to point out that mesh networks 1431 do not necessarily preclude the use of centralized control. It is 1432 possible that a combination of centralized and distributed control 1433 co-exists in mesh networks. Some global configuration or policy 1434 change may be better served in a coordinated fashion if some form of 1435 Access Controller (AC) exists in the mesh network, even if not the 1436 full blown version of the AC as defined in the Centralized WLAN 1437 Architecture. For example, a centralized management entity can be 1438 used to update every mesh node's default configuration; it may also 1439 be more desirable to leave certain functions such as user 1440 authentication to a single centralized end point (such as a RADIUS 1441 server), but mesh networks allow the possibility of each mesh AP to 1442 directly talk to the RADIUS server. This eliminates the single point 1443 of failure and takes advantage of the client distribution in the 1444 network. 1446 The backhaul transport network of the mesh network can be either an 1447 L2 or L3 networking technology. Currently, vendors are using 1448 proprietary mesh technologies on top of standard 802.11 wireless 1449 links to enable peer-to-peer communication between the mesh nodes, 1450 and hence no interoperability exists among mesh nodes from different 1451 vendors. The IEEE 802.11 WG has recently started a new Task Group 1452 (TGs) to define the mesh standard for 802.11. 1454 6.2 Security 1456 Similar security concerns for client data security as described in 1457 Section 5.8.1 also apply to the Distributed Mesh Architecture. 1458 Additionally, one important security consideration for the mesh 1459 networks is that the mesh nodes must authenticate each other within 1460 the same administrative domain. Also to protect user and management 1461 data that may not be secured at layer 3, data transmission among 1462 neighboring nodes should be secured by a layer 2 mechanism of 1463 confidentiality, integrity and replay protection. 1465 7. Summary and Conclusions 1467 We requested existing WLAN vendors and other interested parties to 1468 submit a short description of existing or desired WLAN access network 1469 architectures to define a taxonomy of possible WLAN access network 1470 architectures. The information from the 16 submissions was condensed 1471 and summarized in this document. 1473 New terminology has been defined wherever existing terminology was 1474 found to be either insufficient or ambiguous in describing the WLAN 1475 architectures and supporting functions listed in the document. For 1476 example, the broad set of Access Point functions has been divided 1477 into two categories - 802.11 functions which include those that are 1478 required by the IEEE 802.11 standards, and CAPWAP functions which 1479 include those that are not required by the IEEE 802.11, but are 1480 deemed essential for control, configuration, and management of 802.11 1481 WLAN access networks. Another term that has caused considerable 1482 ambiguity is "Access Point", which was usually tied to reflect a 1483 physical box that has the antennas, but did not have a uniform set of 1484 externally consistent behavior across all submissions. To remove 1485 this ambiguity, we have re-defined the AP to be the set of 802.11 and 1486 CAPWAP functions, while the physical box that terminates the 802.11 1487 PHY is called the Wireless Termination Point. 1489 Based on the submissions during the architectural survey phase, we 1490 have classified the existing WLAN architectures into three broad 1491 classes: 1492 1. Autonomous WLAN Architecture indicates a family of architectures 1493 where all the 802.11 functions and, where applicable, CAPWAP 1494 functions are implemented in the WTPs. 1495 2. Centralized WLAN Architecture indicates a family of architectures 1496 where the AP functions are split between the WTPs and the AC with 1497 the AC, typically, acting as a centralized control point for 1498 multiple WTPs. 1499 3. Distributed WLAN Architecture indicates a family of architectures 1500 where part of the control functions are implemented across a 1501 distributed network of peer entities. 1503 Within the Centralized WLAN Architecture, there are a few 1504 sub-categories that are visible depending on how one maps the MAC 1505 functions, at a high-level, between the WTP and the AC. Three 1506 prominent ones emerged from the information present in the 1507 submissions: 1508 1. Split MAC Architecture, where the 802.11 MAC functions are split 1509 between the WTP and the AC. This subgroup includes all 1510 architectures that split the 802.11 MAC functions even though 1511 individual submissions differed on the specifics of the split. 1513 2. Local MAC Architecture, where the entire set of 802.11 MAC 1514 functions is implemented on the WTP. 1515 3. Remote MAC Architecture, where the entire set of 802.11 MAC 1516 functions is implemented on the AC. 1518 The following tree diagram summarizes the architectures documented in 1519 this taxonomy. 1521 +----------------+ 1522 |Autonomous | 1523 +---------->|Architecture | 1524 | |Family | 1525 | +----------------+ 1526 | +--------------+ 1527 | |Local | 1528 | +---->|MAC | 1529 | | |Architecture | 1530 | | +--------------+ 1531 | | 1532 | +----------------+ | +--------------+ 1533 | |Centralized | | |Split | 1534 +---------->|Architecture |--+---->|MAC | 1535 | |Family | | |Architecture | 1536 | +----------------+ | +--------------+ 1537 | | 1538 | | +--------------+ 1539 | | |Remote | 1540 | +---->|MAC | 1541 | |Architecture | 1542 | +--------------+ 1543 | +----------------+ 1544 | |Distributed Mesh| 1545 +---------->|Architecture | 1546 |Family | 1547 +----------------+ 1549 A majority of the submitted WLAN access network architectures (12 out 1550 of 16) followed the Centralized WLAN Architecture. All but one of 1551 the centralized WLAN architecture submissions were grouped into 1552 either a Split MAC architecture or a Local MAC architecture. There 1553 was one submission that followed the Autonomous WLAN Architecture. 1554 There were three submissions under the Distributed WLAN Architecture. 1556 The WLAN access network architectures in the submissions indicated 1557 that the connectivity assumptions were: 1558 o Direct connection between the WTP and the AC. 1560 o L2 switched connection between the WTP and the AC. 1561 o L3 routed connection between the WTP and the AC. 1562 o Wireless connection between the mesh nodes in the distributed mesh 1563 architecture. 1565 Interoperability between equipment from different vendors is one of 1566 the fundamental problems in the WLAN market today. In order to 1567 achieve interoperability via open standard development, the following 1568 next steps are suggested for IETF and IEEE 802.11. 1570 Using this taxonomy, a functional model of an Access Point should be 1571 defined, by the new study group recently formed within the IEEE 1572 802.11. The functional model will consist of defining functional 1573 elements of an 802.11 access point that are considered atomic, i.e. 1574 not subject to further splitting across multiple network elements. 1575 Such a functional model should serve as a common foundation to 1576 support the existing WLAN architectures as outlined in this taxonomy, 1577 and any further architecture development either within or outside of 1578 IEEE 802.11 group. It is possible, and even recommended, that the 1579 work on the functional model definition may also include impact 1580 analysis of implementing each functional element on either the WTP or 1581 the AC. 1583 As part of the functional model definition, interfaces must be 1584 defined in the form of primitives between these functional elements. 1585 If a pair of functional elements that have an interface defined 1586 between them is subject to being implemented on two different network 1587 entities, then a protocol specification between such pair of network 1588 elements is required to be defined, and should be developed by IETF. 1590 8. Security Considerations 1592 A comprehensive threat analysis of all of the security issues with 1593 the different WLAN architectures is not a goal of this document. 1594 Nevertheless, in addition to documenting the architectures employed 1595 in the existing IEEE 802.11 products in the market, this taxonomy 1596 document also catalogs, in a non-exhaustive manner, the security 1597 issues that arise and the manner in which vendors address these 1598 security threats. The WLAN architectures are broadly categorized 1599 into three families: Autonomous Architecture, Centralized 1600 Architecture, and Distributed Architecture. While Section 4, Section 1601 5 and Section 6 are devoted to each of these three architecture 1602 families, respectively, each section also contains a subsection to 1603 address the security issues within each architecture family. 1605 In summary, the main security concern in the Autonomous Architecture 1606 is the mutual authentication between WTP and the wired (Ethernet) 1607 infrastructure equipment. Physical security of the WTPs is also a 1608 network security concern because the WTPs contain secret information 1609 and theft of these devices could potentially compromise even the 1610 wired network. 1612 In the Centralized Architecture there are a few new security 1613 concerns, due to the introduction of the new network binding between 1614 WTP and AC. The following security concerns are raised for this 1615 architecture family: keying material for mobile client traffic may 1616 need to be securely transported from AC to WTP; secure discovery of 1617 WTP and AC is required, as well as mutual authentication between 1618 WTPs and AC; man-in-the-middle attacks to the control channel 1619 between WTP and AC, confidentiality, integrity and replay protection 1620 of control channel frames, and theft of WTPs for extraction of 1621 embedded secrets within. Each of the survey results for this broad 1622 architecture category have presented a variety of mechanisms to 1623 address these security issues. 1625 The new security issue in the Distributed Mesh Architecture is the 1626 need for mesh nodes to authenticate each other before forming a 1627 secure mesh network. It is also recommended that all communication 1628 between mesh nodes be encrypted to protect both control and user 1629 data. 1631 9. Acknowledgements 1633 This taxonomy is truly a collaborative effort with contributions from 1634 a large group of people. First of all, we want to thank all the 1635 CAPWAP Architecture Design Team members who have spent many hours in 1636 the teleconference calls, over emails and in writing and reviewing 1637 the draft. The full Design Team is listed here: 1638 o Peyush Agarwal 1639 STMicroelectronics 1640 Plot# 18, Sector 16A 1641 Noida, U.P 201301 1642 India 1643 Phone: +91-120-2512021 1644 EMail: peyush.agarwal@st.com 1645 o Dave Hetherington 1646 Roving Planet 1647 4750 Walnut St., Suite 106 1648 Boulder, CO 80027 1649 United States 1650 Phone: +1-303-996-7560 1651 EMail: Dave.Hetherington@RovingPlanet.com 1652 o Matt Holdrege 1653 Strix Systems 1654 26610 Agoura Road 1655 Calabasas, CA 91302 1656 Phone: +1 818-251-1058 1657 EMail: matt@strixsystems.com 1658 o Victor Lin 1659 Extreme Networks 1660 3585 Monroe Street 1661 Santa Clara, CA 95051 1662 Phone: +1 408-579-3383 1663 EMail: vlin@extremenetworks.com 1664 o James M. Murphy 1665 Trapeze Networks 1666 5753 W. Las Positas Blvd. 1667 Pleasanton, CA 94588 1668 Phone: +1 925-474-2233 1669 EMail: jmurphy@trapezenetworks.com 1670 o Partha Narasimhan 1671 Aruba Wireless Networks 1672 180 Great Oaks Blvd 1673 San Jose, CA 95119 1674 Phone: +1 408-754-3018 1675 EMail: partha@arubanetworks.com 1676 o Bob O'Hara 1677 Airespace 1678 110 Nortech Parkway 1679 San Jose, CA 95134 1680 Phone: +1 408-635-2025 1681 EMail: bob@airespace.com 1682 o Emek Sadot (see Authors' Addresses) 1683 o Ajit Sanzgiri 1684 Cisco Systems 1685 170 W Tasman Drive 1686 San Jose, CA 95134 1687 Phone: +1 408-527-4252 1688 EMail: sanzgiri@cisco.com 1689 o Singh 1690 Chantry Networks 1691 1900 Minnesota Court 1692 Mississauga, Ontario L5N 3C9 1693 Canada 1694 Phone: +1 905-567-6900 1695 EMail: isingh@chantrynetworks.com 1696 o L. Lily Yang (Editor, see Authors' Addresses) 1697 o Petros Zerfos (see Authors' Addresses) 1699 In addition, we would also like to acknowledge the contributions from 1700 the following individuals who participated in the architecture 1701 survey, and provided detailed input data in preparation of the 1702 taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, 1703 Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao 1704 Addepalli, Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted 1705 Kuo, and Tyan-shu Jou. It is simply impossible to write this 1706 taxonomy without the large set of representative data points that 1707 they provided us. We would also like to thank our CAPWAP WG 1708 co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area 1709 Director, Bert Wijnen, for their unfailing support. 1711 10 Normative References 1713 [1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, . 1716 [2] "CAPWAP Problem Statement", 1717 . 1720 [3] "Key words for use in RFCs to Indicate Requirement Levels", 1721 March 1997, . 1723 [4] "IEEE Std 802.11i: Medium Access Control (MAC) Security 1724 Enhancements", April 2004. 1726 [5] "IEEE Std 802.11h: Spectrum and Transmit Power Management 1727 Extensions in the 5 GHz Band in Europe", October 2003. 1729 [6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001. 1731 Authors' Addresses 1733 L. Lily Yang 1734 Intel Corp. 1735 MS JF3 206, 2111 NE 25th Avenue 1736 Hillsboro, OR 97124 1738 Phone: +1 503-264-8813 1739 EMail: lily.l.yang@intel.com 1741 Petros Zerfos 1742 UCLA - Computer Science Department 1743 4403 Boelter Hall 1744 Los Angeles, CA 90095 1746 Phone: +1 310-206-3091 1747 EMail: pzerfos@cs.ucla.edu 1749 Emek Sadot 1750 Avaya 1751 Atidim Technology Park, Building #3 1752 Tel-Aviv 61131 1753 Israel 1755 Phone: +972-3-645-7591 1756 EMail: esadot@avaya.com 1758 Intellectual Property Statement 1760 The IETF takes no position regarding the validity or scope of any 1761 Intellectual Property Rights or other rights that might be claimed to 1762 pertain to the implementation or use of the technology described in 1763 this document or the extent to which any license under such rights 1764 might or might not be available; nor does it represent that it has 1765 made any independent effort to identify any such rights. Information 1766 on the procedures with respect to rights in RFC documents can be 1767 found in BCP 78 and BCP 79. 1769 Copies of IPR disclosures made to the IETF Secretariat and any 1770 assurances of licenses to be made available, or the result of an 1771 attempt made to obtain a general license or permission for the use of 1772 such proprietary rights by implementers or users of this 1773 specification can be obtained from the IETF on-line IPR repository at 1774 http://www.ietf.org/ipr. 1776 The IETF invites any interested party to bring to its attention any 1777 copyrights, patents or patent applications, or other proprietary 1778 rights that may cover technology that may be required to implement 1779 this standard. Please address the information to the IETF at 1780 ietf-ipr@ietf.org. 1782 Disclaimer of Validity 1784 This document and the information contained herein are provided on an 1785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1787 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1788 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1789 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1792 Copyright Statement 1794 Copyright (C) The Internet Society (2004). This document is subject 1795 to the rights, licenses and restrictions contained in BCP 78, and 1796 except as set forth therein, the authors retain all their rights. 1798 Acknowledgment 1800 Funding for the RFC Editor function is currently provided by the 1801 Internet Society.