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

Versions: 00

CAPWAP Working Group                                         Wenhui Zhou
Internet Draft                    China Mobile Communication Corporation
                                                            Zhonghui Yao
Document: Objectives for Control and                 Huawei Technologies
Provisioning of Wireless Access Points                         Lily Yang
                                                             Intel Corp.
                                                             Meimei Dang
                    Research Institute of Telecommunication Transmission
                                                               Dong Wang
                                                                     ZTE
Expires: April 2005                                        November 2004

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

Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire in April 2005.




Wenhui Zhou              Expires - April 2005                   [Page 1]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract

   This document presents a set of objectives or requirements for the
   Control and Provisioning of Wireless Access Points (CAPWAP) protocol.
   It presents the requirements from different aspects including
   architecture, user (client) access, service, control, management and
   security.






































Wenhui Zhou              Expires - April 2005                   [Page 2]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


1.  Definitions

1.1  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.

1.2  Terminology Used in this Document

   CAPWAP - Control and Provisioning of Wireless Access Points.

   CAPWAP Functions - a set of WLAN control functions that are not
   directly defined by IEEE 802.11 Standards, but deemed essential
   for effective control, configuration and management of 802.11 WLAN
   access networks.

   Wireless Termination Point (WTP) -  the physical or network entity
   that contains RF antenna and 802.11 PHY to transmit and receive
   station traffics for the IEEE 802.11 WLAN access networks.  Such
   physical entities are often called "Access Points" (AP) previously,
   but "AP" can also be used to refer to logical entity that
   implements 802.11services. So we recommend using "WTP" instead to
   explicitly refer to the physical entity.

   Centralized WLAN Architecture - the WLAN access network
   architecture family in which the logical functions, including both
   IEEE 802.11 and CAPWAP functions (wherever applicable), are
   implemented across a hierarchy of network entities.  At the low
   level of such hierarchy are the WTPs while at the higher level are
   the Access Controllers(ACs), which are responsible to control,
   configure and manage the entire WLAN access networks.

   Access Controller (AC) - The network entity in the Centralized WLAN
   architectures that provide WTPs access to the centralized
   hierarchical network infrastructure, either in the data plane,
   control plane, or management plane, or a combination therein.

   Local MAC Architecture - A sub-group of the Centralized WLAN
   Architecture, where the majority or entire set of 802.11 MAC
   functions (including most of the 802.11 management frame
   processing) are implemented at the WTP. Therefore, the 802.11 MAC
   stays intact and local in the WTP, along with PHY.








Wenhui Zhou              Expires - April 2005                   [Page 3]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


   Split MAC Architecture - A sub-group of the Centralized WLAN
   Architecture, with the characteristic that WTPs in such WLAN
   access networks only implement the delay sensitive MAC services
   (including all control frames and some management frames) for IEEE
   802.11, while tunneling all the remaining management and data
   frames to AC for centralized processing.The IEEE 802.11 MAC as
   defined by IEEE 802.11 Standards is effectively split between the
   WTP and AC.

2.  Introduction

   As IEEE 802.11 Wireless LAN (WLAN) technology matures, large scale
   deployment of WLAN networks is highlighting certain technical
   challenges including management, monitoring and control of large
   number of Access Points (APs). Distributing and maintaining a
   consistent configuration throughout the entire set of APs in the WLAN
   is a difficult task.  The shared and dynamic nature of the wireless
   medium also demands effective coordination among the APs to minimize
   radio interference and maximize network performance. Furthermore,
   vendors implement not only the services defined in the IEEE 802.11
   standard, but also a variety of value-added services or functions,
   like load balancing support, QoS, station mobility support, rogue AP
   detection, etc.

   The Centralized WLAN Architecture family, as described in [2], is
   an innovative architectural solution intended to address the
   aforementioned problems. Two classes of the Centralized WLAN
   Architecture family, namely the Local MAC and the Split MAC, will be
   supported by the CAPWAP protocol to realize interoperability of the
   AC-WTP interface among vendors. This document puts forth the
   requirements for CAPWAP protocol between the AC and WTP.

2.1  Centralized WLAN Architecture

   Figure 1 shows a diagram of the Centralized WLAN Architecture from
   [2]. In the Centralized WLAN Architecture, there is one or more
   centralized controllers for managing a large number of WTP devices.
   The centralized controller is commonly referred to as an Access
   Controller (AC), whose main function is to manage, control and
   configure the WTP devices that are present in the network.  In
   addition to being a centralized entity for the control and management
   plane, it may also become a natural aggregation point for the data
   plane, since it is typically situated in a centralized location in
   the wireless access network. The AC is often co-located with an L2
   bridge, a switch, or an L3 router, and hence may be referred to as
   Access Bridge, or Access Router in those particular cases.  Therefore,
   an Access Controller could be either an L3 or L2 device, and Access
   Controller is the generic terminology we use throughout this document.



Wenhui Zhou              Expires - April 2005                   [Page 4]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


   It is also possible that multiple ACs are present in a network for
   purposes of redundancy, load balancing, etc.  This architecture
   family has several distinct characteristics that are worth noting.
   First of all, the hierarchical architecture and the centralized AC
   afford much better manageability for the large scale networks.
   Secondly, since the IEEE 802.11 functions and the CAPWAP control
   functions are provided by the WTP devices and the AC together, the
   WTP devices themselves may not implement the full 802.11 functions as
   defined in the standards any more. Therefore, it can be said that the
   full 802.11 functions are implemented across multiple physical
   network devices, namely, the WTPs and ACs.  Since the WTP devices
   only implement a portion of the functions that standalone APs
   implement, WTP devices in this architecture are sometimes referred to
   as light weight or thin APs by some vendors.

   As shown in Figure 1, CAPWAP protocol is the protocol between WTP and
   AC that will provide vendor interoperability when it is standardized.
   This protocol may run on different interconnection technology.

íííí+----------------+     +---------------+     +---------------+
    |  802.11 BSS 1 |     |  802.11 BSS 2 |     |  802.11 BSS 3 |
    |  ...          |     |  ...          |     |  ...          |
    |    +-------+  |     |    +-------+  |     |    +-------+  |
    +----|  WTP  |--+     +----|  WTP  |--+     +----|  WTP  |--+
         +---+---+             +---+---+             +---+---+
             |                     |                     |
             +------------------+  |   +-----------------+
                                |  |...|
                           +----+--+---+--------+
                           |  CAPWAP Protocol   |
                           +----+--+---+--------+
                                   |
                                   |
                             +-----+----+
                             |    AC    |
                             +----------+

            Figure 1: Centralized WLAN Architecture Diagram

2.2  Local MAC

   The main motivation of Local MAC architecture model is to offload
   network access policies and management functions (CAPWAP functions
   described in [2]) to the AC, without splitting the 802.11 MAC
   functionality between WTPs and AC. The whole 802.11 MAC resides on
   the WTPs locally, including all the 802.11 management and control
   frame processing for the STAs; on the other hand, information related
   to management and configuration of the WTP devices is communicated



Wenhui Zhou              Expires - April 2005                   [Page 5]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


   with a centralized AC, to facilitate management of the network, and
   maintain a consistent network-wide configuration for the WTP devices.

2.3  Split MAC

   The main idea behind the Split MAC architecture is to implement part
   of the 802.11 MAC functionality on a centralized AC instead of the
   WTPs, in addition to the services required for managing and
   monitoring the WTP devices. Usually, the decision of which functions
   of the 802.11 MAC need to be provided by the AC is based on the time-
   criticality of the services considered.

   In the Split MAC architecture, the WTP terminates the
   infrastructure side of the wireless physical link, provides radio-
   related management, and also implements all time-critical

   functionality of the 802.11 MAC. In addition, the non real-time
   management functions are handled by a centralized AC, along with
   higher-level services, such as configuration, QoS, policies for load-
   balancing, access control lists, etc.  The subtle but key distinction
   between Local MAC and Split MAC relates to the non real-time
   functions: in Split MAC architecture, the AC terminates 802.11 non
   real-time functions, whereas in Local MAC architecture the WTP
   terminates the 802.11 non real-time functions and consequently sends
   appropriate messages to the AC.

   There are several motivations for taking the Split MAC approach.
   The first is to offload to the WTP functionality that is specific and
   relevant only to the locality of each BSS, in order to allow the AC
   to scale to a large number of 'light weight' WTP devices. Moreover,
   real-time functionality is subject to latency constraints and cannot
   tolerate delays due to transmission of 802.11 Control frames (or
   other real-time information) over multiple-hops. The latter would
   limit the available choices for the connectivity between the AC and
   the WTP, hence the real-time criterion is usually employed to
   separate MAC services between the devices.  Another consideration is
   cost reduction of the WTP to make it as cheap and simple as possible.
   Last but not least, moving functions like encryption and decryption
   to the AC reduces vulnerabilities from a compromised WTP, since user
   encryption keys no longer reside on the WTP.  As a result, any
   advancements in security protocols and algorithms design do not
   necessarily obsolete the WTPs; the ACs implement the new security
   schemes instead, and the management and update task is therefore
   simplified. Additionally, the network is protected against LAN-side
   eavesdropping.






Wenhui Zhou              Expires - April 2005                   [Page 6]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


3.  Architectural requirements

   The following are the architectural requirements for CAPWAP protocol:

   1) Both local MAC and split MAC technologies based products, i.e.,
   ACs or WTPs must be able to co-exist and inter-operate in one WLAN
   access network.

   2) ACs and WTPs MUST be able to connect by a variety of interconnect
   technologies. CAPWAP protocol should be transmitted transparently
   regardless of lower technologies. Examples of interconnect
   technologies used in current architectures include Ethernet, bus
   backplanes, and ATM (cell) fabrics. Ethernet architecture is most
   widely used and should be recommended.

   3) CAPWAP-supported WTPs should be able to co-exist with non-CAPWAP
   WTPs in one WLAN access network.

4.  User (client) access requirements

   There shouldn't be any impact on the client (both hardware and
   software platform) due to the use of    CAPWAP protocol. Clients
   should not be required to be aware of the existence of CAPWAP
   protocol.

5.  Service requirements

   The following are the service requirements:

   1)Voice over WLAN. So CAPWAP should support IEEE 802.11e and provide
   fast-handoff capability to avoid voice interruption.

   2)Isolate STA from other STAs and restrict inter-STA in layer 2
   communication directly.

   3)WLAN network resource share. It is required that two or more WLAN
   service providers can share a hotspot WLAN network. This means
   that a physical WLAN network can be virtualized into several
   logical WLAN network.

6.  Centralized Control requirements

   The following are the control requirements:

   1)AC may perform access control functions based on radio resource
   and/or network resource.

   2)To support handover and load balancing between different WTPS, AC
   should have the capability of centralized control via CAPWAP protocol.


Wenhui Zhou              Expires - April 2005                   [Page 7]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


7.  Management Requirements

   The following are the management requirements:
   It is possible that WTPs can be managed directly or through AC
   where AC acts as a management agent.

8.  Security Requirements

   The following are the security requirements:

   1)It is required to support WPA and/or IEEE 802.11i for wireless air
   interface security.

   2)It is required to provide mechanism supporting secure information
   exchange between AC and WTP

9.  QoS Requirements

  The following are the QoS requirements:

  WLAN air interface QoS implementation should be based on the current
  IEEE802.11e, but it is required to support QoS centralized control
  Policy between WTPS and AC via CAPWAP protocol.

10.  References

   1. í—CAPWAP Problem Statementí˜, August 2004,
   <http://www.ietf.org/internet-drafts/draft-ietf-capwap-problem-
   statement-02.txt>

   2. í—Architecture Taxonomy for Control and Provisioning of Wireless
   Access Points (CAPWAP)í˜, August 2004,
   http://www.ietf.org/internet-drafts/draft-ietf-capwap-arch-05.txt>

   3. í—Functionality Classifications for Control and Provisioning of
   Wireless Access Points (CAPWAP)í˜, July 2004,
   <http://www.ietf.org/internet-drafts/draft-cheng-capwap-
   classifications-01.txt>












Wenhui Zhou              Expires - April 2005                   [Page 8]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


11.  Authors' Addresses

   Wenhui Zhou
   53A, Xibianmen Ave, Xuanwu District
   Beijing 100053
   P. R. China
   Phone: +86 10 66006688 ext.3061
   Email: zhouwenhui@chinamobile.com

   Zhonghui Yao
   Huawei Longgang Production Base,
   Shenzhen 518129
   P. R. China
   Phone: +86 755 28780808
   EMail: yaoth@huawei.com

   L. Lily Yang
   JF3-206, Intel Corp.
   2111 NE 25th Ave.
   Hillsboro, OR 97124
   USA
   Phone: +1 503 264 8813
   EMail: lily.l.yang@intel.com

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

   Dong Wang
   No.68 Zijinghua Rd,Yuhuatai District,
   Nanjing,Jiangsu Prov. 210012
   P.R. China.
   Phone: +86-25-52871713
   EMail: wang.dong@mail.zte.com.cn













Wenhui Zhou              Expires - April 2005                   [Page 9]

Internet-Draft       CAPWAP Protocol 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.




Wenhui Zhou              Expires - April 2005                  [Page 10]

Internet-Draft       CAPWAP Protocol Objectives            November 2004


Acknowledgment


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














































Wenhui Zhou              Expires - April 2005                  [Page 11]


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