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]