[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-zhou-capwap-objectives) 00 01 02 03 04 RFC 4564

CAPWAP Working Group                                S. Govindan (Editor)
Internet-Draft                                                 Panasonic
Expires: May 2005                                                ZH. Yao
                                                                  Huawei
                                                                WH. Zhou
                                                            China Mobile
                                                                 L. Yang
                                                                   Intel
                                                                H. Cheng
                                                               Panasonic
                                                           November 2004

   Objectives for Control and Provisioning of Wireless Access Points
                                (CAPWAP)
                  draft-ietf-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 on May 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract


Govindan (Editor), et al.    Expires May 2005                   [Page 1]

Internet-Draft             CAPWAP Objectives               November 2004

   This document presents a set of objectives for an interoperable
   protocol for the Control and Provisioning of Wireless Access Points
   (CAPWAP).  It presents objectives in three categories: architecture,
   operations and security.  The primary purpose of the document is to
   present focused requirements which when realized, will ensure
   interoperability among wireless local area network (WLAN) devices of
   alternative designs.  These objectives will form the basis for the
   development and evaluation of a CAPWAP protocol.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Categories of Objectives . . . . . . . . . . . . . . . . . . .  7
   5.  Architecture Objectives  . . . . . . . . . . . . . . . . . . .  8
     5.1   Interoperability Objective . . . . . . . . . . . . . . . .  8
       5.1.1   Objective Details  . . . . . . . . . . . . . . . . . .  8
       5.1.2   Motivation and Protocol Benefits . . . . . . . . . . .  9
       5.1.3   Relation to Problem Statement  . . . . . . . . . . . .  9
       5.1.4   Customer Requirements  . . . . . . . . . . . . . . . .  9
       5.1.5   Classification (Mandatory, Desirable, Rejected)  . . .  9
     5.2   Interconnection Objective  . . . . . . . . . . . . . . . .  9
       5.2.1   Objective Details  . . . . . . . . . . . . . . . . . . 10
       5.2.2   Motivation and Protocol Benefits . . . . . . . . . . . 10
       5.2.3   Relation to Problem Statement  . . . . . . . . . . . . 10
       5.2.4   Customer Requirements  . . . . . . . . . . . . . . . . 10
       5.2.5   Classification (Mandatory, Desirable, Rejected)  . . . 10
     5.3   Support for Logical Networks . . . . . . . . . . . . . . . 10
       5.3.1   Objective Details  . . . . . . . . . . . . . . . . . . 11
       5.3.2   Motivation and Protocol Benefits . . . . . . . . . . . 11
       5.3.3   Relation to Problem Statement  . . . . . . . . . . . . 12
       5.3.4   Customer Requirement . . . . . . . . . . . . . . . . . 12
       5.3.5   Classification (Mandatory, Desirable, Rejected)  . . . 12
     5.4   Extensibility Objective  . . . . . . . . . . . . . . . . . 12
       5.4.1   Objective Details  . . . . . . . . . . . . . . . . . . 12
       5.4.2   Motivation and Protocol Benefits . . . . . . . . . . . 13
       5.4.3   Relation to Problem Statement  . . . . . . . . . . . . 13
       5.4.4   Customer Requirements  . . . . . . . . . . . . . . . . 13
       5.4.5   Classification (Mandatory, Desirable, Rejected)  . . . 13
   6.  Operations Objective . . . . . . . . . . . . . . . . . . . . . 14
     6.1   WLAN Monitoring Objective  . . . . . . . . . . . . . . . . 14
       6.1.1   Objective Details  . . . . . . . . . . . . . . . . . . 14
       6.1.2   Motivation and Protocol Benefits . . . . . . . . . . . 15
       6.1.3   Relation to Problem Statement  . . . . . . . . . . . . 15
       6.1.4   Customer Requirement . . . . . . . . . . . . . . . . . 15
       6.1.5   Classification (Mandatory, Desirable, Rejected)  . . . 15
     6.2   Resource Control Objective . . . . . . . . . . . . . . . . 15


Govindan (Editor), et al.    Expires May 2005                   [Page 2]

Internet-Draft             CAPWAP Objectives               November 2004

       6.2.1   Objective Details  . . . . . . . . . . . . . . . . . . 15
       6.2.2   Motivation and Protocol Benefits . . . . . . . . . . . 16
       6.2.3   Relation to Problem Statement  . . . . . . . . . . . . 16
       6.2.4   Customer Requirements  . . . . . . . . . . . . . . . . 16
       6.2.5   Classification (Mandatory, Desirable, Rejected)  . . . 16
     6.3   Support for Traffic Separation . . . . . . . . . . . . . . 17
       6.3.1   Objective Details  . . . . . . . . . . . . . . . . . . 17
       6.3.2   Motivation and Protocol Benefits . . . . . . . . . . . 17
       6.3.3   Relation to Problem Statement  . . . . . . . . . . . . 17
       6.3.4   Customer Requirements  . . . . . . . . . . . . . . . . 17
       6.3.5   Classification (Mandatory, Desirable, Rejected)  . . . 17
     6.4   STA Admission Control Objective  . . . . . . . . . . . . . 17
       6.4.1   Objective Details  . . . . . . . . . . . . . . . . . . 18
       6.4.2   Motivation and Protocol Benefits . . . . . . . . . . . 18
       6.4.3   Relation to Problem Statement  . . . . . . . . . . . . 18
       6.4.4   Customer Requirements  . . . . . . . . . . . . . . . . 18
       6.4.5   Classification (Mandatory, Desirable, Rejected)  . . . 18
     6.5   Centralized WTP Management . . . . . . . . . . . . . . . . 18
   7.  Security Objectives  . . . . . . . . . . . . . . . . . . . . . 19
     7.1   CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 19
       7.1.1   Objective Details  . . . . . . . . . . . . . . . . . . 19
     7.2   System-wide Security . . . . . . . . . . . . . . . . . . . 19
   8.  Objectives for Further Discussion  . . . . . . . . . . . . . . 20
     8.1   Centralized WTP Management . . . . . . . . . . . . . . . . 20
     8.2   Security borderline Control  . . . . . . . . . . . . . . . 20
     8.3   Trust model Definition . . . . . . . . . . . . . . . . . . 20
     8.4   IEEE 802.11i Considerations  . . . . . . . . . . . . . . . 20
   9.  Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 21
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 22
   11.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
       Intellectual Property and Copyright Statements . . . . . . . . 26









Govindan (Editor), et al.    Expires May 2005                   [Page 3]

Internet-Draft             CAPWAP Objectives               November 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 (Editor), et al.    Expires May 2005                   [Page 4]

Internet-Draft             CAPWAP Objectives               November 2004

2.  Terminology

   This document follows the terminologies of [I-D.ietf-capwap-arch].
   Additionally, the following terms are defined;

   Switching segment: Those aspects of a centralized WLAN that primarily
   deal with switching or routing control and data information between
   Wireless Termination Points (WTPs) and the WLAN controller.

   Wireless medium segment: Those aspects of a centralized WLAN that
   primarily deal with the end-user interface which is wireless.
   Initially, CAPWAP focuses on IEEE 802.11 technologies but this
   segment may also refer to other technologies such as IEEE 802.16.

   CAPWAP framework: A term that includes the local MAC and split MAC
   designs of the Centralized WLAN Architecture.  Standardization
   efforts are focussed on these designs.

   CAPWAP protocol: The protocol between WLAN controller and WTPs in the
   CAPWAP framework.  It facilitates control, management and
   provisioning of WTPs in an interoperable manner.















Govindan (Editor), et al.    Expires May 2005                   [Page 5]

Internet-Draft             CAPWAP Objectives               November 2004

3.  Introduction

   The growth in large scale wireless local area network (WLAN)
   deployments has brought to focus a number of technical challenges.
   This includes the complexity of managing large numbers of wireless
   termination points (WTPs), which is further exacerbated by
   differences in their design.  Another challenge is the maintenance of
   consistent configurations among the numerous WTPs.  The dynamic
   nature of the wireless medium is also a concern together with WLAN
   security.  These challenges have been highlighted in
   [I-D.ietf-capwap-problem-statement].

   Many vendors have addressed these challenges for large scale WLAN
   deployments by developing new architectures and solutions.  A survey
   of the various architectures and solutions was conducted to better
   understand the context of the challenges so as to develop
   interoperability among them.  The Architecture Taxonomy
   [I-D.ietf-capwap-arch] is a result of this survey in which major
   architecture families are classified.  Broadly, these are the
   autonomous, centralized WLAN and distributed mesh architectures.  The
   survey showed that the current majority of large scale deployments
   follow the centralized WLAN architecture in which portions of the
   wireless medium access control (MAC) operations are centralized in a
   WLAN controller.  This architecture family is further classified into
   remote MAC, split MAC and local MAC.  Each differs in the degree of
   separation of MAC layer capabilities among WTPs and WLAN controller.

   This document puts forth critical objectives for achieving
   interoperability in a CAPWAP framework.  It presents objectives that
   address the challenges of large scale WLAN deployments.  The
   realization of these objectives will ensure that WLAN equipment of
   major design types may be integrally deployed and managed.










Govindan (Editor), et al.    Expires May 2005                   [Page 6]

Internet-Draft             CAPWAP Objectives               November 2004

4.  Categories of Objectives

   The objectives for the CAPWAP protocol are organized into three major
   categories; architecture, operations and security.

   Architecture objectives deal with system level aspects of the CAPWAP
   protocol.  They address issues of protocol extensibility, diverse
   network deployments and architecture designs and differences in
   transport technologies.

   Operational objectives address the control and management features of
   the CAPWAP protocol.  They deal with operations relating to
   system-wide resource management, WTP management, QoS and STA access
   control.

   Security objectives address potential threats to WLANs and their
   containment.  Specifically, they deal with securing the CAPWAP
   protocol and the WLAN system as a whole.  The objectives also address
   security requirements from end-users and service providers.
















Govindan (Editor), et al.    Expires May 2005                   [Page 7]

Internet-Draft             CAPWAP Objectives               November 2004

5.  Architecture Objectives

   The architectural considerations of centralized WLAN networks are
   fundamental to the development and evaluation of a CAPWAP protocol.
   The objectives in this category deal with system level aspects
   relating to protocol extensibility, diversity of network deployments
   and differences among vendor equipment.

5.1  Interoperability Objective

   Two major designs of the centralized WLAN architecture are local MAC
   and split MAC.  With the focusing of standardization efforts on these
   two designs, it is crucial to ensure mutual interoperation among
   them.

5.1.1  Objective Details

   This objective for the CAPWAP protocol is to ensure that WTPs of both
   local MAC and split MAC architecture designs are capable of
   interoperation within a single WLAN.  Consequently, a single WLAN
   controller will be capable of controlling both types of WTPs using a
   single CAPWAP protocol.  Integral support for these designs comprises
   a number of protocol aspects.

   i.  Functionality negotiations between WLAN controller and WTPs

   Local MAC and split MAC designs differ in the degree of IEEE 802.11
   MAC functionalities that each type of WTP realizes.  The CAPWAP
   protocol should allow WLAN controllers to determine the
   functionalities of different WTPs as a first step in controlling
   them.

   ii.  Establishment of alternative interfaces

   The functionality differences among different WTPs essentially
   equates to alternative interfaces with a WLAN controller.  So the
   CAPWAP protocol should be capable of adapting its operations to the
   different interfaces.  The definition of these interfaces is
   dependent on the functionality differences among local MAC and split
   MAC WTPs.  It is therefore out of scope of the objectives
   specifications.

   [Functionality Classifications] presents additional details on these
   two aspects.  It shows how flexibility in the CAPWAP protocol may be
   achieved so as to realize this architecture objective.

   This objective also addresses the need for flexibly configuring WTPs
   based on their design types and other setup aspects.


Govindan (Editor), et al.    Expires May 2005                   [Page 8]

Internet-Draft             CAPWAP Objectives               November 2004

5.1.2  Motivation and Protocol Benefits

   The benefits of realizing this architecture objective are both
   technical and practical.  First, there are substantial overlaps in
   the control operations of local MAC and split MAC architecture
   designs.  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
   alternative interfaces is marginal.  Consequently, the benefits of
   this objective will far outweigh any cost of realizing it.

5.1.3  Relation to Problem Statement

   The objective for supporting both local MAC and split MAC WTPs is
   fundamental to addressing [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 objective will
   ensure the development of a comprehensive set of solutions to the
   challenges of large scale WLAN deployments.

5.1.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.  WTPs of
   different designs are placed in different locations so as to
   selectively take advantage of their respective characteristics.  The
   integral support of different architectures 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.

5.1.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]

5.2  Interconnection Objective

   Large scale WLAN deployments are likely to use a variety of
   interconnection technologies between different devices of the


Govindan (Editor), et al.    Expires May 2005                   [Page 9]

Internet-Draft             CAPWAP Objectives               November 2004

   network.  It should therefore be possible for the CAPWAP protocol to
   operate over the different interconnection technologies.  So the
   protocol needs to be independent of underlying transport
   technologies.

5.2.1  Objective Details

   WLAN controllers and WTPs must be able to connect by a variety of
   interconnection technologies.  The fundamental intent is for CAPWAP
   protocol exchanges to be transparent to underlying transport
   technologies.  As a result of realizing this objective, the protocol
   will be capable of operation over different interconnect technologies
   including Ethernet, bus backplanes, ATM (cell) fabrics and also
   wireless technologies such as IEEE 802.11.  Ethernet architecture is
   most widely used and should be recommended.

   The CAPWAP protocol should have the ability to support this diversity
   of interconnection technologies for data and control exchanges.  For
   example, VLAN tunnels are an example of an interconnection technology
   over which CAPWAP may operate.

   Related to this objective, is the QoS aspect of interconnection
   technologies.  Given that QoS will be enabled differently in each of
   these technologies, the CAPWAP protocol must ensure that network
   performance is consistent across different transport means.
   Additionally, QoS consistency has to cover the switching segment and
   the wireless medium segment.

5.2.2  Motivation and Protocol Benefits

   [TBD]

5.2.3  Relation to Problem Statement

   [TBD]

5.2.4  Customer Requirements

   [TBD]

5.2.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]

5.3  Support for Logical Networks

   Large WLAN deployments are complex and expensive.  Furthermore,


Govindan (Editor), et al.    Expires May 2005                  [Page 10]

Internet-Draft             CAPWAP Objectives               November 2004

   enterprises are under pressure to improve the efficiency of their
   expenditures.  These issues are increasingly being addressed by means
   of shared deployments.  As a result, a number of logical networks
   cover a single physical WLAN infrastructure.  This way the cost of
   deployment and management can be shared among network service
   providers.  A scenario together with additional details for such
   shared WLANs is presented in [Functionality Classifications].

5.3.1  Objective Details

   The objective for supporting logical networks involves a number of
   aspects.  These are discussed below;

   i.  WLAN management in terms of logical groups

   Traditionally, each WTP has represented one complete subset of a
   larger WLAN system.  However, with shared deployments, each WTP
   represents a number of subsets of possibly a number of larger WLAN
   systems.  So with such deployments, WLANs need to be managed in terms
   of logical groups instead of physical devices.

   ii.  Mutual separation of control and communications

   Since different logical networks are likely to be associated to
   different enterprises, it is crucial that control and data
   communications among them be mutually separated.  In addition to
   being a security concern, this aspect of the objective also
   highlights a complexity concern.  Specifically, mixing of traffic for
   different logical networks can complicate control.  So the CAPWAP
   protocol must be capable of separating traffic among logical
   networks.  VLANs and other types of tunnels may be used for this
   purpose.

   iii.  Multiple authentication mechanisms

   The presence of multiple logical networks within an infrastructure
   also means there are different subscriber groups in a WLAN system.
   Since the subscriber groups are likely to belong to different service
   providers or WLAN domains, their authentication needs will also be
   different.  As a result, the CAPWAP protocol must be capable of
   transferring different authentication information.  For example, one
   subscriber group may be authenticated with IEEE 802.11i with the WLAN
   controller being the authenticator, while another group could use web
   authentication at an alternative server.

5.3.2  Motivation and Protocol Benefits

   Given the realities of cost and complexity of WLANs, a CAPWAP


Govindan (Editor), et al.    Expires May 2005                  [Page 11]

Internet-Draft             CAPWAP Objectives               November 2004

   protocol that incorporates the objective of supporting logical
   networks 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.

5.3.3  Relation to Problem Statement

   This objective for supporting logical networks addresses problem of
   management complexity in terms of cost.  Such cost complexity is
   reduced by sharing infrastructure among a number of service
   providers.  Consequently, deployment and managements
   cost-efficiencies are realized.

5.3.4  Customer Requirement

   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.

5.3.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]

5.4  Extensibility Objective

   Wireless technology is developing at rapid pace in a number of
   industry and scientific groups.  With such pace, it is important to
   design CAPWAP in a way as to allow future extensibility.  In
   particular, the IEEE is in the process of specifying standards for
   broadband wireless access, namely IEEE 802.16.  There also other
   activities within the IEEE that needs to be considered in the CAPWAP
   context.

5.4.1  Objective Details

   This objective has a number of aspects that are described below;

   i.  Enable support for future wireless technologies


Govindan (Editor), et al.    Expires May 2005                  [Page 12]

Internet-Draft             CAPWAP Objectives               November 2004

   This aspect of the objective essentially purposes that the CAPWAP
   protocol does not rely on specifics of IEEE 802.11 technology for its
   operations.  This will simplify extensibility to support IEEE 802.16.

   ii.  Enable support for new IEEE extensions

   The IEEE is currently reviewing IEEE 802.11 functionality.  It is
   expected that the review will result in new functional blocks,
   interfaces or information flows.  The CAPWAP protocol must be able to
   handle these revisions with minimal changes.

   iii.  User(Client) Access Requirement

   There should not be any impact on the end-user of CAPWAP WLAN in
   terms of both hardware and software aspects.  End-users should not be
   required to be aware of the existence of CAPWAP protocol.

5.4.2  Motivation and Protocol Benefits

   [TBD]

5.4.3  Relation to Problem Statement

   [TBD]

5.4.4  Customer Requirements

   Service providers are not enthusiastic about deploying technologies
   with limited potential for extension.  They require WLAN
   infrastructure to be able to meet current and future market
   requirements.  So the objective for extensibility is critical to
   service providers and other customers of WLAN equipment.

5.4.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]







Govindan (Editor), et al.    Expires May 2005                  [Page 13]

Internet-Draft             CAPWAP Objectives               November 2004

6.  Operations Objective

   CAPWAP aims to provide an interoperable solution to the control and
   provisioning of large scale WLAN deployments.  In this context, the
   operational objectives address functional aspects of the protocol.
   These functions cover system monitoring, resource management and QoS.

6.1  WLAN Monitoring Objective

   The scale of WLANs in the CAPWAP context results in numerous
   information sources.  For example, the configuration of each WTP can
   be considered as an information source.  Additionally, the switching
   segment and wireless medium segment can also be considered as
   information sources.  So for effective performance, the CAPWAP
   protocol needs to regularly monitor the various information sources.

6.1.1  Objective Details

   Large WLANs need a variety of information sources to be monitored.
   So this objective includes a number of aspects.

   i.  Configuration consistency

   CAPWAP based WLANs include a large number of WTPs, each of which need
   to be configured and managed.  The protocol should therefore allow
   WTPs to regularly send information on the state of their
   configuration to their WLAN controller.  Furthermore, it should also
   be capable of consistently distributing firmware to all the WTPs.

   ii.  System-wide resource state

   The centralized WLAN architecture is made up of a switching segment
   and wireless medium segment.  In the switching segment, network
   congestion and WTP status, including firmware information, have to be
   monitored.  In the wireless medium segment, the dynamic nature of the
   medium itself has to be monitored.  Overall, there are also various
   statistics that are required for operation.

   The CAPWAP protocol should therefore be capable of monitoring various
   information sources.  Moreover, given relationships among information
   sources, CAPWAP should combine information from such sources.  For
   example, statistics information may be merged with status signals.
   So this aspect of the objective proposes collective information
   arising from different information sources.  Within this aspect of
   the monitoring objective, the protocol may also allow WTPs to send
   regular send feedback using CAPWAP.



Govindan (Editor), et al.    Expires May 2005                  [Page 14]

Internet-Draft             CAPWAP Objectives               November 2004

6.1.2  Motivation and Protocol Benefits

   The effectiveness of a protocol is based on the relevance of
   information on which it operates.  The objective for WLAN monitoring
   can provide this information to the CAPWAP protocol.  So there will
   tangible benefits with this objective.

6.1.3  Relation to Problem Statement

   This objective addresses the problems of management complexity.  This
   challenge is better solved with the appropriate information resulting
   from this WLAN monitoring.  With collective information from various
   information sources, realizing this objective will help control and
   manage complexity.

   The objective also helps address the challenge of maintaining
   consistent configurations among WTPs.

6.1.4  Customer Requirement

   WLAN equipment customers require effective management solutions for
   their networks.  This objective will ensure such a solution by
   providing collective information from a variety of information
   sources.

6.1.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]

6.2  Resource Control Objective

   Integral to the success of any wireless network system is the
   performance and quality it can offer its subscribers.  Since CAPWAP
   based WLANs combine a switching segment and a wireless medium
   segment, performance and quality need to be coordinated across both
   of these segments.  So QoS performance must be enforced system-wide.

6.2.1  Objective Details

   This objective is for QoS over the entire WLAN system which includes
   the switching segment and the wireless medium segment.  Given the
   fundamental differences between the two, it is likely that there are
   alternate QoS mechanisms between WTPs and wireless service
   subscribers and between WTPs and WLAN controllers.  For instance, the
   former will be based on IEEE 802.11e while the latter will be an
   alternative.  So resources need to be adjusted in a coordinated
   fashion over both segments.  The CAPWAP protocol should ensure that


Govindan (Editor), et al.    Expires May 2005                  [Page 15]

Internet-Draft             CAPWAP Objectives               November 2004

   these adjustments are appropriately exchanged between WLAN
   controllers and WTPs.

6.2.2  Motivation and Protocol Benefits

   A protocol that addresses QoS aspects of WLAN systems will deliver
   high performance thereby being beneficial for subscribers and
   resource utilization.  Since CAPWAP deals with WTPs directly and with
   the wireless medium indirectly, both of these must be considered for
   performance.

   For the wireless medium segment, QoS aspects in the protocol enable
   high quality communications within the domain of a WLAN controller.
   Since each domain generally covers an enterprise or a group of
   service providers, such protocol performance has wide-ranging
   effects.

   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.

6.2.3  Relation to Problem Statement

   QoS control is critical to large WLANs and relates to a number of
   aspects.  In particular, this objective can help address the problem
   of managing 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.

6.2.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.

6.2.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]



Govindan (Editor), et al.    Expires May 2005                  [Page 16]

Internet-Draft             CAPWAP Objectives               November 2004

6.3  Support for Traffic Separation

   The centralized WLAN architecture simplifies complexity associated
   with large scale deployments.  This is achieved by consolidating some
   functionality at a central WLAN controller and distributing the
   remaining across WTPs.  As a result, WTPs and WLAN controller
   exchange control and data among them.  This objective suggests
   separating control and data aspects of the exchanges for further
   simplicity.

6.3.1  Objective Details

   It is the aim of CAPWAP to simplify the control and management of
   large scale WLANs.  One way of achieving this is to separate control
   and data aspects within the protocol.  This will allow solutions for
   control and data exchanges to be independently optimized.

6.3.2  Motivation and Protocol Benefits

   The aim of separating data and control aspects of the protocol is to
   simplify the protocol.  It also allows for flexibility since each
   part can be separately addressed in the most appropriate manner.

   Furthermore, such separation can also allow separation of data and
   control paths.  This will enable remotely located WTPs to handle data
   in alternative ways instead of forwarding them across a wide network
   to the WLAN controller.

6.3.3  Relation to Problem Statement

   Broadly, this objective relates to the challenge of managing
   complexity in large scale WLANs.

6.3.4  Customer Requirements

   This objective offers simplicity and flexibility in operation.  These
   are important issues for service providers and other enterprises
   deploying large scale WLANs.

6.3.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to contain reasons for the particular
   classification of the objective.]

6.4  STA Admission Control Objective

   STA Admission control deals with client authentication, handoff
   between WTPs, load balance, QoS etc.  Access control in the CAPWAP


Govindan (Editor), et al.    Expires May 2005                  [Page 17]

Internet-Draft             CAPWAP Objectives               November 2004

   context must be based on a variety of information.  This is because
   CAPWAP combines both switching and wireless medium segments.

6.4.1  Objective Details

   This objective focuses on access control based on collective
   information from the switching and wireless medium segments.  As
   such, access to the WLAN is based on both the radio resources, i.e.
   wireless medium segment and network resources, i.e.  switching
   segment.

6.4.2  Motivation and Protocol Benefits

   Due to the scale of deployments in which CAPWAP will be employed,
   comprehensive access control is crucial.  The effectiveness of access
   control in turn is affected by the information on which such control
   is based.  As a result, this objective has critical relevance to a
   CAPWAP protocol.

6.4.3  Relation to Problem Statement

   This objective addresses the issue of access control in large WLANs.
   Broadly, it relates the problem of managing the complexity scale of
   such networks.  With collective information of both switching and
   wireless medium segments, realizing this objective will help control
   and manage complexity.

6.4.4  Customer Requirements

   [TBD]

6.4.5  Classification (Mandatory, Desirable, Rejected)

   [TBD]

6.5  Centralized WTP Management

   Large scale WLAN deployments necessitate in centralized control.  The
   CAPWAP protocol interfaces the central control to the numerous WTPs.
   One aspect of centralized control includes firmware distribution.
   This objective relates to configuration aspects of the WLAN.





Govindan (Editor), et al.    Expires May 2005                  [Page 18]

Internet-Draft             CAPWAP Objectives               November 2004

7.  Security Objectives

   Security is a major issue for any communications network and is
   especially important for large scale WLANs.  In this context,
   security must encompass both the protocol between WLAN controller and
   WTPs and also the WLAN system as a whole.  So the following
   objectives deal with securing exchanges between WLAN elements and
   devising contingencies in case of physical security breaches.

7.1  CAPWAP Protocol Security

   This objective addresses the security of the protocol.

7.1.1  Objective Details

   [Note: This objective generally deals with the security between WTP
   and WLAN controller.  It deals with threats that arise from within
   the network infrastructure.]

   The CAPWAP protocol between WLAN controller and WTPs must be secured
   such that information exchange between them is not threatened.  As
   such, it must provide confidentiality, integrity and authenticity for
   those exchanges.

   Furthermore, CAPWAP protocol security must ensure that rogue WTPs do
   not breach legitimate WLAN systems.  The CAPWAP protocol should
   therefore include authentication mechanisms for WTPs.  For example,
   WTPs may be required to regularly renew their authentication states.

   As a result of realizing this objective it should not be possible for
   individual WTP breaches to affect the security of the WLAN as a
   whole.  So WTP mis-use will be protected against.

7.2  System-wide Security

   [Note: This objective is to prevent against security threats from
   outside the CAPWAP framework.  Specifically, it addresses threats
   posed by rogue wireless users.  For example, recent discussions of
   PMK sharing in the CAPWAP context illustrates a situation while may
   be taken advantage of by a rogue wireless user.  This objective
   differs from that of the previous section in that it deals with
   external threats that may affect the WLAN system.

   The emphasis here is that there should be no ambiguities arising from
   the CAPWAP framework that causes threats from external entities.]



Govindan (Editor), et al.    Expires May 2005                  [Page 19]

Internet-Draft             CAPWAP Objectives               November 2004

8.  Objectives for Further Discussion

   [Note: The following are some of objectives for further discussion in
   the WG.]

8.1  Centralized WTP Management

   The CAPWAP protocol should provide an engine-mechanism to spring WTP
   auto-configuration and/or software version updates and should support
   integration with existing network management system.  WLAN controller
   as a management agent is optional.

   If entities other than WLAN controllers manage some aspects of WTPs,
   such as software downloads, the CAPWAP protocol may be used for WTPs
   to notify WLAN controllers of any changes made by the other entities.

   One example of transport mechanism for the CAPWAP protocol is TCP/IP.
   This will bring more flexibility to the way in which WLAN systems are
   deployed.

8.2  Security borderline Control

   [Note: This objective addresses the issue of a large WLAN
   infrastructure featuring the co-existence of different security
   policies for different user groups.  It deals with traffic flow
   isolation on borderline of any two user groups or two users.]

8.3  Trust model Definition

   [Note: When 802.1x authenticator role in 802.11i is relocated from
   WTP to WLAN controller, the following needs to be clarified for
   CAPWAP protocol development; whether there are any potential changes
   in the trust relationship between WTP and infrastructure.  If there
   are changes, the new trust model needs to be defined.]

8.4  IEEE 802.11i Considerations

   In the centralized WLAN architecture, authentication based on IEEE
   802.11i presents options based on the location of the authenticator.
   Particularly, if the authenticator is located within the WLAN
   controller, means for key distribution need to be considered, whereas
   if the authenticator is within a WTP, communications between the AAA
   server and the WTP need to be considered.  The CAPWAP protocol should
   therefore be able to address these options.




Govindan (Editor), et al.    Expires May 2005                  [Page 20]

Internet-Draft             CAPWAP Objectives               November 2004

9.  Summary and Conclusion

   The objectives presented in this document address architectural,
   operational and security aspects for CAPWAP.  They present a
   framework which will be used to develop and evaluate candidate
   protocols for managing large scale WLAN deployments.























Govindan (Editor), et al.    Expires May 2005                  [Page 21]

Internet-Draft             CAPWAP Objectives               November 2004

10.  Security Considerations

   [Note: This section will detail the security implications of the
   various objectives.  One way to look at it would be to analyze the
   security considerations of the Architecture Taxonomy and borrow/infer
   from it.]

   The objective dealing with alternative interfaces covers the
   interoperability of WTPs 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 WTPs.

   In shared deployments with a number of 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 exchanges be prevented with the
   automation of discovery and initialization processes.

   The objective for WLAN monitoring relates to security also.  Wireless
   systems need to be constantly monitored for potential threats in the
   form of rogue WTPs or terminals.  For example, profiles for DoS and
   replay attacks need to be monitored.

   In addition to securing protocol exchanges between devices in large
   scale WLANs, the CAPWAP protocol should also incorporate
   contingencies for physical security breaches.  For instance, it
   should be ensured that the network as a whole is not compromised if a
   single AP is stolen or otherwise compromised.  The protocol should
   therefore contain measures to detect and contain physical security
   threats.








Govindan (Editor), et al.    Expires May 2005                  [Page 22]

Internet-Draft             CAPWAP Objectives               November 2004

11.  Contributors

   This document is the result of a merger of two individual
   Internet-Draft submissions.  The authors of both drafts have
   contributed to shape this document.  The authors are;

   Meimei Dang
   RITT, CATR
   No.11 YueTanNanJie, Xicheng District
   Beijing 100045
   P.  R.  China
   Phone: +86 10 68094457
   Email: dangmeimei@mail.ritt.com.cn

   Satoshi Iino
   Panasonic Mobile Communications
   600, Saedo-cho
   Tsuzuki-ku
   Yokohama  224 8539
   Japan
   Phone: +81 45 938 3789
   EMail: iino.satoshi@jp.panasonic.com

   Mikihito Sugiura
   Panasonic Mobile Communications
   600, Saedo-cho
   Tsuzuki-ku
   Yokohama  224 8539
   Japan
   Phone: +81 45 938 3789
   EMail: sugiura.mikihito@jp.panasonic.com

   Dong Wang
   ZTE
   No.68 Zijinghua Rd, Yuhuatai District
   Tsuzuki-ku
   Nanjing, Jiangsu Prov.  210 012
   P.  R.  China
   Phone: +86 25 5287 1713
   EMail: wang.dong@mail.zte.com.cn






Govindan (Editor), et al.    Expires May 2005                  [Page 23]

Internet-Draft             CAPWAP Objectives               November 2004

12.  Acknowledgements

   The authors would like to thank the Working Group Chairs, Dorothy
   Gellert and Mahalingam Mani, for their support and patience with this
   document.  We would also like to thank participants of the Working
   Group who have helped shape the objectives.  In particular, the
   authors thank Pat Calhoun and Inderpreet Singh for their invaluable
   inputs.

13  References

   [Functionality Classifications]
              Cheng, H. et al, "Functionality 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-06 (work in
              progress), November 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

   Saravanan Govindan
   Panasonic Singapore Laboratories
   Block 1022, Tai Seng Industrial Estate
   #06-3530, Tai Seng Avenue
   Singapore  534 415
   Singapore

   Phone: +65 6550 5441
   EMail: sgovindan@psl.com.sg




Govindan (Editor), et al.    Expires May 2005                  [Page 24]

Internet-Draft             CAPWAP Objectives               November 2004

   Zhonghui Yao
   Huawei Longgang Production Base
   Shenzhen  518 129
   P. R. China

   Phone: +86 755 2878 0808
   EMail: yaoth@huawei.com

   Wenhui Zhou
   China Mobile
   53A, Xibianmen Ave, Xuanwu District
   Beijing  100 053
   P. R. China

   Phone: +86 10 6600 6688 ext.3061
   EMail: zhouwenhui@chinamobile.com

   L. Lily Yang
   Intel Corp.
   JF3-206, 2111 NE 25th Ave.
   Hilsboro, OR  97124
   USA

   Phone: +1 503 264 8813
   EMail: lily.l.yang@intel.com

   Hong Cheng
   Panasonic Singapore Laboratories
   Block 1022, Tai Seng Industrial Estate
   #06-3530, Tai Seng Avenue
   Singapore  534 415
   Singapore

   Phone: +65 6550 5447
   EMail: hcheng@psl.com.sg







Govindan (Editor), et al.    Expires May 2005                  [Page 25]

Internet-Draft             CAPWAP Objectives               November 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


Govindan (Editor), et al.    Expires May 2005                  [Page 26]


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