CAPWAP Working Group L. Yang (Editor) Internet-Draft Intel Corp. Expires: May 17, 2005 P. Zerfos UCLA E. Sadot Avaya November 16, 2004 Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP) draft-ietf-capwap-arch-06 Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 17, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzing WLAN (Wireless LAN) functions and services and describing the different Yang (Editor), et al. Expires May 17, 2005 [Page 1] Internet-Draft CAPWAP Arch. Taxonomy November 2004 variants in distributing these functions and services among the architectural entities. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . . . 4 2.2 CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . 6 2.3 WLAN Architecture Proliferation . . . . . . . . . . . . . 8 2.4 Taxonomy Methodology and Document Organization . . . . . . 9 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 IEEE 802.11 Definitions . . . . . . . . . . . . . . . . . 11 3.2 Terminology Used in this Document . . . . . . . . . . . . 12 3.3 Terminology Used Historically but Not Recommended . . . . 14 4. Autonomous Architecture . . . . . . . . . . . . . . . . . . . 15 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Centralized WLAN Architecture . . . . . . . . . . . . . . . . 17 5.1 Interconnection between WTPs and ACs . . . . . . . . . . . 18 5.2 Overview of Three Centralized WLAN Architecture Variants . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Local MAC . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4 Split MAC . . . . . . . . . . . . . . . . . . . . . . . . 24 5.5 Remote MAC . . . . . . . . . . . . . . . . . . . . . . . . 29 5.6 Comparisons of Local MAC, Split MAC and Remote MAC . . . . 30 5.7 Communication Interface between WTPs and ACs . . . . . . . 31 5.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.8.1 Client Data Security . . . . . . . . . . . . . . . . . 32 5.8.2 Security of Control Channel between the WTP and AC . . 33 5.8.3 Physical Security of WTPs and ACs . . . . . . . . . . 33 6. Distributed Mesh Architecture . . . . . . . . . . . . . . . . 35 6.1 Common Characteristics . . . . . . . . . . . . . . . . . . 35 6.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 10. Normative References . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . 44 Yang (Editor), et al. Expires May 17, 2005 [Page 2] Internet-Draft CAPWAP Arch. Taxonomy November 2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. Yang (Editor), et al. Expires May 17, 2005 [Page 3] Internet-Draft CAPWAP Arch. Taxonomy November 2004 2. Introduction As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale deployment of WLAN networks is highlighting certain technical challenges. As outlined in [2], management, monitoring and control of large number of Access Points (APs) in the network may prove to be a significant network administration burden. Distributing and maintaining a consistent configuration throughout the entire set of APs in the WLAN is a difficult task. The shared and dynamic nature of the wireless medium also demands effective coordination among the APs to minimize radio interference and maximize network performance. Network security issues, which have always been a concern in WLAN's, present even more challenges in large deployments and new architectures. Recently many vendors have begun offering partially proprietary solutions to address some or all of the above mentioned problems. Since interoperable solutions allow for a broader choice, a standardized interoperable solution addressing the aforementioned problems is desirable. As the first step toward establishing interoperability in the market place, this document attempts to provide a taxonomy of the architectures employed in existing WLAN products. We hope to provide a cohesive understanding of the market practices for the standard bodies involved (including the IETF and IEEE 802.11). This document may be reviewed and utilized by the IEEE 802.11 Working Group as input to their task of defining the functional architecture of an access point. 2.1 IEEE 802.11 WLAN Functions The IEEE 802.11 specifications are wireless standards that specify an "over-the-air" interface between a wireless client (STA) and an Access Point (AP), and also among wireless clients. 802.11 also describes how mobile devices can associate together into a basic service set (BSS). A BSS is identified by a basic service set identifier (BSSID) or name. The WLAN architecture can be considered as a type of 'cell' architecture where each cell is the Basic Service Set (BSS) and each BSS is controlled by the Access Point (AP). When two, or more APs are connected via a broadcast layer 2 network and all are using the same SSID, an extended service set (ESS) is created. The architectural component used to interconnect BSSs is the distribution system (DS). An access point (AP) is a STA that provides access to the DS by providing DS services in addition to acting as a STA. Another logical architectural component -- portal -- is introduced to integrate the IEEE 802.11 architecture with a traditional wired LAN. It is possible for one device to offer both Yang (Editor), et al. Expires May 17, 2005 [Page 4] Internet-Draft CAPWAP Arch. Taxonomy November 2004 the functions of an AP and a portal. IEEE 802.11 explicitly does not specify the details of DS implementations. Instead, the 802.11 standard defines services that provide the functions that the LLC layer requires for sending MAC Service Data Units (MSDUs) between two entities on the network. These services can be classified into two categories: the station service (SS) and the distribution system service (DSS). Both categories of service are used by the IEEE 802.11 MAC sublayer. Station services consist of the following four services: o Authentication: The service used to establish the identity of one station as a member of the set of stations authorized to associate with another station. o Deauthentication: The service that voids an existing authentication relationship. o Confidentiality: The service used to prevent the content of messages from being read by other than the intended recipients. o MSDU Delivery: The service to deliver the MAC service data unit (MSDU) for the Stations. Distribution system services consist of the following five services: o Association: The service used to establish access point/station (AP/STA) mapping and enable STA invocation of the distribution system services. o Disassociation: The service that removes an existing association. o Reassociation: The service that enables an established association [between access point (AP) and station (STA)] to be transferred from one AP to another (or the same) AP. o Distribution: The service that provides MSDU forwarding by APs for the STAs associated with them. MSDUs can be either forwarded to the Wireless destination or to the Wired (Ethernet) destination (or both) using the "Distribution System" concept of 802.11. o Integration: The service that is used to translate the MSDU received from the Distribution System to a non-802.11 format and vice versa. Any MSDU that is received from the DS invokes the "Integration" services of the DSS before the 'Distribution' services are invoked. The point of connection of the DS to the wired LAN is termed as 'portal'. Apart from these services the IEEE 802.11 also defines additional MAC services that must be implemented by the APs in the WLAN. For example: o Beacon Generation o Probe Response/Transmission o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK o Synchronization o Retransmissions Yang (Editor), et al. Expires May 17, 2005 [Page 5] Internet-Draft CAPWAP Arch. Taxonomy November 2004 o Transmission Rate Adaptation o Privacy: 802.11 Encryption/Decryption In addition to the services offered by the 802.11, the IEEE 802.11 WG is also developing technologies to support Quality of Service (802.11e), Security Algorithms (802.11i), Inter-AP Protocol (IAPP, or 802.11F -- recommended practice) to update APs when a STA roams from one BSS to the other, Radio Resource Management (802.11k) etc. IEEE 802.11 does not exactly specify how all these functions get implemented, nor does it specify that these functions be implemented all in one physical device. Conceptually, all it requires is that the APs and the rest of the DS together implement all these services. Typically, vendors implement not only the services defined in the IEEE 802.11 standard, but also a variety of value-added services or functions, such as load balancing support, QoS, station mobility support, rogue AP detection, etc. What will become clear from the rest of this document is that vendors do take advantage of the flexibility in the 802.11 architecture, and have come up with many different flavors of architectures and implementations of the WLAN services. Because many vendors choose to implement these WLAN services across multiple network elements, we want to make a clear distinction between the logical WLAN access network functions, and the individual physical devices, by adopting different terminology from now on. We use "AP" to refer to the logical entity that provides access to the distribution services, and "WTP" (Wireless Termination Point) to the physical device that features RF antenna and 802.11 PHY to transmit and receive station traffic in the BSS network. In one of the architectures discussed later, namely, Centralized Architecture, the combination of WTPs with AC (Access Controller) together implements the logical functions. Each of these physical devices (WTP or AC) may implement only part of the logical functions. But the DS including all the physical devices as a whole implements all, or most of the functions. 2.2 CAPWAP Functions In order to address the four problems identified in the [2] (management, consistent configuration, RF control, security) additional functions, especially in the control plane and management plane, are typically offered by vendors to assist better coordination and control across the entire ESS network. Such functions are especially important when the IEEE 802.11 WLAN functions are implemented across a large scale network of multiple entities, instead of within a single entity. Such functions include: Yang (Editor), et al. Expires May 17, 2005 [Page 6] Internet-Draft CAPWAP Arch. Taxonomy November 2004 o RF monitoring, such as Radar detection, noise and interference detection and measurement. o RF configuration, e.g., for retransmission, channel selection, transmission power adjustment, etc. o WTP configuration, e.g., for SSID, etc. o WTP firmware loading, e.g., automatic loading and upgrading of WTP firmware for network wide consistency. o Network-wide STA state information database, including the information needed to support value-added services, such as mobility, load balancing etc. o Mutual authentication between network entities, e.g., for AC and WTP authentication in a Centralized WLAN Architecture. The services listed are concerned with configuration and control of the radio resource ('RF Monitoring' and 'RF Configuration'), management and configuration of the WTP device ('WTP Configuration', 'WTP Firmware upgrade'), and also security regarding the registration of the WTP to an AC ('AC/WTP mutual authentication'). Moreover, the device from which other services such as mobility management across subnets, and load balancing can obtain state information regarding the STA(s) associated with the wireless network, is also reported as a service ('STA state info database'). The above list of CAPWAP functions does not attempt to be an exhaustive enumeration of all additional services offered by vendors. Instead, we included only those functions that are commonly represented in the survey data, and are also pertinent to the understanding of the central problem of interoperability. Most of these functions are not explicitly specified by IEEE 802.11, but some of the functions are. For example, control and management of the radio-related functions of an AP are described implicitly in the MIB, such as: o Channel Assignment o Transmit Power Control o Radio Resource Measurement (work currently under way in IEEE 802.11k) The 802.11h [5] amendment to the base 802.11 standard specifies the operation of a MAC management protocol to accomplish the requirements of some regulatory bodies (principally in Europe, but expanding to others) in these areas: o RADAR detection o Transmit Power Control o Dynamic Channel Selection Yang (Editor), et al. Expires May 17, 2005 [Page 7] Internet-Draft CAPWAP Arch. Taxonomy November 2004 2.3 WLAN Architecture Proliferation This document provides a taxonomy of the WLAN network architectures developed by the vendor community in an attempt to address some or all of the problems outlined in [2]. As the IEEE 802.11 standard purposely avoids to specify the details of DS implementations, different architectures have proliferated in the market. While all these different architectures conform to the IEEE 802.11 standard as a whole, their individual functional components are not standardized. The interfaces between the network architecture components are mostly proprietary, and there is no guarantee of cross-vendor interoperability of products, even within the same architecture family. In order to achieve interoperability in the market place, the IETF CAPWAP working group is taking on the first logical task of documenting both the functions and the network architectures offered by the existing WLAN vendors today. The end result of this task is this taxonomy document. After analyzing more than a dozen different vendors' architectures, we believe that the existing 802.11 WLAN access network architectures can be broadly categorized into three distinct families, based on the characteristics of the Distribution Systems that are employed to provide the 802.11 functions. o Autonomous WLAN Architecture: The first architecture family is the traditional autonomous WLAN architecture, where each WTP is a single physical device that implements all the 802.11 services, including both the distribution and integration services, and the portal function. Such an AP architecture is called Autonomous WLAN Architecture because each WTP is autonomous in its functionality, and no explicit 802.11 support is needed from devices other than the WTP. The WTP in such architecture is typically configured and controlled individually, and can be monitored and managed via typical network management protocols like SNMP. The WTPs in this architecture are the traditional Access Points most people are familiar with. Sometimes such WTPs are referred to as "Fat APs" or "Standalone APs". o Centralized WLAN Architecture: The second WLAN architecture family is an emerging hierarchical architecture utilizing one or more centralized controllers for managing a large number of WTP devices. The centralized controller is commonly referred to as an Access Controller (AC), whose main function is to manage, control and configure the WTP devices that are present in the network. In addition to being a centralized entity for the control and management plane, it may also become a natural aggregation point for the data plane, since it is typically situated in a centralized location in the wireless access network. The AC is Yang (Editor), et al. Expires May 17, 2005 [Page 8] Internet-Draft CAPWAP Arch. Taxonomy November 2004 often co-located with an L2 bridge, a switch, or an L3 router, and hence may be referred to as Access Bridge, or Access Router in those particular cases. Therefore, an Access Controller could be either an L3 or L2 device, and Access Controller is the generic terminology we use throughout this document. It is also possible that multiple ACs are present in a network for purposes of redundancy, load balancing, etc. This architecture family has several distinct characteristics that are worth noting. First, the hierarchical architecture and the centralized AC afford much better manageability for the large scale networks. Second, since the IEEE 802.11 functions and the CAPWAP control functions are provided by the WTP devices and the AC together, the WTP devices themselves may not implement the full 802.11 functions as defined in the standards any more. Therefore, it can be said that the full 802.11 functions are implemented across multiple physical network devices, namely, the WTPs and ACs. Since the WTP devices only implement a portion of the functions that standalone APs implement, WTP devices in this architecture are sometimes referred to as light weight or thin APs by some vendors. o Distributed WLAN Architecture: The third emerging WLAN architecture family is the distributed architecture in which the participating wireless nodes are capable of forming a distributed network among themselves, via either wired or wireless media. A wireless mesh network is one example in the distributed architecture family, where the nodes themselves form a mesh network, and connect with neighboring mesh nodes via 802.11 wireless links. Some of these nodes also have wired Ethernet connections, acting as gateways to the external network. 2.4 Taxonomy Methodology and Document Organization Before the IETF CAPWAP working group started documenting the various WLAN architectures, we conducted an open survey soliciting WLAN architecture description contributions via the IETF CAPWAP mailing list. We provided the interested parties with a common template that included a number of questions about their WLAN architectures. We received 16 contributions in the form of short text descriptions answering those questions. 15 of them are from WLAN vendors (AireSpace, Aruba, Avaya, Chantry Networks, Cisco, Cranite Systems, Extreme Networks, Intoto, Janusys Networks, Nortel, Panasonic, Trapeze, Instant802, Strix Systems, Symbol) and one from the academic research community (UCLA). Out of the 16 contributions, one describes an Autonomous WLAN Architecture, three are Distributed Mesh Architectures, while the rest twelve entries represent architectures that fall into the family of Centralized WLAN Architecture. The main objective of this survey is to identify the general categories and trends in WLAN architecture evolution, discover their Yang (Editor), et al. Expires May 17, 2005 [Page 9] Internet-Draft CAPWAP Arch. Taxonomy November 2004 common characteristics, determine what is performed differently among them, and why. In order to represent the survey data in a compact format, a "Functional Distribution Matrix" is used in this document, mostly in the Centralized WLAN architecture section, to tabulate the various services and functions in the vendors' offerings. These services and functions are classified into three main categories: o Architecture Considerations: the choice of the connectivity between the AC and the WTP; the design choices regarding the physical device on which processing of management, control, and data frames of the 802.11 takes place. o 802.11 Functions: as described in Section 2.1. o CAPWAP Functions: as described in Section 2.2. For each one of these categories, the mapping of each individual function to network entities implemented by each vendor is shown in tabular form. The rows in the Functional Distribution Matrix represent the individual functions that are organized into the above mentioned three categories, while each column of the Matrix represents one vendor's architecture offering in the survey data. See Figure 7 as an example of the Matrix. This Functional Distribution Matrix is intended for the sole purpose of organizing the architecture taxonomy data, and represents the contributors' view of their architectures, from an engineering perspective. It does not necessarily imply an existing product, shipping or not, nor an intent by the vendor to build such a product. The next section provides a list of definitions used in this document, some defined by IEEE 802.11 while others by this document. The rest of this document is organized around the three broad WLAN architecture families that were introduced in Section 2.3. Each architecture family is discussed in a separate section. The section on Centralized Architecture contains more in-depth details than the other two families, largely due to the large number of the survey data (12 out of 16) collected that fall into the Centralized Architecture category. Summary and conclusions are provided at the end of the document to highlight the basic findings from this taxonomy exercise. Yang (Editor), et al. Expires May 17, 2005 [Page 10] Internet-Draft CAPWAP Arch. Taxonomy November 2004 3. Definitions 3.1 IEEE 802.11 Definitions Station (STA): A device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Access Point (AP): An entity that has station functionality and provides access to distribution services, via the wireless medium (WM) for associated stations. Basic Service Set (BSS): A set of stations controlled by a single coordination function. Station Service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations, within a basic service set (BSS). Distribution System (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). Extended Service Set (ESS): A set of one or more interconnected basic service sets (BSSs) with the same SSID and integrated local area networks (LANs), which appears as a single BSS to the logical link control layer at any station associated with one of those BSSs. Portal: The logical point at which medium access control (MAC) service data units (MSDUs) from a non-IEEE 802.11 local area network (LAN) enter the distribution system (DS) of an extended service set (ESS). Distribution System Service (DSS): The set of services provided by the distribution system (DS) that enable the medium access control (MAC) layer to transport MAC service data units (MSDUs) between stations that are not in direct communication with each other, over a single instance of the wireless medium (WM). These services include transport of MSDUs between the access points (APs) of basic service sets (BSSs) within an extended service set (ESS), transport of MSDUs between portals and BSSs within an ESS, and transport of MSDUs between stations in the same BSS in cases where the MSDU has a multicast or broadcast destination address, or where the destination is an individual address, but the station sending the MSDU chooses to involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs. Integration: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution Yang (Editor), et al. Expires May 17, 2005 [Page 11] Internet-Draft CAPWAP Arch. Taxonomy November 2004 system (DS) and an existing, non-IEEE 802.11 local area network (via a portal). Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS). 3.2 Terminology Used in this Document One of the motivations in defining new terminology in this document is to clarify some of the ambiguity and confusion surrounding some conventional terms. One such term is "Access Point (AP)". Typically ,when people talk about "AP", they refer to the physical entity (box) that has an antenna, implements 802.11 PHY and receives/transmits the station (STA) traffic over the air. However, the 802.11 Standard [1] describes the AP mostly as a logical entity that implements a set of logical services so that station traffic can be received and transmitted effectively over the air. So when people refer to "AP functions", they usually mean the logical functions the whole WLAN access network supports, and not just the subset of functions supported by the physical entity (box) that the STAs communicate to directly. Such confusion can be especially acute when the logical functions is implemented across a network instead of within a single physical entity. So to avoid further confusion, we define the following terminology used in this document: CAPWAP: Control and Provisioning of Wireless Access Points. IEEE 802.11 WLAN Functions: a set of logical functions defined by the IEEE 802.11 Working Group, including all the MAC services, Station Services, and Distribution Services. These logical functions are required to be implemented in the IEEE 802.11 Wireless LAN (WLAN) access networks by the IEEE 802.11 Standard[1]. CAPWAP Functions: a set of WLAN control functions that are not directly defined by IEEE 802.11 Standards, but deemed essential for effective control, configuration and management of 802.11 WLAN access networks. Wireless Termination Point (WTP): the physical or network entity that contains RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks. Such physical entities are often called "Access Points" (AP) previously, but "AP" can also be used to refer to the logical entity that implements 802.11 services. So we recommend "WTP" as the generic term used to explicitly refer to the physical entity with the above property (i.e. featuring an RF antenna and 802.11 PHY), applicable to network entities of both Autonomous and Centralized WLAN Architecture (see Yang (Editor), et al. Expires May 17, 2005 [Page 12] Internet-Draft CAPWAP Arch. Taxonomy November 2004 below). Autonomous WLAN Architecture: the WLAN access network architecture family in which all the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented within each Wireless Termination Point (WTP) in the network. The WTPs in such networks are also called standalone APs, or fat APs, because these devices implement the full set of functions that enable the devices to operate without any other support from the network. Centralized WLAN Architecture: the WLAN access network architecture family in which the logical functions, including both IEEE 802.11 and CAPWAP functions (wherever applicable), are implemented across a hierarchy of network entities. At the low level of such hierarchy are the WTPs while at the higher level are the Access Controllers (ACs), which are responsible to control, configure and manage the entire WLAN access networks. Distributed WLAN Architecture: the WLAN access network architecture family in which some of the control functions (e.g., CAPWAP functions) are implemented across a distributed network consisting of peer entities. A wireless mesh network can be considered as an example of such an architecture. Access Controller (AC): The network entity in the Centralized WLAN architectures that provides WTPs access to the centralized hierarchical network infrastructure, either in the data plane, control plane, management plane, or a combination therein. Standalone WTP: referred to the WTP in Autonomous WLAN Architecture. Controlled WTP: referred to the WTP in Centralized WLAN Architecture. Split MAC Architecture: A sub-group of the Centralized WLAN Architecture, with the characteristic that WTPs in such WLAN access networks only implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while tunneling all the remaining management and data frames to AC for centralized processing. The IEEE 802.11 MAC, as defined by IEEE 802.11 Standards in [1], is effectively split between the WTP and AC. Remote MAC Architecture: A sub-group of the Centralized WLAN Architecture, where the entire set of 802.11 MAC functions (including delay-sensitive functions) is implemented at the AC. The WTP terminates the 802.11 PHY functions. Local MAC Architecture: A sub-group of the Centralized WLAN Architecture, where the majority or entire set of 802.11 MAC Yang (Editor), et al. Expires May 17, 2005 [Page 13] Internet-Draft CAPWAP Arch. Taxonomy November 2004 functions (including most of the 802.11 management frame processing) are implemented at the WTP. Therefore, the 802.11 MAC stays intact and local in the WTP, along with PHY. 3.3 Terminology Used Historically but Not Recommended While some terminology has been used by vendors historically to describe "Access Points", we recommend to defer its use, in order to avoid further confusion. A list of such terms and the recommended new terminology is provided below: Split WLAN Architecture: use Centralized WLAN Architecture. Hierarchical WLAN Architecture: use Centralized WLAN Architecture. Standalone Access Point: use Standalone WTP. Fat Access Point: Use Standalone WTP. Thin Access Point: use Controlled WTP. Light weight Access Point: Use Controlled WTP. Split AP Architecture: use Local MAC Architecture. Antenna AP Architecture: use Remote MAC Architecture. Yang (Editor), et al. Expires May 17, 2005 [Page 14] Internet-Draft CAPWAP Arch. Taxonomy November 2004 4. Autonomous Architecture 4.1 Overview Figure 1 shows an example network of the Autonomous WLAN Architecture. This architecture implements all the 802.11 functionality in a single physical device, the Wireless Termination Point (WTP). A common embodiment of this architecture is a WTP that translates between 802.11 frames to/from its radio interface and 802.3 frames to/from an Ethernet interface. An 802.3 infrastructure that interconnects the Ethernet interfaces of different WTPs together provides the distribution system. It can also provide portals for integrated 802.3 LAN segments. +---------------+ +---------------+ +---------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | | ... | | ... | | ... | | +-----+ | | +-----+ | | +-----+ | +----| WTP |----+ +----| WTP |----+ +----| WTP |----+ +--+--+ +--+--+ +--+--+ |Ethernet | | +------------------+ | +------------------+ | | | +---+--+--+---+ | Ethernet | 802.3 LAN --------------+ Switch +-------------- 802.3 LAN segment 1 | | segment 2 +------+------+ Figure 1: Example of Autonomous WLAN Architecture A single physical WTP can optionally be provisioned as multiple virtual WTPs, by supporting multiple SSIDs to which 802.11 clients may associate. In some cases, this will also involve putting a corresponding 802.1Q VLAN tag on each packet forwarded to the Ethernet infrastructure and removal of 802.1Q tags prior to forwarding the packets to the wireless medium. The scope of the ESS(s) created by interconnecting the WTPs will be confined by the constraints imposed by the Ethernet infrastructure. Authentication of 802.11 clients may be performed locally by the WTP or by using a centralized authentication server. 4.2 Security Since both the 802.11 and CAPWAP functionality is tightly integrated into a single physical device, security issues with this architecture Yang (Editor), et al. Expires May 17, 2005 [Page 15] Internet-Draft CAPWAP Arch. Taxonomy November 2004 are confined to the WTP. There are no extra implications from the client authentication and encryption/decryption perspective as the AAA interface is integrated into the WTP, so is the key generation mechanisms required for 802.11i encryption/decryption. One of the security issues in this architecture is the need for mutual authentication between the WTP and the Ethernet infrastructure. This can be ensured by existing mechanisms such as 802.1X between the WTP and the Ethernet switch it connects to. Another critical security issue with this architecture is the very fact that the WTP is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personnel of pushing a "template" to all devices, theft of such a device would potentially compromise the wired network. Yang (Editor), et al. Expires May 17, 2005 [Page 16] Internet-Draft CAPWAP Arch. Taxonomy November 2004 5. Centralized WLAN Architecture Centralized WLAN Architecture is an emerging architecture family in the WLAN market. Contrary to the Autonomous WLAN Architecture where the 802.11 functions and network control functions are all implemented within each Wireless Termination Point (WTP), the Centralized WLAN Architecture employs one or multiple centralized controllers, called Access Controller(s), to enable network-wide monitoring, improve management scalability, and facilitate dynamic configurability. The following figure shows schematically the Centralized WLAN Architecture network diagram, where the Access Controller (AC) connects to multiple Wireless Termination Points (WTPs) via an interconnection medium. This can be either a direct connection, an L2-switched, or an L3-routed network as described in Section 5.1. The AC exchanges configuration and control information with the WTP devices, allowing the management of the network from a centralized point. Also, designs of the Centralized WLAN Architecture family do not presume (as the diagram might suggest to some readers) that the AC necessarily intercedes in the data plane to/from the WTP(s). More details are provided later in this section. +---------------+ +---------------+ +---------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | 802.11 BSS 3 | | ... | | ... | | ... | | +-------+ | | +-------+ | | +-------+ | +----| WTP |--+ +----| WTP |--+ +----| WTP |--+ +---+---+ +---+---+ +---+---+ | | | +------------------+ | +-----------------+ | |...| +----+--+---+--------+ | Interconnection | +-------+------------+ | | +-----+----+ | AC | +----------+ Figure 2: Centralized WLAN Architecture Diagram In the diagram above, the AC is shown as a single physical entity that provides all of the CAPWAP functions listed in section 2.2. But that may not be always the case. Closer examination of the functions reveals that their different resource requirements (e.g. CPU, memory, storage) may lend themselves to being distributed across Yang (Editor), et al. Expires May 17, 2005 [Page 17] Internet-Draft CAPWAP Arch. Taxonomy November 2004 different devices. For instance, complex radio control algorithms can be CPU intensive. Storing and downloading images and configurations can be storage intensive. Therefore different CAPWAP functions might be implemented on different physical devices due to the different nature of their resource requirements. The network entity marked 'AC' in the diagram above should accordingly be thought of as a multiplicity of logical functions, and not necessarily as a single physical device. The AC(s) may also choose to implement some of the control functions locally while providing interfaces to access other global network management functions which are typically implemented on separate boxes, such as a SNMP Network Management Station and an AAA backend server (e.g., Radius Authentication Server). 5.1 Interconnection between WTPs and ACs There are several connectivity options which can be considered between the AC(s) and the WTPs, including direct connection, L2 switched connection, or L3 routed connection, as shown in Figure 3, Figure 4, and Figure 5. -------+------ LAN | +-------+-------+ | AC | +----+-----+----+ | | +---+ +---+ | | +--+--+ +--+--+ | WTP | | WTP | +--+--+ +--+--+ Figure 3: Directly Connected Yang (Editor), et al. Expires May 17, 2005 [Page 18] Internet-Draft CAPWAP Arch. Taxonomy November 2004 -------+------ LAN | +-------+-------+ | AC | +----+-----+----+ | | +---+ +---+ | | +--+--+ +-----+-----+ | WTP | | Switch | +--+--+ +---+-----+-+ | | +-----+ +-----+ | WTP | | WTP | +-----+ +-----+ Figure 4: Switched Connections +-------+-------+ | AC | +-------+-------+ | --------+------ LAN | +-------+-------+ | router | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | WTP | | WTP| +--+--+ +--+--+ Figure 5: Routed Connections 5.2 Overview of Three Centralized WLAN Architecture Variants While dynamic and consistent network management is one of the primary motivations for the Centralized Architecture, the survey data from vendors also shows that different varieties of this architecture family have emerged to meet a complex set of different requirements for possibly different deployment scenarios. This is also a direct result of the inherent flexibility in the 802.11 standard [1] Yang (Editor), et al. Expires May 17, 2005 [Page 19] Internet-Draft CAPWAP Arch. Taxonomy November 2004 regarding the implementation of the logical functions that are broadly described under the term "Access Point (AP)". As there is no standard mapping of these AP functions to physical network entities, several design choices have been made by vendors that offer related products. Moreover, the increased demand for monitoring and consistent configuration of large wireless networks has resulted into a set of 'value-added' services provided by the various vendors, most of which share common design properties and service goals. In the following, we describe the three main variants observed from the survey data within the family of Centralized WLAN Architecture, namely the Local MAC, Split MAC, and Remote MAC approaches. For each approach we provide the mapping characteristics of the various functions into the network entities from each vendor. The naming of Local MAC, Split MAC and Remote MAC reflects how the functions, and especially the 802.11 MAC functions, are mapped onto the network entities. Local MAC indicates that the MAC functions stay intact and local to WTPs, while Remote MAC denotes that the MAC is moved away from the WTP to a remote AC in the network. Split MAC shows the MAC being split between the WTPs and ACs, largely along the line of real time sensitivity. Typically, Split MAC vendors choose to put real time functions on the WTPs while leaving non-real time functions to the ACs. 802.11 does not clearly specify what constitutes real-time functions versus non-real-time functions, and so there does not exist such a clear and definitive line among them. As shown in Section 5.4, each vendor has its own interpretation on this and so there exists some discrepancy in where to draw the line between real time However, vendors also manage to agree on the characterization of the majority of the MAC functions. For example, every vendor classifies the DCF as a real-time function. Yang (Editor), et al. Expires May 17, 2005 [Page 20] Internet-Draft CAPWAP Arch. Taxonomy November 2004 The differences among Local MAC, Split MAC and Remote MAC architectures are shown graphically in the following figure: +--------------+--- +---------------+--- +--------------+--- | CAPWAP | | CAPWAP | | CAPWAP | | functions |AC | functions |AC | functions | |==============|=== |---------------| |--------------| | | | non RT MAC | | |AC | 802.11 MAC | |===============|=== | 802.11 MAC | | |WTP | Real Time MAC | | | |--------------| |---------------|WTP |==============|=== | 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP +--------------+--- +---------------+--- +--------------+--- (a) "Local MAC" (b) "Split MAC" (c) "Remote MAC" Figure 6: Three Architectural Variants within Centralized WLAN Architecture Family 5.3 Local MAC The main motivation of Local MAC architecture model, as shown in Figure 6.(a), is to offload network access policies and management functions (CAPWAP functions described in Section 2.2) to the AC, without splitting the 802.11 MAC functionality between WTPs and AC. The whole 802.11 MAC resides on the WTPs locally, including all the 802.11 management and control frame processing for the STAs; on the other hand, information related to management and configuration of the WTP devices is communicated with a centralized AC, to facilitate management of the network, and maintain a consistent network-wide configuration for the WTP devices. Figure 7 offers a tabular representation of the design choices made by the six vendors in the survey that follow the Local MAC approach with respect to the aforementioned architecture considerations. "WTP-AC connectivity" shows the type of connectivity between WTPs and AC every vendor's architecture can support. It is clear that all the vendors can support L3 routed network connectivity between WTPs and the AC, which implies that direct connections and L2 switched networks are also supported by all vendors. By '802.11 mgmt termination', and '802.11 control termination' we denote the physical network device on which processing of the 802.11 management and control frames is done respectively. All the vendors here choose to terminate 802.11 management and control frames at the WTPs. The last row of the table, '802.11 data aggregation', refers to the device on which aggregation and delivery of 802.11 data frames from one STA to another (possibly through a DS) is performed. As we can see from the Yang (Editor), et al. Expires May 17, 2005 [Page 21] Internet-Draft CAPWAP Arch. Taxonomy November 2004 table, vendors make different choices as whether or not all the 802.11 data traffic is aggregated and routed through the AC. The survey data shows that some vendors choose to tunnel or encapsulate all the station traffic to or from the ACs, implying the AC also acts as the access router for this WLAN access network; other vendors choose to separate the control plane and data plane by letting the station traffic being bridged or routed locally while keeping the centralized control at the AC. Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ WTP-AC connectivity L3 L3 L3 L3 L3 802.11 mgmt termination WTP WTP WTP WTP WTP 802.11 control termination WTP WTP WTP WTP WTP 802.11 data aggregation AC AC WTP AC WTP Figure 7: Architecture Considerations for Local MAC Architecture Figure 8 shows that most of the CAPWAP functions as described in Section 2.2 are implemented at the AC, with help from WTPs to monitor RF channels, and collect statistics and state information from the STAs, as the AC offers the advantages of network-wide visibility, which is essential for many of the control, configuration and value-added services. Yang (Editor), et al. Expires May 17, 2005 [Page 22] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ RF Monitoring WTP WTP AC/WTP WTP WTP RF Config. AC AC AC AC AC WTP config. AC AC AC AC AC WTP Firmware AC AC AC AC AC STA state info database AC AC/WTP AC/WTP AC/WTP AC AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP AC/WTP Figure 8: Mapping of CAPWAP Functions for Local MAC Architecture The matrix shown in Figure 9 shows that most of the 802.11 functions are implemented at the WTPs for Local MAC Architecture, with some minor differences among the vendors with regard to distribution service, 802.11e scheduling and 802.1X/EAP authentication. The difference in distribution service is consistent with the difference described earlier with regard to "802.11 data aggregation" in Figure 7. Arch7 Arch8 Arch9 Arch10 Arch11 ----- ----- ----- ------ ------ Distribution Service AC AC WTP AC WTP Integration Service WTP WTP WTP WTP WTP Beacon Generation WTP WTP WTP WTP WTP Probe Response WTP WTP WTP WTP WTP Yang (Editor), et al. Expires May 17, 2005 [Page 23] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Power mgmt Packet Buffering WTP WTP WTP WTP WTP Fragmentation/ Defragment. WTP WTP WTP WTP WTP Association Disassoc. Reassociation AC WTP WTP WTP WTP WME/11e -------------- classifying AC WTP scheduling WTP AC/WTP WTP WTP WTP queuing WTP WTP WTP WTP Authentication and Privacy -------------- 802.1X/EAP AC AC AC/WTP AC AC/WTP Keys Management AC AC WTP AC AC 802.11 Encryption/ Decryption WTP WTP WTP WTP WTP Figure 9: Mapping of 802.11 Functions for Local MAC Architecture From Figure 7, Figure 8 and Figure 9, it is clear that differences among vendors in the Local MAC Architecture are relatively minor, and most of the functional mapping appears to be common across vendors. 5.4 Split MAC As shown in Figure 6.(b), the main idea behind the Split MAC architecture is to implement part of the 802.11 MAC functionality on a centralized AC instead of the WTPs, in addition to the services required for managing and monitoring the WTP devices. Usually, the decision of which functions of the 802.11 MAC need to be provided by the AC is based on the time-criticality of the services considered. In the Split MAC architecture, the WTP terminates the infrastructure side of the wireless physical link, provides radio-related Yang (Editor), et al. Expires May 17, 2005 [Page 24] Internet-Draft CAPWAP Arch. Taxonomy November 2004 management, and also implements all time-critical functionality of the 802.11 MAC. In addition, the non real-time management functions are handled by a centralized AC, along with higher-level services, such as configuration, QoS, policies for load-balancing, access control lists, etc. The subtle but key distinction between Local MAC and Split MAC relates to the non real-time functions: in Split MAC architecture, the AC terminates 802.11 non real-time functions, whereas in Local MAC architecture the WTP terminates the 802.11 non real-time functions and consequently sends appropriate messages to the AC. There are several motivations for taking the Split MAC approach. The first is to offload to the WTP functionality that is specific and relevant only to the locality of each BSS, in order to allow the AC to scale to a large number of 'light weight' WTP devices. Moreover, real-time functionality is subject to latency constraints and cannot tolerate delays due to transmission of 802.11 Control frames (or other real-time information) over multiple-hops. The latter would limit the available choices for the connectivity between the AC and the WTP, hence the real-time criterion is usually employed to separate MAC services between the devices. Another consideration is cost reduction of the WTP to make it as cheap and simple as possible. Last but not least, moving functions like encryption and decryption to the AC reduces vulnerabilities from a compromised WTP, since user encryption keys no longer reside on the WTP. As a result, any advancements in security protocols and algorithms design do not necessarily obsolete the WTPs; the ACs implement the new security schemes instead, and the management and update task is therefore simplified. Additionally, the network is protected against LAN-side eavesdropping. Since there is no clear definition in the 802.11 specification as to which 802.11 MAC functions are considered "real time", each vendor has taken the liberty to interpret that in his own way. Most vendors agree that the following services of 802.11 MAC are examples of real time services and so are chosen to be implemented on the WTPs. o Beacon Generation o Probe Response/Transmission o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK o Synchronization o Retransmissions o Transmission Rate Adaptation The following list includes examples of non-real-time MAC functions as interpreted by most vendors: o Authentication/Deauthentication o Association/Disassociation/Reassociation/Distribution Yang (Editor), et al. Expires May 17, 2005 [Page 25] Internet-Draft CAPWAP Arch. Taxonomy November 2004 o Integration Services: bridging between 802.11 and 802.3 o Privacy: 802.11 Encryption/Decryption o Fragmentation/Defragmentation However, some vendors may choose to classify some of the above "non-real time" functions as real-time functions, in order to support specific applications with strict QoS requirements. For example Reassociation is sometimes implemented as "real-time" function in order to support VoIP applications. The non-real-time aspects of the 802.11 MAC are handled by the AC, through the processing of raw 802.11 management frames (Split MAC). The following matrix in Figure 10 offers a tabular representation of the design choices made by the six vendors that follow the Split MAC design with respect to the architecture considerations. While most vendors support L3 connectivity between WTPs and ACs, some vendors can only support L2 switched connections, due to the tighter delay constraint resulting from splitting MAC between two physical entities across a network. Comparing to Figure 7, it is clear that the commonality between Split MAC and Local MAC is that the 802.11 control frames are all processed by the WTP, while the difference lies in the termination point for 802.11 management frames. Local MAC terminates 802.11 management frames at WTP, while at least some of the 802.11 management frames are terminated at the AC for the Split MAC Architecture. In most cases, since WTP devices are IP-addressable, any of the direct connection, L2-switched, or L3-routed connections of Section 2.2 can be used. In the case where only Ethernet-encapsulation is performed (e.g., as in Architecture 4) then only direct connection and L2-switched connections are supported. Yang (Editor), et al. Expires May 17, 2005 [Page 26] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ----- ----- ----- WTP-AC connectivity L3 L3 L3 L2 L3 L3 802.11 mgmt termination AC AC AC AC AC/WTP AC 802.11 control termination WTP WTP WTP WTP WTP WTP 802.11 data aggregation AC AC AC AC AC AC Figure 10: Architecture Considerations for Split MAC Architecture Similar to the Local MAC Architecture, the following matrix in Figure 11 shows that most of the CAPWAP control functions are implemented at the AC, with the exception of RF monitoring and in some cases RF configuration being done locally at the WTPs. Yang (Editor), et al. Expires May 17, 2005 [Page 27] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ----- ----- ----- RF Monitoring WTP WTP WTP WTP WTP WTP RF Config. AC/WTP AC/WTP AC AC AC WTP config. AC AC AC AC AC WTP Firmware AC AC AC AC AC STA state info database AC AC AC AC AC AC/WTP mutual authent. AC/WTP AC/WTP AC/WTP AC/WTP Figure 11: Mapping of CAPWAP Functions for Split MAC Architecture The most interesting matrix for Split MAC Architecture is the Functional Distribution Matrix for 802.11 functions, as shown below in Figure 12. There exists certain regularity in how the vendors map the functions onto the WTPs and AC. For example, all vendors choose to implement Distribution, Integration Service at the AC, along with 802.1X/EAP authentication and keys management. All vendors also choose to implement beacon generation at WTPs. On the other hand, it is also clear that vendors choose to map many of the other functions differently. Therefore, Split MAC Architectures are not consistent regarding the exact way the MAC is split. Arch1 Arch2 Arch3 Arch4 Arch5 Arch6 ----- ----- ----- ------ ----- ----- Distribution Service AC AC AC AC AC AC Integration Service AC AC AC AC AC AC Beacon Generation WTP WTP WTP WTP WTP WTP Yang (Editor), et al. Expires May 17, 2005 [Page 28] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Probe Response WTP AC/WTP WTP WTP WTP WTP Power mgmt Packet Buffering WTP WTP WTP AC AC/WTP WTP Fragmentation Defragment. WTP WTP AC AC AC Association Disassoc. Reassociation AC AC AC AC WTP AC WME/11e -------------- classifying AC AC AC AC scheduling WTP/AC AC WTP AC AC WTP/AC queuing WTP/AC WTP WTP AC WTP WTP Authentication and Privacy -------------- 802.1X/EAP AC AC AC AC AC AC Keys Management AC AC AC AC AC AC 802.11 Encryption/ Decryption WTP AC WTP AC AC AC Figure 12: Mapping of 802.11 Functions for Split MAC Architecture 5.5 Remote MAC One of the main motivations for the Remote MAC Architecture is to keep the WTPs as light weight as possible, by having only the radio interfaces on the WTPs and offloading the entire set of 802.11 MAC functions (including delay-sensitive ones) to the Access Controller. This leaves all the complexities of the MAC and other CAPWAP control functions to the centralized controller. The WTP acts only as a pass-through between the Wireless LAN clients Yang (Editor), et al. Expires May 17, 2005 [Page 29] Internet-Draft CAPWAP Arch. Taxonomy November 2004 (STA) and the AC, though they may have an additional feature to convert the frames from one format (802.11) to the other (Ethernet, TR, Fiber etc.). The centralized controller provides network monitoring, management and control, entire set of the 802.11 AP services, security features, resource management, channel selection features, guarantees of Quality of Service to the users, etc. Because the MAC is separated from the PHY, we call this the "Remote MAC Architecture". Typically such architecture is deployed with special attention to the connectivity between the WTPs and AC so that the delay is minimized. The RoF (Radio over Fiber) from Architecture 5 is such an example of Remote MAC Architecture. 5.6 Comparisons of Local MAC, Split MAC and Remote MAC Two commonalities across all the three Centralized Architectures (Local MAC, Split MAC and Remote MAC) are: o Most of the CAPWAP functions related to network control and configuration reside on the AC. o IEEE 802.11 PHY resides on the WTP. The difference between Remote MAC and the other two Centralized Architectures (namely, Local MAC and Split MAC) is pretty clear, as the 802.11 MAC is completely separated from the PHY in the former, while the other two at least keep some portion of the MAC functions together with PHY at the WTPs. So the implication of PHY and MAC separation is that it severely limits the kind of interconnection between WTPs and ACs, so that the 802.11 timing constraints are satisfied. As pointed out earlier, this usually results in tighter constraint over the interconnection between WTP and AC for the Remote MAC Architecture. The advantage of Remote MAC Architecture is that it offers the lightest possible WTPs for certain deployment scenarios. The commonalities and differences between Local MAC and Split MAC are most clearly seen by comparing Figure 7 and Figure 10. The commonality between the two is that 802.11 control frames are terminated at WTPs in both cases. The main difference between Local MAC and Split MAC is that in the latter the WTP terminates only the 802.11 control frames, while in the former the WTP may terminate all 802.11 frames. An interesting consequence of this difference is that the Integration Service, which essentially refers to bridging between 802.11 and 802.3 frames, is implemented by the AC in the Split MAC, but can be part of either the AC or WTP in the Local MAC. As a second note, the Distribution Service, although usually provided by the AC, can also be implemented at the WTP in some Local MAC architectures. The rationale behind this approach is to increase performance in delivering STAs data traffic by avoiding tunnelling it Yang (Editor), et al. Expires May 17, 2005 [Page 30] Internet-Draft CAPWAP Arch. Taxonomy November 2004 to the AC, and also relax the dependency of the WTP from the AC. Therefore, it is possible that the data and control planes are separated in the Local MAC Architecture. Even though all the 802.11 traffic is aggregated at ACs in the case of Split MAC Architecture, the data plane and control plane can still be separated by employing multiple ACs. For example, one AC can implement most of the CAPWAP functions (control plane), while other ACs can be used for 802.11 frames bridging (data plane). Each of the three architectural variants may be advantageous in certain aspects for certain deployment scenarios. While Local MAC retains most of the STAs' state information at the local WTPs, Remote MAC centralizes most of the state into the backend AC. Split MAC sits somewhat in the middle of this spectrum, keeping some state information locally at the WTPs, and the rest centrally at the AC. Many factors should be taken into account to determine the exact balance desired between centralized v.s. decentralized state. The impact of such balance on network manageability is currently a matter of dispute within the technical community. 5.7 Communication Interface between WTPs and ACs Before any messages can be exchanged between an AC and WTP, the WTP needs to discover, authenticate and register with the AC first, then download the firmware and establish control channel with the AC. Message exchanges between the WTP and AC for control and configuration can happen after that. The following list outlines the basic operations that are typically performed between the WTP and the AC in the typical order: 1. Discovery : The WTPs discover the AC with which they will be bound to and controlled by. The discovery procedure can employ either static or dynamic configuration. In the latter case, a protocol is used in order for the WTP to discover candidate AC(s). 2. Authentication: After discovery, the WTP device authenticates itself with the AC. However, mutual authentication, in which the WTP also authenticates the AC, is not always supported since some vendors strive for zero-configuration on the WTP side. This is not necessarily secure as it leaves the possible vulnerability of the WTP being attached to a rogue AC. 3. WTP Association: After successful authentication, an WTP registers with the AC, in order to start receiving management and configuration messages. 4. Firmware Download: After successful association, the WTP may pull, or the AC may push the WTPs firmware, which may be protected by some manner, such as digital signatures. Yang (Editor), et al. Expires May 17, 2005 [Page 31] Internet-Draft CAPWAP Arch. Taxonomy November 2004 5. Control Channel Establishment: The WTP establishes either an IP-tunnel or performs Ethernet encapsulation with the AC, in order to transfer data traffic and management frames. 6. Configuration Download: Following the control channel establishment process, the AC may push configuration parameters to the WTPs. 5.8 Security Given the varied distribution of functionalities for the Centralized Architecture as surveyed in Section 4.3, it is obvious that an extra network binding is created between the WTP and the AC. This brings along new and unique security issues and subsequent requirements. 5.8.1 Client Data Security The survey shows clearly that the termination point for "over the air" 802.11 encryption [4] can be implemented either in the WTP or in the AC. Furthermore, the 802.1X/EAP [6] functionality is also distributed between the WTP and the AC where, in almost all cases, the AC performs the necessary functions as the authenticator in the 802.1X exchange. If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the PTK (Pairwise Transient Key) has to be transferred from the AC to the WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by a STA from one WTP to another WTP that is connected to the same AC without establishing a separate PMK. However, this leaves the STA in a difficult position. The STA cannot distinguish between a compromised PMK and one that is intentionally being shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons. In the case where the 802.11i encryption/decryption is performed in the AC, the key exchange and state transitions occur between the AC and the STA. Therefore, there is no need to transfer any crypto material between the AC and the WTP. Regardless of 802.11i termination point, the Centralized WLAN Architecture records two practices for "over the wire" client data security. In some cases there is an encrypted tunnel (IPsec or SSL) Yang (Editor), et al. Expires May 17, 2005 [Page 32] Internet-Draft CAPWAP Arch. Taxonomy November 2004 between the WTP and AC which assumes the security boundary to be in the AC. In other cases an end-to-end mutually authenticated secure VPN tunnel is assumed between the client and AC, other security gateway or end host entity. 5.8.2 Security of Control Channel between the WTP and AC In order for the CAPWAP functions to be implemented in the Centralized WLAN Architecture it is necessary for a control channel to exist between the WTP and AC. In order to address potential security threats against the control channel, existing implementations feature one or more of the following security mechanisms: 1. Secure discovery of WTP and AC. 2. Authentication of the WTPs to the ACs (and possibly mutual authentication). 3. Confidentiality, integrity, and replay protection of control channel frames. 4. Secure management of WTPs and ACs, including mechanisms for securely setting and resetting secrets and state. Discovery and authentication of WTPs are addressed in the submissions by implementing authentication mechanisms that range from X.509 certificates, AAA authentication to pre-shared credential authentication. In all cases, the issues of confidentiality, integrity and protection against man-in-the-middle attacks of the control frames are addressed by a secure encrypted tunnel between WTP and AC(s), utilizing keys derived from the varied authentication methods mentioned previously. Finally, one of the motivations for the Centralized WLAN Architecture is to minimize the storage of cryptographic and security sensitive information, in addition to operational configuration parameters within the WTPs. It is for that reason that the majority of the submissions under the Centralized Architecture category have employed a post WTP authenticated discovery phase of configuration provisioning, which in turn protects against the theft of WTPs. 5.8.3 Physical Security of WTPs and ACs In order to provide comprehensive radio coverage, WTPs are often installed in locations that are difficult to secure physically; it is relatively easier to secure the AC physically. If high-value secrets, such as a RADIUS shared secret, are stored in the AC instead of WTPs, then the physical loss of an WTP does not compromise these secrets. Hence, the Centralized Architecture may reduce the security consequences of a stolen WTP. Yang (Editor), et al. Expires May 17, 2005 [Page 33] Internet-Draft CAPWAP Arch. Taxonomy November 2004 On the other hand, concentrating all of the high-value secrets in one place makes the AC an attractive target, so strict physical, procedural and technical controls are needed to protect the secrets. Yang (Editor), et al. Expires May 17, 2005 [Page 34] Internet-Draft CAPWAP Arch. Taxonomy November 2004 6. Distributed Mesh Architecture Out of the 16 architecture survey submissions, 3 belong to the Distributed Mesh Architecture family. An example of the Distributed Mesh Architecture is shown in Figure 13, which reflects some of the common characteristics found in these 3 submissions. +-----------------+ +-----------------+ | 802.11 BSS 1 | | 802.11 BSS 2 | | ... | | ... | | +---------+ | | +---------+ | +----|mesh node|--+ +----|mesh node|--+ +-+---+---+ +-+-+-----+ | | | | | | | | +----------+ | +-----------------------+ | Ethernet | Ethernet | | 802.11 wireless links | +--------+ Switch | | +-----------------------+ | | | | | | | | | +----------+ +-+---+---+ +-+--+----+ +----|mesh node|--+ +----|mesh node|--+ | +---------+ | | +---------+ | | ... | | ... | | 802.11 BSS 4 | | 802.11 BSS 3 | +-----------------+ +-----------------+ Figure 13: Example of Distributed Mesh Architecture 6.1 Common Characteristics One of the main characteristics of these mesh architecture submissions is that mesh nodes in the network may act as APs to the client stations in their respective BSS, as well as traffic relays to neighboring mesh nodes via 802.11 wireless links, in order to provide wider wireless coverage. It is also possible that some of the mesh nodes in the network may serve only as wireless traffic relays for other mesh nodes, but not as APs for any client stations. Instead of pulling Ethernet cable connections to every AP, wireless mesh networks provide an attractive alternative to relaying backhaul traffic. Another key characteristic of these mesh architecture submissions is that mesh nodes can keep track of the state of their neighboring nodes, or even nodes beyond their immediate neighborhood, by exchanging information periodically amongst them; this way, mesh nodes can be fully aware of the dynamic network topology and RF conditions around them. Such peer-to-peer communication model allows Yang (Editor), et al. Expires May 17, 2005 [Page 35] Internet-Draft CAPWAP Arch. Taxonomy November 2004 mesh nodes to actively coordinate among themselves to achieve self-configuration and self-healing. This is the major distinction between this Distributed Architecture family and the Centralized Architecture -- much of the CAPWAP functions can be implemented across the mesh nodes in a distributed fashion, without a centralized entity making all the control decisions. On the other hand, it is worthwhile to point out that mesh networks do not necessarily preclude the use of centralized control. It is possible that a combination of centralized and distributed control co-exists in mesh networks. Some global configuration or policy change may be better served in a coordinated fashion if some form of Access Controller (AC) exists in the mesh network, even if not the full blown version of the AC as defined in the Centralized WLAN Architecture. For example, a centralized management entity can be used to update every mesh node's default configuration; it may also be more desirable to leave certain functions such as user authentication to a single centralized end point (such as a RADIUS server), but mesh networks allow the possibility of each mesh AP to directly talk to the RADIUS server. This eliminates the single point of failure and takes advantage of the client distribution in the network. The backhaul transport network of the mesh network can be either an L2 or L3 networking technology. Currently, vendors are using proprietary mesh technologies on top of standard 802.11 wireless links to enable peer-to-peer communication between the mesh nodes, and hence no interoperability exists among mesh nodes from different vendors. The IEEE 802.11 WG has recently started a new Task Group (TGs) to define the mesh standard for 802.11. 6.2 Security Similar security concerns for client data security as described in Section 5.8.1 also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain. Also to protect user and management data that may not be secured at layer 3, data transmission among neighboring nodes should be secured by a layer 2 mechanism of confidentiality, integrity and replay protection. Yang (Editor), et al. Expires May 17, 2005 [Page 36] Internet-Draft CAPWAP Arch. Taxonomy November 2004 7. Summary and Conclusions We requested existing WLAN vendors and other interested parties to submit a short description of existing or desired WLAN access network architectures to define a taxonomy of possible WLAN access network architectures. The information from the 16 submissions was condensed and summarized in this document. New terminology has been defined wherever existing terminology was found to be either insufficient or ambiguous in describing the WLAN architectures and supporting functions listed in the document. For example, the broad set of Access Point functions has been divided into two categories - 802.11 functions which include those that are required by the IEEE 802.11 standards, and CAPWAP functions which include those that are not required by the IEEE 802.11, but are deemed essential for control, configuration, and management of 802.11 WLAN access networks. Another term that has caused considerable ambiguity is "Access Point", which was usually tied to reflect a physical box that has the antennas, but did not have a uniform set of externally consistent behavior across all submissions. To remove this ambiguity, we have re-defined the AP to be the set of 802.11 and CAPWAP functions, while the physical box that terminates the 802.11 PHY is called the Wireless Termination Point. Based on the submissions during the architectural survey phase, we have classified the existing WLAN architectures into three broad classes: 1. Autonomous WLAN Architecture indicates a family of architectures where all the 802.11 functions and, where applicable, CAPWAP functions are implemented in the WTPs. 2. Centralized WLAN Architecture indicates a family of architectures where the AP functions are split between the WTPs and the AC with the AC, typically, acting as a centralized control point for multiple WTPs. 3. Distributed WLAN Architecture indicates a family of architectures where part of the control functions are implemented across a distributed network of peer entities. Within the Centralized WLAN Architecture, there are a few sub-categories that are visible depending on how one maps the MAC functions, at a high-level, between the WTP and the AC. Three prominent ones emerged from the information present in the submissions: 1. Split MAC Architecture, where the 802.11 MAC functions are split between the WTP and the AC. This subgroup includes all architectures that split the 802.11 MAC functions even though individual submissions differed on the specifics of the split. Yang (Editor), et al. Expires May 17, 2005 [Page 37] Internet-Draft CAPWAP Arch. Taxonomy November 2004 2. Local MAC Architecture, where the entire set of 802.11 MAC functions is implemented on the WTP. 3. Remote MAC Architecture, where the entire set of 802.11 MAC functions is implemented on the AC. The following tree diagram summarizes the architectures documented in this taxonomy. +----------------+ |Autonomous | +---------->|Architecture | | |Family | | +----------------+ | +--------------+ | |Local | | +---->|MAC | | | |Architecture | | | +--------------+ | | | +----------------+ | +--------------+ | |Centralized | | |Split | +---------->|Architecture |--+---->|MAC | | |Family | | |Architecture | | +----------------+ | +--------------+ | | | | +--------------+ | | |Remote | | +---->|MAC | | |Architecture | | +--------------+ | +----------------+ | |Distributed Mesh| +---------->|Architecture | |Family | +----------------+ A majority of the submitted WLAN access network architectures (12 out of 16) followed the Centralized WLAN Architecture. All but one of the centralized WLAN architecture submissions were grouped into either a Split MAC architecture or a Local MAC architecture. There was one submission that followed the Autonomous WLAN Architecture. There were three submissions under the Distributed WLAN Architecture. The WLAN access network architectures in the submissions indicated that the connectivity assumptions were: o Direct connection between the WTP and the AC. Yang (Editor), et al. Expires May 17, 2005 [Page 38] Internet-Draft CAPWAP Arch. Taxonomy November 2004 o L2 switched connection between the WTP and the AC. o L3 routed connection between the WTP and the AC. o Wireless connection between the mesh nodes in the distributed mesh architecture. Interoperability between equipment from different vendors is one of the fundamental problems in the WLAN market today. In order to achieve interoperability via open standard development, the following next steps are suggested for IETF and IEEE 802.11. Using this taxonomy, a functional model of an Access Point should be defined, by the new study group recently formed within the IEEE 802.11. The functional model will consist of defining functional elements of an 802.11 access point that are considered atomic, i.e. not subject to further splitting across multiple network elements. Such a functional model should serve as a common foundation to support the existing WLAN architectures as outlined in this taxonomy, and any further architecture development either within or outside of IEEE 802.11 group. It is possible, and even recommended, that the work on the functional model definition may also include impact analysis of implementing each functional element on either the WTP or the AC. As part of the functional model definition, interfaces must be defined in the form of primitives between these functional elements. If a pair of functional elements that have an interface defined between them is subject to being implemented on two different network entities, then a protocol specification between such pair of network elements is required to be defined, and should be developed by IETF. Yang (Editor), et al. Expires May 17, 2005 [Page 39] Internet-Draft CAPWAP Arch. Taxonomy November 2004 8. Security Considerations A comprehensive threat analysis of all of the security issues with the different WLAN architectures is not a goal of this document. Nevertheless, in addition to documenting the architectures employed in the existing IEEE 802.11 products in the market, this taxonomy document also catalogs, in a non-exhaustive manner, the security issues that arise and the manner in which vendors address these security threats. The WLAN architectures are broadly categorized into three families: Autonomous Architecture, Centralized Architecture, and Distributed Architecture. While Section 4, Section 5 and Section 6 are devoted to each of these three architecture families, respectively, each section also contains a subsection to address the security issues within each architecture family. In summary, the main security concern in the Autonomous Architecture is the mutual authentication between WTP and the wired (Ethernet) infrastructure equipment. Physical security of the WTPs is also a network security concern because the WTPs contain secret information and theft of these devices could potentially compromise even the wired network. In the Centralized Architecture there are a few new security concerns, due to the introduction of the new network binding between WTP and AC. The following security concerns are raised for this architecture family: keying material for mobile client traffic may need to be securely transported from AC to WTP; secure discovery of WTP and AC is required, as well as mutual authentication between WTPs and AC; man-in-the-middle attacks to the control channel between WTP and AC, confidentiality, integrity and replay protection of control channel frames, and theft of WTPs for extraction of embedded secrets within. Each of the survey results for this broad architecture category have presented a variety of mechanisms to address these security issues. The new security issue in the Distributed Mesh Architecture is the need for mesh nodes to authenticate each other before forming a secure mesh network. It is also recommended that all communication between mesh nodes be encrypted to protect both control and user data. Yang (Editor), et al. Expires May 17, 2005 [Page 40] Internet-Draft CAPWAP Arch. Taxonomy November 2004 9. Acknowledgements This taxonomy is truly a collaborative effort with contributions from a large group of people. First of all, we want to thank all the CAPWAP Architecture Design Team members who have spent many hours in the teleconference calls, over emails and in writing and reviewing the draft. The full Design Team is listed here: o Peyush Agarwal STMicroelectronics Plot# 18, Sector 16A Noida, U.P 201301 India Phone: +91-120-2512021 EMail: peyush.agarwal@st.com o Dave Hetherington Roving Planet 4750 Walnut St., Suite 106 Boulder, CO 80027 United States Phone: +1-303-996-7560 EMail: Dave.Hetherington@RovingPlanet.com o Matt Holdrege Strix Systems 26610 Agoura Road Calabasas, CA 91302 Phone: +1 818-251-1058 EMail: matt@strixsystems.com o Victor Lin Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 Phone: +1 408-579-3383 EMail: vlin@extremenetworks.com o James M. Murphy Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588 Phone: +1 925-474-2233 EMail: jmurphy@trapezenetworks.com o Partha Narasimhan Aruba Wireless Networks 180 Great Oaks Blvd San Jose, CA 95119 Phone: +1 408-754-3018 EMail: partha@arubanetworks.com o Bob O'Hara Airespace Yang (Editor), et al. Expires May 17, 2005 [Page 41] Internet-Draft CAPWAP Arch. Taxonomy November 2004 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2025 EMail: bob@airespace.com o Emek Sadot (see Authors' Addresses) o Ajit Sanzgiri Cisco Systems 170 W Tasman Drive San Jose, CA 95134 Phone: +1 408-527-4252 EMail: sanzgiri@cisco.com o Singh Chantry Networks 1900 Minnesota Court Mississauga, Ontario L5N 3C9 Canada Phone: +1 905-567-6900 EMail: isingh@chantrynetworks.com o L. Lily Yang (Editor, see Authors' Addresses) o Petros Zerfos (see Authors' Addresses) In addition, we would also like to acknowledge the contributions from the following individuals who participated in the architecture survey, and provided detailed input data in preparation of the taxonomy: Parviz Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, Dennis Volpano, Shankar Narayanaswamy, Simon Barber, Srinivasa Rao Addepalli, Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted Kuo, and Tyan-shu Jou. It is simply impossible to write this taxonomy without the large set of representative data points that they provided us. We would also like to thank our CAPWAP WG co-chairs, Mahalingam Mani and Dorothy Gellert, and our Area Director, Bert Wijnen, for their unfailing support. 10 Normative References [1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, . [2] "CAPWAP Problem Statement", . [3] "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [4] "IEEE Std 802.11i: Medium Access Control (MAC) Security Enhancements", April 2004. Yang (Editor), et al. Expires May 17, 2005 [Page 42] Internet-Draft CAPWAP Arch. Taxonomy November 2004 [5] "IEEE Std 802.11h: Spectrum and Transmit Power Management Extensions in the 5 GHz Band in Europe", October 2003. [6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001. Authors' Addresses L. Lily Yang Intel Corp. MS JF3 206, 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: +1 503-264-8813 EMail: lily.l.yang@intel.com Petros Zerfos UCLA - Computer Science Department 4403 Boelter Hall Los Angeles, CA 90095 Phone: +1 310-206-3091 EMail: pzerfos@cs.ucla.edu Emek Sadot Avaya Atidim Technology Park, Building #3 Tel-Aviv 61131 Israel Phone: +972-3-645-7591 EMail: esadot@avaya.com Yang (Editor), et al. Expires May 17, 2005 [Page 43] Internet-Draft CAPWAP Arch. Taxonomy November 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Yang (Editor), et al. Expires May 17, 2005 [Page 44]