Separation of CAPWAP Control and Data Plane: Scenarios, Requirements and Solutions
draft-zhang-opsawg-capwap-cds-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Last updated 2013-07-14
Replaced by draft-ietf-opsawg-capwap-alt-tunnel
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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]