Capability Announcement and AR Discovery in CAPWAP Control and Data Channel Separation
draft-xue-opsawg-capwap-separation-capability-00

Network Working Group                                             L. Xue
Internet-Draft                                                     Z. Du
Intended status: Informational                                    Huawei
                                                                  D. Liu
                                                            China Mobile
                                                                R. Zhang
                                                           China Telecom
                                                     John Kaippallimalil
                                                                  Huawei
                                                           July 10, 2013

  Capability Announcement and AR Discovery in CAPWAP Control and Data
                           Channel Separation
            draft-xue-opsawg-capwap-separation-capability-00

Abstract

   In a centralized IEEE 802.11 Wireless Local Area Network (WLAN)
   architecture, the Access Controller (AC) does not have the
   intelligence to aggregate all the wireless frames. In addition,
   increasing amounts of traffic handled by each access point would
   require even more processing at an AC.  Thus it is normal in an
   existing operator's network for the WTPs to forward the wireless
   frames directly to AR to avoid overloading the AC.  In this scenario,
   CAPWAP Control Channel and CAPWAP Data Channel are separated from
   each other.  This document provides extensions to CAPWAP for the
   split scenario where CAPWAP Control and Data Channel are separated.

Requirements Language

   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].

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
 

Xue, et al.             Expires January 11, 2014                [Page 1]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   material or to cite them other than as "work in progress."

 

Xue, et al.             Expires January 11, 2014                [Page 2]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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
   2.  Split CAPWAP-CTL and CAPWAP-DATA Establishment  . . . . . . .   3
     2.1.  AR Discovery  . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Split Mode Capability Announcement  . . . . . . . . . . .   4
   3.  CAPWAP Message Elements for Split Mode  . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In a centralized IEEE 802.11 Wireless Local Area Network (WLAN)
   architecture, Control and Provisioning of Wireless Access Points
   (CAPWAP) protocol is defined to enable Access Controller (AC) to
   manage a collection of Wireless Termination Points (WTPs), specified
   in [RFC5415] and [RFC5416].  In the existing specifications, CAPWAP
   Control Channel and Data Channel between a WTP and AC are setup and
   managed in a converged procedure.  CAPWAP Control messages are
   management messages exchanged between a WTP and AC; meanwhile, CAPWAP
   data messages encapsulate forwarded wireless frames.

   In practice, it is a general case in existing operator networks that
   WTPs forward the wireless frames directly to AR to avoid overload on
   the AC. This requirement is also mentioned in [I-D.cao-capwap-eap].
   The AC does not have the intelligence to aggregate all the wireless
   frames. In addition, increasing amounts of traffic handled by each
   access point would require even more processing at an AC.  In this
   scenario, CAPWAP Control Channel and CAPWAP Data Channel should be
 

Xue, et al.             Expires January 11, 2014                [Page 3]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   separated from each other, as shown in the following figure.

            CAPWAP-CTL +--------+
             ++========+   AC   |
            //         +--------+
           //
   +-----+//   CAPWAP-DATA           +--------------+
   | WTP |===========================| Access Router|
   +-----+                           +--------------+

          Figure 1: Split CAPWAP Control and CAPWAP DATA Channel

   However, up to now, there is only one common procedure for both
   CAPWAP Control Channel and CAPWAP Data Channel setup [RFC5415]
   between a WTP and AC.  This is not sufficient if CAPWAP Control
   Channel and CAPWAP Data Channel are split. This document extends
   CAPWAP for applicability in split CAPWAP Control Channel and CAPWAP
   Data Channel.

2.  Split CAPWAP-CTL and CAPWAP-DATA Establishment

   This section describes the session establishment process for split
   CAPWAP Control Channel and CAPWAP Data Channel, called CAPWAP Split
   Mode.  In this architecture, the CAPWAP protocol should be concerned
   with not only the interface between the WTP and the AC, but also the
   interface between the WTP and the AR.

   Using existing CAPWAP procedure [RFC5415] as the basis, additional
   phases are needed, and these are specified in following sub sections.

2.1.  AR Discovery

   In CAPWAP Split Mode, AR discovery should be the Preliminary phase
   for CAPWAP Data Channel procedures.  The WTPs MUST obtain the AR
   information, such as IP address which are used to establish the
   CAPWAP Data Channel.  

   It is possible for the AR information to be configured manually on
   the WTP. However, it is difficult to operate when there are large
   numbers of WTPs in the network.  An auto-configuration method is
   required to enable AR discovery in larger networks.  Several dynamic
   methods such as DHCP or DNS could be used, but this document does not
   discuss these methods in detail. It is also possible for AR Discovery
   to be completed in the process of CAPWAP Control Channel procedures
   defined in [RFC5415].

 

Xue, et al.             Expires January 11, 2014                [Page 4]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   A common deployment is for the AC and AR to be in a  centralized
   location in the operators network.  In all cases, the AC can default
   to acquiring AR information in the network via manual configuration. 
   After the Discovery Response messages received[RFC5415], a WTP can
   select an AC with which to establish a secure DTLS session for CAPWAP
   Control Channel.  Then AC configures the WTP with AR address
   appropriately via Configuration Status Response.  When a WTP receives
   the Configuration Status Response message carrying AR address, it
   checks and restores the AR address for CAPWAP Data Channel.

   In order to support AR discovery on a WTP, a new CAPWAP message
   element, the AR Information Element is defined in section 3.

   Additionally, the AR discovery process may also support load-sharing
   and recovery from a single AR point of failure.

2.2.  Split Mode Capability Announcement

   In order to support CAPWAP Split Mode, the split mode capability MUST
   be announced with agreement between a WTP and AC.  Otherwise, the
   CAPWAP Data messages will be sent to the AC instead of the AR, which
   is not the expected outcome in split mode.

   The CAPWAP Split Capability announcement can be achieved during Join
   Operations [RFC5415] between a WTP and AC.  A new CAPWAP message
   element, the CAPWAP Mode Element is included in the Join Request
   message and Join Response message between WTP and AC in order to
   negotiate about the CAPWAP Mode.  The element format is defined in
   Section 3.

   Besides, the decision about the CAPWAP mode between a WTP and AC can
   be made based on operator requirements.  For example, if the CAPWAP
   Mode Element is included in either Join Request message or Join
   Response message, or both are set to Split Mode value, CAPWAP will
   operate in Split mode.  Alternatively, the agreement that is
   consistent with the value of CAPWAP Mode element carried in Join
   Request messages send by WTP may be acceptable. This document does
   not prescribe a single method to arrive at an agreement about the
   CAPWAP mode. 

3.  CAPWAP Message Elements for Split Mode

   As mentioned in earlier sections, two new CAPWAP message elements are
   defined in this section for CAPWAP Split Mode.

   The AR Information Element is used by the AC to configure the AR
 

Xue, et al.             Expires January 11, 2014                [Page 5]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   information to WTP.  The format is as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Type                 |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
   .                     AR Information                            .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          AR Information Element

   Type: TBD

   Length: >=8

   AR Information: The IP address of AR served for WTP in the network.
   In order to support load-sharing and recovery from a single AR point
   of failure.  The AR information can be formatted via TLV for sub-
   elements, the sub-element format is:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Type                 |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
    | Prefer|              AR Address                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       .
    +-+-+-+-+

                  Load-sharing AR Information sub-element

   Type: 1

   Length; >= 9

   AR Address: the IP address of AR served for WTP in the network.

   The CAPWAP Mode element that is used for the split mode capability
   MUST be announced with agreement between a WTP and AC.  The format is
   shown as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 

Xue, et al.             Expires January 11, 2014                [Page 6]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   |          Type                 |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
   |         CAPWAP Mode           |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            CAPWAP Mode Element

   Type: TBD

   Length: 8

   CAPWAP Mode: If the value is 0, the CAPWAP operates in converged mode
   defined in [RFC5415].  If the value is 1, the CAPWAP mode is split
   mode, defined in this document.

   Reserved: It can be used by operators to define the rule for making
   CAPWAP mode decision.

4.  IANA Considerations

   This document defines two CAPWAP elements used in CAPWAP Split Mode.
   IANA is requested to allocate the following type.

   o  The type for AR Information Element

   o  The type for CAPWAP Mode Element

5.  Security Considerations

   This document does not constrain the use of encryption mechanisms to
   protect the data channel.  If there are security requirements for
   CAPWAP Data Channel, Datagram Transport Layer Security (DTLS)
   [RFC4347] and the IPSec mechanism [RFC2401] can be used to guarantee
   the security of the CAPWAP Data Channel.

   If DTLS is used for CAPWAP Data Channel in CAPWAP Split Mode, the
   DTLS procedure is required between a WTP and AR.

6.  References

 

Xue, et al.             Expires January 11, 2014                [Page 7]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5415]  Calhoun, P., Montemurro, M., and D. Stanley, "Control And
              Provisioning of Wireless Access Points (CAPWAP) Protocol
              Specification", RFC 5415, March 2009.

   [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.

6.2.  Informative References

   [I-D.cao-capwap-eap]
              Zhang, R., Cao, Z., and H. Luo, "Encapsulation of EAP
              Messages in CAPWAP Control Plane", draft-cao-capwap-eap-00
              (work in progress), October 2012.

Authors' Addresses

   Li Xue
   Huawei
   No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 
   HaiDian District
   Beijing  100095
   China

   Email: xueli@huawei.com

   Zongpeng Du
   Huawei
   No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, 
   HaiDian District
   Beijing  100095
   China

   Email: duzongpeng@huawei.com

 

Xue, et al.             Expires January 11, 2014                [Page 8]
Internet-Draft    CAPWAP-CTL and CAPWAP-DATA Separatio     July 10, 2013

   Dapeng Liu
   China Mobile
   Unit 2, 28 Xuanwumenxi Ave, Xuanwu District
   Beijing  100053
   China

   Email: liudapeng@chinamobile.com

   Rong Zhang
   China Telecom
   No. 109 Zhongshandadao avenue
   Guangzhou  510630
   China

   Email: zhangr@gsta.com

   John Kaippallimalil
   Huawei
   5430 Legacy Drive, Suite 175
   Plano TX 75024

   Email: john.kaippallimalil@huawei.com

Xue, et al.             Expires January 11, 2014                [Page 9]