One document matched: draft-ietf-opsawg-capwap-alt-tunnel-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2003 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2003.xml">
<!ENTITY rfc2661 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2661.xml">
<!ENTITY rfc2784 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2784.xml">
<!ENTITY rfc3828 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY rfc3931 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY rfc4564 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4564.xml">
<!ENTITY rfc5213 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!ENTITY rfc5415 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5415.xml">
<!ENTITY rfc5416 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5416.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="std" docName="draft-ietf-opsawg-capwap-alt-tunnel-06"
ipr="trust200902">
<front>
<title abbrev="Alternate Tunnel">Alternate Tunnel Encapsulation for Data
Frames in CAPWAP</title>
<author fullname="Rong Zhang" initials="R.Z" surname="Zhang">
<organization>China Telecom</organization>
<address>
<postal>
<street>No.109 Zhongshandadao avenue</street>
<city>Guangzhou</city>
<region></region>
<code>510630</code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>zhangr@gsta.com</email>
<uri></uri>
</address>
</author>
<author fullname="Zhen Cao" initials="Z.C" surname="Cao">
<organization>China Mobile</organization>
<address>
<postal>
<street>Xuanwumenxi Ave. No. 32</street>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city>
<region></region>
<code>100871</code>
<country>China</country>
</postal>
<phone>+86-10-52686688</phone>
<email>zhen.cao@gmail.com, caozhen@chinamobile.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Hui Deng" initials="H." surname="Deng">
<organization>China Mobile</organization>
<address>
<postal>
<street>No.32 Xuanwumen West Street</street>
<city>Beijing 100053</city>
<country>China</country>
</postal>
<email>denghui@chinamobile.com</email>
</address>
</author>
<author fullname="Rajesh S. Pazhyannur" initials="R.P"
surname="Pazhyannur">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose, CA 95134</city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>rpazhyan@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Sri Gundavelli" initials="S.G" surname="Gundavelli">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose, CA 95134</city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>sgundave@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Li Xue" initials="L.X" surname="Xue">
<organization>Huawei</organization>
<address>
<postal>
<street>No.156 Beiqing Rd. Z-park, HaiDian District</street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>xueli@huawei.com</email>
<uri></uri>
</address>
</author>
<author fullname="Jianjie You" initials="J." surname="You">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhuatai District</street>
<city>Nanjing,</city>
<code>210012</code>
<country>China</country>
</postal>
<email>youjianjie@huawei.com</email>
</address>
</author>
<date year="2015" />
<area>Ops Area</area>
<workgroup>Opsawg Working Group</workgroup>
<abstract>
<t>Control And Provisioning of Wireless Access Points (CAPWAP) defines a
specification to encapsulate a station's data frames between the
Wireless Transmission Point (WTP) and Access Controller (AC).
Specifically, the station's IEEE 802.11 data frames can be either
locally bridged or tunneled to the AC. When tunneled, a CAPWAP data
channel is used for tunneling. In many deployments encapsulating data
frames to an entity other than the AC (for example to an Access Router
(AR)) is desirable. Further, it may also be desirable to use different
tunnel encapsulations to carry the stations' data frames. This document
provides a specification for this and refers to it as 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) 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 or join process and
AC may select one of the supported alternate tunnel encapsulation types
while configuring the WTP.</t>
</abstract>
</front>
<middle>
<section title="Introduction ">
<t>Service Providers are deploying very large Wi-Fi deployments (ranging
from hundreds of thousands of Access Points, APs (referred to as WTPs in
CAPWAP terminology) to millions of APs. These networks are designed to
carry traffic generated from mobile users. The volume in mobile user
traffic is already very large and expected to continue growing rapidly.
As a result, operators are looking for scalable solutions that can meet
the increasing demand. The scalability requirement can be met by
splitting the control/management plane from the data plane. This enables
the data plane to scale independent of the control/management plane.
This specification provides a way to enable such separation.</t>
<t>CAPWAP (<xref target="RFC5415"></xref>, <xref
target="RFC5416"></xref>) defines a tunnel mode that describes how the
WTP handles the data plane (user traffic). The following types are
defined: <list style="symbols">
<t>Local Bridging: All data frames are locally bridged.</t>
<t>802.3 Tunnel: All data frames are tunneled to the AC in 802.3
format.</t>
<t>802.11 Tunnel: All data frames are tunneled to the AC in 802.11
format.</t>
</list></t>
<t><xref target="Fig.scenario"></xref> describes a system with Local
Bridging. The AC is in a centralized location. The data plane is locally
bridged by the WTPs leading to a system with centralized control plane
with distributed data plane. This system has two benefits: 1) reduces
the scale requirement on data traffic handling capability of the AC and
2) leads to more efficient/optimal routing of data traffic while
maintaining centralized control/management.</t>
<figure anchor="Fig.scenario"
title="Centralized Control with Distributed Data ">
<artwork align="center">
Locally Bridged
+-----+ Data Frames +----------------+
| WTP |===============| Access Router |
+-----+ +----------------+
\\
\\ CAPWAP Control Channel +----------+
++=========================| AC |
// CAPWAP Data Channel: | |
// IEEE 802.11 Mgmt traffic +----------+
//
+-----+ +----------------+
| WTP |============== | Access Router |
+=====+ +----------------+
Locally Bridged
Data Frames
</artwork>
</figure>
<t>The AC handles control of WTPs. In addition, the AC also handles the
IEEE 802.11 management traffic to/ from the stations. There is CAPWAP
Control and Data Channel between the WTP and the AC. Note that even
though there is no user traffic transported between the WTP and AC,
there is still a CAPWAP Data Channel. The CAPWAP Data channel carries
the IEEE 802.11 management traffic (like IEEE 802.11 Action Frames).</t>
<t><xref target="Centralized-data.scenario"></xref> shows a system where
the tunnel mode is configured to tunnel data frames between the WTP and
the AC either using 802.3 Tunnel or 802.11 Tunnel configurations.
Operators deploy this configuration when they need to tunnel the user
traffic. 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 requirement could be met in the locally
bridged system (<xref target="Fig.scenario"></xref>) if the access
router implemented the required policy. However, in many deployments the
operator managing the WTP is different than the operator managing the
Access Router. When the operators are different, the policy has to be
enforced in a tunnel termination point in the WTP operator's network.
<figure anchor="Centralized-data.scenario"
title="Centralized Control and Centralized Data ">
<artwork align="center">
+-----+
| WTP |
+-----+
\\
\\ CAPWAP Control Channel +----------+
++=========================| AC |
// CAPWAP Data Channel: | |
// IEEE 802.11 Mgmt traffic | |
// Data Frames +----------+
//
+-----+
| WTP |
+=====+
</artwork>
</figure> The key difference with the locally bridged system is that
the data frames are tunneled to the AC instead of being locally bridged.
There are two shortcomings with system in <xref
target="Centralized-data.scenario"></xref>. 1) They do not allow the WTP
to tunnel data frames to an endpoint different from the AC and 2) They
do not allow the WTP to tunnel data frames using any encapsulation other
than CAPWAP (as specified in Section 4.4.2 of <xref
target="RFC5415"></xref>).</t>
<t><xref target="Fig.scenario2"></xref> shows a system where the WTP
tunnels data frames to an alternate entity different from the AC. The
WTP also uses an alternate tunnel encapsulation such as such as L2TP,
L2TPv3, IP-in-IP, IP/GRE, etc. This enables 1) independent scaling of
data plane and 2) leveraging of commonly used tunnel encapsulations such
as L2TP, GRE, etc <figure anchor="Fig.scenario2"
title="Centralized Control with Alternate Tunnel for Data">
<artwork align="center">
Alternate Tunnel to AR (L2TPv3, IP-IP, CAPWAP, etc)
_________
+-----+ ( ) +-----------------+
| WTP |======+Internet +==============|Access Router(AR)|
+-----+ (_________) +-----------------+
\\ ________ CAPWAP Control
\\ ( ) Channel +--------+
++==Internet+========================| AC |
// (________)CAPWAP Data Channel: +--------+
// IEEE 802.11 Mgmt traffic
// _________
+-----+ ( ) +----------------+
| WTP |====+Internet +================| Access Router |
+=====+ (_________) +----------------+
Alternate Tunnel to AR (L2TPv3, IP-IP, CAPWAP, etc)
</artwork>
</figure></t>
<t>The WTP may support widely used encapsulation types such as L2TP,
L2TPv3, IP-in-IP, IP/GRE, etc. The WTP advertises the different
alternate tunnel encapsulation types it can support. The AC configures
one of the advertised types. As shown in the figure there is a CAPWAP
control and data channel between the WTP and AC. The CAPWAP data channel
carries the stations' management traffic as in the case of the locally
bridged system. The main reason to maintain a CAPWAP data channel is to
maintain similarity with the locally bridged system. The WTP maintains
three tunnels: CAPWAP Control, CAPWAP Data, and another alternate tunnel
for the data frame. The data frames are transported by an alternate
tunnel between the WTP and a tunnel termination point such as an Access
Router. This specification describes how the alternate tunnel can be
established. The specification defines message elements for the WTP to
advertise support for alternate tunnel encapsulation, the AC to
configure alternate tunnel encapsulation, and for the WTP to report
failure of the alternate tunnel.</t>
<t>The alternate tunnel encapsulation also supports the third-party WLAN
service provider scenario (i.e. Virtual Network Operator, VNO). Under
this scenario, the WLAN provider owns the WTP and AC resources, while
the VNOs can rent the WTP resources from the WLAN provider for network
access. The AC belonging to the WLAN service provider manages the WTPs
in the centralized mode.</t>
<t>As shown in Figure 4, VNO 1&2 don't possess the network access
resources, however they provide services by acquiring resources from the
WLAN provider. Since 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, SSID1
is advertised by the WTP for VNO1; while SSID2 is advertised by the WTP
for VNO2. Therefore the data traffic from the user can be directly
steered to the corresponding access router of the VNO who owns that
user.</t>
<figure anchor="VNO.scenario" title="Third-party WLAN Service Provider">
<artwork align="center">
+----+
| 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|
+---------------+
</artwork>
</figure>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119"></xref></t>
</section>
<section title="Terminology">
<t>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).</t>
<t>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.</t>
<t>Access Router (AR): A specialized router usually residing at the
edge or boundary of a network. This router ensures the connectivity of
its network with external networks, a wide area network or the
Internet.</t>
<t>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.</t>
<t>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.</t>
<t>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. In certain WTP modes, the CAPWAP Data
Channel only transports IEEE 802.11 management frames and not the data
plane (user traffic).</t>
</section>
</section>
<section title="Alternate Tunnel Encapsulation">
<section title="Description">
<figure anchor="fig.tunnel-neg" title="Setup of Alternate Tunnel">
<artwork>
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| WTP | | AC |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|Join Request[Supported Alternate Tunnel |
| Encapsulations ] |
|---------------------------------------->|
| |
|Join Response |
|<----------------------------------------|
| |
|IEEE 802.11 WLAN Config. Request [ |
| IEEE 802.11 Add WLAN, |
| Alternate Tunnel Encapsulation ( |
| Tunnel Type, Tunnel Info Element) |
| ] |
|<----------------------------------------|
| |
| |
+-+-+-+-+-+-+ |
| Setup | |
| Alternate | |
| Tunnel | |
+-+-+-+-+-+-+ |
| |
|IEEE 802.11 WLAN Config. Response |
|---------------------------------------->|
| |
| |
+-+-+-+-+-+-+ |
| Tunnel | |
| Failure | |
+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(report failure (AR address(es))) |
|---------------------------------------->|
| |
+-+-+-+-+-+-+-+ |
| Tunnel | |
| Established | |
+-+-+-+-+-+-+-+ |
|WTP Alternate Tunnel Failure Indication |
|(report clearing failure) |
|---------------------------------------->|
| |
</artwork>
</figure>
<t>The above example describes how the alternate tunnel encapsulation
may be established. When the WTP joins the AC, it should indicate its
alternate tunnel encapsulation capability. The AC determines whether
an alternate tunnel configuration is required. If an appropriate
alternate tunnel type is selected, then the AC provides the alternate
tunnel encapsulation message element containing the tunnel type and a
tunnel-specific information element. (The tunnel-specific information
element, for example, may contain information like the IP address of
the tunnel termination point.) The WTP sets up the alternate tunnel
using the alternate tunnel encapsulation message element.</t>
<t>On detecting a tunnel failure, WTP shall forward data frames to the
AC and discard the frames. In addition, WTP may dissociate existing
clients and refuse association requests from new clients. Depending on
the implementation and deployment scenario, the AC may choose to
reconfigure the WLAN (on the WTP) to a local bridging mode or to
tunnel frames to the AC. When the WTP detects an alternate tunnel
failure, the WTP informs the AC using a message element, WTP Alternate
Tunnel Fail Indication (defined in this specification). </t>
<t>The WTP also needs to notify the AC of which AR(s) are unavailable.
Particularly, in the VNO scenario, the AC of the WLAN service provider
needs to maintain the association of the AR addresses of the VNOs and
SSIDs, and provide this information to the WTP for the purpose of load
balancing or master-slave mode.</t>
<t>The message element has a status field that indicates whether the
message denotes reporting a failure or the clearing of the previously
reported failure.</t>
<t>For the case where AC is unreachable but the tunnel end point is
still reachable, the WTP behavior is up to the implementation. For
example, the WTP could either choose to tear down the alternate tunnel
or let the existing user's traffic continue to be tunneled.</t>
</section>
</section>
<section title="Protocol Considerations">
<section anchor="tunnel-support"
title="Supported Alternate Tunnel Encapsulations">
<t>This message element is sent by a WTP to communicate its capability
to support alternate tunnel encapsulations. The message element
contains the following fields: <figure anchor="support-encap"
title="Supported Alternate Tunnel Encapsulations">
<artwork>
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-Type 1 | Tunnel-Type [2..N]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> <list style="symbols">
<t>Type: <IANA-1> for Supported Alternate Tunnel
Encapsulations</t>
<t>Length: The length in bytes is 1 + Num_Tunnels</t>
<t>Num_Tunnels: This refers to number of tunnel types present in
the message element. At least one tunnel type must be present.</t>
<t>Tunnel-Type: This is identified by value defined in <xref
target="tunnel-config"></xref></t>
</list></t>
</section>
<section anchor="tunnel-config"
title=" Alternate Tunnel Encapsulations Type">
<t>This message element is sent by the AC. This message element allows
the AC to select the alternate tunnel encapsulation. This message
element may be provided along with the IEEE 802.11 Add WLAN message
element. When the message element is present the following fields of
the IEEE 802.11 Add WLAN element shall be set as follows: MAC mode is
set to 0 (Local MAC) and Tunnel Mode is set to 0 (Local Bridging). The
message element contains the following fields <figure anchor="format2"
title="Alternate Tunnel Encapsulations Type">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Info Element
+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> <list style="symbols">
<t>Type: <IANA-2> for Alternate Tunnel Encapsulation
Type</t>
<t>Length: > 4</t>
<t>Tunnel-Type: The tunnel type is specified by a 2 byte value.
This specification defines the values from zero (0) to five (5) as
given below. The remaining values are reserved for future use.
<list style="symbols">
<t>0: CAPWAP. This refers to a CAPWAP data channel described
in [RFC5415][RFC5416].</t>
<t>1: L2TP. This refers to tunnel encapsulation described in
<xref target="RFC2661"></xref>.</t>
<t>2: L2TPv3. This refers to tunnel encapsulation described in
<xref target="RFC3931"></xref>.</t>
<t>3: IP-in-IP. This refers to tunnel encapsulation described
in <xref target="RFC2003"></xref>.</t>
<t>4: PMIPv6. This refers to the tunneling encapsulation
described in <xref target="RFC5213"></xref></t>
<t>5: GRE-IPv4. This refers to GRE encapsulation with IPv4 as
the delivery protocol as described in RFC2874.</t>
<t>6: GRE-IPv6. This refers to GRE encapsulation with IPv6 as
the delivery protocol as described in RFC2874.</t>
</list></t>
<t>Info Element: This field contains tunnel specific configuration
parameters to enable the WTP to setup the alternate tunnel. This
specification provides details for this elements for CAPWAP and
PMIPv6. We anticipate that message elements for the other
protocols (like L2TPv3, etc) will be defined in other
specifications in the future.</t>
</list></t>
</section>
<section anchor="tunnel-failure"
title=" IEEE 802.11 WTP Alternate Tunnel Failure Indication">
<t>The Alternate Tunnel Failure Indication message element is sent by
the WTP to inform the AC about the status of the Alternate Tunnel. For
the case where WTP establishes data tunnels with multiple ARs (e.g.,
under VNO scenario), the WTP needs to notify the AC of which AR(s) are
unavailable. The message element contains the following fields:<figure
anchor="format3"
title="IEEE 802.11 WTP Alternate Tunnel Failure Indication">
<artwork align="center">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN ID | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure> <list style="symbols">
<t>Type: <IANA-3> for IEEE 802.11 WTP Alternate Tunnel
Failure Indication</t>
<t>Length: == 4</t>
<t>WLAN ID: An 8-bit value specifying the WLAN Identifier. The
value MUST be between one (1) and 16.</t>
<t>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.</t>
<t>Access Router Information Element: IPv4 address or IPv6 address
or Fully Qualified Domain Name (FQDN), of the Access Router for
the alternate tunnel. The Access Router Information Elements allow
the WTP to notify the AC of which AR(s) are unavailable. </t>
</list></t>
</section>
<section anchor="capwap-tunnel" title="CAPWAP based Alternate Tunnel">
<t>If the CAPWAP encapsulation is selected by the AC and configured by
the AC to the WTP, the Info Element field defined in <xref
target="tunnel-config"></xref> should contain the following
information:</t>
<t><list style="symbols">
<t>Access Router Information: IPv4 address or IPv6 address or
Fully Qualified Domain Name (FQDN), of the Access Router for the
alternate tunnel.</t>
<t>Tunnel DTLS Policy: The CAPWAP protocol allows optional
protection of data packets using DTLS. Use of data packet
protection on a WTP is not mandatory but determined by the
associated AC policy (This is consistent with the WTP behavior
described in <xref target="RFC5415"></xref>).</t>
<t>IEEE 802.11 Tagging Mode Policy: It is used to specify how the
CAPWAP data channel packet are to be tagged for QoS purposes (see
<xref target="RFC5416"></xref> for more details).</t>
<t>CAPWAP Transport Protocol: The CAPWAP protocol supports both
UDP and UDP-Lite (see RFC3828). When run over IPv4, UDP is used
for the CAPWAP data channels. When run over IPv6, the CAPWAP data
channel may use either UDP or UDP-lite.</t>
</list> The message element structure for CAPWAP encapsulation is
shown in <xref target="CAPWAP"> </xref>:</t>
<t><figure anchor="CAPWAP"
title="Alternate Tunnel Encapsulation - CAPWAP">
<artwork> 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=0 | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Tunnel DTLS Policy Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. IEEE 802.11 Tagging Mode Policy Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. CAPWAP Transport Protocol Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section anchor="pmipv6-tunnel" title="PMIPv6 based Alternate Tunnel">
<t>Proxy Mobile IPv6 (PMIPv6) (defined in <xref
target="RFC5213"></xref>) can also be used for alternate tunnel
encapsulation between the WTP and the AR. In this scenario, a WTP acts
as the Mobile Access Gateway (MAG) function that manages the
mobility-related signaling for a station that is attached to the WTP
IEEE 802.11 radio access. The Local Mobility Anchor (LMA) function is
at the AR. If PMIPv6 encapsulation is selected by the AC and
configured by the AC to a WTP, the Info Element field defined in <xref
target="tunnel-config"></xref> should contain the following
information:</t>
<t><list style="symbols">
<t>Access Router (acts as LMA) Information: IPv6 address or Fully
Qualified Domain Name (FQDN) for the alternate tunnel
endpoint.</t>
</list> The message element structure for PMIPv6 encapsulation is
shown in <xref target="pmipv6"> </xref>:</t>
<t><figure anchor="pmipv6"
title="Alternate Tunnel Encapsulation - PMIPv6">
<artwork> 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel-Type=4 | Info Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Access Router (LMA) Information Element .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Alternate Tunnel Information Elements">
<t>This section defines the various elements described in <xref
target="capwap-tunnel"></xref> and <xref
target="pmipv6-tunnel"></xref></t>
<section title="Access Router Information Elements">
<t>The Access Router Information Elements allow the AC to notify a
WTP of which AR(s) are available for establishing a data tunnel. The
AR information may be IPv4 address, IPv6 address, or AR domain name.
If a WTP obtains the correct AR FQDN, the Name-to-IP address mapping
is handled in the WTP (see RFC2782).</t>
<t>The following are the Access Router Information Elements defined
in this specification. The AC can use one of them to notify the
destination information of the data tunnel to the WTP. The Elements
containing the AR IPv4 address MUST NOT be used if an IPv6 data
channel such as PMIPv6 or GREv6 is used.</t>
<section title="AR IPv4 List Element">
<t>This Element (see <xref target="capwapv4"> </xref>) is used by
the AC to configure a WTP with the AR IPv4 address available for
the WTP to establish the data tunnel for user traffic.</t>
<t><figure anchor="capwapv4" title="AR IPv4 List Element">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR IPv4 Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-1 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-2 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv4 Address-N .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Length: This refers to the total length in octets of the
element excluding the Type and Length fields.</t>
<t>AR IPv4 Address: IPv4 address of the AR. At least one IPv4
address shall be present. Multiple addresses may be provided for
load balancing or redundancy.</t>
</section>
<section title="AR IPv6 List Element">
<t>This Element (see <xref target="capwapv6"> </xref>) is used by
the AC to configure a WTP with the AR IPv6 address available for
the WTP to establish the data tunnel for user traffic.</t>
<t><figure anchor="capwapv6" title=" AR IPv6 List Element">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR IPv6 Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-1 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-2 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR IPv6 Address-N .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Length: This refers to the total length in octets of the
element excluding the Type and Length fields.</t>
<t>AR IPv6 Address: IPv6 address of the AR. At least one IPv6
address shall be present. Multiple addresses may be provided for
load balancing or redundancy.</t>
</section>
<section title="AR FQDN List Element">
<t>This Element (see <xref target="capwapfqdn"> </xref>) is used
by the AC to configure a WTP with AR FQDN available to establish
the data tunnel for user traffic. Based on the FQDN, a WTP can
acquire the AR IP address via DNS.</t>
<t><figure anchor="capwapfqdn" title="AR FQDN List Element">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AR FQDN Element Type | Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AR FQDN-1 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AR FQDN-2 .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AR FQDN-N .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Element Length: This refers to the total length in octets of
the element excluding the Type and element Length fields.</t>
<t>Length: The length of each AR FQDN.</t>
<t>AR FQDN: An array of variable-length string containing AR FQDN.
This can be used to satisfy load-balance and reliability
requirements.</t>
</section>
</section>
<section anchor = "config-response" title ="IEEE 802.11 WLAN Configuration Response">
<t>
Since AC can configure a WTP with more than one AR available for the WTP to establish the data tunnel(s) for user traffic, it may be useful for the WTP to communicate the selected AR. To enable this, the IEEE 802.11 WLAN Configuration Response may contain the AR list element containing the selected AR.
</t>
</section>
<section title="Tunnel DTLS Policy Element">
<t>The AC distributes its DTLS usage policy for the CAPWAP data
tunnel between a WTP and the AR. There are multiple supported
options, represented by the bit field below as defined in AC
Descriptor message elements. The WTP MUST abide by one of the
options for tunneling user traffic with AR. The Tunnel DTLS Policy
Element obey the definition in <xref target="RFC5415"></xref>. If
there are more than one ARs information provided by the AC for
reliability reasons, the same Tunnel DTLS Policy (see <xref
target="dtls"></xref>) is generally applied for all tunnels
associated with the ARs. Otherwise, Tunnel DTLS Policy MUST be
bonding together with each of the ARs, then WTP will enforce the
independent tunnel DTLS policy for each tunnel with a specific
AR.</t>
<t><figure anchor="dtls" title="Tunnel DTLS Policy Element">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tunnel DTLS Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|D|C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. AR Information (optional) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Reserved: A set of reserved bits for future use. All
implementations complying with this protocol MUST set to zero any
bits that are reserved in the version of the protocol supported by
that implementation. Receivers MUST ignore all bits not defined for
the version of the protocol they support.</t>
<t>A: If A bit is set, there is an AR information associated with
the DTLS policy. There may be an array of pairs binding DTLS policy
information and AR information contained in the Tunnel DTLS Policy
Element. Otherwise, the same Tunnel DTLS Policy (see <xref
target="dtls"></xref>) is generally applied for all tunnels
associated with the ARs configured by the AC.</t>
<t>D: DTLS-Enabled Data Channel Supported (see <xref
target="RFC5415"></xref>).</t>
<t>C: Clear Text Data Channel Supported (see <xref
target="RFC5415"></xref>).</t>
<t>R: A reserved bit for future use abide (see <xref
target="RFC5415"></xref>).</t>
</section>
<section title="IEEE 802.11 Tagging Mode Policy Element">
<t>In 802.11 networks, IEEE 802.11 Tagging Mode Policy Element is
used to specify how the WTP apply the QoS tagging policy when
receiving the packets from stations on a particular radio. When the
WTP sends out the packet to data channel to the AR(s), the packets
have to be tagged for QoS purposes (see <xref
target="RFC5416"></xref>).</t>
<t>The IEEE 802.11 Tagging Mode Policy abides the IEEE 802.11 WTP
Quality of Service defined in Section 6.22 of <xref
target="RFC5416"></xref>.</t>
</section>
<section title="CAPWAP Transport Protocol Element">
<t>The CAPWAP data tunnel supports both UDP and UDP-Lite (see
RFC3828). When run over IPv4, UDP is used for the CAPWAP data
channels. When run over IPv6, the CAPWAP data channel may use either
UDP or UDP-lite. The AC specifies and configure the WTP for which
transport protocol is to be used for the CAPWAP data tunnel.</t>
<t>The CAPWAP Transport Protocol Element abides the definition in
Section 4.6.14 of <xref target="RFC5415"></xref>.</t>
<t><figure anchor="format13"
title="CAPWAP Transport Protocol Element">
<artwork align="center"> 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=51 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>Type: 51 for CAPWAP Transport Protocol <xref
target="RFC5415"></xref>.</t>
<t>Length: 1</t>
<t>Transport: The transport to use for the CAPWAP Data channel. The
following enumerated values are supported:</t>
<t>1 - UDP-Lite: The UDP-Lite transport protocol is to be used for
the CAPWAP Data channel. Note that this option MUST NOT be used if
the CAPWAP Control channel is being used over IPv4 and AR address is
IPv4 contained in the AR Information Element.</t>
<t>2 - UDP: The UDP transport protocol is to be used for the CAPWAP
Data channel.</t>
</section>
<section title="GRE Key Element">
<t>If a WTP receives the GRE Key Element in the Alternate Tunnel
Encapsulation message element for GREv4 or GREv6 selection, the WTP
must insert the GRE Key to the encapsulation packet (see <xref
target="RFC2890"></xref>). An AR acting as decapsulating tunnel
endpoint identifies packets belonging to a traffic flow based on the
Key value.</t>
<t>The GRE Key Element field contains a four octet number defined in
<xref target="RFC2890"></xref>.</t>
<t><figure anchor="format14" title="GRE Key Element">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Element Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>GRE Key: The Key field contains a four octet number which is
inserted by the WTP according to <xref target="RFC2890"></xref>.</t>
</section>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document requires the following IANA considerations. <list
style="symbols">
<t><IANA-1>. This specification defines the Supported
Alternate Tunnel Encapsulations Type message element in <xref
target="tunnel-support"></xref>. This elements needs to be
registered in the existing CAPWAP Message Element Type registry,
defined in <xref target="RFC5415"></xref>. The Type value for this
element needs to be between 1 and 1023 (see Section 15.7 in <xref
target="RFC5415"></xref>).</t>
<t><IANA-2>. This specification defines the Alternate Tunnel
Encapsulations Type message element in <xref
target="tunnel-config"></xref>. This element needs to be registered
in the existing CAPWAP Message Element Type registry, defined in
<xref target="RFC5415"></xref>. The Type value for this element
needs to be between 1 and 1023.</t>
<t><IANA-3>. This specification defines the IEEE 802.11 WTP
Alternate Tunnel Failure Indication message element in <xref
target="tunnel-failure"></xref>. This element needs to be registered
in the existing CAPWAP Message Element Type registry, defined in
<xref target="RFC5415"></xref>. The Type value for this element
needs to be between 1024 and 2047.</t>
<t>Tunnel-Type: This specification defines the Alternate Tunnel
Encapsulations Type message element. This element contains a field
Tunnel-Type. The namespace for the field is 16 bits (0-65535)). This
specification defines values, zero (0) through six (6) and can be
found in <xref target="tunnel-config"></xref>. Future allocations of
values in this name space are to be assigned by IANA using the
"Specification Required" policy. IANA needs to create a registry
called CAPWAP Alternate Tunnel-Types. The registry format is given
below.
</t>
<t> AR IPv4 Element Type: AR IPv4 List Element (see Figure 11) is used by the AC to configure a WTP with the AR IPv4 address available for the WTP to establish the data tunnel for user traffic.
</t>
<t> AR IPv6 Element Type: AR IPv6 List Element (see Figure 12) is used by the AC to configure a WTP with the AR IPv6 address available for the WTP to establish the data tunnel for user traffic.
</t>
<t> AR FQDN Element Type: AR FQDN Element (see Figure 13) is used by the AC to configure a WTP with AR FQDN available to establish the data tunnel for user traffic.
</t>
<t> Tunnel DTLS Element Type: The Tunnel DTLS Policy Element obey the definition in [RFC5415].
</t>
<t> GRE Key Element Type: If a WTP receives the GRE Key Element in the Alternate Tunnel Encapsulation message element for GREv4 or GREv6 selection, the WTP must insert the GRE Key to the encapsulation packet
<figure>
<artwork>
Tunnel-Type Type Value Reference
CAPWAP 0 [RFC5415],[RFC5416]
L2TP 1 [RFC2661]
L2TPv3 2 [RFC3931]
IP-IP 3 [RFC2003]
PMIPv6 4 [RFC5213]
GRE-IPv4 5 [RFC2784]
GRE-IPv6 6 [RFC2784]
</artwork>
</figure></t>
</list>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces three new CAPWAP WTP message elements. These
elements are transported within CAPWAP Control messages as the existing
message elements. Therefore, this document does not introduce any new
security risks compared to <xref target="RFC5415"></xref> and <xref
target="RFC5416"></xref>. In CAPWAP, security for CAPWAP Data Channel is
optional and security policy is determined by AC. Similarly, the AC
determines the security for the Alternate Tunnel between WTP and
Alternate Tunnel Encapsulation Gateway. The security considerations
described in <xref target="RFC5415"></xref> and <xref
target="RFC5416"></xref> apply here as well.</t>
</section>
<section title="Contributors">
<t>This document stems from the joint work of Hong Liu, Yifan Chen,
Chunju Shao from China Mobile Research. The authors would like to thank
Zongpeng Du and Jin Li for their valuable comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2003.xml'?>
<?rfc include='reference.RFC.2890.xml'?>
<?rfc include='reference.RFC.2661.xml'?>
<?rfc include='reference.RFC.2784.xml'?>
<?rfc include='reference.RFC.3828.xml'?>
<?rfc include='reference.RFC.3931.xml'?>
<?rfc include='reference.RFC.5415.xml'?>
<?rfc include='reference.RFC.5416.xml'?>
<?rfc include='reference.RFC.5213.xml'?>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include='reference.RFC.2119.xml'?>
>
<!-- A reference written by by an organization not a person. -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:10:57 |