diff options
Diffstat (limited to 'doc/rfc/rfc4118.txt')
| -rw-r--r-- | doc/rfc/rfc4118.txt | 2299 |
1 files changed, 2299 insertions, 0 deletions
diff --git a/doc/rfc/rfc4118.txt b/doc/rfc/rfc4118.txt new file mode 100644 index 0000000..7b32250 --- /dev/null +++ b/doc/rfc/rfc4118.txt @@ -0,0 +1,2299 @@ + + + + + + +Network Working Group L. Yang +Request for Comments: 4118 Intel Corp. +Category: Informational P. Zerfos + UCLA + E. Sadot + Avaya + June 2005 + + + Architecture Taxonomy for + Control and Provisioning of Wireless Access Points (CAPWAP) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document provides a taxonomy of the architectures employed in + the existing IEEE 802.11 products in the market, by analyzing + Wireless LAN (WLAN) functions and services and describing the + different variants in distributing these functions and services among + the architectural entities. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. IEEE 802.11 WLAN Functions . . . . . . . . . . . . . . 3 + 1.2. CAPWAP Functions . . . . . . . . . . . . . . . . . . . 5 + 1.3. WLAN Architecture Proliferation . . . . . . . . . . . 6 + 1.4. Taxonomy Methodology and Document Organization . . . . 8 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.1. IEEE 802.11 Definitions . . . . . . . . . . . . . . . 9 + 3.2. Terminology Used in This Document . . . . . . . . . . 11 + 3.3. Terminology Used Historically but Not Recommended . . 13 + 4. Autonomous Architecture . . . . . . . . . . . . . . . . . . 13 + 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . 14 + 5. Centralized WLAN Architecture . . . . . . . . . . . . . . . 15 + 5.1. Interconnection between WTPs and ACs . . . . . . . . . 16 + + + + +Yang, et al. Informational [Page 1] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 5.2. Overview of Three Centralized WLAN Architecture + Variants . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. Local MAC . . . . . . . . . . . . . . . . . . . . . . 19 + 5.4. Split MAC . . . . . . . . . . . . . . . . . . . . . . 22 + 5.5. Remote MAC . . . . . . . . . . . . . . . . . . . . . . 27 + 5.6. Comparisons of Local MAC, Split MAC, and Remote MAC. . 27 + 5.7. Communication Interface between WTPs and ACs . . . . . 29 + 5.8. Security . . . . . . . . . . . . . . . . . . . . . . . 29 + 5.8.1. Client Data Security . . . . . . . . . . . . . 30 + 5.8.2. Security of Control Channel between + the WTP and AC . . . . . . . . . . . . . . . . 30 + 5.8.3. Physical Security of WTPs and ACs . . . . . . 31 + 6. Distributed Mesh Architecture . . . . . . . . . . . . . . . 32 + 6.1. Common Characteristics . . . . . . . . . . . . . . . . 32 + 6.2. Security . . . . . . . . . . . . . . . . . . . . . . . 33 + 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . 33 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 36 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 10. Normative References . . . . . . . . . . . . . . . . . . . . 39 + +1. 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 burden for network administration. 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 WLANs, + 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 systems allow for a broader choice of solutions, + a standardized interoperable solution addressing the aforementioned + problems is desirable. As the first step toward establishing + interoperability in the market place, this document provides 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 in defining the functional architecture of an AP. + + + + + +Yang, et al. Informational [Page 2] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +1.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 Station (STA) and + an Access Point (AP), and also among wireless clients. 802.11 also + describes how mobile devices can associate 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, in which each cell is the Basic Service Set (BSS), and + each BSS is controlled by the 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 AP is an STA that provides access to + the DS by providing DS services, as well as acting as an 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 the functions of an AP + and a portal. + + IEEE 802.11 does not specify the details of DS implementations + explicitly. Instead, the 802.11 standard defines services that + provide 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: Establishes the identity of one station as a + member of the set of stations that are authorized to associate + with one another. + + o De-authentication: Voids an existing authentication relationship. + + o Confidentiality: Prevents the content of messages from being read + by others than the intended recipients. + + o MSDU Delivery: Delivers the MAC service data unit (MSDU) for the + stations. + + Distribution system services consist of the following five + services: + + o Association: Establishes Access Point/Station (AP/STA) mapping and + enables STA invocation of the distribution system services. + + + + +Yang, et al. Informational [Page 3] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + o Disassociation: Removes an existing association. + + o Reassociation: Enables an established association (between AP and + STA) to be transferred from one AP to another or the same AP. + + o Distribution: 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: Translates 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 + + 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 another, Radio Resource Measurement Enhancements + (802.11k), etc. + + IEEE 802.11 does not specify exactly how these functions are + implemented, nor does it specify that they be implemented in one + physical device. It only requires 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, and rogue AP + + + +Yang, et al. Informational [Page 4] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + detection. What becomes clear from this document is that vendors + 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. 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 allows the RF antenna and 802.11 PHY to transmit and + receive station traffic in the BSS network. In the Centralized + Architecture (see section 5), the combination of WTPs with Access + Controller (AC) implements all 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. + +1.2. CAPWAP Functions + + To address the four problems identified in [2] (management, + consistent configuration, RF control, security) additional functions, + especially in the control and management plane, are typically offered + by vendors to assist in better coordination and control across the + entire ESS network. Such functions are especially important when the + IEEE 802.11 WLAN functions are implemented over multiple entities in + a large scale network, instead of within a single entity. Such + functions include: + + 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. + + o WTP configuration, e.g., for SSID. + + 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 and load balancing. + + o Mutual authentication between network entities, e.g., for AC and + WTP authentication in a Centralized WLAN Architecture. + + + + +Yang, et al. Informational [Page 5] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + The services listed are concerned with the 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 is not an exhaustive enumeration + of all additional services offered by vendors. We included only + those functions that are commonly represented in the survey data, and + are pertinent to understanding 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, the 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 is 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 the following areas: + + o RADAR detection + + o Transmit Power Control + + o Dynamic Channel Selection + +1.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 specifying 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. + + + +Yang, et al. Informational [Page 6] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + Interfaces between the network architecture components are mostly + proprietary, and there is no guarantee of cross-vendor + interoperability of products, even within the same family of + architectures. + + To achieve interoperability in the market place, the IETF CAPWAP + working group is first documenting both the functions and the network + architectures currently offered by the existing WLAN vendors. The + end result 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, in which 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. In such architecture, the WTP is + typically configured and controlled individually, and can be + monitored and managed via typical network management protocols + like SNMP. The WTPs are the traditional APs with which most + people are familiar. Such WTPs are sometimes 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 often co- + located with an L2 bridge, a switch, or an L3 router, and 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 is the generic term 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 + + + +Yang, et al. Informational [Page 7] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + centralized AC affords much better manageability for 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 no longer fully implement + the 802.11 functions as defined in the standards. 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. + + 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 wired or wireless media. A wireless + mesh network is one example within 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. + +1.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 descriptions 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, and the + remaining twelve entries represent architectures in the family of the + Centralized WLAN Architecture. + + The main objective of this survey was to identify the general + categories and trends in WLAN architecture evolution, discover their + common characteristics, and 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: + + + + +Yang, et al. Informational [Page 8] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 1.1. + + o CAPWAP Functions: As described in Section 1.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 individual functions that are organized into the above + mentioned three categories. 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' views of their architectures from an engineering + perspective. It does not necessarily imply that a product exists or + will be shipped, nor an intent by the vendor to build such a product. + + The next section provides a list of definitions used in this + document. The rest of this document is organized around the three + broad WLAN architecture families that were introduced in Section 1.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 (twelve out of sixteen) collected that fall into the + Centralized Architecture category. Summary and conclusions are + provided at the end to highlight the basic findings from this + taxonomy exercise. + +2. 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]. + +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). + + + + +Yang, et al. Informational [Page 9] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 + the 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 + 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). + + + + + +Yang, et al. Informational [Page 10] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +3.2. Terminology Used in This Document + + One of the motivations in defining new terminology is to clarify + 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. 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 with directly. Such + confusion can be especially acute when logical functions are + implemented across a network instead of within a single physical + entity. To avoid further confusion, we define the following + terminology: + + 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 an RF antenna and 802.11 PHY to transmit and receive station + traffic for the IEEE 802.11 WLAN access networks. Such physical + entities were often called "Access Points" (AP), but "AP" can also + refer to the logical entity that implements 802.11 services. We + recommend "WTP" as the generic term that explicitly refers to the + physical entity with the above property (e.g., featuring an RF + antenna and 802.11 PHY), applicable to network entities of both + Autonomous and Centralized WLAN Architecture (see 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 + + + + + +Yang, et al. Informational [Page 11] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 lower level are the WTPs, + while at the higher level are the Access Controllers (ACs), which are + responsible for controlling, configuring, and managing the entire + WLAN access network. + + 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 an example + of such an architecture. + + Access Controller (AC): The network entity in the Centralized WLAN + Architecture that provides WTPs access to the centralized + hierarchical network infrastructure in the data plane, control plane, + management plane, or a combination therein. + + Standalone WTP: Refers to the WTP in Autonomous WLAN Architecture. + + Controlled WTP: Refers to the WTP in Centralized WLAN Architecture. + + Split MAC Architecture: A subgroup of the Centralized WLAN + Architecture whereby 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 all the remaining + management and data frames are tunnelled to the 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 subgroup 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 subgroup of the Centralized WLAN + Architecture, where the majority or entire set of 802.11 MAC + 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. + + + + + + +Yang, et al. Informational [Page 12] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +3.3. Terminology Used Historically but Not Recommended + + While some terminology has been used by vendors historically to + describe "Access Points", we recommend deferring 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. + +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). An 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 provides + the distribution system. It can also provide portals for integrated + 802.3 LAN segments. + + + + + + + + + + + + + + + +Yang, et al. Informational [Page 13] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + +---------------+ +---------------+ +---------------+ + | 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 involve putting a corresponding + 802.1Q VLAN tag on each packet forwarded to the Ethernet + infrastructure and removing 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 functions are tightly integrated + into a single physical device, security issues with this architecture + are confined to the WTP. There are no extra implications from the + client authentication and encryption/decryption perspective, as the + AAA interface and the key generation mechanisms required for 802.11i + encryption/decryption are integrated into the WTP. + + One of the security needs in this architecture is 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 to which it connects. Another critical + security issue is the fact that the WTP is most likely not under lock + and key, but contains secret information to communicate with back-end + systems, such as AAA and SNMP. Because IT personnel uses the common + management method of pushing a "template" to all devices, theft of + such a device would potentially compromise the wired network. + + + +Yang, et al. Informational [Page 14] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +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 more centralized + controllers, called Access Controller(s), to enable network-wide + monitoring, improve management scalability, and facilitate dynamic + configurability. + + The following figure schematically shows 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 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. Designs of the Centralized WLAN Architecture family do not + presume (as the diagram might suggest) 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 + + + + + + + + + +Yang, et al. Informational [Page 15] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + In the diagram above, the AC is shown as a single physical entity + that provides all of the CAPWAP functions listed in Section 1.2. + However, this may not always be the case. Closer examination of the + functions reveals that their different resource requirements (e.g., + CPU, memory, storage) may be distributed across 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 be thought of as a multiplicity of logical + functions, and not necessarily as a single physical device. The ACs + may also choose to implement some control functions locally, and + provide 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 back-end server (e.g., + Radius Authentication Server). + +5.1. Interconnection between WTPs and ACs + + There are several connectivity options to consider between the AC(s) + and the WTPs, including direct connection, L2 switched connection, + and L3 routed connection, as shown in Figures 3, 4, and 5. + + -------+------ LAN + | + +-------+-------+ + | AC | + +----+-----+----+ + | | + +---+ +---+ + | | + +--+--+ +--+--+ + | WTP | | WTP | + +--+--+ +--+--+ + + Figure 3: Directly Connected + + + + + + + + + + + + + + +Yang, et al. Informational [Page 16] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + -------+------ 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 + + 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 various possible deployment scenarios. This is also a direct + result of the inherent flexibility in the 802.11 standard [1] + regarding the implementation of the logical functions that are + + + +Yang, et al. Informational [Page 17] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + broadly described under the term "Access Point (AP)". Because 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 in 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 has 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 + realtime sensitivity. Typically, Split MAC vendors choose to put + realtime functions on the WTPs while leaving non-realtime functions + to the ACs. 802.11 does not clearly specify what constitutes + realtime functions versus non-realtime functions, and so a clear and + definitive line does not exist. As shown in Section 5.4, each vendor + has its own interpretation on this, and there are some discrepancies + about where to draw the line between realtime and non-realtime + functions. However, vendors agree on the characterization of the + majority of MAC functions. For example, every vendor classifies the + DCF as a realtime function. + + 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 | Realtime 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 the Centralized + WLAN Architecture Family + + + +Yang, et al. Informational [Page 18] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +5.3. Local MAC + + The main motivation of the Local MAC architecture model, as shown in + Figure 6 (a), is to offload network access policies and management + functions (CAPWAP functions described in Section 1.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 shows 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 above mentioned architecture considerations. + "WTP-AC connectivity" shows the type connectivity between the WTPs + and AC that every vendor's architecture can support. Clearly, 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 shown by + the table, vendors make different choices as to whether 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 that the AC also + acts as the access router for this WLAN access network. Other + vendors choose to separate the control and data plane by letting the + station traffic be bridged or routed locally, while keeping the + centralized control at the AC. + + + + + + + + + + + + + + + +Yang, et al. Informational [Page 19] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 reveals that most of the CAPWAP functions, as described in + Section 1.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. + + 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 + + + + + +Yang, et al. Informational [Page 20] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + The matrix 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 regarding distribution service, 802.11e + scheduling, and 802.1X/EAP authentication. The difference in + distribution service is consistent with that described earlier + regarding "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 + + 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 + + + + + + + + + + + + +Yang, et al. Informational [Page 21] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 Figures 7, 8, and 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 depicted 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 providing the + required services 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 + management, and also implements time-critical functionality of the + 802.11 MAC. In addition, the non-realtime management functions are + handled by a centralized AC, along with higher level services, such + as configuration, QoS, policies for load balancing, and access + control lists. The key distinction between Local MAC and Split MAC + relates to non-realtime functions: in Split MAC architecture, the AC + terminates 802.11 non realtime functions, whereas in Local MAC + architecture, the WTP terminates the 802.11 non-realtime functions + and consequently sends appropriate messages to the AC. + + There are several motivations for taking the Split MAC approach. The + first is to offload functionality that is specific and relevant only + to the locality of each BSS to the WTP, in order to allow the AC to + scale to a large number of 'light weight' WTP devices. Moreover, + realtime functionality is subject to latency constraints and cannot + tolerate delays due to transmission of 802.11 control frames (or + other realtime information) over multiple-hops. The latter would + limit the available choices for connectivity between the AC and the + + + +Yang, et al. Informational [Page 22] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + WTP. Therefore, the realtime 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. + Finally, 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 protocol and algorithm designs do not necessarily obsolete + the WTPs; the ACs implement the new security schemes instead, which + simplifies the management and update task. 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 "realtime", each vendor + interprets this in their own way. Most vendors agree that the + following services of 802.11 MAC are examples of realtime services, + and 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-realtime MAC functions as + interpreted by most vendors: + + o Authentication/De-authentication + + o Association/Disassociation/Reassociation/Distribution + + 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- + realtime" functions as realtime functions in order to support + specific applications with strict QoS requirements. For example, + Reassociation is sometimes implemented as a "realtime" function to + support VoIP applications. + + + + +Yang, et al. Informational [Page 23] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + The non-realtime 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 regarding the architecture considerations. While most vendors + support L3 connectivity between WTPs and ACs, some can only support + L2 switched connections due to the tighter delay constraint resulting + from splitting MAC between two physical entities across a network. + In Figure 7, it is clear that the WTP processes the 802.11 control + frames in both the Split MAC and Local MAC. The difference between + the two 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. Since in most cases WTP devices are IP- + addressable, any of the direct connection, L2-switched, or L3-routed + connections of Section 1.2 can be used. If only Ethernet- + encapsulation is performed (e.g., as in Architecture 4), then only + direct connection and L2-switched connections are supported. + + 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 + + + + + + + + + + + + + + + + +Yang, et al. Informational [Page 24] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + Similar to the Local MAC Architecture, the matrix in Figure 11 shows + that most of the CAPWAP control functions are implemented at the AC. + The exception is RF monitoring, and in some cases RF configuration, + which are performed locally at the WTPs. + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Yang, et al. Informational [Page 25] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + The most interesting matrix for Split MAC Architecture is the + Functional Distribution Matrix for 802.11 functions, as shown below + in Figure 12. Vendors map the functions onto the WTPs and AC with a + certain regularity. 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, vendors + sometimes 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 + + 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 + + + + + + + + +Yang, et al. Informational [Page 26] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 + (STA) and the AC, though they may have an additional feature to + convert the frames from one format (802.11) to the other (i.e., + Ethernet, TR, Fiber). The centralized controller provides network + monitoring, management and control, an entire set of 802.11 AP + services, security features, resource management, channel selection + features, and guarantees Quality of Service to the users. 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 Radio over Fiber (RoF) from Architecture 5 + is an example of Remote MAC Architecture. + +5.6. Comparisons of Local MAC, Split MAC, and Remote MAC + + Two commonalities across all 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. + + + + + +Yang, et al. Informational [Page 27] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + There is a clear difference between Remote MAC and the other two + Centralized Architectures (namely, Local MAC and Split MAC), as the + 802.11 MAC is completely separated from the PHY in the former, while + the other two keep some portion of the MAC functions together with + PHY at the WTPs. 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 to Figure 10. The + commonality is that 802.11 control frames are terminated at WTPs in + both cases. The main difference between Local MAC and Split MAC is + that the WTP terminates only the 802.11 control frames in the Split + MAC, while the WTP may terminate all 802.11 frames in the Local MAC. + 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 and by the + WTP in the Local MAC, as shown in Figures 9 and 12, respectively. + + 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. This approach is meant to increase performance in + delivering STAs data traffic by avoiding tunneling it to the AC, and + relaxing the dependency of the WTP from the AC. Therefore, it is + possible for the data and control planes to be 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 and control planes 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 for + certain deployment scenarios. While the Local MAC retains most of + the STA's state information at the local WTPs, Remote MAC centralizes + most of the state into the back-end 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 + the centralized and decentralized state. The impact of such balance + on network manageability is currently a matter of dispute within the + technical community. + + + + +Yang, et al. Informational [Page 28] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +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 a 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 their 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, a 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 in some manner, such as digital signatures. + + 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 + new and unique security issues and subsequent requirements. + + + + + + + +Yang, et al. Informational [Page 29] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +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 distributed + between the WTP and the AC where, in most 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 + Pairwise Transient Key (PTK) 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 an STA from one WTP to another that is connected to the same AC + without establishing a separate PMK. However, this leaves the STA in + a difficult position, as 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. + + When 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 where the 802.11i termination point occurs, 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) between the WTP and AC, which assumes that the + security boundary is 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, a control channel is necessary between + the WTP and AC. + + + + + + + + +Yang, et al. Informational [Page 30] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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, confidentiality, integrity, and + protection against man-in-the-middle attacks of the control frames + are addressed by a secure encrypted tunnel between the WTP and AC(s), + utilizing keys derived from the 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 + + 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. On the other hand, concentrating all the high-value + secrets in one place makes the AC an attractive target that requires + strict physical, procedural, and technical controls to protect the + secrets. + + + + + + + + + +Yang, et al. Informational [Page 31] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +6. Distributed Mesh Architecture + + Out of the sixteen architecture survey submissions, three belong to + the Distributed Mesh Architecture family. An example of the + Distributed Mesh Architecture is shown in Figure 13, and reflects + some of the common characteristics found in these three 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 + + To provide wider wireless coverage, mesh nodes in the network may act + as APs to client stations in their respective BSS, as well as traffic + relays to neighboring mesh nodes via 802.11 wireless links. It is + also possible that some 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. + + Mesh nodes can also 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 + 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 + + + +Yang, et al. Informational [Page 32] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + across the mesh nodes in a distributed fashion, without a centralized + entity making all the control decisions. + + 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 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. + Hence, there is no interoperability 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. 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. + +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 + + + +Yang, et al. Informational [Page 33] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 usually reflected a physical box + that has the antennas, but did not have a uniform set of externally + consistent behavior across submissions. To remove this ambiguity, we + have redefined the AP as 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 architecture survey phase, we + have classified the existing WLAN architectures into three broad + classes: + + 1. Autonomous WLAN Architecture: Indicates a family of architectures + in which all the 802.11 functions and, where applicable, CAPWAP + functions are implemented in the WTPs. + + 2. Centralized WLAN Architecture: Indicates a family of architectures + in which the AP functions are split between the WTPs and the AC, + with the AC acting as a centralized control point for multiple + WTPs. + + 3. Distributed WLAN Architecture: Indicates a family of architectures + in which part of the control functions is implemented across a + distributed network of peer entities. + + Within the Centralized WLAN Architecture, there are a few visible + sub-categories that depend on how one maps the MAC functions (at a + high-level), between the WTP and the AC. Three prominent sub- + categories emerged from the information in the submissions: + + 1. Split MAC Architecture: 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. + + 2. Local MAC Architecture: The entire set of 802.11 MAC functions is + implemented on the WTP. + + 3. Remote MAC Architecture: The entire set of 802.11 MAC functions is + implemented on the AC. + + + + + + +Yang, et al. Informational [Page 34] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 (twelve + out of sixteen) 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. + One submission followed the Autonomous WLAN Architecture, and three + followed 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. + + o L2 switched connection between the WTP and the AC. + + o L3 routed connection between the WTP and the AC. + + + + + +Yang, et al. Informational [Page 35] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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. To achieve + interoperability via open standard development, the following 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 within or outside the IEEE + 802.11 group. It is possible, and even recommended, that 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 as primitives between these functional elements. If a pair + of functional elements that have an interface defined between them is + being implemented on two different network entities, then a protocol + specification definition between such a pair of network elements is + required, and should be developed by the IETF. + +8. Security Considerations + + This document does not intend to provide a comprehensive threat + analysis of all of the security issues with the different WLAN + architectures. Nevertheless, in addition to documenting the + architectures employed in the existing IEEE 802.11 products in the + market, this taxonomy document also catalogues 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 Sections 4, 5, and 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 the 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. + + + +Yang, et al. Informational [Page 36] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + In the Centralized Architecture there are a few new security concerns + due to the new network binding between the 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 the AC to WTP; secure discovery of the WTP and AC is + required, as well as mutual authentication between the 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 has + presented 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. Encrypted communication between mesh nodes is + recommended to protect both control and user data. + +9. Acknowledgements + + This taxonomy is truly a collaborative effort with contributions from + a large group of people. First, we want to thank all the CAPWAP + Architecture Design Team members who have spent many hours in the + teleconference calls, over e-mails, and in writing and reviewing the + document. 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 + + + + +Yang, et al. Informational [Page 37] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + 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 + 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) + + + +Yang, et al. Informational [Page 38] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + + In addition, we would also like to acknowledge 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 to 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, <IEEE + 802.11-99>. + + [2] O'Hara, B., Calhoun, P., and J. Kempf, "Configuration and + Provisioning for Wireless Access Points (CAPWAP) Problem + Statement", RFC 3990, February 2005. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] "IEEE Std 802.11i: Medium Access Control (MAC) Security + Enhancements", April 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. + + + + + + + + + + + + + + + + + + + + +Yang, et al. Informational [Page 39] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +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, et al. Informational [Page 40] + +RFC 4118 CAPWAP Architecture Taxonomy June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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. + + 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. + +Intellectual Property + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Yang, et al. Informational [Page 41] + |