[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/