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

   Objectives for Control and Provisioning of Wireless Access Points
                                (CAPWAP)
                  draft-ietf-capwap-objectives-00.txt
                  draft-ietf-capwap-objectives-01.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 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 August 5, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).

Abstract

   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 aims to
   present establish a set of focused requirements which when realized, will ensure for the
   development and evaluation of a CAPWAP protocol.  The objectives
   address Architecture, Operation, Security and Network Operator
   Requirements that are necessary to enable 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   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5   4
   3.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6   5
   4.  Categories of   Objectives Overview  . . . . . . . . . . . . . . . . . . .  7 .   6
   5.  Architecture   Objectives . . . . . . . . . . . . . . . . . . .  8
     5.1   Interoperability Objective . . . . . .   7
     5.1  Mandatory and Accepted Objectives  . . . . . . . . . . . .  8   7
       5.1.1   Objective Details  Logical Groups . . . . . . . . . . . . . . . . . .  8 . .   7
       5.1.2   Motivation and Protocol Benefits  Support for Traffic Separation . . . . . . . . . . .  9 .   8
       5.1.3   Relation to Problem Statement  Wireless Terminal Transparency . . . . . . . . . . . .   9
       5.1.4   Customer Requirements  Configuration Consistency  . . . . . . . . . . . . . .  10
       5.1.5  Firmware Trigger . .  9
       5.1.5   Classification (Mandatory, Desirable, Rejected) . . .  9
     5.2   Interconnection Objective . . . . . . . . . . . . . .  11
       5.1.6  Monitoring and Exchange of System-wide Resource
              State  . .  9
       5.2.1   Objective Details . . . . . . . . . . . . . . . . . . 10
       5.2.2   Motivation and Protocol Benefits . . . .  11
       5.1.7  Resource Control Objective . . . . . . . 10
       5.2.3   Relation to Problem Statement . . . . . . .  12
       5.1.8  CAPWAP Protocol Security . . . . . 10
       5.2.4   Customer Requirements . . . . . . . . . .  14
       5.1.9  System-wide Security . . . . . . 10
       5.2.5   Classification (Mandatory, Desirable, Rejected) . . . 10
     5.3   Support for Logical Networks . . . . . . . .  15
       5.1.10   IEEE 802.11i Considerations  . . . . . . . 10
       5.3.1   Objective Details . . . . .  16
       5.1.11   Interoperability Objective . . . . . . . . . . . . . 11
       5.3.2   Motivation and Protocol Benefits  17
     5.2  Desirable Objectives . . . . . . . . . . . . 11
       5.3.3   Relation to Problem Statement . . . . . . .  19
       5.2.1  Multiple Authentication Mechanisms . . . . . . 12
       5.3.4   Customer Requirement . . . .  19
       5.2.2  Support for Future Wireless Technologies . . . . . . .  20
       5.2.3  Support for New IEEE Requirements  . . . . . . . 12
       5.3.5   Classification (Mandatory, Desirable, Rejected) . . . 12
     5.4   Extensibility  21
       5.2.4  Interconnection Objective  . . . . . . . . . . . . . .  22
       5.2.5  Access Control . . . 12
       5.4.1   Objective Details . . . . . . . . . . . . . . . . .  22
     5.3  Rejected Objectives  . 12
       5.4.2   Motivation and Protocol Benefits . . . . . . . . . . . 13
       5.4.3   Relation to Problem Statement . . . . . . .  24
       5.3.1  Support for Non-CAPWAP WTPs  . . . . . 13
       5.4.4   Customer Requirements . . . . . . . .  24
     5.4  Operator Requirements  . . . . . . . . 13
       5.4.5   Classification (Mandatory, Desirable, Rejected) . . . 13
   6.  Operations Objective . . . . . . .  24
       5.4.1  AP Fast Handoff  . . . . . . . . . . . . . . 14
     6.1   WLAN Monitoring Objective . . . . .  25
   6.   Summary and Conclusion . . . . . . . . . . . 14
       6.1.1   Objective Details . . . . . . . .  26
   7.   Security Considerations  . . . . . . . . . . 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
       6.2.1   Objective Details  . . . . . . . . . . . . . . . . . . 15
       6.2.2   Motivation and Protocol Benefits . . . . . .  27
   8.   Acknowledgements . . . . . 16
       6.2.3   Relation to Problem Statement . . . . . . . . . . . . 16
       6.2.4   Customer Requirements . . . . .  28
   9.   References . . . . . . . . . . . 16
       6.2.5   Classification (Mandatory, Desirable, Rejected) . . . 16
     6.3   Support for Traffic Separation . . . . . . . . . . .  28
        Authors' Addresses . . . 17
       6.3.1   Objective Details . . . . . . . . . . . . . . . . . . 17
       6.3.2   Motivation  28
        Intellectual Property and Protocol Benefits . . . . . . . . . . . 17
       6.3.3   Relation to Problem Statement  . . . . . Copyright Statements . . . . . . . 17
       6.3.4   Customer  30

1.  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 notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and Protocol Benefits . . . . . . . . . . . 18
       6.4.3   Relation "OPTIONAL" in this
   document are 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 be interpreted as described in [RFC2119].

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 of 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 wireless interface between WTPs and wireless
   terminals.  The Wireless Medium Segment is specific to layer 2
   wireless technology, such as IEEE 802.11.

   CAPWAP Protocol Security . . . . . . . . . . . . . . . . . 19
       7.1.1   Objective Details  . . . . . . . . . . . . . . . . . . 19
     7.2   System-wide Security . . . . . . . . . . . . . . . . . . . 19
   8.  Objectives for Further Discussion  . . . . . . . . . . . . . . 20
     8.1 Framework: A term that covers the local-MAC and split-MAC
   designs of the 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 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.

3.  Introduction

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

   Many vendors have addressed these challenges by developing new
   architectures and solutions.  A survey of the various developments
   was conducted to better understand the context of these challenges.
   This survey is a first step towards designing interoperability among
   the solutions.  The Architecture Taxonomy [I-D.ietf-capwap-arch] is a
   result of this survey in which major WLAN architecture families are
   classified.  Broadly, these are the autonomous, centralized WLAN and
   distributed mesh architectures.

   The Architecture Taxonomy identified 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 centralized WLAN
   architecture is further classified into remote-MAC, split-MAC and
   local-MAC designs.  Each differs in the degree of separation of
   wireless MAC layer capabilities between WTPs and WLAN controller.

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

4.  Objectives Overview

   The objectives for CAPWAP have been broadly classified to address
   architecture, operation and security requirements of managing
   large-scale WLAN deployments.

   Architecture objectives deal with system level aspects of the CAPWAP
   protocol.  They address issues of protocol extensibility, diversity
   in 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 WLAN
   monitoring, resource management, QoS and access control.

   Security objectives address potential threats to WLANs and their
   containment.  In the CAPWAP context, security requirements cover both
   the protocol between WLAN controller and WTPs and also the WLAN
   system as a whole.

5.  Objectives

   The objectives described in this document have been prioritized based
   on their immediate significance in the development and evaluation of
   a control and provisioning protocol for large-scale WLAN deployments.
   Additionally, one category is provided for requirements gathered from
   network service operators.  These are specific need that arise from
   operators' experiencese in deploying and managing large-scale WLANs.
   The priorities are;

       i.    Mandatory and Accepted Objectives
       ii.   Desirable Objectives
       iii.  Rejected Objectives
       iv.   Operator Requirements

   The priorities have been assigned to individual objectives in
   accordance with working group discussions.

5.1  Mandatory and Accepted Objectives

   Objectives prioritized as Mandatory and Accepted have been deemed
   crucial for the control and provisioning of WTPs.  They directly
   address the challenges of large-scale WLAN deployments and must be
   realized by a CAPWAP protocol.

5.1.1  Logical Groups

   [Ed.  Note: Was 5.2.3i]

   Classification: Architecture

   Description:

   Large WLAN deployments are complex and expensive.  Furthermore,
   enterprises deploying such networks are under pressure to improve the
   efficiency of their expenditures.

   Shared WLAN deployments, where a single physical WLAN infrastructure
   supports a number of logical networks, are increasingly used to
   address these two issues of large-scale WLANs.  These are popular as
   they allow deployment and management costs to be spread across
   businesses.

   In traditional WLANs, each physical WTP represents one complete
   subset of a larger WLAN system.  Shared WLANs differ in that each
   physical WTP represents a number of logical subsets of possibly a
   number of larger WLAN systems.  Each logical division of a physical
   WTP is referred to as a logical group.  For example, each BSSID of a
   physical WTP can be construed to be a logical group.  So WLANs are
   managed in terms of logical groups instead of physical WTPs.  Virtual
   APs are examples of logical groups.

   Protocol Requirement:

   WLAN deployment trends require the CAPWAP protocol to be capable of
   controlling and managing physical WTPs in terms of logical groups.

   Motivation and Protocol Benefits:

   Commercial realities necessitate that WLANs be manageable in terms of
   its logical groups.  This allows separation of logical services and
   underlying infrastructure management.  A protocol that realizes this
   need ensures simlper and cost effective WLANs, which directly address
   the requirements of network service operators.

   Relation to Problem Statement:

   This objective addresses the problem of management complexity in
   terms of costs.  Cost complexity is reduced by sharing WLAN
   deployments.  Consequently, deployment and Conclusion . . . . . . . . . . . . . . . . . . . . 21
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 22
   11.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
   12.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
       Intellectual Property management
   cost-efficiencies are realized.

5.1.2  Support for Traffic Separation

   [Ed.  Note: Was 5.2.7 and 5.2.3ii]

   Classification: Operations

   Description:

   The centralized WLAN architecture simplifies complexity associated
   with large-scale deployments by consolidating portions of wireless
   MAC functionality at a central WLAN controller and distributing the
   remaining across WTPs.  As a result, WTPs and WLAN controller
   exchange control and data information between them.  This objective
   states that control and data aspects of the exchanges be mutually
   separated for further simplicity.  This will allow solutions for each
   type of exchange to be independently optimized.

   Furthermore, in the context of shared WLAN deployments, the mutual
   separation of control and data also addresses security concerns.  In
   particular, given the likelihood of different logical groups being
   managed by different administrators, separation of control and Copyright Statements . . . . . . . . 26

1.  Requirements notation data
   is a first step towards individually containing and securing the
   logical groups.

   It is also important to ensure that traffic from each logical group
   be mutually separated to maintain the integrity and independence of
   the logical groups.

   Protocol Requirement:

   In order to maintain the separation of control and data traffic, the
   CAPWAP protocol is required to define control messages such that they
   do not involve piggybacking or other combination with data traffic.

   Motivation and Protocol Benefits:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", aim of separating data and "OPTIONAL" control aspects of the protocol is to
   simplify the protocol.  It also allows for the flexibility of
   addressing each type of traffic in the most appropriate manner.

   Furthermore, such separation provides for the separation of data and
   control paths.  This will help remotely located WTPs to handle data
   traffic in alternative ways without the need for forwarding them
   across a wide network to the WLAN controller.

   Separation of WTP control and data also aids in the secure
   realization of shared WLAN deployments.

   Relation to Problem Statement:

   Broadly, this
   document are objective relates to be interpreted as described the challenge of managing
   complexity in [RFC2119].

2.  Terminology

   This document follows large-scale WLANs.  The requirement for traffic
   separation simplifies control as this is separated from the terminologies task of [I-D.ietf-capwap-arch].
   Additionally,
   data transport.

5.1.3  Wireless Terminal Transparency

   [Ed.  Note: Was 5.2.4iii]

   Classification: Operations

   Description:

   The CAPWAP protocol is applicable between a centralized WLAN
   controller and a number of WTPs, i.e.  it affects only the following terms are defined;

   Switching segment: Those aspects switching
   segment of a the centralized WLAN that primarily
   deal with switching or routing control and data information between architecture.  Its operations should
   therefore be independent of the wireless terminal.  Wireless Termination Points (WTPs) and
   terminals should not be required to be aware of the WLAN controller. existence of the
   CAPWAP protocol.

   Protocol Requirement:

   Wireless medium segment: Those aspects terminals should not be required to recognize or be aware of a centralized WLAN that
   primarily deal with
   the end-user interface which is wireless.
   Initially, CAPWAP focuses on protocol.

   Motivation and Protocol Benefits:

   IEEE 802.11 technologies but based wireless terminals are mature and widely available.
   It would be beneficial for CAPWAP not to impose new requirements on
   these wireless terminals.  In effect, this
   segment may also requirement ensures that
   the setup cost of the protocol is reduced as the numerous existing
   wireless terminals need not be altered.

   Relation to Problem Statement:

   The Problem Statement highlights the challenges faced by large WLANs
   consisting of many WTPs.  It does not refer to other technologies such as IEEE 802.16.

   CAPWAP framework: A term that includes the local MAC operations of
   wireless terminals and split MAC
   designs this objective emphasizes the independence.

5.1.4  Configuration Consistency

   [Ed.  Note: Was 5.2.5i]

   Classification: Operations

   Description:

   WLANs in the CAPWAP framework contain numerous WTPs, each of which
   need to be configured and managed in a consistent manner.  This is
   possible by providing the Centralized centralized WLAN Architecture.  Standardization
   efforts are focussed controller with regular
   updates on these designs. the state of their operations.  The centralized WLAN
   controller can in turn apply information from the regular updates to
   consistently configure the WTPs.

   Protocol Requirement:

   The CAPWAP protocol: protocol must allow for regular exchanges of state
   information between WTPs and WLAN controller.  Examples of state
   information include WTP processing load and memory utilization.

   Motivation and Protocol Benefits:

   A protocol that has access to regular state information can in turn
   use this to enhance WLAN performance.  The CAPWAP protocol between WLAN controller and WTPs in will be
   better equipped to address configuration related problems with the
   CAPWAP framework.  It facilitates control, management
   state information.  So with greater state information, control and
   provisioning of WTPs in an interoperable manner.

3.  Introduction

   The growth in large scale wireless local area network (WLAN)
   deployments has brought
   management operations can be improved.

   Relation to focus a number Problem Statement:

   One of technical challenges.
   This includes the complexity of managing large numbers of wireless
   termination points (WTPs), which is further exacerbated by
   differences major challenges described in their design.  Another challenge is the maintenance Problem Statement is
   that of maintaining consistent configurations among configuration across the numerous WTPs.  The dynamic
   nature WTPs
   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 WLAN.  This objective fundamentally addresses this challenge by developing new architectures and solutions.  A survey
   providing relevant state information based on which configurations
   can be appropriately maintained.

5.1.5  Firmware Trigger

   [Ed.  Note: Was 5.2.5i]

   [Ed.  Note: Was titled "Firmware Distribution]

   Classification: Operations

   Description:

   One specific aspect of configuration consistency is the firmware used
   by various architectures and solutions was conducted to better
   understand the context of the challenges so as to develop
   interoperability among them. WTPs.  The Architecture Taxonomy
   [I-D.ietf-capwap-arch] is a result scale of this survey large WLANs introduces possibilities
   for variations in which major
   architecture families are classified.  Broadly, these are the
   autonomous, centralized WLAN and distributed mesh architectures.  The
   survey showed that firmware used among WTPs.  This objective
   highlights the current majority of large scale deployments
   follow need for the centralized WLAN architecture in which portions CAPWAP protocol to trigger the delivery
   of appropriate versions of firmware to WTPs.  The actual delivery of
   firmware need not be inclusive to the
   wireless medium access control (MAC) operations are centralized in prtoocol.

   Protocol Requirement:

   The CAPWAP protocol must support a trigger for delivery of firmware
   updates.

   Motivation and Protocol Benefits:

   The CAPWAP protocol interfaces many WTPs to a centralized WLAN
   controller.  Firmware distribution allows these interfaces to be
   appropriately equivalent.  This architecture family is further classified into
   remote MAC, split MAC and local MAC.  Each differs in turn results in consistent
   configuration and simplified management.  So the degree protocol benefits by
   including triggers for the distribution of
   separation firmware updates.

   Relation to Problem Statement:

   Inconsistencies in the configuration of MAC layer capabilities among WTPs and WLAN controller. has been identified as a
   major challenge for large-scale WTPs.  This document puts forth critical objectives helps overcome
   the challenge by providing for achieving
   interoperability in a CAPWAP framework.  It presents objectives that
   address way for the challenges of large scale WLAN deployments.  The
   realization protocol to initiate
   delivery of these objectives will ensure that WLAN equipment equivalent versions of
   major design types may be integrally deployed firmware to all WTPs.

5.1.6  Monitoring and managed.

4.  Categories Exchange of Objectives System-wide Resource State

   [Ed.  Note: Was 5.2.5ii]

   [Ed.  Note: Was titled "System-wide Resource State"]
   Classification: Operations

   Description:

   The objectives for centralized WLAN architecture is made up of a switching segment
   and wireless medium segment.  In the CAPWAP protocol are organized into three major
   categories; architecture, operations switching segment, network
   congestion, WTP status and security.

   Architecture objectives deal with system level aspects 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 need to be considered for efficient WLAN operation.

   The CAPWAP
   protocol.  They address issues of protocol extensibility, diverse
   network deployments and architecture designs should be capable of monitoring the various
   information sources and differences in
   transport technologies.

   Operational objectives address deliver the resulting information to the
   relevant WLAN devices - either WTPs or WLAN controller.  Moreover,
   given the control relationship among information sources, the CAPWAP protocol
   should combine state information from them.  For example, statistics
   information and management features status signals from WTPs may be merged before being
   exchanged.

   Examples of statistics information that the CAPWAP protocol.  They deal with operations relating to
   system-wide resource management, WTP management, QoS protocol should
   monitor and STA access
   control.

   Security objectives address potential threats to WLANs exchange include; congestion state, interference levels,
   loss rates and their
   containment.  Specifically, they deal with securing the various delay factors.

   Protocol Requirement:

   The CAPWAP protocol and must allow for the exchange of statistics,
   congestion and other WLAN system as a whole.  The objectives also address
   security requirements from end-users state information.

   Motivation and service providers.

5.  Architecture Objectives Protocol Benefits:

   The architectural considerations effectivness of centralized WLAN networks are
   fundamental to a protocol is based on the development and evaluation relevance of a
   information on which it operates.  This requirement for resource
   monitoring and exchange can provide the appropriate information to
   the CAPWAP protocol.

   Relation to Problem Statement:

   The objectives in this category deal Problem Statement highlights the challenge of dealing with system level aspects
   relating to protocol extensibility, diversity large
   numbers of network deployments WTPs and differences among vendor equipment.

5.1  Interoperability Objective

   Two major designs the dynamic nature of the centralized WLAN architecture are local MAC
   and split MAC.  With wireless medium.
   Information on the focusing state of standardization efforts on these
   two designs, it WTPs and the medium is crucial important to ensure mutual interoperation among
   them.

5.1.1  Objective Details

   This deal
   with them effectively.  So this objective for relates to the CAPWAP protocol is problem of
   managing consistency in large WLANs.

5.1.7  Resource Control Objective

   [Ed.  Note: Was 5.2.6]

   Classification: Operations
   Description:

   Integral to ensure that WTPs the success of both
   local MAC any wireless network system is the
   performance and split MAC architecture designs are capable of
   interoperation within quality it can offer its subscribers.  Since CAPWAP
   based WLANs combine a single WLAN.  Consequently, switching segment and a single WLAN
   controller will wireless medium
   segment, performance and quality need to be capable of controlling coordinated across both types
   of WTPs using a
   single CAPWAP protocol.  Integral support for these designs comprises
   a number of protocol aspects.

   i.  Functionality negotiations between segments.  So QoS performance must be enforced system-wide.

   This objective highlights QoS over the entire WLAN controller 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

   Local MAC and split MAC designs differ in wireless service
   subscribers and between WTPs and WLAN controllers.  For instance, the degree of
   former will be based on IEEE 802.11
   MAC functionalities that each type of WTP realizes.  The CAPWAP
   protocol should allow WLAN controllers to determine 802.11e while 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 latter will be an
   alternative.  So resources need to alternative interfaces with be adjusted in a WLAN controller.  So the coordinated
   fashion over both segments.  The CAPWAP protocol should be capable of adapting its operations to the
   different interfaces.  The definition of ensure that
   these interfaces is
   dependent on the functionality differences among local MAC adjustments are appropriately exchanged between WLAN
   controllers and split
   MAC WTPs.  It is therefore out of scope

   In addition to IEEE 802.11e, there are a number of the objectives
   specifications.

   [Functionality Classifications] presents additional details on these
   two aspects.  It shows how flexibility in the other IEEE Task
   Groups that may affect network resources.  These include IEEE TGk,
   TGu and TGv, which are currently under progress.  CAPWAP protocol may should
   therefore not be
   achieved so as restricted to realize this architecture objective.

   This objective also addresses the need for flexibly configuring WTPs IEEE 802.11e based on their design types mapping.

   Protocol Requirement:

   The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across
   the switching and other setup aspects.

5.1.2 wireless medium segments.

   Motivation and Protocol Benefits

   The benefits Benefits:

   A protocol that addresses QoS aspects of realizing this architecture objective are both
   technical WLAN systems will deliver
   high performance thereby being beneficial for subscribers and practical.  First, there are substantial overlaps for
   resource utilization efficiency.  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 control operations protocol enable
   high quality communications within the domain of local MAC and split MAC architecture
   designs.  As a result, it is technically practical to devise WLAN controller.
   Since each domain generally covers an enterprise or a single
   protocol that manages both types group of devices.

   Next,
   service providers, such protocol performance has wide-ranging
   effects.

   Within the ability to operate switching segment of CAPWAP, a CAPWAP QoS-enabled 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,
   minimizes the benefits of
   this objective will far outweigh any cost adverse effects of realizing it.

5.1.3 dynamic traffic characteristics so
   as to ensure system-wide performance.

   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 Statement:

   QoS control is the ultimate aim of
   standardization efforts.  The realization critical to large WLANs and relates to a number of
   aspects.  In particular, this objective will
   ensure can help address the development problem
   of a comprehensive set managing dynamic conditions of solutions to the
   challenges of wireless medium.

   Furthermore, traffic characteristics in 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 WLANs are placed in different locations so as to
   selectively take advantage of their respective characteristics.
   constantly varying.  So network utilization becomes inefficient and
   user experience is unpredictable.

   The
   integral support interaction and coordination between the two aspects of different architectures
   system-wide QoS is therefore addresses critical needs for performance.

5.1.8  CAPWAP Protocol Security

   [Ed.  Note: Was 5.2.10]

   Classification: Security

   Description:

   This objective addresses the market.

   Furthermore, since there are products security of each design type already in the market and widely deployed, it is necessary for CAPWAP protocol.

   The CAPWAP protocol
   to support both of them.

5.1.5  Classification (Mandatory, Desirable, Rejected)

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

5.2  Interconnection Objective

   Large scale participating entities
   - WLAN deployments are likely controller and WTPs - to use a variety of
   interconnection technologies between different devices of the
   network.  It should therefore be possible for the CAPWAP protocol mutually authenticated.  This is
   to
   operate over the different interconnection technologies.  So the
   protocol needs ensure that rogue WTPs do not breach legitimate WLAN systems.  For
   example, WTPs may need to be independent of underlying transport
   technologies.

5.2.1  Objective Details regularly renew their authentication state
   with the WLAN controllers and controller.

   Once WTPs and WLAN controller have been mutually authenticated,
   information exchanges between them must be able to connect by a variety of
   interconnection technologies.  The fundamental intent is for CAPWAP
   protocol exchanges secured against various
   security threats.  This should cover illegitimate modifications to
   protocol exchanges, eavesdropping and DoS attacks, among other
   potential compromises.  So the protocol must be transparent to underlying transport
   technologies. provide
   confidentiality, integrity and authenticity for those exchanges.

   As a result of realizing this objective, the protocol
   will objective it should not be capable possible for
   individual WTP breaches to affect the security of operation over different interconnect technologies
   including Ethernet, bus backplanes, ATM (cell) fabrics and also
   wireless technologies such the WLAN as IEEE 802.11.  Ethernet architecture is
   most widely used and should a
   whole.  So WTP mis-use will be recommended.

   The CAPWAP protocol should have protected against.

   Additionally, the ability to support this diversity
   of interconnection technologies key establishment protocol for data authentication and control exchanges.  For
   example, VLAN tunnels are an example of an interconnection technology
   over which
   securing CAPWAP may operate.

   Related exchanges must be designed to this objective, minimize the
   possibility of future compromises after the keys are established.

   While mutual authentication is necessary for CAPWAP, the QoS aspect protocol
   should not prevent the use of interconnection
   technologies.  Given that QoS will be enabled differently in each asymmetric, non-mutual authentication.
   The security considerations of
   these technologies, such asymmetric authentication are
   described in the Security Considerations section.

   Protocol Requirement:

   The CAPWAP protocol must ensure that network
   performance is consistent across different transport means.
   Additionally, QoS consistency has to cover the switching segment support mutual authentication of WTPs and
   the wireless medium segment.

5.2.2 centralized controller.  It must also ensure that information
   exchanges between them are secured.

   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,
   enterprises are under pressure to improve the efficiency of their
   expenditures.  These issues Benefits:

   WLANs 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 deployed in critical aspects of
   deployment enterprise and management can be shared among
   consumer networks.  In these contexts, protocol security is crucial
   to assure the privacy and integrity expected from network service
   providers.  A scenario together with additional details for such
   shared
   administrators and end-users.  So securing the CAPWAP protocol has
   direct benefits in addressing these concerns.

   Relation to Problem Statement:

   Security problems in large-scale WLANs is presented are detailed in [Functionality Classifications].

5.3.1  Objective Details the Problem
   Statement.  These include complications arising from rogue WTPs and
   compromised interfaces between WTPs and WLAN controller.  The objective
   requirement for supporting logical networks involves a number protocol security addresses these problems and
   highlights the importance of
   aspects.  These are discussed below;

   i.  WLAN management in terms protecting against them.

5.1.9  System-wide Security

   [Ed.  Note: Was 5.2.11]

   Classification: Security

   Description:

   The emphasis of logical groups

   Traditionally, each WTP has represented one complete subset this objective is on the security threats external to
   the centralized CAPWAP segment of a
   larger WLAN system.  However, with shared deployments, each WTP
   represents a number of subsets of possibly  The focus is
   therefore on rogue wireless clients and other illegitimate wireless
   interferences.  There are a number of larger WLAN
   systems.  So with such deployments, WLANs specific external threats that
   need to be managed in terms addressed within the CAPWAP framework.

   i.  PMK Sharing

   One aspect of logical groups instead this objective relates to recent discussions on PMK
   sharing in the CAPWAP framework.  This objective highlights the need
   to prevent exploitation of physical devices.

   ii.  Mutual separation this ambiguity by rogue wireless clients.
   It is to ensure that any ambiguities arising from the CAPWAP
   framework are not cause for security breaches.

   Protocol Requirement:

   The design of control the CAPWAP protocol should not allow for any
   compromises to the WLAN system by external entities.

   Motivation and communications

   Since different logical networks are likely Protocol Benefits:

   The external threats to be associated the centralized WLAN architecture become
   increasingly crucial given the low cost of wireless clients.  Since
   it is relatively inexpensive for rogue individuals to
   different enterprises, mount attacks,
   it is crucial important that control and data
   communications among them be mutually separated.  In addition WLAN systems are protected against them.
   Adequate mechanisms to
   being a security concern, this aspect thwart such external threats will be of
   tremendous benefit to the WLAN systems controlled and managed with
   the CAPWAP protocol.

   Relation to Problem Statement:

   This objective also
   highlights a complexity concern. is based on the security needs highlighted in the
   Problem Statement.  Specifically, mixing of traffic for
   different logical networks can complicate control.  So the CAPWAP
   protocol must be capable Problem Statement discusses the
   effects of separating traffic among logical
   networks.  VLANs and other types the shared wireless medium.  This represents the external
   aspects of tunnels may be used for this
   purpose.

   iii.  Multiple authentication mechanisms the CAPWAP framework from which certain threats can arise.
   The presence of multiple logical networks within an infrastructure
   also means there are different subscriber groups system-wide security objective addresses such threats in a WLAN system.
   Since the subscriber groups are likely to belong relation
   to different service
   providers or WLAN domains, their authentication needs will also be
   different.  As a result, the Problem Statement.

5.1.10  IEEE 802.11i Considerations

   [Ed.  Note: Was 5.2.15]

   Classification: Operations

   Description:

   The CAPWAP protocol must be capable of
   transferring different support authentication information.  For example, one
   subscriber group may be authenticated with IEEE 802.11i with in the centralized
   WLAN architecture in which the authenticator and encryption points
   can be located on distinct entities, i.e.  WLAN controller being or WTP.
   The Architecture Taxonomy illustrates a number of variants, in both
   local-MAC and split-MAC designs, in which the authenticator, while another group could use web
   authentication authenticator is
   located at an alternative server.

5.3.2  Motivation and Protocol Benefits

   Given the realities of cost WLAN controller and complexity of WLANs, a CAPWAP
   protocol that incorporates the objective of supporting logical
   networks ensures simpler encryption points are at the
   WTPs.  The CAPWAP protocol must be applicable to these variants and cost effective WLAN management
   allow authentication mechanisms and
   deployment.  A protocol that realizes this is therefore consistent
   with the goal of reducing complexity their consistituent processes to
   be operable in large scale WLANs.

5.3.3  Relation these cases.

   An important issue to Problem Statement

   This objective for supporting logical networks addresses problem of
   management complexity consider in terms of cost.  Such cost complexity this case is
   reduced by sharing infrastructure among a number the exchange of service
   providers.  Consequently, deployment key
   information when authenticator and managements
   cost-efficiencies encryption points 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 located on
   distinct entities.  For example, consider the objective of
   supporting logical networks within case where IEEE 802.11i
   is used in a single set of physical WLAN
   equipment.  There are a number of ways of realizing this objective in which the WLAN controller realizes the
   authenticator, some being virtual APs, VLAN tunnels WTPs realize encryption (possibly local-MAC WTPs)
   and other tunnels.

   This objective also allows for separation between providers of
   infrastructure from services.  Logical networks allows for WTPs rely on the
   separation of physical deployment and maintenance from actual
   management of WLANs.  This helps lower costs and responsibilities WLAN controller for
   service providers.

5.3.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section encryption (possibly
   split-MAC WTPs).

   Here, CAPWAP will first need to contain reasons for identify the particular
   classification location of the objective.]

5.4  Extensibility Objective

   Wireless technology is developing at rapid pace in a number of
   industry
   authenticator and scientific groups.  With such pace, it is important encryption points between each WLAN controller-WTP
   pair.  This will likely be part of the initial WTP configuration.
   Subsequently, the WTPs which realize encryption will need CAPWAP to
   design
   exchange key information with the authenticator at the WLAN
   controller.  For the WTPs which do not realize encryption, CAPWAP in a way as
   need to allow future extensibility.  In
   particular, adapt its control to bypass the IEEE is in key exchange phase.

   Clearly, the process of specifying standards centralized WLAN architecture presents a different
   platform for
   broadband wireless access, namely IEEE 802.16.  There also other
   activities within the IEEE that needs authentication mechanisms compared to be considered legacy WLANs in the CAPWAP
   context.

5.4.1  Objective Details

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

   i.  Enable support for future wireless technologies
   This aspect of the WTP realized both authenticator and encryption roles.  So
   this objective essentially purposes that highlights the CAPWAP
   protocol does not rely on specifics of IEEE 802.11 technology need for its
   operations.  This will simplify extensibility CAPWAP 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
   authentication and key management in new functional blocks,
   interfaces or information flows. the centralized WLAN
   architecture.

   Protocol Requirement:

   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 determine the end-user exact structure of CAPWAP the
   centralized WLAN architecture in
   terms of both hardware and software aspects.  End-users should not be
   required which authentication needs to be aware
   supported, i.e.  the location of major authentication components.
   This may be achieved during WTP initialization where major
   capabilities are distinguished.

   The protocol must allow for the existence exchange of CAPWAP protocol.

5.4.2 key information when
   authenticator and encryption roles are located in distinct entities.

   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 Benefits:

   The immediate focus of CAPWAP is on supporting IEEE 802.11 based
   WLANs.  As such, it is necessary for extension.  They require WLAN
   infrastructure the protocol to be able recognize the
   major distinction in WLAN design with respect to meet current IEEE 802.11i
   authenticator and future market
   requirements.  So encryption points.  This represents a significant
   variation that has been highlighted in the objective Architecture Taxonomy.
   The CAPWAP protocol benefits by accommodating such a major
   consideration fro IEEE 802.11i.

   These requirements will be common for extensibility is critical all authentication mechanisms
   over the centralized WLAN architecture.  So they are applicable to
   service providers
   IEEE 802.11i, UMA and other customers of WLAN equipment.

5.4.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section mechanisms.

   Relation to contain reasons for Problem Statement:

   The Problem Statement highlights the particular
   classification availability of different WTP
   designs and the objective.]

6.  Operations Objective

   CAPWAP aims to provide an interoperable solution need to the control and
   provisioning of large scale WLAN deployments. ensure interoperability among them.  In this context, the
   regard, operational objectives address functional aspects changes occuring due to the separation of the protocol.
   These functions cover system monitoring, resource management
   IEEE 802.11i authenticator and QoS.

6.1  WLAN Monitoring Objective

   The scale of WLANs in encryption points need to be
   accommated within the CAPWAP context results in numerous
   information sources.  For example, the configuration protocol.

5.1.11  Interoperability Objective

   [Ed.  Note: Was 5.2.1]

   Classification: Architecture
   Description:

   Two major designs of each WTP can
   be considered as an information source.  Additionally, the switching
   segment centralized WLAN architecture are local-MAC
   and wireless medium segment can also be considered as
   information sources.  So split-MAC.  With the focusing of standardization efforts on these
   two designs, it is crucial to ensure mutual interoperation among
   them.

   This objective for effective performance, the CAPWAP protocol needs is to regularly monitor the various information sources.

6.1.1  Objective Details

   Large WLANs need a variety ensure that WTPs of information sources to both
   local-MAC and split-MAC architecture designs are capable of
   interoperation within a single WLAN.  Consequently, a single WLAN
   controller will be monitored.
   So this objective includes capable of controlling both types of WTPs using a
   single CAPWAP protocol.  Integral support for these designs comprises
   a number of protocol aspects.

   i.  Configuration consistency

   CAPWAP based WLANs include a large number  Capability negotiations between WLAN controller and WTPs

   WTP designs differ in the degree of WTPs, IEEE 802.11 MAC functionalities
   that each type of which need
   to be configured and managed. WTP realizes.  The major distinctions, split-MAC
   and local-MAC differ in the processing of IEEE 802.11 MAC frames.  In
   this regard, the CAPWAP protocol should therefore allow include functionality that
   allows for negotiationg of significant capabilities between WTPs to regularly send information on and
   WLAN controller.

   As a first step, such negotiations could cover the state type of WTP -
   split-MAC or local-MAC - as this provides substantial information on
   their
   configuration respective capabilities.

   ii.  Establishment of alternative interfaces

   The capability differences among different WTPs essentially equates
   to their alternative interfaces with a WLAN controller.  Furthermore, it  So the CAPWAP
   protocol should also be capable of consistently distributing firmware adapting its operations to all the major
   different interfaces.  In a first case, this would include
   accommodating capability differences between local-MAC and split-MAC
   WTPs.

   ii.  System-wide resource state

   The centralized WLAN architecture is made up definition of a switching segment
   and wireless medium segment.  In the switching segment, network
   congestion and WTP status, including firmware information, have to these interfaces in terms of finer granularity of
   functionalities will be
   monitored.  In the wireless medium segment, based on the dynamic nature outcome of the
   medium itself has IEEE AP
   Functionality (APF) Ad-Hoc Committee.  The APF Ad-Hoc Committee will
   provide appropriate insight in to specific functional blocks which
   may be monitored.  Overall, there are also various
   statistics that are required used for operation. finer capabilities negotiations within the CAPWAP
   protocol.

   Protocol Requirement:

   The CAPWAP protocol should therefore be capable must include sufficient capabilities negotiations
   to distinguish between major types 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 WTPs.

   Motivation and Protocol Benefits:

   The benefits of the objective proposes collective information
   arising from different information sources.  Within realizing this aspect of
   the monitoring objective, architecture objective are both
   technical and practical.  First, there are substantial overlaps in
   the protocol may also allow WTPs to send
   regular send feedback using CAPWAP.

6.1.2  Motivation control operations of local-MAC and Protocol Benefits split-MAC architecture
   designs.  The effectiveness Architecture Taxonomy tabulates major common features
   of a protocol is based on the relevance of
   information on which two designs.  As a result, it operates.  The objective for WLAN monitoring
   can provide this information is technically practical to
   devise a single protocol that 	manages both types of devices.

   Next, the ability to operate a CAPWAP protocol.  So there protocol for both types of
   architectural designs enhances its practical prospects as it will
   tangible
   have wider appeal.

   Furthermore, the additional complexity resulting from such
   alternative interfaces is marginal.  Consequently, the benefits with of
   this objective.

6.1.3 objective will far outweigh any cost of realizing it.

   Relation to Problem Statement

   This Statement:

   The objective addresses for supporting both local-MAC and split-MAC WTPs is
   fundamental to addressing the Problem Statement.  It forms the basis
   for those problems of management complexity. to be uniformly addressed across the major WLAN
   architectures.  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. ultimate aim of standardization efforts.
   The objective also helps address the challenge realization of maintaining
   consistent configurations among WTPs.

6.1.4  Customer Requirement

   WLAN equipment customers require effective management solutions for
   their networks.  This 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 development of the objective.]

6.2  Resource Control Objective

   Integral to the success a
   comprehensive set of any wireless network system is mechanisms that address 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 challenges of
   large-scale WLAN deployments.

5.2  Desirable Objectives

   These objectives have been determined to be coordinated across both
   of desirable for a CAPWAP
   protocol but not mandatory.  Realizing these segments.  So QoS performance must objectives may help
   improve control of WLANs but need not necessarily be enforced system-wide.

6.2.1  Objective Details

   This objective is required for QoS over the entire all
   networks or scenarios.

5.2.1  Multiple Authentication Mechanisms

   [Ed.  Note: Was 5.2.3iii]

   Classification: Architecture

   Description:

   Shared WLAN system which includes
   the switching segment and the wireless medium segment.  Given the
   fundamental differences between infrastructure raise the two, it issue of multiple authentication
   mechanisms.  This is because each logical group is likely that there are
   alternate QoS mechanisms between WTPs and wireless to be
   associated with different service
   subscribers and between WTPs and providers or WLAN controllers.  For instance, domains.  As a
   result, the
   former authentication needs withing them will be based on different.
   While CAPWAP is required to support IEEE 802.11e 802.11i, it is also
   necessary for it to support other authentication mechanisms.  For
   example, one logical group may use IEEE 802.11i while the latter will another may use
   web authentication.  CAPWAP must be an
   alternative.  So resources need able to be adjusted operate in a coordinated
   fashion over both segments. such shared
   WLANs.

   Protocol Requirement:

   The CAPWAP protocol should ensure that
   these adjustments are appropriately exchanged between WLAN
   controllers and WTPs.

6.2.2 must support different authentication mechanisms
   in addition to IEEE 802.11i.

   Motivation and Protocol Benefits

   A protocol that addresses QoS aspects Benefits:

   The benefit of WLAN systems will deliver
   high performance thereby being beneficial for subscribers and
   resource utilization.  Since CAPWAP deals with WTPs directly and with supporting various authentication mechanisms is that
   the wireless medium indirectly, both of these must be considered protocol then becomes flexible for
   performance.

   For the wireless medium segment, QoS aspects use 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 various deployments.
   The protocol performance has wide-ranging
   effects.

   Within will therefore not mandate the switching segment use of CAPWAP, any particular
   mechanisms which may not be appropriate for a QoS-enabled protocol
   minimizes the adverse effects of dynamic traffic characteristics so
   as to ensure system-wide performance.

6.2.3 particular deployment.

   Relation to Problem Statement

   QoS control is critical to large WLANs and Statement:

   This objective relates to a number of
   aspects.  In particular, this objective can help address the problem of managing dynamic conditions management complexity.
   Shared WLAN deployments simplifies management of the wireless medium.

   Furthermore, traffic characteristics in large scale WLANs are
   constantly varying.  So network utilization becomes inefficient and
   user experience is unpredictable. networks.

5.2.2  Support for Future Wireless Technologies

   [Ed.  Note: Was 5.2.4i]

   Classification: Architecture

   Description:

   The interaction and coordination between the two aspects rapid pace of
   system-wide QoS is therefore critical technology developments means that new advances
   need to be catered for performance.

6.2.4  Customer Requirements

   VoIP in current analyses.  Among these is a major application over WLANs.  The basic requirement the
   support for new wireless technologies within the CAPWAP protocol,
   such applications is QoS.  Furthermore, end-users demand quality
   means of communications, so service providers in turn emphasize as IEEE 802.16.  The protocol should therefore not rely on
   the QoS capabilities
   specifics of WLAN systems.  Adopting this objective will
   ensure IEEE 802.11 technology.

   In all demands are met.

6.2.5  Classification (Mandatory, Desirable, Rejected)

   [TBD] [This section to cases where the CAPWAP protocol messages contain reasons for specific
   layer 2 information elements, the particular
   classification definition of the objective.]

6.3  Support protocol needs to
   provide for Traffic Separation

   The centralized WLAN architecture simplifies complexity associated
   with large scale deployments. extensibility so that these elements can be defined for
   specific layer 2 wireless protocols.  This is achieved by consolidating some
   functionality at a central WLAN controller and distributing the
   remaining across WTPs.  As may entail assigning 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
   layer 2 wireless protocol type and version field to the aim message PDU.
   Examples of other wireless protocols that might be supported include
   but are not limited to 802.16e, 802.15.x, etc.

   Protocol Requirement:

   CAPWAP protocol messages must be designed to be extensible for
   specific layer 2 wireless technologies.  It should not be limited to simplify
   the control and management of
   large scale WLANs.  One way transport of achieving this is elements relating to separate control IEEE 802.11.

   Motivation and data aspects within the Protocol Benefits:

   There are many benefits to an extensible protocol.  This will allow solutions  It allows for
   control
   application in different networks and data exchanges to provides greater scope.
   Furthermore, service providers require WLAN solutions that will be independently optimized.

6.3.2  Motivation
   able to meet current and Protocol Benefits future market requirements.

   Relation to Problem Statement:

   The aim of separating data and control aspects Problem Statement describes some of the protocol is to
   simplify advances taking place in
   other standards bodies like the protocol. IEEE.  It also allows is important for flexibility since each
   part the CAPWAP
   protocol to reflect the advances and provide a framework in which
   they can be separately addressed in supported.

5.2.3  Support for New IEEE Requirements

   [Ed.  Note: Was 5.2.4ii]

   Classification: Architecture

   Description:

   The IEEE is currently reviewing IEEE 802.11 functionality.  It is
   expected that 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 review by the IEEE AP Functionality Ad-Hoc
   Committee may result in alternative ways instead new definitions of forwarding them across functional blocks,
   interfaces or information flows.  The CAPWAP protocol must be able to
   incorporate these revisions with minimal change.

   Protocol Requirement:

   The CAPWAP protocol must be openly designed to support new IEEE
   extensions.

   Motivation and Protocol Benefits:

   There are a wide network number of advances being made within the IEEE regarding
   the functionality of IEEE 802.11 technology.  Since this represents
   one of the major wireless technologies in use today, it will be
   beneficial for CAPWAP to incorporate the WLAN controller.

6.3.3 relevant new extensions.

   Relation to Problem Statement:

   The Problem Statement

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

6.3.4  Customer Requirements the IEEE
   802.11 working group.  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 group is focussed on defining the particular
   classification
   functional architecture of WTPs.  It is necessary for the objective.]

6.4  STA Admission Control CAPWAP
   protocol to reflect these definitions.

5.2.4  Interconnection Objective

   STA Admission control deals with client authentication, handoff

   [Ed.  Note: Was 5.2.2]

   Classification: Architecture

   Description:

   Large scale WLAN deployments are likely to use a variety of
   interconnection technologies between WTPs, load balance, QoS etc.  Access control in different devices of the CAPWAP
   context must
   network.  It should therefore be based on possible for the CAPWAP protocol to
   operate over various interconnection technologies.

   As a variety result of information.  This is because
   CAPWAP combines realizing this objective, the protocol will be capable
   of operation over both switching IPv4 and wireless medium segments.

6.4.1  Objective Details

   This objective focuses on access control based IPv6.  It will also be designed such
   that it can operate within tightly administered networks, such as
   enterprise networks, or on collective
   information from the switching and wireless medium segments.  As
   such, open, public 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 networks.  For
   example, VLAN tunnels can be used across different types of deployments in networks
   over which CAPWAP will operate.

   Protocol Requirement:

   The CAPWAP protocol must not be employed,
   comprehensive access control is crucial. constrained to specific underlying
   transport mechanisms.

   Motivation and Protocol Benefits:

   The effectiveness of access
   control in turn is affected by the information on which such control main aim of the CAPWAP protocol is based. to achieve interoperability
   among various WTPs and WLAN controllers.  As a result, such, the motivation for
   this objective has critical relevance requirement is for the protocol to a
   CAPWAP protocol.

6.4.3 be operable independent of
   underlying interconnection technologies.

   Relation to Problem Statement:

   The Problem Statement

   This objective addresses discusses the issue complexity of access control in configuring large
   WLANs.
   Broadly, it relates the problem of managing the complexity scale of
   such networks.  With collective information  The selection of both switching and
   wireless medium segments, realizing available interconnection technologies for
   large-scale deployments further intensifies 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  This
   requirement avoids part of the numerous WTPs.
   One aspect complexity by advocating independence
   of centralized control includes firmware distribution.
   This objective relates to configuration the operational aspects of the WLAN.

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 from from underlying
   transport.

5.2.5  Access Control

   [Ed.  Note: Was 5.2.8]

   [Ed.  Note: Was titled "STA Admission Control Objective"]

   Classification: Operations
   [Ed.  Note: Priority of physical security breaches.

7.1  CAPWAP Protocol Security this objectives needs to be confirmed by WG.]

   Description:

   This objective addresses focuses on the security informational needs 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 access
   control and authenticity for
   those exchanges.

   Furthermore, specifically the role of the CAPWAP protocol security must ensure that rogue in
   transporting this information between WTPs do
   not breach legitimate and their WLAN systems. controller.

   The following are some specific information aspects that need to be
   transported by the CAPWAP protocol should
   therefore include protocol;

   i.  IEEE 802.11 association and authentication mechanisms

   The association of wireless clients is distinct for WTPs.  For example,
   WTPs may be required to regularly renew their authentication states. initial and
   roaming cases.  As a result of realizing this objective it should not result, access control mechanisms requires
   specific contextual information regarding each case.  Additionally,
   load balancing, QoS, security and congestion information in both
   wireless medium segments and switching segments need to be possible for
   individual
   considered.

   ii.  WTP breaches Access Control

   In addition to affect the security controlling access for wireless clients, it is also
   necessary to control admission of new WTPs.  Given the WLAN as a
   whole.  So WTP mis-use will be protected against.

7.2  System-wide Security

   [Note: This objective threat of
   rogue WTPs, it is important for CAPWAP to prevent against security threats from
   outside relay appropriate
   authentication information between new WTPs and the WLAN controller.

   Protocol Requirement:

   The CAPWAP framework.  Specifically, it addresses threats
   posed by rogue protocol must be capable of exchanging information
   required for access control of WTPs and wireless users.  For example, recent discussions terminals.

   Motivation and Protocol Benefits:

   Due to the scale of
   PMK sharing deployments in the which CAPWAP context illustrates a situation while may will be taken advantage 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 rogue wireless user. result, this objective has critical relevance to a
   CAPWAP protocol.

   Relation to Problem Statement:

   This objective
   differs from that of addresses the previous section issue of access control in that it deals with
   external threats that may affect large WLANs.
   Broadly, it relates the WLAN system.

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

8. complexity scale of
   such networks.  With collective information of both switching and
   wireless medium segments, realizing this objective will help control
   and manage complexity.

5.3  Rejected Objectives for Further Discussion

   [Note:

   The following are some objectives have been rejected during the course of
   working group consultations.  These objectives for further discussion have been rejected in
   the WG.]

8.1  Centralized context of CAPWAP and its considerations.  They may however be
   applicable in alternative contexts.

5.3.1  Support for Non-CAPWAP WTPs

   [Ed.  Note: Was 5.2.12]

   [Ed.  Note: Was titled "Centralized WTP Management Management"]

   Classification: Architecture

   Description:

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

   Protocol Requirement:

   The CAPWAP protocol should be capable of recognizing legacy WTPs and
   existing network management systems.

   Motivation and Protocol Benefits:

   It is expected that in many cases, the centralized WLAN architecture
   will be deployed incrementally with legacy systems.  In this regard,
   it is necessary for the protocol to be used in scenarios with mixed
   WLAN devices.

   Relation to Problem Statement:

   The Problem Statement highlights management complexity as a major
   issue with large WLANs.  One part of this comlpexity can be related
   to the incremental deployment of centralized WLAN devices for which
   this objective is applicable.

5.4  Operator Requirements

   The following objectives have been provided by network service
   operators.  They represent the requirements from those ultimately
   deploying the CAPWAP protocol in their WLANs.

5.4.1  AP Fast Handoff

   [Ed.  Note: Operator requirements from China Mobile]

   Classification: Operations

   Description:

   Network service operators consider handoffs crucially because of the
   mobile nature of their customers.  In this regard, the CAPWAP
   protocol should not adversely affect AP fast handoff procedures.  The
   protocol may support optimizations for fast handoff procedures so as
   to allow better support for real-time services during handoffs.

   Protocol Requirement:

   CAPWAP protocol operations must not impede or obstruct the efficacy
   of AP fast handoff procedures.

6.  Summary and Conclusion

   The objectives presented in this document address three main aspects
   of the CAPWAP protocol, namely;

        i.    Architecture
        ii.   Operations
        iii.  Security

   These requirements are aimed to focus standardization efforts on a
   simple, interoperable protocol may be used for WTPs
   to notify WLAN controllers of any changes made by managing large-scale WLANs.  The
   architecture requirements specify the other entities.

   One example structural features of transport mechanism for the CAPWAP
   protocol is TCP/IP.
   This will bring more flexibility such as those relating to WTP types (local-MAC and
   split-MAC) and WTP structures (logical groups).  The operations
   requirements address 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 functional aspects dealing with WTP
   configuration and management.  Finally, the co-existence of different security
   policies for different user groups.  It deals with traffic flow
   isolation on borderline requirements
   cover authentication and integrity aspects 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 protocol exchanges.

   The objectives have additionally been prioritized to WLAN controller, the following needs reflect their
   immediate significance to be clarified for
   CAPWAP protocol development; whether there are any potential changes
   in the trust relationship between WTP development and infrastructure.  If there evaluation of an
   interoperable CAPWAP protocol.  The priorities 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 Mandatory and
   Accepted, Desirable and Rejected.  They reflect working group
   consensus on the location effectiveness 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 requirements in the WTP need to be considered.  The CAPWAP context of
   protocol should
   therefore be able to address these options.

9.  Summary and Conclusion

   The objectives presented design.

   Additionally, this document includes requirements from network
   service operators that have been derived based on their experience in
   operating large- scale WLANs.

   The resulting requirements from this document address architectural,
   operational and security aspects for CAPWAP.  They present a
   framework which will be used in
   conjunction with the CAPWAP Problem Statement
   [I-D.ietf-capwap-problem-statement] and CAPWAP Architecture Taxonomy
   [I-D.ietf-capwap-arch] to develop and evaluate candidate
   protocols evalute an interoperable
   protocol for managing large scale WLAN deployments.

10. the control and provisioning of WTPs in large-scale
   WLANs.

7.  Security Considerations

   [Note: This section will detail the security implications

   The CAPWAP framework highlights support for both local-MAC and
   split-MAC WTPs.  In deployments where both types of the
   various objectives.  One way to look at WTPs are used, it would be
   is crucial to analyze the
   security considerations ensure that each be secured in consideration of the their
   capabilities.  The Architecture Taxonomy and borrow/infer
   from it.]

   The objective dealing with alternative interfaces covers illustrates how different
   WTPs incorporate varying levels of functionalities.  Development of
   the
   interoperability CAPWAP protocol should ensure that the deployment of WTPs from both local MAC
   local-MAC and split MAC designs.
   As such, split-MAC WTPs within a single WLAN controller must be capable of securing both of these
   design types.  This may include handling different degrees of
   security or authentication processing do not present
   loopholes for the two types of WTPs. security compromises.

   In shared WLAN deployments with made of a number of logical networks, it is
   crucial groups,
   traffic from each group needs to ensure mutual separation of be mutually separated.  So in
   addition to protocol related exchanges, data traffic among them.  Access
   control from wireless
   terminals should therefore also be distinct for each of segregated with respect to the logical
   networks.  Furthermore, subscribers to different service providers
   need to be managed based on their respective requirements,
   subscriptions, etc.  Cross exchanges need
   groups to be secured against. which they belong.  It should not be ensured that any possible for data or
   control traffic from one logical group to stray exchanges be prevented with to or influence
   another logical group.

   The use of IEEE 802.11i over the
   automation centralized WLAN architecture allows
   for implementations in which the PMK is shared across WTPs.  This
   raises the ambiguity between legitimate sharing and illegitimate
   copies.  Wireless terminals may unknowingly fall prey to or exploit
   this ambiguity.  The resolution of discovery this issue is currently being
   evaluted by the IEEE 802 and initialization processes. IETF liaisons.

   The objective for WLAN monitoring relates to security also.  Wireless
   systems need low-cost of launching attacks on WLANs makes the CAPWAP protocol
   a target.  A first step in securing against any form of attacks is to be constantly monitored
   continuously monitor the WLAN for conditions of potential threats in the
   form of
   from rogue WTPs or wireless 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, considered for the CAPWAP protocol should also incorporate
   contingencies for to
   effectively monitor security conditions.

   The open environment of many WLAN deployments makes physical security breaches.
   breaches highly probable.  Compromises resulting from theft and
   physical damage must be considered during protocol development.  For
   instance, it should not be ensured that possible for a single compromised WTP to
   affect the network WLAN as a whole whole.

   Considering asymmetric, non-mutual authentication between WTPs and
   WLAN controller, there is not compromised if a
   single AP risk of a rogue participant exploiting
   such an arrangement.  It is stolen or otherwise compromised.  The protocol should
   therefore contain measures preferrable to detect and contain physical security
   threats.

11.  Contributors

   This document is avoid non-mutual
   authentication.  In some cases, the result legitimacy of a merger the protocol
   exchange participants may be verified externally, for example by
   means of two individual
   Internet-Draft submissions.  The authors physical containment within a close environment.  Asymmetric
   authentication may be appropriate here without risk 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

12. security
   compromises.

8.  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 James Kempf, Pat Calhoun and Calhoun, Inderpreet Singh and T.
   Sridhar for their invaluable inputs.

13  References

   [Functionality Classifications]
              Cheng, H. et al, "Functionality Classifications for
              Control  The authors also acknowledge
   the contributions from Meimei Dang, Satoshi Iino, Mikihito Sugiura
   and Provisioning of Wireless Access Points",
              draft-cheng-capwap-classifications-01, (work in
              progress), July 2004. Dong Wang.

9.  References

   [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), Internet-Draft draft-ietf-capwap-arch-06,
              November 2004.

   [I-D.ietf-capwap-problem-statement]
              Calhoun, P., "CAPWAP Problem Statement",
              draft-ietf-capwap-problem-statement-02 (work in progress),
              Internet-Draft draft-ietf-capwap-problem-statement-02,
              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:
   Email: sgovindan@psl.com.sg

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

   Phone: +86 755 2878 0808
   EMail:
   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:
   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:
   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:
   Email: hcheng@psl.com.sg

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). (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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