Network Working Group P. Calhoun Internet-Draft B. O'Hara Expires: January 16, 2006 Cisco Systems, Inc. I. Singh Chantry Networks Inc. July 15, 2005 CAPWAP Taxonomy Recommendations draft-calhoun-capwap-taxonomy-recommendation-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The IETF's CAPWAP working group has documented various product architectures and has categorized the Centralized WLAN Architectures into two main buckets: Split and Local MAC. While the document contains very relevant and useful information, what it does is list the architectural variants of these two buckets, but does not unambiguously define either the Split MAC or Local MAC architectures. Calhoun, et al. Expires January 16, 2006 [Page 1] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 In order for CAPWAP to be successful, it is crucial for the protocol evaluation team, and the working group, to agree on unambiguous terminology to describe these architectures. This document proposes terminology to unambiguously describe the relevant architectures found in the taxonomy document, for the purpose of initiating a discussion within the working group and to allow the protocol evaluation work to come to a fruitful conclusion. We conclude in this document that the architectures are very similar and could be supported via a single protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions used in this document . . . . . . . . . . . . 5 2. CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Split AP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Local AP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. CAPWAP Signalling . . . . . . . . . . . . . . . . . . . . . . 12 6. Capabilities Negotiation . . . . . . . . . . . . . . . . . . . 14 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 18 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Calhoun, et al. Expires January 16, 2006 [Page 2] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 1. Introduction The CAPWAP's taxonomy specification [3] documents various architectures, 6 of which are labeled by their proponents to be Split MAC and 5 being Local MAC. In observing the various architectures listed, it is clear that there is significant differentiation from one vendor to another in the location of various functions among both the WTP and the AC. Figure 1 (below) comes from the taxonomy draft and shows the location of various AP functions across different architectures. Note that the Remote MAC architecture was determined by the Working Group to be out of scope for CAPWAP. In this specification, this table will be referred to as the "architecture table". +--------------+--- +---------------+--- +--------------+--- | 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 1: Three Architectural Variants within Centralized WLAN Architecture Family In reading the above, one can easily understand the primary difference between the Local and Split MAC. The Local MAC architecture means that all of the 802.11 functions reside in the WTP, while the CAPWAP functions reside in the AC. Conversely, the Split MAC architecture requires that only the real-time functions of the 802.11 MAC reside in the WTP, while the AC takes on an additional role of participating in the 802.11 MAC management protocol in addition to providing the CAPWAP functions. The taxonomy draft defines the CAPWAP functions as follows: o RF monitoring, such as Radar detection, noise and interference detection and measurement. Calhoun, et al. Expires January 16, 2006 [Page 3] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 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. Given the above conclusions, where a Local MAC architecture's AC only provides the above functions, the following paragraph, found in the taxonomy document, comes to a different conclusion: 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. The above paragraph clearly creates a contradiction between the "architecture table" and the local MAC architectures surveyed. Most importantly is the fact that in certain local MAC architectures, the Integration and Distribution Functions reside in the WTP while in others they exist in the AC. As per the "architecture table", a protocol whose Integration and Distribution Functions reside in the AC is by definition a Split MAC architecture. Some of the confusion stems from the actual definition of a Split MAC architecture, which is copied here from the taxonomy specification: 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 Calhoun, et al. Expires January 16, 2006 [Page 4] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 defined by IEEE 802.11 Standards in [1], is effectively split between the WTP and AC. If one were to use the strict definition above, an architecture that terminates the MAC in the WTP, but tunnels traffic to the AC would be considered Local MAC. It is important to note that in order for the AC to properly terminate these "data tunnels", it must somehow communicate STA information to the AC. Therefore, an architecture that takes an 802.11 MAC management message and reformats it into a different packet, containing much of the same information, which is then sent to the AC for processing and tunnels data traffic could be considered a Local MAC. However, the functionality provided by such an architecture is nearly identical to a Split MAC architecture, and the only difference is where the authors of the architecture sliced the AP function. It is believed that the crux of the issue is in terminology. If the CAPWAP working group had used the terminology Split AP and Local AP instead of MAC, this confusion could have been avoided. The term MAC implies that the 802.11 MAC has been split as opposed to AP functions. In this document we will attempt to provide a clearer definition of both architectures by focusing on functions rather than terminology, and will therefore use the terms Split and Local AP. The proposals in this document are intended to initiate discussions and gain some level of consensus on the architectures. 1.1 Conventions used in this document 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 [1]. Calhoun, et al. Expires January 16, 2006 [Page 5] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 2. CAPWAP Functions The CAPWAP taxonomy specification defines the CAPWAP functions, which are also described in Section 1 of this document. In order to ensure compatibility among CAPWAP devices, it is necessary to come to agreement on the location of the various CAPWAP Functions. There was a surprising amount of similarity in the placement of the CAPWAP functions across all architectures within a given category in the taxonomy specification. From that document, Figure 2 attempts to use the most consistent location for each function and proposes a model for both the Local and Split architecture. Local Split Functions MAC MAC ----- ----- RF Monitoring WTP WTP RF Configuration AC AC WTP Configuration AC AC WTP Firmware AC AC STA State Info Database WTP/AC AC AC/WTP Mutual Authentication WTP/AC WTP/AC Figure 2: Mapping of CAPWAP Functions Note when a function appears to reside in both network elements (e.g., WTP/AC), it implies that this is a split function among both the WTP and the AC. Calhoun, et al. Expires January 16, 2006 [Page 6] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 3. Split AP It is clear that there are significant similarities among most of the Split MAC architectures, and as a consequence providing a proposed architecture here should be simpler. In this section we attempt to provide a proposal for a Split AP architecture for the CAPWAP working group. The following paragraphs are found in the taxonomy specification and provide a high level view of the "CAPWAP 802.11 MAC Split" 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 the 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 o Integration Services: bridging between 802.11 and 802.3 o Privacy: 802.11 Encryption/Decryption o Fragmentation/Defragmentation The above list is a good starting place for evaluating a Split AP protocol. However, there are two issues with functions listed as residing in the AC: Calhoun, et al. Expires January 16, 2006 [Page 7] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 o Fragmentation/Defragmentation. Requiring this function to exist in the AC will cause issues with support for 802.11e. In the 802.11e specification, and more importantly the HCCA mechanism defined, an AP may need to fragment frames in order to fill a scheduled service period; thus 802.11e defines this function to be realtime for some instance. Moving this function to the AC is not possible since access to the air is required in order to be able to react to instantaneous changes in bandwidth, either as a result of noise or co-channel interference from adjacent APs or STAs. Placing this function in the AC would preclude an implementer from using the feature of 802.11e. In addition, this function is often used as part of the retransmission strategy, the control of which is in the WTP. o Privacy. There are two components to Privacy; 802.11 data privacy and secure session establishment (802.1X/EAP). It is agreed that the 802.1X/EAP function should reside in the AC. However, while encryption/decryption services could be performed in the WTP in most of today's circumstances, this becomes very problematic when used in conjunction with HCCA. As previously noted, HCCA will cause frames to be fragmented in order to fill a service period, and fragmentation occurs prior to encryption in 802.11. Requiring encryption services in the AC is not possible, again, else it preclude an implementer from utilizing these 802.11e features. Taking the above information, and assuming that the CAPWAP functions are handled in the AC, Figure 3 proposes a functional definition for all functions in a Split MAC architecture. Function Location Distribution Service AC Integration Service AC Beacon Generation WTP Probe Response WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc AC (1) 802.11e Classifying AC Scheduling WTP/AC (2) Queuing WTP 802.11i 802.1X/EAP AC Key Management AC 802.11 Encryption/Decryption WTP Calhoun, et al. Expires January 16, 2006 [Page 8] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 Figure 3: Mapping of 802.11 Functions for Split AP Architecture (1) The messages exchanged between the AC and the WTP do not necessarily mean these are 802.11 MAC management packets, but an equivalent message would have to be exchanged to allow the AC to maintain proper state. However, note that the introduction of 802.11r will necessitate the co-location of both 802.11i key management and 802.11 MAC Management messages. (2) Packet scheduling may occur on the AC, but MUST occur on the WTP. Calhoun, et al. Expires January 16, 2006 [Page 9] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 4. Local AP The local MAC architecture is one that is not very well defined in the taxonomy specification, primarily due to the variations in the architectures listed. The following paragraph can be found in the taxonomy document and is central to the architecture being proposed in this section (please note all references are against the taxonomy specification, not this document): 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. There appears to be some confusion as to what a local MAC architecture means in the various implementations listed in the taxonomy document. For instance, an implementation that takes an 802.11 MAC management packet and creates a separate request, which is forwarded for processing at the AC, is sometimes considered a Local MAC. This is primarily due to the fact that the actual 802.11 MAC protocol never leaves the WTP. While this is correct in principle, the reality is that the functionality provided by such a solution would be identical in nature to a Split MAC approach. As a consequence, this document assumes that even though these architectures were classified as being Local MAC in the taxonomy document, they are really Split MAC (but implemented in a slightly different way). This section will attempt to provide a proposal for a local AP architecture that the CAPWAP WG could consider. Using the above assumptions, all of the 802.11 MAC resides on the Local AP WTP and only the CAPWAP functions are found on the AC. However, it is important to note that the 802.11i components in Figure 4 overlap directly with the "STA State Info Database" CAPWAP function described in Figure 2. As a consequence, it is only natural to locate the 802.1X and Key Management 802.11i functions centrally in the AC. The resulting function distribution for a Local AP architecture can be found in Figure 4 Calhoun, et al. Expires January 16, 2006 [Page 10] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 Function Location Distribution Service WTP Integration Service WTP Beacon Generation WTP Probe Response WTP Power Mgmt/Packet Buffering WTP Fragmentation/Defragmentation WTP Assoc/Disassoc/Reassoc WTP 802.11e Classifying WTP Scheduling WTP Queuing WTP 802.11i 802.1X/EAP AC Key Management AC 802.11 Encryption/Decryption WTP Figure 4: Mapping of 802.11 Functions for Local AP Architecture To summarize, a Local AP architecture is one where all of the normal 802.11 AP functions, with the exception of 802.1X and the 802.11i key management functions, reside in the WTP, but centralized control and provisioning, defined as CAPWAP functions, reside in the AC. Calhoun, et al. Expires January 16, 2006 [Page 11] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 5. CAPWAP Signalling The issue that remains at this point is whether a single protocol is capable of supporting both Split and Local AP modes. The primary differences between both is that a Local AP implementation is generally used in network deployments where a long latency link exists between the WTP and the AC. Therefore, it is not realistic to expect that the MAC management response times assumptions in 802.11 stations can be supported if the MAC management packets had to traverse a high latency network towards the AC. As a result, certain Local MAC implementations have created an agent that sits at the 802.11 SME layer on the WTP. This agent simply creates a protocol PDU based on the information received at the SME, and forwards it to the AC (see Figure 5. +----------------------------+ | CAPWAP AC Function | |- - - - - - - - - - - - - - | AC | CAPWAP Protocol | +----------------------------+ IP Network +----------------------------+ | CAPWAP Protocol | |- - - - - - - - - - - - - - | | SME Layer | WTP |- - - - - - - - - - - - - - | | 802.11 MAC Management | +----------------------------+ Figure 5: Local AP Diagram While creating an SME agent at the WTP is one method of implementing a Local AP architecture, there is an alternative that allows for a single CAPWAP protocol to be used by both Split and Local AP architectures. This method is known as Proxy MAC, whereby the WTP actually processes the MAC management frames received, and then forwards these frames to the AC. This allows the AC to be notified of SME events at the WTP, while allowing this to be provided by simply encapsulating the 802.11 MAC management frames. This Proxy MAC mechanism is agnostic to wireless MAC technology. A Proxy MAC function can be applied to other wireless MAC technologies to allow a WTP to transmit MAC-specific events to the AC. Calhoun, et al. Expires January 16, 2006 [Page 12] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 +----------------------------+ | CAPWAP AC Function | |----^---------- - - - - - - | | | Split AP | AC |----|---------- - - - - ^ - | | | CAPWAP Protocol | | +----|-------------------|---+ | | | IP Network | | | +----|-------------------|---+ | | CAPWAP Protocol | | |- - v - - - - ----------|---| | Proxy MAC | | WTP |- - - - - - - ----------v---| | 802.11 MAC Management | +----------------------------+ Figure 6: Proxy AP Diagram Calhoun, et al. Expires January 16, 2006 [Page 13] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 6. Capabilities Negotiation Many of the discussions in the CAPWAP mailing list have revolved around the need for flexibility, and as such, the need to provide multiple optional features that would be negotiated between the WTP and the AC. The introduction of optional features is a means to introduce interoperability issues. This is clearly seen in some CAPWAP proposals that lay out a complex options matrix, allowing for a large number of combinations. While it is not possible to eliminate all of the options in a protocol or architecture, it is clear that the presence of such options must not create interoperability issues, must be limited in number, and have clear mandatory to implement modes. In the end, the CAPWAP WG serves the Internet Community, and not resolving this issue simply places the burden on the end customer, causing them to try to figure out how to get multiple CAPWAP compliant devices to interoperate. This document suggests out of the box interoperability by proposing the following CAPWAP protocol options, with specific default values: o Data Path Tunneling: While some proposals encapsulate the user frames in their natural 802.11 form, other proposals prefer the use of 802.3, a clear indication of an interoperability issue. However, if one were to make Local AP, meaning local bridging of user frames, be the default (mandatory to implement) mode, then interoperability would be guaranteed, and Split AP mode could be enabled only if both the AC and the WTP supported the same encapsulation format. o Split vs. Local AP: The WG needs to pick a mandatory to implement mode for handling MAC Management frames. A recommendation is local AP. o Split AP Encryption Mode: Given the issues discussed in this document regarding support for HCCA, the only reasonable mandatory to implement encryption mode is in the WTP. Further, this is only natural as all 802.11 MACs today support the 802.11i encryption mechanisms in hardware. The CAPWAP protocol MUST allow for negotiation of encryption in the AC. Calhoun, et al. Expires January 16, 2006 [Page 14] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 7. Conclusion We have defined both the Local and Split AP architectures in the previous sections. The observations described in this document clearly outline their differences. To summarize, these are: o Data Path Tunneling: In a Split AP approach, all of the 802.11 data frames are tunneled to the AC, while a Local AP design would require the WTP to locally bridge the traffic. o 802.11 Functions: In a Split AP approach, the 802.11 MAC management functions reside in the AC. In the Local AP architecture all of the access control decisions reside in the WTP, while the 802.1X authenticator resides in the AC. This document has also observed that a single protocol could provide both Local and Split AP modes, through the introduction of Proxy MAC. This method allows the AC to be notified of SME events, without requiring a new protocol, significantly simplifying the task of the Working Group. Lastly, this document has listed a small number of CAPWAP architectures, with specific default (mandatory to implement) values, guaranteeing interoperability among any CAPWAP compliant devices. The CAPWAP working group should seriously consider the Split and Local AP architectures defined in this document, allowing the working group to put aside the bagagge associated with the concept of splitting the MAC and focus instead on splitting the AP functions. Calhoun, et al. Expires January 16, 2006 [Page 15] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 8. Security Considerations This document is an observation of the two main architectures being discussed within the CAPWAP working group. As a consequence, there is nothing specific about this document that introduces new security considerations. Calhoun, et al. Expires January 16, 2006 [Page 16] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 9. IANA Considerations This document requires no action by IANA. Calhoun, et al. Expires January 16, 2006 [Page 17] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 10. IPR Statement The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Please refer to http://www.ietf.org/ietf/IPR for more information. 11. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Govindan, S., "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", draft-ietf-capwap-objectives-03 (work in progress), June 2005. [3] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-06 (work in progress), November 2004. Authors' Addresses Pat R. Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5269 Email: pcalhoun@cisco.com Bob O'Hara Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408-853-5513 Email: bob.ohara@cisco.com Calhoun, et al. Expires January 16, 2006 [Page 18] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 Inderpreet Singh Chantry Networks Inc. 1900 Minnesota Court Mississauga, ON L5N 3C9 Canada Phone: +1 905-363-6412 Email: inderpreet.singh@siemens.com Calhoun, et al. Expires January 16, 2006 [Page 19] Internet-Draft CAPWAP Taxonomy Recommendations July 2005 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Calhoun, et al. Expires January 16, 2006 [Page 20]