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]