One document matched: draft-you-opsawg-capwap-separation-for-mp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:05:58 |