Internet DRAFT - draft-you-opsawg-capwap-separation-for-mp
draft-you-opsawg-capwap-separation-for-mp
Opsawg Working Group J. You
Internet-Draft H. Song
Intended status: Standards Track Huawei
Expires: November 26, 2015 R. Zhang
China Telecom
May 25, 2015
CAPWAP Control and Data Channel Separation for Multi-provider Scenario
draft-you-opsawg-capwap-separation-for-mp-01
Abstract
The CAPWAP control channel and data channel split architecture has
some benefits, such as relieving the capacity pressure of the AC.
However, the current documents are not specific to the multi-provider
scenario. This document discusses the third-party WLAN service
provider scenario (i.e. Virtual Network Operator, VNO), 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 November 26, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
You, et al. Expires November 26, 2015 [Page 1]
Internet-Draft capwap separation for mp May 2015
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. IEEE 802.11 WTP Alternate Tunnel Failure Indication . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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] etc.
In this document, we introduce a third-party WLAN service provider
scenario (i.e. VNO), as shown in Figure 1, and also verify the
benefits of having this split architecture. In this scenario, the
WLAN provider owns the WTP and AC resources. Other VNOs 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 VNOs 1/2 don't have their own network access resources,
they rent the WTP resources from the WLAN provider. VNO 1/2 provide
the services to their customers by renting the network access
resources. The users of VNO 1/2 are authenticated by VNO 1/2
themselves respectively. As the WLAN service provider isn't aware of
the users' data traffic of VNO 1/2, 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.
You, et al. Expires November 26, 2015 [Page 2]
Internet-Draft capwap separation for mp May 2015
+----+
| AC |
+--+-+
CAPWAP-CTL |
+-----------------+
| CAPWAP-DATA: IEEE 802.11 Mgmt traffic
|
WLAN Provider| VNO 1
+-----+ CAPWAP-DATA (SSID1) +---------------+
SSID1 | WTP +--------------------------|Access Router 1|
SSID2 +--+-++ +---------------+
| |
| | VNO 1
| | GRE-IPv4-DATA (SSID1) +---------------+
| +---------------------------|Access Router 2|
| +---------------+
|
| VNO 2
| CAPWAP-DATA (SSID2) +---------------+
+-----------------------------|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 use case.
[I-D.ietf-opsawg-capwap-alt-tunnel] describes CAPWAP Control Channel
and CAPWAP Data Channel separation (i.e. CAPWAP Split Mode), but it
is not specific to multi-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).
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.
You, et al. Expires November 26, 2015 [Page 3]
Internet-Draft capwap separation for mp May 2015
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 providers with different SSIDs. For example, in Figure 1,
SSID1 is advertised by the WTP for VNO1; and SSID2 is advertised by
the WTP for VNO2. Give that a user attaches to the network by SSID1,
the WTP needs to send the user's data traffic to AR1/AR2 of VNO1 via
CAPWAP/GRE-IPv4 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.
For the above example (Figure 1), the following steps describe how
the alternate tunnels are established using the alternate tunnel
encapsulation message element [I-D.ietf-opsawg-capwap-alt-tunnel].
1. The AC provides an alternate tunnel encapsulation message
element containing the tunnel type and a tunnel-specific
information element, as shown in Figure 2. Specifically,
IEEE 802.11 WLAN Config. Request [IEEE 802.11 Add WLAN (WLAN ID 1
(mapping to SSID1)), Alternate Tunnel Encapsulation (Tunnel
Type=CAPWAP, Tunnel Info Element (AR1))];
The WTP sets up the alternate tunnel with AR1.
2. The AC provides an alternate tunnel encapsulation message
element containing the tunnel type and a tunnel-specific
information element, as shown in Figure 2. Specifically,
You, et al. Expires November 26, 2015 [Page 4]
Internet-Draft capwap separation for mp May 2015
IEEE 802.11 WLAN Config. Request [IEEE 802.11 Add WLAN (WLAN ID 1
(mapping to SSID1)), Alternate Tunnel Encapsulation (Tunnel Type=
GRE-IPv4, Tunnel Info Element (AR2))];
The WTP sets up the alternate tunnel with AR2. Multiple ARs may
be provided for load balancing for VNO1.
3. The AC provides an alternate tunnel encapsulation message
element containing the tunnel type and a tunnel-specific
information element, as shown in Figure 2. Specifically,
IEEE 802.11 WLAN Config. Request [IEEE 802.11 Add WLAN (WLAN ID 2
(mapping to SSID2)), Alternate Tunnel Encapsulation (Tunnel Type=
CAPWAP, Tunnel Info Element (AR3))];
The WTP sets up the alternate tunnel with AR3.
4. When the WTP detects an alternate tunnel failure, the WTP
informs the AC using a message element, WTP Alternate Tunnel Fail
Indication defined in [I-D.ietf-opsawg-capwap-alt-tunnel]. The
WTP needs to notify the AC of which AR(s) are unavailable.
You, et al. Expires November 26, 2015 [Page 5]
Internet-Draft capwap separation for mp May 2015
+-----------+ +-----------+
| WTP | | AC |
+-----+-----+ +-----+-----+
+---------------------------------------------------------+
|Alternative | | |
Step 1, |Tunnel |IEEE 802.11 WLAN Config. Request [ | |
Step 2, |Establishment| IEEE 802.11 Add WLAN, | |
Step 3 | | Alternate Tunnel Encapsulation ( | |
| | Tunnel Type, Tunnel Info Element) | |
| | ] | |
| |<----------------------------------------| |
| | | |
| | | |
| +-----+-----+ | |
| | Setup | | |
| | Alternate | | |
| | Tunnel | | |
| +-----+-----+ | |
| | | |
| |IEEE 802.11 WLAN Config. Response | |
| |---------------------------------------->| |
+---------------------------------------------------------+
| |
+-----+-----+ |
| Tunnel | |
| Failure | |
+-----+-----+ |
|WTP Alternate Tunnel Failure Indication |
Step 4 |[(report failure (AR Address(es)))] |
|---------------------------------------->|
| |
+------+------+ |
| Tunnel | |
| Established | |
+------+------+ |
|WTP Alternate Tunnel Failure Indication |
|(report clearing failure) |
|---------------------------------------->|
| |
Figure 2: Setup of Alternate Tunnels
4. IEEE 802.11 WTP Alternate Tunnel Failure Indication
When the WTP detects an alternate tunnel failure, the WTP informs the
AC using a message element, WTP Alternate Tunnel Fail Indication
defined in [I-D.ietf-opsawg-capwap-alt-tunnel]. For the case where
WTP establishes data tunnels with multiple ARs under VNO scenarios,
You, et al. Expires November 26, 2015 [Page 6]
Internet-Draft capwap separation for mp May 2015
the WTP needs to notify the AC of which AR(s) are unavailable, as
shown in Figure 2.
The Alternate Tunnel Failure Indication message element is extended
to contain the AR information, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Sub-Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IEEE 802.11 WTP Alternate Tunnel Failure Indication
Type: IEEE 802.11 WTP Alternate Tunnel Failure Indication defined
in [I-D.ietf-opsawg-capwap-alt-tunnel].
Length: > 4
Radio ID: The Radio Identifier, whose value is between one (1) and
31, typically refers to some interface index on the WTP.
WLAN ID: An 8-bit value specifying the WLAN Identifier. The value
MUST be between one (1) and 16.
Status: An 8-bit boolean indicating whether the radio failure is
being reported or cleared. A value of zero is used to clear the
event, while a value of one is used to report the event.
Access Router Information Sub-Element
[I-D.ietf-opsawg-capwap-alt-tunnel]: IPv4 address or IPv6 address
or Fully Qualified Domain Name (FQDN), of the Access Router for
the alternate tunnel. The Access Router Information Sub-Elements
allow the WTP to notify the AC of which AR(s) are unavailable.
5. IANA Considerations
This document has no IANA actions.
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 November 26, 2015 [Page 7]
Internet-Draft capwap separation for mp May 2015
7. Acknowledgement
The authors would like to thank Zongpeng Du and Jin Li for their
valuable comments.
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-05
(work in progress), April 2015.
Authors' Addresses
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing 210012
China
Email: youjianjie@huawei.com
You, et al. Expires November 26, 2015 [Page 8]
Internet-Draft capwap separation for mp May 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 November 26, 2015 [Page 9]
