Internet Engineering Task Force R. Zhang
Internet-Draft China Telecom
Intended status: Informational Z. Cao
Expires: January 15, 2014 H. Deng
China Mobile
R. Pazhyannur
S. Gundavelli
Cisco
July 14, 2013
Separation of CAPWAP Control and Data Plane: Scenarios, Requirements and
Solutions
draft-zhang-opsawg-capwap-cds-00
Abstract
This document describes the scenarios and requirements of separating
CAPWAP Data and Control plane. This specification provides a CAPWAP
extension to allow two distinct AC component: AC-DP (AC-Data Plane)
and AC-CP (AC-Control Plane). AC-DP handles all user payload with
the exception of layer 2 management frames between the AC and user
such as IEEE 802.11 association, authentication, probe, Action Frame.
AC-CP handles all control messages between the WTP and AC. In
addition, the AC-CP wil handle user payload related to layer-2
management frames such as those mentioned above.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 15, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires January 15, 2014 [Page 1]
Internet-Draft CAPWAP Separation July 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenario and Analysis . . . . . . . . . . . . . . . . . . . . 3
3. Analysis of Local Bridging Model . . . . . . . . . . . . . . 5
4. Multiple CAPWAP Data Tunnels . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Control and Provisioning of Wireless Access Points (CAPWAP) was
designed as an interoperable protocol between the wireless access
point and the access controller. This architecture makes it possible
for the access controller to manage a huge number of wireless access
points. With the goals and requirements established in[RFC4564] ,
CAPWAP protocols were specified in [RFC5415] , [RFC5416]and
[RFC5417].
The specificaitons mentioned above mainly design the different
control message types used by the AC to control multiple WTPs.
CAPWAP specifies that all user payload is transported on the CAPWAP-
DATA channel. As an example, EAP messages, as key protocol exchange
elements in the WLAN architecture also need to be encapsulated in the
CAPWAP-DATA. The CAPWAP protocol does not specify how to encapsulate
EAP message in its control plane. As a result, the protocol does not
allow for splitting the CAPWAP control and data plane where control
messages
There are multiple ways of meeting the above requirements. This
document first analyzes the capability of current CAPWAP solutions
Zhang, et al. Expires January 15, 2014 [Page 2]
Internet-Draft CAPWAP Separation July 2013
and proposes ways to working around the problem without changing
existing specifications.
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 [RFC2119]
1.2. Terminology
Access Controller (AC): The network entity that provides WTP access
to the network infrastructure in the data plane, control plane,
management plane, or a combination therein.
Access Point (AP): the same with Wireless Termination Point (WTP),
The physical or network entity that contains an RF antenna and
wireless Physical Layer (PHY) to transmit and receive station traffic
for wireless access networks.
CAPWAP Control Plane: A bi-directional flow over which CAPWAP Control
packets are sent and received.
CAPWAP Data Plane: A bi-directional flow over which CAPWAP Data
packets are sent and received.
EAP: Extensible Authentication Protocol, the EAP framework is
specified in [RFC3748].
2. Scenario and Analysis
The following figure shows where and how the problem arises. In many
operators' network, the Access Controller is placed remotely at the
central data center. In order to avoid the traffic aggregation at
the AC, the data traffic from the AP is directed to the Access Router
(AR). In this scenario, the CAPWAP-CTL plane and CAPWAP-DATA plane
are separated from each other.
Note: a powerful AC that aggregates the data flows is not a long-term
solution to the problem. Because operators always plan the network
capacity at a certain level, but with the air interface bandwidth
increasing (e.g., from 11g to 11n and 11ac), and the increasing
number of access requests on each WTP, the AC may not scale to meet
the requirements.
CAPWAP-CTL +--------+
++============+ AC |
Zhang, et al. Expires January 15, 2014 [Page 3]
Internet-Draft CAPWAP Separation July 2013
// +--------+
//
+-----+// CAPWAP-DATA +----------------+
| WTP |===========================| Access Router |
+-----+ +----------------+
Figure 1: Split between CAPWAP-CTL and CAPWAP-DATA Plane
Because there are no explict message types to support the
encapsulation of EAP packets (and more generally layer 2 management
frames) in the CAPWAP-CTL plane, the EAP messages are tunneled via
the CAPWAP-DATA plane to the AR. AR would act as the authenticator
in the EAP framework. After authentication, the AR receives the EAP
keying message for the session. However, this mode of operation
would undermine the main benefit of having the AC .as the centralized
entity for authentication and policy.
Another scenario is the third-party WLAN deployment scenario, in
which the access network is a rental property from an broadband
operator different from the one who provides authentication services.
As shown in Figure 2, The AP is broadcasting a SSID of the Operator
#1, say "Operator-1-WLAN", but broadband access network is provided
by another Operator #2. To authenticate the users of operator one,
the users should be authenticated by the AC in operator one. The
data traffic can be routed locally with the access router of operator
#2. In this case, there is also a need of separation between CAPWAP-
CTL and CAPWAP-DATA traffics.
*----------*
+-----+ ( ) +---------+
| WTP |===============++============+ Internet +========| AC(OP#1)|
+-----+ || (___________) +---------+
||
+-------------------+
|Access Router(OP#2)|
+-------------------+
Figure 2: Access Service and Authentication Service Provided by
different Operators
Zhang, et al. Expires January 15, 2014 [Page 4]
Internet-Draft CAPWAP Separation July 2013
3. Analysis of Local Bridging Model
In the Local-MAC model defined in [RFC5416] Section 2.2.2, it says
that:
"The WTP MAY locally bridge client data frames (and provide the
necessary encryption and decryption services). The WTP MAY also
tunnel client data frames to the AC, using 802.3 frame tunnel mode or
802.11 frame tunnel mode."
Some have rightly suggested that the Local-MAC model provides a way
to separate Data and Control Plane. In this case where the WTP can
locally bridge the user traffic (wihtout any CAPWAP encapsulation).
EAP and other management traffic can still be carried over the
CAPWAP-DATA tunnel between the WTP and AC. The limitation of this
behavior is two fold: This requries the Access Router (that will
apply policy, etc) to be on the same Layer-2 network as the WTP. In
many deployments, the traffic would need to be tunneled between the
WTP and the Access Router that applies the policy. Second, without
outer layer CAPWAP Data header, charging and controlling policies
could not be applied to the data plane.
The Figure 3 shows this case where WTP encapsulates EAP messages into
CAPWAP-DATA plane but locally bridges data frames.
+-----+ +----------------+
| |=======CAPWAP-CTL==========+ AC |
| |=======CAPWAP-DATA=========+ |
| WTP | +----------------+
| | +----------------+
| |=======Local Bridge========| Access Router |
+-----+ +----------------+
Figure 3: Local Bridging Model
4. Multiple CAPWAP Data Tunnels
A proposed solution is to create multiple CAPWAP-DATA tunnels. As
shown in Figure 4, the WTP encapsulates all control messages between
the WTP and AC in teh CAPWAP-Control tunnel. In addition, all Layer
2 management frames (EAP, etc) are also transported in the CAPWAP-
DATA tunnel between WTP and AC-CP. In addition, WTP encapsulates all
non-management user payload into a secondary CAPWAP-DATA tunnel
between WTP and AC-DP.
This brings up issues related to setting up of the secondary data
tunnel, such as how does the WTP discover the IP address of AC-DP,
Zhang, et al. Expires January 15, 2014 [Page 5]
Internet-Draft CAPWAP Separation July 2013
and what security creedentials are used to setup the tunnel. We plan
to address this in the next version of this draft.
+-----+ +----------------+
| |=======CAPWAP-CTL==========+ AC-CP |
| |=======CAPWAP-DATA=========+ |
| WTP | +----------------+
| | +----------------+
| |=======CAPWAP-DATA=========| AC-DP |
+-----+ +----------------+
Figure 4: Multiple DATA tunnels Model
5. IANA Considerations
This document has no requests to the IANA.
6. Security Considerations
Security considerations for the CAPWAP protocol has been analyzed in
Section 12 of [RFC5415]. This document does not introduce other
security issues besides what has been analyzed in RFC5415.
7. Contributors
This document stems from the joint work of Hong Liu, Yifan Chen,
Chunju Shao from China Mobile Research.
Thank Dorothy Stanley for reviewing the document and recommending
ways to move forward with both technology and editorial parts of the
document.
Thank all the contributors of this document.
8. References
8.1. Normative References
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
Zhang, et al. Expires January 15, 2014 [Page 6]
Internet-Draft CAPWAP Separation July 2013
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
"Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and
Provisioning of Wireless Access Points (CAPWAP) Protocol
Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access
Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
March 2009.
Authors' Addresses
Rong Zhang
China Telecom
No.109 Zhongshandadao avenue
Guangzhou 510630
China
Email: zhangr@gsta.com
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100871
China
Phone: +86-10-52686688
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Zhang, et al. Expires January 15, 2014 [Page 7]
Internet-Draft CAPWAP Separation July 2013
Hui Deng
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100053
China
Email: denghui@chinamobile.com
Rajesh S. Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: rpazhyan@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Zhang, et al. Expires January 15, 2014 [Page 8]