< draft-shao-capwap-plus-ps-00.txt   draft-shao-capwap-plus-ps-01.txt >
Network Working Group CJ. Shao Network Working Group CJ. Shao
Internet-Draft H. Deng Internet-Draft H. Deng
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: April 18, 2013 R. Zhang Expires: April 25, 2013 R. Zhang
China Telecom China Telecom
October 15, 2012 F. Bari
AT&T Services
October 22, 2012
Enhancement of CAPWAP Problem Statement Enhancement of CAPWAP Problem Statement
draft-shao-capwap-plus-ps-00 draft-shao-capwap-plus-ps-01
Abstract Abstract
With the recent widely deployment of large public Wifi network, and In recent widescale deployments of large public Wi-Fi networks, and
the integration with cellular network. EAP based authentication has in their integration with cellular networks EAP based authentication
been considered as the good candidate to improve the Wifi user has been considered as a good candidate to making Wi-Fi user
experience similarly to the extend of GSM network. Couple of new experience seamless similar to what it has been for cellular users.
functions which could enhance CAPWAP protocol have been raised to A few new functions which could enhance CAPWAP protocol have been
improve the large carrier grade Wifi network. identified in such deployments that can help improve the large scale
carrier grade Wi-Fi networks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Supporting EAP authencation in Wifi network . . . . . . . . . . 3 3. Supporting EAP authencation in Wi-Fi network . . . . . . . . . 3
3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3 3.1. Scenario Description . . . . . . . . . . . . . . . . . . . 3
4. The scope of definition of split MAC mode . . . . . . . . . . . 4 4. The Scope of Split and Local MAC mode . . . . . . . . . . . . . 4
5. 802.11n support . . . . . . . . . . . . . . . . . . . . . . . . 4 5. 802.11n support . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Channel auto reconfiguration . . . . . . . . . . . . . . . . . 5 6. Channel auto reconfiguration . . . . . . . . . . . . . . . . . 5
7. Power auto reconfiguration . . . . . . . . . . . . . . . . . . 5 7. Power auto reconfiguration . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
11. Normative References . . . . . . . . . . . . . . . . . . . . . 6 11. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Public Wifi service has been paid more attention due to the growth of Mobile devices such as smartphones and tablets continue to lead
cellular data traffic, this is mainly originated from faster mobile growth in internet traffic. It is predicted that such growth will
network and more smart terminals. It is predcited that such growth continue even with the deployment of LTE network. Almost all mobile
will continue even with the deployment of LTE network. The capacity devices today are Wi-Fi enabled. Public Wi-Fi services have lately
and coverage of LTE network still needs the complementation of public been paid more attention for that reason to help bring this growth of
wifi network because Wifi spectrum is free, limited and globally cellular data traffic to a sustainable level. Wi-Fi spectrum is free
available. and almost all smart terminal has the Wifi equiped. and globally available. Because of capacity and coverage issues, LTE
networks will continue to need public Wi-Fi network as a
complementary technology.
Recent efforts have been made to let Wifi roaming similar to as easy Recently industry efforts have been made to make Wi-Fi roaming as
as legacy cellular GSM network by deploying EAP based authentication seamless as it is for cellular GSM networks by deploying EAP based
mechanism, and to let mobile to Wifi integration is seamless and authentication mechanism; Toward this end current CAPWAP protocol
transparent to the customer; Toward this two directions, current could be enhanced to help ease such deployments.
CAPWAP protocol could be enhanced to improve better user experiences.
There have been lots of propritary implementations between AP and AC There have been a number of proprietary implementations of the
interfaces, some of them have very strong capability which could be interface between Access Point (AP) and Access Controller (AC) and
used to improve the wifi performance. Once Standard interface is some of them provide capabilities which could be used to improve the
specified, such merits may be not exist, but it benefit for operators Wi-Fi performance. Once a standard interface is specified, the
deployment with such sacrifice. benefits for operators of standards based deployment will outweigh
any benefits of past proprietary solutions.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Supporting EAP authencation in Wifi network 3. Supporting EAP authencation in Wi-Fi network
Current EAP message is designed to be transmited in CAPWAP data Current EAP message is designed to be transmitted in CAPWAP data
plane, AC in the middle of data path will act as the authenticator to Plane. AC which is in the data path will act as the authenticator to
transmit this EAP message to AAA server, but sometime, operator would transmit this EAP message to AAA server. An operator may however
like to let AC to be in the bypass of the data plane which could help prefer to bypass the AC for the user plane in order to improve the
to improve the performance of AC, allow it can manage more APs once performance of AC and allow it to manage more APs when the network is
the network is growing. In order to allow AC be bypassed, the capwap growing. In order to allow ACs to be bypassed for EAP messages, the
control message could be extended to support EAP messages. CAPWAP control message could be extended to support EAP messages.
3.1. Scenario Description 3.1. Scenario Description
The following figure shows where and how the problem arises. In many The following figure shows where and how the problem arises. In many
operators' network, the Access Controller is placed remotely at the operators networks. The Access Controller is placed remotely at the
central data center. In order to avoid the traffic aggregation at central data center. In order to avoid the traffic aggregation at
the AC, the data plane out of the AP is directed to the Access Router the AC, the data plane out of the AP is directed to the Access Router
(AR). In this scenario, the CAPWAP-CTL tunnel and CAPWAP-DATA tunnel (AR). In this scenario, the CAPWAP-CTL tunnel and CAPWAP-DATA tunnel
are separated from each other. are separated from each other.
Because there are no explict message types to support the Because there are no explicit message types to support the
encapsulation of EAP packets in the CAPWAP-CTL tunnel, the EAP encapsulation of EAP packets in the CAPWAP-CTL tunnel, the EAP
messages are tunneled via the CAPWAP-DATA plane to the AR. AR acts messages are tunneled via the CAPWAP-DATA plane to the AR. AR acts
as authenticator in the EAP framework. After authentication, the AR as authenticator in the EAP framework. After authentication, the AR
receives the keying message for the session. But AC is supposed to receives the keying message for the session. But AC is supposed to
delieve these keying messages to the AP, and AR has no standard deliver these keying messages to the AP, and AR has no standard
interface to ship them to the AP or the AC. This is unacceptable in interface to ship them to the AP or the AC. This is unacceptable in
the scenario of EAP-based auto-authentication. the scenario of EAP-based auto-authentication.
CAPWAP-CTL +--------+ CAPWAP-CTL +--------+
++========+ AC | ++========+ AC |
// +--------+ // +--------+
// //
+-----+// CAPWAP-DATA +--------------+ +-----+// CAPWAP-DATA +--------------+
| AP |===========================| Access Router| | AP |===========================| Access Router|
+-----+ +--------------+ +-----+ +--------------+
Figure 1: Split between CAPWAP-CTL and CAPWAP-DATA Plane Figure 1: Split between CAPWAP-CTL and CAPWAP-DATA Plane
So it is desirable to encapsulate EAP messages in the CAPWAP-CTL So it is desirable to encapsulate EAP messages in the CAPWAP-CTL
plane, to avoid data aggregation and improve WLAN system scalability. plane, to avoid data aggregation and improve WLAN system scalability.
4. The scope of definition of split MAC mode 4. The Scope of Split and Local MAC mode
There are many functions hasn't been clearly defined whether they There are 3 major categories has been specified by CAPWAP, the first
belong to either AP and AC in the split mode. Operation needs to is about Functions: such as "Distribution Service", "Integration
configure differently handle the various implementation of split MAC Service", "Beacon Generation", "Probe Response Generation" "Power
mode. if there is no clear scope definition of split MAC and local Mgmt/Packet Buffering", "Fragmentation/Defragmentation", and "Assoc/
MAC, then operator has the diffculty to interoperate different Disassoc/Reassoc"; the second is about QoS, such as, "Classifying",
vendors. "Scheduling", and "Queuing"; the third is about RSN (WPA2) such as
"IEEE 802.1X/EAP", "RSNA Key Management", and "IEEE 802.11
Encryption/Decryption". Even Split and Local MAC model has optional
implementation, either at AP or AC, this lead to serious issue about
Interoperation
Proposing a specific mode about all this implementation will help
interoperation among different vendors.
5. 802.11n support 5. 802.11n support
There are couple of capabilities of 802.11n need to be supported by There are a couple of capabilities of 802.11n that need to be
CAPWAP control message such as radio capability, radio configuration supported by CAPWAP control message such as radio capability, radio
and station information. configuration and station information.
IEEE 802.11n standard was published in 2009 and it is an amendment to IEEE 802.11n standard was published in 2009 and it is an amendment to
the IEEE 802.11-2007 standard to improve network throughput. The the IEEE 802.11-2007 standard to improve network throughput. The
maximum data rate increases to 600Mbit/s physical throughput rate. maximum data rate increases to 600Mbit/s physical throughput rate.
In the physical layer, 802.11n use OFDM and MIMO to achive the high In the physical layer, 802.11n use OFDM and MIMO to achieve the high
throughput. 802.11n use multiple antennas to form antenna array which throughput. 802.11n use multiple antennas to form antenna array which
can be dynamically adjusted to imporve the signal strength and extend can be dynamically adjusted to improve the signal strength and extend
the coverage. the coverage.
802.11n support two modes of channel usage: 20MHz mode and 40Mhz 802.11n support two modes of channel usage: 20MHz mode and 40Mhz
mode.802.11n has a new feature called channel binding. It can bind mode.802.11n has a new feature called channel binding. It can bind
two adjacent 20MHz channel to one 40MHz channel to improve the two adjacent 20MHz channel to one 40MHz channel to improve the
throughput.If using 40Mhz channel configuration there will be only throughput.If using 40Mhz channel configuration there will be only
one non-overlapping channel in 2.4GHz. In the large scale deployment one non-overlapping channel in 2.4GHz. In the large scale deployment
scenario, operator need to use 20MHz channel configuration in 2.4GHz scenario, operator need to use 20MHz channel configuration in 2.4GHz
to allow more non-overlapping channels. to allow more non-overlapping channels.
skipping to change at page 5, line 22 skipping to change at page 5, line 32
802.11a/g use 800ns guard interval between the adjacent information 802.11a/g use 800ns guard interval between the adjacent information
symbols. In 802.11n, the GI can be configured to 400nm under good symbols. In 802.11n, the GI can be configured to 400nm under good
wireless condition. wireless condition.
Another feature in 802.11 MAC layer is Block ACK. 802.11n can use one Another feature in 802.11 MAC layer is Block ACK. 802.11n can use one
ACK frame to acknowledge several MPDU receiving event. ACK frame to acknowledge several MPDU receiving event.
CAPWAP need to be extended to support the above new 802.11n features. CAPWAP need to be extended to support the above new 802.11n features.
For example, CAPWAP should allow the access controller to know the For example, CAPWAP should allow the access controller to know the
supported 802.11n features and the access controller should be able supported 802.11n features and the access controller should be able
to configure the differe channel binding modes. One possible to configure the different channel binding modes. One possible
solution is to extend the CAPWAP information element for 802.11n. solution is to extend the CAPWAP information element for 802.11n.
6. Channel auto reconfiguration 6. Channel auto reconfiguration
Channel auto reconfiguration could imporve the Wifi performance, Channel auto reconfiguration could imporve the Wi-Fi performance,
CAPWAP message could be extended to support this function. CAPWAP message could be extended to support this function.
Each channel may provide different quality of service, when WTP Each channel may provide different quality of service, when WTP
works. WTP can be active or passive scanning and monitoring each works. WTP can be active or passive scanning and monitoring each
channel, form the report of measurement results to the Access channel, form the report of measurement results to the Access
Controller. WTP can periodically send configure status request to Controller. WTP can periodically send configure status request to
the AC. According to the current channel quality and other channel the AC. According to the current channel quality and other channel
quality scanning report, ACs decide whether modify the channel to be quality scanning report, ACs decide whether modify the channel to be
used, send the configure status response packet to set up a new used, send the configure status response packet to set up a new
channel for the WTP. channel for the WTP.
7. Power auto reconfiguration 7. Power auto reconfiguration
Power auto reconfiguration could imporve the Wifi performance. Power auto reconfiguration could improve the Wi-Fi performance.
CAPWAP message could be extended to achieve following outcome. CAPWAP message could be extended to achieve following outcome.
o Maximize Spectrum Usage: Real-world Wi-Fi deployments are o Maximize Spectrum Usage: Real-world Wi-Fi deployments are
depending on the features of shared media. Three channels depending on the features of shared media. Three channels
available in the 2.4GHz band and 23 channels in the 5GHz band. available in the 2.4GHz band and 23 channels in the 5GHz band.
Power auto reconfiguration could help these channels be fully Power auto reconfiguration could help these channels be fully
utilized. As the results, clients could be distributed across all utilized. As the results, clients could be distributed across all
available channels. available channels.
o Reduce Interference: when multiple devices attempt to o Reduce Interference: when multiple devices attempt to
simutaneously access the same channel at the same time, a co- simutaneously access the same channel at the same time, a co-
channel interference likely happned. It reduces overall channel interference likely happned. It reduces overall
performance of the channel. The reconfiguration via CAPWAP could performance of the channel. The reconfiguration via CAPWAP could
efficiently mitigate the interference. That is essential to efficiently mitigate the interference. That is essential to
proper network operation proper network operation
o Optimize Coverage: Simply increasing AP power may not help to o Optimize Coverage: Simply increasing AP power may not help to
maximize converage because it creates an unbalanced condition in maximize converage because it creates an unbalanced condition in
which more distantly located clients may perforIm poorly due to which more distantly located clients may perforIm poorly due to
their lower transmit output power. The power reconfiguration their lower transmit output power. The power reconfiguration
skipping to change at page 6, line 33 skipping to change at page 6, line 44
9. IANA Considerations 9. IANA Considerations
None None
10. Contributors 10. Contributors
Yifan Chen chenyifan@chinamobile.com Yifan Chen chenyifan@chinamobile.com
Bocun Deng 13316090701@189.cn Bocun Deng 13316090701@189.cn
Satoru Matsushima satoru.matsushima@tm.softbank.co.jp
11. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
"Objectives for Control and Provisioning of Wireless "Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006. Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
skipping to change at line 275 skipping to change at page 8, line 4
Email: denghui@chinamobile.com Email: denghui@chinamobile.com
Rong Zhang Rong Zhang
China Telecom China Telecom
No.109 Zhongshandadao avenue No.109 Zhongshandadao avenue
Tianhe District, Tianhe District,
Guangzhou 510630 Guangzhou 510630
China China
Email: zhangr@gsta.com Email: zhangr@gsta.com
Farooq Bari
AT&T Services
7277 164th Avenue NE
Redmond
US
Email: farooq.bari@att.com
 End of changes. 28 change blocks. 
58 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/