Network Working Group S. Govindan Internet-Draft H. Cheng Expires: April 2005 S. Iino M. Sugiura Panasonic October 2004 Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) draft-govindan-capwap-objectives-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in April 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document presents objectives for the Control and Provisioning of Wireless Access Points (CAPWAP) framework. Primarily it presents a fundamental objective for interoperability among wireless local area Govindan, et al. Expires April 2005 [Page 1] Internet-Draft CAPWAP Objectives October 2004 network (WLAN) devices of different designs. The document also describes additional objectives for shared WLAN infrastructure and QoS. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Adaptive Interfaces Objective . . . . . . . . . . . . . . . . 5 3.1 Objective Details . . . . . . . . . . . . . . . . . . . . 5 3.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 5 3.3 Relation to Problem Statement . . . . . . . . . . . . . . 5 3.4 Customer Requirements . . . . . . . . . . . . . . . . . . 6 4. Logical Networks Support . . . . . . . . . . . . . . . . . . . 7 4.1 Objective Details . . . . . . . . . . . . . . . . . . . . 7 4.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 7 4.3 Relation to Problem Statement . . . . . . . . . . . . . . 7 4.4 Customer Requirements . . . . . . . . . . . . . . . . . . 7 5. Coexistence of Multiple Authentication Mechanisms . . . . . . 9 5.1 Objective Details . . . . . . . . . . . . . . . . . . . . 9 5.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 9 5.3 Relation to Problem Statement . . . . . . . . . . . . . . 9 5.4 Customer Requirements . . . . . . . . . . . . . . . . . . 9 6. Automated Processes Objective . . . . . . . . . . . . . . . . 10 6.1 Objective Details . . . . . . . . . . . . . . . . . . . . 10 6.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 10 6.3 Relation to Problem Statement . . . . . . . . . . . . . . 10 6.4 Customer Requirements . . . . . . . . . . . . . . . . . . 10 7. WLAN Status Monitoring Objective . . . . . . . . . . . . . . . 11 7.1 Objective Details . . . . . . . . . . . . . . . . . . . . 11 7.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 11 7.3 Relation to Problem Statement . . . . . . . . . . . . . . 11 7.4 Customer Requirements . . . . . . . . . . . . . . . . . . 11 8. QoS Objective . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1 Objective Details . . . . . . . . . . . . . . . . . . . . 12 8.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 12 8.3 Relation to Problem Statement . . . . . . . . . . . . . . 12 8.4 Customer Requirements . . . . . . . . . . . . . . . . . . 13 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Govindan, et al. Expires April 2005 [Page 2] Internet-Draft CAPWAP Objectives October 2004 1. Requirements notation 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 [RFC2119]. Govindan, et al. Expires April 2005 [Page 3] Internet-Draft CAPWAP Objectives October 2004 2. Introduction The first phase of standardization for the Control and Provisioning of Wireless Access Points (CAPWAP) has resulted in the recognition of major problems associated with large scale wireless local area network (WLAN) deployments [I-D.ietf-capwap-problem-statement]. Briefly, these relate to management complexity, configuration consistency, management of wireless medium and WLAN security. The WLAN landscape, in the context of design variants, was also surveyed as part of this initial phase. The Architecture Taxonomy [I-D.ietf-capwap-arch] classifies WLANs in to three major architecture families; remote MAC, split MAC and local MAC. Each differs in the degree of separation of MAC layer capabilities among access points (APs) and WLAN controller. This document puts forth critical objectives for realizing interoperability in a CAPWAP framework. It presents a basic objective for APs of different architectural designs to interoperate within a single WLAN controller domain. The realization of this objective will enable true interoperability in that major WLAN designs may be integrally deployed and managed. Additional objectives put forth in this document relate to Qos and shared infrastructure deployments. Such deployments are increasingly popular in the commercial market as they offer cost benefits and flexibility. Details of the deployment scenario are provided in [I-D.cheng-capwap-classifications]. Govindan, et al. Expires April 2005 [Page 4] Internet-Draft CAPWAP Objectives October 2004 3. Adaptive Interfaces Objective With the focusing of standardization efforts on local MAC and split MAC designs, it is crucial to ensure mutual interoperation among them. This is emphasized in the first objective. 3.1 Objective Details The first objective for CAPWAP is to ensure that APs designed for both local MAC and split MAC architectures are capable of interoperation within a single WLAN. On the basis of this objective, the CAPWAP protocol will utilize adaptive interfaces corresponding to the design variants. [I-D.cheng-capwap-classifications] presents additional details on how flexibility in the CAPWAP protocol may be achieved so as to realize this objective. This objective also addresses the need for flexibly configuring APs based on their design types and other setup aspects. 3.2 Protocol Benefits The benefits of realizing the adaptive interfaces objective are both technical and practical. First, there are substantial overlaps in the control operations between the local MAC and split MAC architectures. As a result, it is technically practical to devise a single protocol that manages both types of devices. Next, the ability to operate a CAPWAP protocol for both types of architectural designs enhances its practical prospects as it will have wider appeal. Furthermore, the additional complexity resulting from such adaptive interfaces is marginal. Consequently, the benefits of this objective will far outweigh any cost of realizing it. 3.3 Relation to Problem Statement The objective for adaptive interfaces between APs and WLAN controllers is fundamental to addressing the Problem Statement [I-D.ietf-capwap-problem-statement]. It forms the basis for those problems to be uniformly addressed across the major WLAN architectures. This is the ultimate aim of standardization efforts. The realization of this first objective will ensure that the solutions for [I-D.ietf-capwap-problem-statement] are consistent for both WLAN designs. Govindan, et al. Expires April 2005 [Page 5] Internet-Draft CAPWAP Objectives October 2004 3.4 Customer Requirements A number of service providers and equipment vendors see benefits with the combined usage of both local MAC and split MAC designs. APs of different designs are placed in different locations so as to selectively take advantage of their respective characteristics. The adaptive interface objective therefore addresses critical needs for the market. Furthermore, since there are products of each design type already in the market and widely deployed, it is necessary for CAPWAP protocol to support both of them. [TBD] Govindan, et al. Expires April 2005 [Page 6] Internet-Draft CAPWAP Objectives October 2004 4. Logical Networks Support Large WLANs are complex systems that need to be closely managed for optimal performance. Furthermore, they are expensive to deploy and enterprises are under pressure to improve the efficiency of their expenditures. These issues are being addressed by means of deploying a number of logical networks over a single physical WLAN infrastructure. This way the cost of deployment and management can be shared. A scenario together with additional details for such shared WLANs is presented in [I-D.cheng-capwap-classifications]. 4.1 Objective Details The objective for supporting logical networks involves mutual separation of control and communications among them. Large WLANs are therefore controlled in terms of distinct logical networks. So, a number of service providers may jointly utilize network infrastructure thereby sharing expenditures. 4.2 Protocol Benefits Given the realities of cost and complexity of WLANs, a CAPWAP protocol that incorporates this objective ensures simpler and cost effective WLAN management and deployment. A protocol that realizes this is therefore consistent with the goal of reducing complexity in large scale WLANs. 4.3 Relation to Problem Statement This objective for supporting logical networks directly addresses problem of management complexity. It is solved by breaking complexity in to manageable levels. So different logical networks are separated and then individually managed. 4.4 Customer Requirements Businesses require the benefits of management ease by the most cost effective means. This can be achieved with the objective of supporting logical networks within a single set of physical WLAN equipment. There are a number of ways of realizing this objective some being virtual APs, VLAN tunnels and other tunnels. This objective also allows for separation between providers of infrastructure from services. Logical networks allows for the separation of physical deployment and maintenance from actual management of WLANs. This helps lower costs and responsibilities for service providers. Govindan, et al. Expires April 2005 [Page 7] Internet-Draft CAPWAP Objectives October 2004 [TBD] Govindan, et al. Expires April 2005 [Page 8] Internet-Draft CAPWAP Objectives October 2004 5. Coexistence of Multiple Authentication Mechanisms As WLANs grow in size and utility, there are increasing means of authenticating subscribers. The choice of which to use depends on the deployment scenario, service provider preference and other design aspects. This objective addresses such diversity. 5.1 Objective Details The objective is to include support for multiple authentication mechanisms. This is to ensure that a CAPWAP protocol has a framework where different types of authentication may coexist. In practice, the different mechanisms may coexist within a single logical WLAN or among a number of them. In either case, protocol support is critical. 5.2 Protocol Benefits A protocol that includes support for a number of authentication mechanisms will be applicable in a wide range of deployments and scenarios. 5.3 Relation to Problem Statement This objective relates to large WLAN deployments where there are a variety of requirements from service providers, subscribers and regulators. Authentication mechanisms will therefore differ for various requirements. In order to accommodate all these differences, the CAPWAP protocol must support multiple authentication mechanisms. 5.4 Customer Requirements Customers are demanding choice and flexibility in the way in which they use WLANs. For example, service providers want different ways of authenticating different subscriber groups; some groups need IEEE 802.1X while others web-based authentication. Furthermore, there are trends for temporary authentications where the duration of authentication is adapted. This objective is in response to such requirements. [TBD] Govindan, et al. Expires April 2005 [Page 9] Internet-Draft CAPWAP Objectives October 2004 6. Automated Processes Objective WLANs are increasing in complexity due to the sheer size of deployments. As a result, the cost of operating and managing wireless networks is becoming substantial. This section presents an objective for automating key processes of WLAN control by which operational costs may be reduced. 6.1 Objective Details The objective is to simplify and automate discovery and initialization processes. New AP designs being inexpensive and easy to install, allow for frequent alterations to the physical WLAN according to deployment needs. This calls for automating the processes for setting up new WLAN devices. 6.2 Protocol Benefits Automation is a key benefit to a CAPWAP protocol as it makes for cost-effective deployment. This has a direct effect on the adoption of the protocol. 6.3 Relation to Problem Statement This objective for automation is derived from the problem of managing complexity. The problem relates to large scale deployments in which discovery and initialization are intensive, error-prone and consequently, costly, operations. Realization of this objective will be a direct solution to this problem. 6.4 Customer Requirements Wireless network service providers have consistently required cost-effective solutions. As these providers are predominantly commercial, this objective is crucial for realization. [TBD] Govindan, et al. Expires April 2005 [Page 10] Internet-Draft CAPWAP Objectives October 2004 7. WLAN Status Monitoring Objective The scale of WLANs that CAPWAP addresses results in a number of challenges. Among them, is the possibility of multiple points of failure at different time instances. 7.1 Objective Details This objective is for monitoring the status of WLANs, including various devices, so as to appropriately configure and manage them. WLAN status is used broadly here to include statistics, keepalive signals and other input information. Status information may therefore be combined in the realization of this objective. 7.2 Protocol Benefits The effectiveness of a protocol is based on the relevance of information on which it operates. So, the fulfillment of this objective will ensure that such information is made available to a CAPWAP protocol. 7.3 Relation to Problem Statement This objective addresses the problems of management complexity and WLAN configuration for which solutions require appropriate information. For the former problem, the scale, type and active status of the WLAN is required, while in the latter, consistent configurations are maintained based on timely information. 7.4 Customer Requirements WLAN equipment customers require effective management solutions for their networks. This objective will ensure such a solution by providing the appropriate information on traffic conditions and network status. [TBD] Govindan, et al. Expires April 2005 [Page 11] Internet-Draft CAPWAP Objectives October 2004 8. QoS Objective Integral to the success of any wireless network system is the performance and quality it can offer its subscribers. So for large scale WLANs, system-wide QoS is particularly important. 8.1 Objective Details The objective is for QoS over the entire WLAN system which includes the switching segment and the wireless medium. Given the fundamental differences between the two, it is likely that there are alternate QoS mechanisms between APs and wireless service subscribers and between APs and WLAN controllers. So resources need to be adjusted over both portions of the system so as to ensure throughput and other performance. 8.2 Protocol Benefits A protocol that addresses QoS aspects of WLAN systems will deliver high performance thereby beneficial for wireless subscribers and resource utilization. Since CAPWAP deals with APs directly and with the wireless medium indirectly, both of these must be considered for performance. For the wireless medium portion, QoS aspects in the protocol enable high quality communications within the domain of a WLAN controller. Since each domain generally covers an enterprise, such protocol performance affects enterprise-wide communications. Within the switching segment of CAPWAP, a QoS-enabled protocol minimizes the adverse effects of dynamic traffic characteristics so as to ensure system-wide performance. 8.3 Relation to Problem Statement QoS control is critical to large WLANs and relates to a number of aspects. In particular, this objective addresses the problem of accommodating dynamic conditions of the wireless medium. Furthermore, traffic characteristics in large scale WLANs are constantly varying. So network utilization becomes inefficient and user experience is unpredictable. The interaction and coordination between the two aspects of system-wide QoS is therefore critical for performance. Govindan, et al. Expires April 2005 [Page 12] Internet-Draft CAPWAP Objectives October 2004 8.4 Customer Requirements VoIP is a major application over WLANs. The basic requirement for such applications is QoS. Furthermore, end-users demand quality means of communications, so service providers in turn emphasize on the QoS capabilities of WLAN systems. Adopting this objective will ensure all demands are met. [TBD] Govindan, et al. Expires April 2005 [Page 13] Internet-Draft CAPWAP Objectives October 2004 9. Conclusion This draft presents critical objectives for the CAPWAP framework. Most importantly, it lays down the need for enabling CAPWAP over adaptive interfaces so that APs of both local MAC and split MAC designs are integrally manageable and controlled. The document also provides additional objectives for shared infrastructure and QoS. Govindan, et al. Expires April 2005 [Page 14] Internet-Draft CAPWAP Objectives October 2004 10. Security Considerations The adaptive interface objective covers the interoperability of APs from both local MAC and split MAC designs. As such, a WLAN controller must be capable of securing both of these design types. This may include handling different degrees of security or authentication processing for the two types of APs. In shared deployments with a number of a when a number logical networks, it is crucial to ensure mutual separation of traffic among them. Access control should therefore be distinct for each of the logical networks. Furthermore, subscribers to different service providers need to be managed based on their respective requirements, subscriptions, etc. Cross exchanges need to be secured against. It should be ensured that any stray exchange be prevented with the automation of discovery and initialization processes. The objective for WLAN status monitoring relates to security also. Wireless systems need to be constantly monitored for potential threats in the form of rogue APs or terminals. For example, profiles for DoS and replay attacks need to be monitored. Govindan, et al. Expires April 2005 [Page 15] Internet-Draft CAPWAP Objectives October 2004 11. Acknowledgements The authors gratefully thank T. Sridhar for reviewing an earlier version of this draft. 12 References [I-D.cheng-capwap-classifications] Cheng, H., Iino, S. and Govindan S., "Funcationality Classifications for Control and Provisioning of Wireless Access Points", draft-cheng-capwap-classifications-01 (work in progress), July 2004. [I-D.ietf-capwap-arch] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-05 (work in progress), August 2004. [I-D.ietf-capwap-problem-statement] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-problem-statement-02 (work in progress), September 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses S. Govindan Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5441 EMail: sgovindan@psl.com.sg Govindan, et al. Expires April 2005 [Page 16] Internet-Draft CAPWAP Objectives October 2004 H. Cheng Panasonic Singapore Laboratories Block 1022, Tai Seng Industrial Estate #06-3530, Tai Seng Avenue Singapore 534415 Singapore Phone: +65 6550 5477 EMail: hcheng@psl.com.sg S. Iino Panasonic Mobile Communications 600, Saedo-cho Tsuzuki-ku Yokohama 224-8539 Japan Phone: +81 45 938 3789 EMail: iino.satoshi@jp.panasonic.com M. Sugiura Panasonic Mobile Communications 600, Saedo-cho Tsuzuki-ku Yokohama 224-8539 Japan Phone: +81 45 938 3789 EMail: sugiura.mikihito@jp.panasonic.com Govindan, et al. Expires April 2005 [Page 17] Internet-Draft CAPWAP Objectives October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Govindan, et al. Expires April 2005 [Page 18]