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
Show full document text