Alternate Tunnel Encapsulation for Data Frames in CAPWAP
draft-zhang-opsawg-capwap-cds-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Rong Zhang , Zehn Cao , DENG Hui , Rajesh Pazhyannur , Sri Gundavelli | ||
| Last updated | 2013-10-21 | ||
| Replaced by | draft-ietf-opsawg-capwap-alt-tunnel, draft-ietf-opsawg-capwap-alt-tunnel | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zhang-opsawg-capwap-cds-01
Network Working Group R. Zhang
Internet-Draft China Telecom
Intended status: Standards Track Z. Cao
Expires: April 25, 2014 H. Deng
China Mobile
R. Pazhyannur
S. Gundavelli
Cisco
October 22, 2013
Alternate Tunnel Encapsulation for Data Frames in CAPWAP
draft-zhang-opsawg-capwap-cds-01
Abstract
CAPWAP ([RFC5416]) defines two tunneling modes for encapsulating data
frames from stations associated with WLAN: 802.3 Tunnel and 802.11
Tunnel modes. This document provides for an alternate tunnel
encapsulation. The alternate tunnel encapsulation allows 1) the WTP
to tunnel non-management data frames to an endpoint different from
the AC and 2) allows the WTP to tunnel using one of many known
encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may
advertise support for Alternate Tunnel encapsulation during the
discovery process and AC may select one of the supported Alternate
Tunnel encapsulate types during the WTP configuration. Further, the
AC may configure WTP to enable the alternate tunnel encapsulation.
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 April 25, 2014.
Copyright Notice
Zhang, et al. Expires April 25, 2014 [Page 1]
Internet-Draft Alternate Tunnel October 2013
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
1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Alternate Tunnel Encapsulation . . . . . . . . . . . . . . . 5
2.1. Supported Alternate Tunnel Encpsulation . . . . . . . . . 5
2.2. Alternate Tunnel Encapsulation . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
CAPWAP ([RFC5415], [RFC5416]) defines a tunnel mode that specifies
the frame tunneling type to be used for 802.11 data frames from all
stations associated with the WLAN. The following types are
supported:
o Local Bridging: All user traffic is to be locally bridged.
o 802.3 Tunnel: All user traffic is to be tunneled to the AC in
802.3 format.
o 802.11 Tunnel: All user traffic is to be tunneled to the AC in
802.11 format.
There are two shortcomings with currently specified tunneled modes:
1) it does not allow the WTP to tunnel data frames to an endpoint
different from the AC and 2) it does not allow the WTP to tunnel data
frames using any encapsulation other than CAPWAP (as specified in
Section 4.4.2 of [RFC5415]). Next, we describe what is driving the
above mentioned two requirements.
Zhang, et al. Expires April 25, 2014 [Page 2]
Internet-Draft Alternate Tunnel October 2013
Some operators deploying large number of Access Points prefer to
centralize the management and control of Access Points (AP) while
distributing the handling of data traffic to increase scaling. This
motivates an architecture as shown in Figure 1 that has the Access
Controller in a centralized location and one or more tunnel gateways
(or Access Routers) that terminate the data tunnels from the various
WTPs. central data center. This split architecture has two benefits
over an architecture where data traffic is aggregated at the AC: 1)
reduces the scale requriement on data traffic handling capability of
the AR and 2) leads to more efficient/optimal routing of data
traffic.
+-----+ DATA +----------------+
| WTP |==========| Access Router |
+-----+ +----------------+
\\
\\ CTL(CAPWAP) +--------+
++======================+ AC |
// +--------+
//
+-----+// DATA +----------------+
| WTP |===========| Access Router |
+=====+ +----------------+
Figure 1: Centralized Control with Distributed Data
The above system (shown in Figure 1) could be achieved by setting the
tunnel mode to Local bridging. In such a case the AC would handle
control of WTPs as well as handle the management traffic to/from the
stations. The data frames (non-management) from the stations would
be handled by the local Access Router. However, in many deployments
the operator managing the WTPs/AC may be different from the operator
providing the internet connectivity to the WTPs. Further, the WTP
operator may want (or be required by legal/regulatory requirements)
to tunnel the traffic back to an Access Router in its network as
shown in Figure 2. The tunneling requirement may be driven by the
need to apply policy at the Access Router or a legal requirement to
support lawful intercept of user traffic. This motivates the need
for the WTP to support an alternate Tunnel encapsulation support
where the data tunnels from the WTP are terminated at an AR (and more
specifically at an end point different from the AC).
_________
+-----+ ( ) +----------------+
| WTP |======+Internet +==============| Access Router |
+-----+ (_________} +----------------+
Zhang, et al. Expires April 25, 2014 [Page 3]
Internet-Draft Alternate Tunnel October 2013
\\ ________
\\ ( ) CAPWAP(CNTL) +--------+
++==Internet+===============| AC |
// ( ) +--------+
// ________
+-----+// ( ) +----------------+
| WTP |====+Internet +================| Access Router |
+=====+ (_________} +----------------+
Figure 2: Centralized Control with Distributed Data
In the case where the WTP is tunneling data frames to an AR (and not
the AC), the choice of tunnel encapsulation need not be restricted
only to CAPWAP (as described in Section 4.4.2 of [RFC5415]). In
fact, the WTP may additionally support other widely used
encapsulation types such as L2TP, L2TPv3, IP-in-IP, IP/GRE, etc. The
WTP may advertise the different alterante tunnel encapsulation types
supported and the AC can select one of the supported encapsulation
types.
1.1. Conventions used in this document
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]
1.2. Terminology
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 Point (AP): the same with 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.
CAPWAP Control Plane: A bi-directional flow over which CAPWAP Control
packets are sent and received.
CAPWAP Data Plane: A bi-directional flow over which CAPWAP Data
frames are sent and received.
EAP: Extensible Authentication Protocol, the EAP framework is
specified in [RFC3748].
Zhang, et al. Expires April 25, 2014 [Page 4]
Internet-Draft Alternate Tunnel October 2013
2. Alternate Tunnel Encapsulation
2.1. Supported Alternate Tunnel Encpsulation
The IEEE 802.11 Supported Alternate Tunnel Encapsulations message
element allow the WTP to communicate the supported tunnels. The
Discovery Request message, Primary Discovery Request message, and
Join Request message may include one such message element
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
+=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Num_Tunnels | Tunnel_1 | Tunnel_[2..N]..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: IEEE 802.11 Supported Tunnels Encapsulations
o Type: TBD for IEEE 802.11 Supported MAC Profiles
o Num_Tunnels >=1: This refers to number of profiles presnt in this
messaage element. There must be at least one profile.
o Tunnel: Each Tunnel is idnentified by a value given in Section 2.2
2.2. Alternate Tunnel Encapsulation
The IEEE 802.11 Alternate Tunnel Encapsulation message element allows
the AC to select the profile. This messsage element may be provided
along with the IEEE 802.11 ADD WLAN message element while configuring
a WLAN on the WTP.
0 1 2 3 4 5 6 7
+=+-+-+-+-+-+-+-+
| Tunnel Encap |
| Type |
+-+-+-+-+-+-+-+-+
Figure 4: IEEE 802.11 MAC Profile
o Type: TBD for IEEE 802.11 MAC Profile
o Tunnel Encap Type: The profile is idnentified by a value as given
below
* 0: CAPWAP data channel as described in [RFC5415][RFC5416]
* 1: L2TP
* 2: L2TPv3
* 3: IP-in-IP
* 4: IP/GRE
Zhang, et al. Expires April 25, 2014 [Page 5]
Internet-Draft Alternate Tunnel October 2013
3. IANA Considerations
To be specified.
4. Security Considerations
Security considerations for the CAPWAP protocol has been analyzed in
Section 12 of [RFC5415]. This document does not introduce other
security issues besides what has been analyzed in RFC5415.
5. Contributors
This document stems from the joint work of Hong Liu, Yifan Chen,
Chunju Shao from China Mobile Research. Thank all the contributors
of this document.
6. References
6.1. Normative References
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And
Provisioning of Wireless Access Points (CAPWAP) Protocol
Specification", RFC 5415, March 2009.
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
"Objectives for Control and Provisioning of Wireless
Access Points (CAPWAP)", RFC 4564, July 2006.
[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.
[RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access
Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
March 2009.
Zhang, et al. Expires April 25, 2014 [Page 6]
Internet-Draft Alternate Tunnel October 2013
Authors' Addresses
Rong Zhang
China Telecom
No.109 Zhongshandadao avenue
Guangzhou 510630
China
Email: zhangr@gsta.com
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing 100871
China
Phone: +86-10-52686688
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Hui Deng
China Mobile
No.32 Xuanwumen West Street
Beijing 100053
China
Email: denghui@chinamobile.com
Rajesh S. Pazhyannur
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: rpazhyan@cisco.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Zhang, et al. Expires April 25, 2014 [Page 7]