CAPWAP Control and Data Channel Separation for Multi-provider Scenario
draft-you-opsawg-capwap-separation-for-mp-00

Opsawg Working Group                                              J. You
Internet-Draft                                                   H. Song
Intended status: Standards Track                                  Huawei
Expires: August 29, 2015                                        R. Zhang
                                                           China Telecom
                                                       February 25, 2015

 CAPWAP Control and Data Channel Separation for Multi-provider Scenario
              draft-you-opsawg-capwap-separation-for-mp-00

Abstract

   The CAPWAP control channel and data channel split architecture has
   some benefits, such as relieving the capacity pressure of the AC,
   which has been discussed in [I-D.ietf-opsawg-capwap-alt-tunnel] and
   [I-D.xue-opsawg-capwap-separation-capability].  However, only single-
   provider scenario is considered so far.  This document discusses the
   third-party WLAN service provider scenario (i.e.  multi-provider),
   and proposes to extend CAPWAP for supporting this use case.

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
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2015.

You, et al.              Expires August 29, 2015                [Page 1]
Internet-Draft          capwap separation for mp           February 2015

Copyright Notice

   Copyright (c) 2015 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Split CAPWAP-CTL and CAPWAP-DATA for Multi-provider . . . . .   4
   4.  CAPWAP AR-and-SSID Association Element  . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The CAPWAP control channel and data channel split architecture has
   some benefits, such as relieving the capacity pressure of the AC,
   which has been discussed in [I-D.ietf-opsawg-capwap-alt-tunnel] and
   [I-D.xue-opsawg-capwap-separation-capability].

   In this document, we introduce a third-party WLAN service provider
   scenario, as shown in Figure 1, also verifies the benefits of having
   this split architecture.  In this scenario, the WLAN provider owns
   the WTP and AC resources.  Other service providers can rent the WTP
   resources from the WLAN provider for network access.  The AC
   belonging to the WLAN service provider controls the WTP in a
   centralized location.

   Given that three other service providers (provider 1, 2 and 3) don't
   have their own network access resources, they rent the WTP resources
   from the WLAN provider.  Provider 1/2/3 provide the services to their
   users by renting the network access resources.  The users of the

You, et al.              Expires August 29, 2015                [Page 2]
Internet-Draft          capwap separation for mp           February 2015

   provider 1/2/3 are authenticated by provider 1/2/3 themselves.  As
   the WLAN service provider isn't aware of the users' data traffic of
   provider 1/2/3, the data traffic from the users can be directly
   routed to the corresponding Access Router (AR) of the provider who
   owns the users.  The data traffic directly to the AR can
   significantly avoid overload on the AC.

                                     +----+
                                     | AC |
                                     +--+-+
                          CAPWAP-CTL    |
                      +-----------------+
         WLAN Provider|                            Provider 1
                +-----+   CAPWAP-DATA            +---------------+
                | WTP +--------------------------|Access Router 1|
                +--+-++                          +---------------+
                   | |
                   | |                             Provider 2
                   | |    CAPWAP-DATA            +---------------+
                   | +---------------------------|Access Router 2|
                   |                             +---------------+
                   |
                   |                               Provider 3
                   |      CAPWAP-DATA            +---------------+
                   +-----------------------------|Access Router 3|
                                                 +---------------+

        Figure 1: Third-party WLAN Service Provider

   This document discusses the third-party WLAN service provider
   scenario, and proposes to extend CAPWAP for supporting this case.
   [I-D.xue-opsawg-capwap-separation-capability] describes CAPWAP
   Control Channel and CAPWAP Data Channel separation (i.e.  CAPWAP
   Split Mode), but it only considers single-provider scenario.  The
   following section will discuss the extension in order to support
   multi-provider scenario.

2.  Terminology

   This section contains definitions for terms used frequently
   throughout this document.  However, many additional definitions can
   be found in [RFC5415] and [RFC5416].

      Station (STA): A device that contains an IEEE 802.11 conformant
      medium access control (MAC) and physical layer (PHY) interface to
      the wireless medium (WM).

You, et al.              Expires August 29, 2015                [Page 3]
Internet-Draft          capwap separation for mp           February 2015

      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.

      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 Router (AR): The access server of the provider.

      CAPWAP Control Channel: A bi-directional flow defined by the AC IP
      Address, WTP IP Address, AC control port, WTP control port, and
      the transport-layer protocol (UDP or UDP-Lite) over which CAPWAP
      Control packets are sent and received.

      CAPWAP Data Channel: A bi-directional flow defined by the AC IP
      Address, WTP IP Address, AC data port, WTP data port, and the
      transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data
      packets are sent and received.

3.  Split CAPWAP-CTL and CAPWAP-DATA for Multi-provider

   A WTP is capable of supporting up to 16 Service Set Identifiers
   (SSIDs).  The WLAN provider may provide network access service for
   different provider with different SSID.  For example, for provider 1,
   its corresponding SSID is SSID1.  Give that a user attaches to the
   network by SSID1, the WTP needs to send the user's data traffic to
   AR1 of provider 1 via CAPWAP data channel.  So WTP needs to obtain
   the AR addresses of different providers first.  The AC of the WLAN
   service provider needs to maintain the association of the AR
   addresses of the tenant providers and SSIDs, and provide this
   information to the WTP.  A CAPWAP AR-and-SSID association element is
   proposed to describe this information, that will be discussed in the
   following section.

4.  CAPWAP AR-and-SSID Association Element

   A new CAPWAP message element (as shown in Figure 2) is defined in
   this section for CAPWAP control channel and data channel split
   architecture in order to support multi-provider scenario.  The AC
   maintains an AR-and-SSID association table, and provides the AR-and-
   SSID association element the WTP.

You, et al.              Expires August 29, 2015                [Page 4]
Internet-Draft          capwap separation for mp           February 2015

      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                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   SSID 1                                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   AR Address 1                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   SSID 2                                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   AR Address 2                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   ......                                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: AR-and-SSID Association Element

      Type: The Type field is two octets, and identifies the type of
      CAPWAP packet element.  The value of the Type is TBD.

      Length: The Length field is two octets.  It indicates the length
      of the packet including the Type, Length, SSID and AR address
      fields.  The minimum length is 16.

      SSID: The SSID attribute is the service set identifier that will
      be advertised by the WTP for this WLAN.  The SSID field contains
      any ASCII character and MUST NOT exceed 32 octets in length, as
      defined in [IEEE.802-11.2007].

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

5.  IANA Considerations

   This document defines one CAPWAP element.  IANA is requested to
   allocate the type value of AR-and-SSID association element.

6.  Security considerations

   This document does not constrain the use of encryption mechanisms to
   protect the data channel.  If there is security requirement 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.

You, et al.              Expires August 29, 2015                [Page 5]
Internet-Draft          capwap separation for mp           February 2015

7.  Acknowledgement

8.  References

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

8.2.  Informative References

   [I-D.ietf-opsawg-capwap-alt-tunnel]
              Zhang, R., Cao, Z., Deng, H., Pazhyannur, R., Gundavelli,
              S., and L. Xue, "Alternate Tunnel Encapsulation for Data
              Frames in CAPWAP", draft-ietf-opsawg-capwap-alt-tunnel-04
              (work in progress), November 2014.

   [I-D.xue-opsawg-capwap-separation-capability]
              Xue, L., Du, Z., Liu, D., Zhang, R., and J.
              Kaippallimalil, "Capability Announcement and AR Discovery
              in CAPWAP Control and Data Channel Separation", draft-xue-
              opsawg-capwap-separation-capability-01 (work in progress),
              October 2013.

Authors' Addresses

   Jianjie You
   Huawei
   101 Software Avenue, Yuhuatai District
   Nanjing  210012
   China

   Email: youjianjie@huawei.com

You, et al.              Expires August 29, 2015                [Page 6]
Internet-Draft          capwap separation for mp           February 2015

   Haibin Song
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: haibin.song@huawei.com

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

   Email: zhangr@gsta.com

You, et al.              Expires August 29, 2015                [Page 7]